django-tdd

Django 测试策略，包括 pytest-django、TDD 方法、factory_boy、模拟、覆盖率以及测试 Django REST Framework API。

1.28x

Quality

62%

Does it follow best practices?

Impact

96%

1.28x

Average score across 3 eval scenarios

Securityby

Advisory

Suggest reviewing before use

Optimize this skill with Tessl

npx tessl skill review --optimize ./docs/zh-CN/skills/django-tdd/SKILL.md

Quality

Discovery

82%

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

This description excels at specificity and distinctiveness by naming concrete tools and methodologies (pytest-django, factory_boy, TDD, DRF API testing). Its main weakness is the absence of an explicit 'Use when...' clause, which would help Claude know exactly when to select this skill. Adding trigger guidance would elevate this from a good to excellent description.

Suggestions

Add an explicit 'Use when...' clause, e.g., 'Use when the user asks about writing Django tests, setting up pytest-django, creating test factories, mocking in Django, or testing DRF endpoints.'

Consider adding file extension or pattern triggers like 'tests.py', 'conftest.py', or 'test_*.py' to help with file-based skill selection.

Dimension	Reasoning	Score
Specificity	Lists multiple specific concrete actions and tools: pytest-django, TDD methodology, factory_boy, mocking, coverage, and testing Django REST Framework APIs. These are concrete, identifiable capabilities.	3 / 3
Completeness	Clearly answers 'what does this do' (Django testing strategies with specific tools), but lacks an explicit 'Use when...' clause or equivalent trigger guidance. Per rubric guidelines, missing 'Use when' caps completeness at 2.	2 / 3
Trigger Term Quality	Includes strong natural keywords users would say: 'Django', 'pytest-django', 'TDD', 'factory_boy', 'mock/模拟', 'coverage/覆盖率', 'Django REST Framework', 'API', '测试' (test). These cover the major terms a user working with Django testing would naturally use.	3 / 3
Distinctiveness Conflict Risk	Highly specific to Django testing with named tools (pytest-django, factory_boy, DRF). This is a clear niche that would not easily conflict with general Python testing, general Django development, or other framework skills.	3 / 3
	Total	11 / 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.

This skill is highly actionable with excellent, executable code examples covering the full Django testing stack. However, it is severely bloated—much of the content is boilerplate that Claude can generate on its own, and generic best practices lists add little value. The monolithic structure with no progressive disclosure makes it an inefficient use of context window tokens.

Suggestions

Reduce content by 60-70%: remove generic best practices lists, basic concept explanations (TDD cycle, what factories are), and the quick reference table for standard pytest markers that Claude already knows.

Split into multiple files: keep SKILL.md as a concise overview (~50-80 lines) with key patterns and references to separate files like FACTORIES.md, API_TESTING.md, and CONFTEST_EXAMPLE.md.

Add explicit validation checkpoints to the TDD workflow: e.g., 'Run pytest after each RED step to confirm failure, then after GREEN to confirm pass, check coverage delta after REFACTOR.'

Remove or drastically shorten the coverage targets table and settings boilerplate—these are project-specific configurations that Claude can generate when needed.

Dimension	Reasoning	Score
Conciseness	Extremely verbose at ~500+ lines. Explains basic concepts Claude already knows (TDD red-green-refactor, what factories are, what mocking is). The best practices 'do/don't' lists are generic advice Claude doesn't need. Coverage target tables, quick reference tables for basic pytest markers, and extensive boilerplate code all waste tokens. Much of this could be condensed to 1/4 the size.	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` are specific and runnable.	3 / 3
Workflow Clarity	The TDD red-green-refactor cycle is mentioned but the 'GREEN' and 'REFACTOR' steps are just comments rather than concrete guidance. The integration test shows a clear multi-step flow, but there are no explicit validation checkpoints or error recovery steps for the overall testing workflow (e.g., what to do when tests fail, how to debug, when to re-run).	2 / 3
Progressive Disclosure	Monolithic wall of text with no references to external files. All content—configuration, factories, model tests, view tests, API tests, mocking, integration tests, best practices, coverage—is inlined in a single massive document. No bundle files exist to offload detailed examples, and the content would greatly benefit from splitting into separate reference files.	1 / 3
	Total	7 / 12 Passed

Validation

81%

Warnings & errors only

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

Validation — 9 / 11 Passed

Validation for skill structure

Criteria	Description	Result
skill_md_line_count	SKILL.md is long (730 lines); consider splitting into references/ and linking	Warning
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	9 / 11 Passed

Repository: affaan-m/everything-claude-code
Commit: 64cd1ba

Reviewed: about 12 hours ago

Table of Contents

Discovery Implementation Validation

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.