Conciseness

Dense with non-obvious, high-value facts (config files 'are never merged - the first match wins', strict mode catching '@pytest.mark.skipp' typos, keyword-only parametrize since pytest 9.2) with no basic-concept padding. Minor over-explanation remains (the Overview's de-facto-framework framing, inline changelog quotations, the '2025-11-05' date), though legacy-version guidance is well quarantined in a comparison table plus an 'On pytest 8 or older' note.

Actionability

Every step ships copy-paste-ready, executable material - install commands, a working first test, a complete pytest 9 TOML config, fixture/parametrize/marker/mocker code, coverage commands with a gate, and CI yaml - and the authoring conventions give a concrete detection procedure (check named config files, grep for 'unittest.TestCase' subclasses, stop and ask on conflicting signals).

Workflow Clarity

Steps 1-11 are cleanly sequenced (install, first test, config, fixtures, parametrize, markers, mocking, coverage, CI, subtests, fast-feedback flags) and verification checkpoints exist - check the 'configfile:' line in the run header, '--cov-fail-under' gates, strict markers reject typos - but they are distributed rather than a systematic validate-fix-retry loop. Testing is not a destructive or batch operation, so the workflow-cap-3 rule does not apply.

Progressive Disclosure

Two real one-level-deep references (references/unittest.md, references/doctest.md) are clearly signaled at the decision point ('Match an existing unittest convention ... -> references/unittest.md') and again in the References section with descriptions; the alternative-framework bulk is correctly offloaded while the core pytest workflow stays inline, making navigation easy.

Specificity

Enumerates a dozen concrete capabilities ('pytest fixtures and conftest.py, parametrize, mocking, markers, slow or untrusted suites, coverage gates and CI', 'pytest 9 config and strict mode, subtests, and a checklist for edge cases and weak assertions'), but they are topic nouns rather than the verb-led actions of the top anchor, and the broad opener 'any question or task about Python tests' dilutes specificity slightly.

Completeness

Explicitly answers both parts: 'what' via the enumerated capability list ('pytest fixtures and conftest.py, parametrize, mocking, markers ... coverage gates and CI') and 'when' via the concrete trigger clause 'Use for any question or task about Python tests, including quick how-to questions and tests for one function'.

Trigger Term Quality

Good natural-keyword coverage ('Python tests', 'pytest', 'fixtures', 'parametrize', 'mocking', 'coverage', 'CI') that users would actually say, but misses common variations like 'unit test' (the skill's own name) and 'unittest' (a framework the skill covers via its reference file).

Distinctiveness Conflict Risk

Clearly niched to Python testing with pytest-specific triggers, but 'any question or task about Python tests' would also match async testing, test-data generation, and property-based testing, which the body defers to sibling skills - minor overlap with closely related skills.