Content
75%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
A well-structured, highly actionable reference: executable code and commands at every step, current version-specific pytest 9 guidance, a valuable anti-patterns table, and clean one-level-deep bundle references. The main costs are token weight — a 340-line body where the basics-oriented sections (first test, skip/xfail, CLI flags) compete with the genuinely non-obvious material — and the absence of an explicit validate-the-new-test feedback loop.
Suggestions
Trim or collapse the sections teaching basics Claude already knows — Step 2's trivial sum example, Step 6's skip/skipif/xfail boilerplate, and Step 11's `-lf`/`-ff`/`-x`/`-k`/`-s` flag list — into a one-line mention or move them to a reference file, keeping the body focused on the non-obvious pytest 9 material (config precedence, strict mode, subtests, 9.2 parametrize change).
Add an explicit validation checkpoint to the authoring workflow: after writing a test, run it (`pytest tests/test_<module>.py`) and confirm it passes for the expected reason (and ideally fails when the assertion is inverted), before declaring the task done.
Move the fast-feedback flags and marker basics into references/ (e.g., alongside unittest.md/doctest.md) so SKILL.md acts as a lean overview with well-signaled one-level-deep references.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The high-value non-obvious material (pytest 9 `[tool.pytest]` config and precedence rules, `strict = true`, subtests, 9.2 keyword-only parametrize, the anti-patterns table) is dense and earns its tokens, but several sections re-teach things Claude already knows: the trivial first-test example (`def sum(a, b): return a + b`), basic skip/skipif/xfail syntax, and the `-lf`/`-ff`/`-x`/`-k`/`-s` flag list. At ~340 lines it could be tightened toward the 'efficient, minor instances of over-explanation' anchor without losing value. | 3 / 5 |
Actionability | Guidance is fully executable throughout: install commands, runnable test/fixture/parametrize/mocker code, copy-paste TOML and coverage config, a concrete CI YAML snippet, and exact CLI invocations (`pytest --cov=src ... --cov-fail-under=80`, `pytest -n auto`). Not 4 because the examples cover the common cases completely and are ready to run as written. | 5 / 5 |
Workflow Clarity | Steps 1–11 give a clear install → write → configure → fixtures → parametrize → markers → mock → coverage → CI sequence, with checkpoints like "Check which file pytest picked from the `configfile:` line in the run header" and an 'Authoring conventions' workflow that includes detect-then-match rules and "Conflicting signals → stop and ask". Not 5 because there is no explicit validate-after-writing loop (e.g., run the new test and confirm it fails/pass as expected) and the sequence is a learning path more than a task workflow with error-recovery feedback. | 4 / 5 |
Progressive Disclosure | The two bundle references (references/unittest.md, references/doctest.md) are real files, one level deep, and clearly signaled with purpose ("stdlib unittest + unittest.mock", "stdlib doctest"), and the body delegates async/conventions to named sibling skills. Not 5 because the main body is long (~340 lines) with several sections (basic markers, fast-feedback flags) that could live in a reference file, leaving minor organization gaps. | 4 / 5 |
Total | 16 / 20 Passed |