CtrlK
BlogDocsLog inGet started
Tessl Logo

dmr

Write the best DMR code possible with all the recommended best practices, avoiding common mistakes.

43

Quality

44%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./.agents/skills/dmr/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

56%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is an exceptionally concrete, well-organized catalog of do/don't rules with executable wrong→correct code pairs and per-rule caveats and docs links. Its weaknesses are structural and economical: nearly 1600 lines of heavily duplicated code boilerplate inlined in a single file, where topic-specific reference files and trimmed examples would cut token cost dramatically without losing guidance value.

Suggestions

Split topic clusters (routing, error handling, testing, configuration) into references/ files with one-line summaries in SKILL.md, e.g. "**Routing**: see [references/routing.md](references/routing.md) — dmr.routing.path, 404/500 handlers".

Strip repeated import headers from code blocks and show only the differing lines between wrong/correct pairs — many rules differ by 2-3 lines but repeat ~20 lines of identical context.

Fix the incidental bugs in "Wrong" snippets (undefined `exc` in the endpoint error-handling example, `dmr_rf` in the plain RequestFactory example) and add a minimal schemathesis usage example so every rule's guidance is executable.

DimensionReasoningScore

Conciseness

The 1570-line body pads heavily: 59 code blocks each repeat full import headers (HTTPStatus, msgspec, Controller, MsgspecSerializer re-imported dozens of times), and every rule carries a near-complete "Wrong" twin of the "Correct" example where a 2-3 line diff would convey the same. This is noticeably verbose with many padded sections (anchor 2); it avoids anchor 1 because there is no explanation of concepts Claude already knows, and it falls short of anchor 3's "mostly efficient" given the sheer volume of duplicated boilerplate.

2 / 5

Actionability

Nearly every rule gives copy-paste-ready wrong/correct Python pairs with docs links (e.g. the `@validate`→`@modify` rewrite, the `RedirectTo` open-redirect fix, the `RemoteAddr(runs_before_auth=...)` throttling diff), which is close to anchor 5. Minor gaps hold it at anchor 4: the schemathesis section offers no executable code ("Correct: use `schemathesis`. Check its official docs"), and two "Wrong" snippets contain unrelated bugs (undefined `exc` in the endpoint-body-handling example; `dmr_rf` used in the plain `RequestFactory` example), which muddies the contrast.

4 / 5

Workflow Clarity

This is a best-practice catalog rather than a multi-step pipeline, and its sections progress through an application's concerns in a sensible build order (Installing → Controllers → Redirects → Routing → Error handling → Validation → Auth → Throttling → Testing → Middleware → Configuration → Structure → OpenAPI), each rule stating an unambiguous do/don't with explicit "Limitations" caveats. It sits at anchor 4 (clear, minor gaps) rather than 5 because no section gives validation/verification checkpoints for the riskier flows it touches (e.g. nothing says how to verify a schema after disabling response validation in production), and it stays above anchor 3 since no listed practice is ambiguous.

4 / 5

Progressive Disclosure

There are no bundle files at all: all ~25 rules across 14 topic areas live inline in one 1570-line SKILL.md, and the body's only pointers are external docs URLs. Structure exists (clean topic headers, per-rule headings, "Limitations" callouts), but large self-contained topic clusters (routing, testing, error handling) clearly belong in separate reference files — matching anchor 3 ("content that should be separate is inline") rather than anchor 2, since headers and navigation are present, and short of anchor 4, which expects most bulk content moved out with well-signaled references.

3 / 5

Total

13

/

20

Passed

Description

32%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description identifies its niche (DMR / django-modern-rest) but says almost nothing concrete: no specific capabilities, no natural trigger terms beyond the bare abbreviation, and no 'use when' guidance. It reads as aspiration ("the best DMR code possible") rather than a description of what the skill contains or when to invoke it.

Suggestions

State concrete capabilities instead of aspirations, e.g. "Reviews and writes django-modern-rest (DMR) controllers, routing, error handling, throttling, and test code following framework best practices."

Add an explicit trigger clause: "Use when writing or reviewing code that imports dmr / django-modern-rest, or when the user mentions DMR controllers, DMR routing, or Django REST APIs built with django-modern-rest."

Spell out the framework name at least once ("django-modern-rest (DMR)") so users who say the full name or "Django REST API" naturally match the skill.

DimensionReasoningScore

Specificity

The description names the domain ("DMR code") but the actions are entirely generic — "write the best code possible", "all the recommended best practices", "avoiding common mistakes" name no concrete capability (controllers, routing, error handling, testing, etc.). It matches anchor 2 ("Names the domain but actions are minimal or generic"); it does not reach anchor 3 because no specific action is listed, and it is above anchor 1 only because the DMR domain is named.

2 / 5

Completeness

The 'what' is vague ("best DMR code", "best practices", "common mistakes" say little about actual output) and the 'when' is completely absent — no "Use when..." or equivalent trigger guidance, which caps completeness at 3 per the guidelines, and the vague 'what' pushes it to anchor 2. It is above anchor 1 because a recognizable intent (write DMR code correctly) is present.

2 / 5

Trigger Term Quality

The only keyword is the abbreviation "DMR" — the full names "django-modern-rest", "Django", "REST", "API", or "controller" never appear, so a user saying "django REST API" or "django-modern-rest" would not naturally match. This is one minimal, jargon-only keyword, matching anchor 2 ("One or two generic keywords; missing the natural phrases users say") rather than anchor 3, which requires genuinely relevant keyword coverage.

2 / 5

Distinctiveness Conflict Risk

"DMR code" is a narrow niche that would rarely fire for unrelated skills — mostly distinct with only minor overlap risk against general Django/REST skills (anchor 4). It falls short of anchor 5 because there are no explicit distinct trigger phrases, and the unexpanded abbreviation "DMR" could collide with other meanings of that acronym.

4 / 5

Total

10

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (1571 lines); consider splitting into references/ and linking

Warning

Total

15

/

16

Passed

Repository
wemake-services/django-modern-rest
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.