CtrlK
BlogDocsLog inGet started
Tessl Logo

django-tdd

Django testing strategies with pytest-django, TDD methodology, factory_boy, mocking, coverage, and testing Django REST Framework APIs.

70

1.24x
Quality

56%

Does it follow best practices?

Impact

98%

1.24x

Average score across 3 eval scenarios

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./docs/ja-JP/skills/django-tdd/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

46%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 a well-sectioned but oversized monolith: highly concrete and executable example code, undermined by severe verbosity and zero use of progressive disclosure. Its nominal TDD workflow is nominal in name only, with the green/refactor steps left as comment stubs and no validation checkpoints anywhere.

Suggestions

Split the body into one-level-deep reference files (e.g. references/factories.md, references/api-testing.md, references/mocking.md) and keep SKILL.md as a concise overview with clearly signaled links.

Cut the body to the distinctive guidance — test settings, conftest fixture patterns, factory conventions — and drop generic test-suite examples Claude can generate itself.

Make the Red-Green-Refactor cycle an actual sequenced workflow with explicit checkpoints (write failing test → run pytest to confirm RED → implement → re-run to confirm GREEN → refactor with tests passing), including a validate-and-retry loop.

DimensionReasoningScore

Conciseness

The ~700-line body reproduces standard pytest-django test-suite boilerplate for a hypothetical products app (model, view, serializer, viewset, mocking, integration sections) — patterns Claude already knows and could generate unprompted. This matches 'noticeably verbose; several unnecessary... padded sections'; it is not a 1 because there is no conceptual prose padding (no 'what is Django' explanations), only excess example volume.

2 / 5

Actionability

Guidance is mostly executable: complete pytest.ini, test settings, conftest fixtures, factory definitions, and copy-paste-style test classes with concrete asserts. Minor gaps keep it from 5: examples depend on undefined fixtures ('category', 'product', 'order', 'TagFactory'), 'patch' is unimported in test_integration.py, and everything references a nonexistent 'apps.products' app.

4 / 5

Workflow Clarity

The Red-Green-Refactor cycle is presented as the workflow, but the GREEN and REFACTOR steps are literal comment stubs ('# GREEN - テストを通す'), and the rest of the document is topic-organized rather than sequenced, with no validation checkpoints or run-the-tests feedback loops. This fits the 3 anchor ('sequence present but checkpoints missing'); not 4, which requires most checkpoints to be explicit.

3 / 5

Progressive Disclosure

No references/, scripts/, or assets/ directories exist; the entire body is one monolithic inline document where large blocks (factory reference, full API test suites, coverage tables) clearly belong in separate one-level-deep reference files. This matches the 2 anchor ('content that clearly belongs in separate files is inlined') — not 1 because section headers do provide navigable structure.

2 / 5

Total

11

/

20

Passed

Description

66%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.

A specific, well-scoped description with strong natural trigger keywords and a clear niche. Its main weakness is the complete absence of a 'when to use' clause, which both caps completeness and leaves triggering to keyword luck alone.

Suggestions

Add an explicit trigger clause, e.g. 'Use when implementing or testing Django applications, Django REST Framework APIs, or setting up pytest-django test infrastructure.'

Convert tool/topic nouns into concrete actions to reach top-level specificity, e.g. 'Set up pytest-django, build factory_boy fixtures, mock external services, and test DRF serializers and viewsets.'

Include one or two common user phrasings such as 'write tests' or 'test coverage' to broaden natural trigger coverage.

DimensionReasoningScore

Specificity

The description lists several concrete capabilities — 'pytest-django, TDD methodology, factory_boy, mocking, coverage, and testing Django REST Framework APIs' — matching the 'several specific actions; minor gaps' anchor. It falls short of 5 because most items are tool/topic nouns ('factory_boy', 'coverage') rather than the concrete action verbs ('Extract text... fill forms... merge documents') the top anchor exemplifies.

4 / 5

Completeness

The 'what' is clear (Django testing strategies with the listed tools), but there is no 'Use when...' clause or any equivalent explicit trigger guidance, which caps completeness at 3 per the judging guidelines. It fits the 3 anchor ('clear what but when missing') exactly — not 4, which requires an explicit if imperfect 'when'.

3 / 5

Trigger Term Quality

Good natural keyword coverage — users asking for help would say 'Django', 'pytest', 'factory_boy', 'mock', 'coverage', 'DRF API' — fitting the 'good keyword coverage; a few natural terms missing' anchor. Not 5: common phrasings like 'write tests', 'unit tests', or 'test suite' are absent; not 3 because the terms present are the natural ones, not jargon-only.

4 / 5

Distinctiveness Conflict Risk

The pytest-django/factory_boy/DRF combination carves out a clear niche distinct from generic skills, matching 'mostly distinct; minor overlap risk' — a broader pytest or Python-testing skill could still plausibly overlap. Not 5 because nothing explicitly distinguishes it from a general pytest skill or a Django-development skill.

4 / 5

Total

15

/

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 (729 lines); consider splitting into references/ and linking

Warning

Total

15

/

16

Passed

Repository
affaan-m/ECC
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.