CtrlK
BlogDocsLog inGet started
Tessl Logo

django-tdd

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

73

1.28x
Quality

62%

Does it follow best practices?

Impact

96%

1.28x

Average score across 3 eval scenarios

SecuritybySnyk

Advisory

Suggest reviewing before use

Optimize this skill with Tessl

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

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 trigger term coverage, listing concrete tools and methodologies that Django developers would naturally reference. Its main weakness is the absence of an explicit 'Use when...' clause, which would help Claude know precisely when to select this skill over others. The description is written in appropriate third-person style and covers a clear, distinctive niche.

Suggestions

Add an explicit 'Use when...' clause, e.g., 'Use when the user asks about writing tests for Django applications, setting up test infrastructure, or improving test coverage in Django/DRF projects.'

DimensionReasoningScore

Specificity

Lists multiple specific concrete tools and actions: 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 developer would use when seeking Django testing help.

3 / 3

Distinctiveness Conflict Risk

Highly distinctive niche: Django-specific testing with named tools (pytest-django, factory_boy, DRF). Unlikely to conflict with general Python testing skills or general Django development skills due to the specific combination of testing tools mentioned.

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 provides highly actionable, executable code examples covering the full Django testing stack, which is its primary strength. However, it is severely over-verbose — most of the content represents standard patterns that Claude already knows, and the entire document is a monolithic block with no progressive disclosure. The TDD workflow is mentioned but not deeply demonstrated with validation checkpoints.

Suggestions

Reduce the content to ~100 lines focusing on project-specific conventions, non-obvious patterns, and key configuration decisions — remove standard factory_boy, pytest, and DRF test patterns that Claude already knows.

Split detailed examples (factory definitions, API test patterns, mocking examples) into separate referenced files like FACTORIES.md, API_TESTS.md, MOCKING.md with clear one-level-deep links from the main skill.

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, then after REFACTOR to confirm no regression.'

Remove the best practices do/don't lists — these are general testing knowledge that Claude already possesses and add no project-specific value.

DimensionReasoningScore

Conciseness

The skill is extremely verbose at ~500+ lines, with extensive boilerplate code that Claude already knows how to write. It explains basic concepts like TDD red-green-refactor, includes full factory definitions, complete conftest.py files, and exhaustive test examples that are largely standard patterns. The best practices section restates common knowledge. Much of this could be condensed to key patterns and project-specific conventions.

1 / 3

Actionability

The content provides fully executable, copy-paste ready code examples throughout — from pytest.ini configuration to complete test classes, factory definitions, API tests, and mocking patterns. Every section includes concrete, runnable Python code with specific imports and assertions.

3 / 3

Workflow Clarity

The TDD red-green-refactor cycle is mentioned but only superficially demonstrated with comments rather than a real worked example. 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 run coverage).

2 / 3

Progressive Disclosure

The entire skill is a 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, and coverage — is inlined in a single document. This would benefit greatly from splitting into separate reference files for each major section.

1 / 3

Total

7

/

12

Passed

Validation

81%

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

Validation9 / 11 Passed

Validation for skill structure

CriteriaDescriptionResult

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