The description excels at naming specific, concrete capabilities and includes excellent trigger terms that developers would naturally use. However, it critically lacks any 'Use when...' clause or explicit trigger guidance, which significantly hurts its completeness score and could make it harder for Claude to know exactly when to select this skill over others.

Suggestions

Add a 'Use when...' clause such as 'Use when the user asks about writing tests, test-driven development, pytest configuration, test fixtures, mocking dependencies, or improving test coverage in Python projects.'

Consider adding file extension triggers like '.py test files', 'conftest.py', or 'pytest.ini' to help Claude match on project artifacts.

Dimension	Reasoning	Score
Specificity	Lists multiple specific concrete actions/concepts: pytest, TDD methodology, fixtures, mocking, parametrization, and coverage requirements. These are all distinct, concrete testing capabilities.	3 / 3
Completeness	The description answers 'what' well but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. Per the rubric, a missing 'Use when...' clause should cap completeness at 2, and since the 'when' is entirely absent (not even implied beyond the topic itself), this scores a 1.	1 / 3
Trigger Term Quality	Includes strong natural keywords users would say: 'pytest', 'TDD', 'fixtures', 'mocking', 'parametrization', 'coverage', 'testing'. These are terms developers naturally use when seeking help with Python testing.	3 / 3
Distinctiveness Conflict Risk	The combination of Python, pytest, TDD, fixtures, mocking, and parametrization creates a very clear niche. It is unlikely to conflict with other skills since it targets a specific testing framework and methodology.	3 / 3
	Total	10 / 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 reads as a comprehensive pytest tutorial/reference manual rather than a focused skill document. While the code examples are excellent and fully executable, the document is far too verbose, explaining many concepts Claude already knows (basic assertions, simple test structure, how to run pytest). The lack of progressive disclosure means everything is crammed into one massive file with no external references, making it an inefficient use of context window tokens.

Suggestions

Cut the document to ~100 lines focusing only on project-specific conventions (TDD workflow, coverage requirements, directory structure, DO/DON'T rules) and move reference material (assertions, mocking patterns, parametrization examples, configuration) to separate linked files like PATTERNS.md and CONFIG.md.

Remove sections that explain basic pytest knowledge Claude already has: the 'Basic Test Structure' section, the full assertions catalog, and the 'Running Tests' command list are all standard pytest documentation.

Add validation checkpoints to the TDD workflow, such as 'Run pytest --cov after GREEN step to verify coverage target is met' and 'If coverage drops below 80%, identify untested paths before proceeding to REFACTOR.'

Replace the quick reference table and verbose running tests section with a brief link to pytest documentation, keeping only project-specific configuration choices.

Dimension	Reasoning	Score
Conciseness	Extremely verbose at ~500+ lines. Explains basic pytest concepts Claude already knows (assertions, basic test structure, how to run pytest). The assertions section alone lists trivial patterns like `assert result == expected` and `assert item in collection`. The 'Basic Test Structure' section with `test_addition` testing `2 + 2 == 4` adds no value. Much of this is essentially a pytest tutorial/reference manual rather than a skill adding novel knowledge.	1 / 3
Actionability	All code examples are concrete, executable, and copy-paste ready. Covers fixtures, mocking, parametrization, async testing, and configuration with complete, runnable examples. Commands for running tests are specific and correct.	3 / 3
Workflow Clarity	The TDD cycle (red-green-refactor) is clearly sequenced, but there are no validation checkpoints or feedback loops. For example, there's no guidance on what to do when coverage drops below 80%, no verification step after writing tests, and no error recovery patterns for common testing failures.	2 / 3
Progressive Disclosure	This is a monolithic wall of text with no references to external files. Everything from basic assertions to async testing to configuration is inlined in a single massive document. Content like the full assertions reference, pytest configuration options, and the running tests command reference should be split into separate files with clear navigation links.	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 (817 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

Reviewed

4 days ago

Table of Contents

Discovery Implementation Validation