jbvc/django-tdd
Django testing strategies with pytest-django, TDD methodology, factory_boy, mocking, coverage, and testing Django REST Framework APIs.
59
59%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Advisory
Suggest reviewing before use
Quality
Discovery
47%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 effectively lists relevant technologies and keywords that Django developers would naturally use, making it discoverable. However, it reads as a topic list rather than a capability description—it lacks concrete actions (what it actually does) and completely omits trigger guidance (when to use it). Adding explicit actions and a 'Use when...' clause would significantly improve its effectiveness.
Suggestions
Add a 'Use when...' clause such as 'Use when the user asks about writing Django tests, setting up test infrastructure, achieving test coverage, or testing DRF endpoints.'
Replace the topic list with concrete actions, e.g., 'Writes and structures Django test suites using pytest-django, creates test factories with factory_boy, mocks external dependencies, measures code coverage, and tests Django REST Framework API endpoints.'
Add boundary clarification to reduce overlap, e.g., distinguish from general Python testing or Django development skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Django testing) and lists several tools/concepts (pytest-django, TDD, factory_boy, mocking, coverage, DRF API testing), but doesn't describe concrete actions like 'write test cases', 'generate fixtures', or 'measure code coverage'. It reads more like a topic list than a capability description. | 2 / 3 |
Completeness | Describes 'what' at a high level (Django testing strategies with various tools) but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. Per rubric guidelines, missing 'Use when' caps completeness at 2, and the 'what' is also weak (topic listing rather than actions), warranting a 1. | 1 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'Django testing', 'pytest-django', 'TDD', 'factory_boy', 'mocking', 'coverage', 'Django REST Framework', 'APIs'. These are terms developers naturally use when seeking help with Django testing. | 3 / 3 |
Distinctiveness Conflict Risk | The combination of Django-specific testing tools (pytest-django, factory_boy, DRF) creates reasonable distinctiveness, but it could overlap with general Python testing skills or general Django development skills. The lack of explicit boundaries increases conflict risk. | 2 / 3 |
Total | 8 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides comprehensive, executable Django testing examples covering models, views, serializers, APIs, mocking, and integration tests. However, it is far too verbose for a skill file—it reads like a full tutorial rather than a concise reference, explaining many concepts Claude already knows. The monolithic structure with no progressive disclosure makes it a poor fit for the context window budget.
Suggestions
Reduce content by 60-70%: remove generic testing advice (DO/DON'T lists, 'Remember: Tests are documentation'), trivial docstrings, and explanations of concepts Claude already knows. Keep only project-specific patterns and configurations.
Split into multiple files: keep SKILL.md as a concise overview (~50-80 lines) with quick-start examples, then reference separate files like FACTORIES.md, API_TESTING.md, and MOCKING.md for detailed examples.
Add a clear workflow section with validation steps: e.g., 'Write test → Run pytest → If red, implement → Run pytest → If green, refactor → Run coverage → Verify targets met'.
Remove the coverage goals table and best practices lists—these are generic advice that doesn't add actionable value for Claude.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~500+ lines. Explains basic concepts Claude already knows (what TDD is, what factories are, basic pytest usage). The DO/DON'T lists are generic testing advice Claude doesn't need. Docstrings like '"""Factory for User model."""' and '"""Test User model."""' add zero value. Much of this is a Django testing tutorial rather than a concise skill reference. | 1 / 3 |
Actionability | All code examples are concrete, executable, and copy-paste ready. Includes complete pytest.ini configuration, test settings, conftest.py fixtures, factory definitions, and full test examples for models, views, serializers, and API endpoints. Commands like 'pytest --cov=apps --cov-report=html' are specific and runnable. | 3 / 3 |
Workflow Clarity | The TDD Red-Green-Refactor cycle is mentioned but only superficially demonstrated. The integration test shows a clear multi-step flow. However, there are no validation checkpoints or feedback loops for the overall testing workflow (e.g., what to do when tests fail, how to debug, when to run coverage). The skill reads more as a reference catalog than a guided workflow. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of text with no references to external files. All content—setup, factories, model tests, view tests, API tests, mocking, integration tests, best practices, coverage—is inlined in a single massive document. This would benefit enormously from splitting into separate files (e.g., FACTORIES.md, API_TESTING.md, MOCKING.md) with a concise overview in the main skill. | 1 / 3 |
Total | 7 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (729 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
Reviewed
Table of Contents