Test Audit
Invoke whenever writing, changing, reviewing, or sweeping Vitest tests in this repo.
Install
npx skills add every-app/open-seo --skill test-audit -g -a claude-code -y- Repository
- every-app/open-seo26k
- Category
- Testing
- Updated
- 5d ago
- License
- MIT
- Context cost
- Mediumabout 2,718 tokens
- Runs scripts
- No, instructions only
What it does
Invoke whenever writing, changing, reviewing, or sweeping Vitest tests in this repo. Authoring gate for new or changed tests, plus an audit workflow for low-value, implementation-coupled, or duplicative tests and the test-only production seams they keep alive. Use when asked to add tests, review tests, clean up tests, or when a PR touches *.test.ts.
Test Audit
Three modes, one value bar. Authoring mode gates every new or changed test at write time. Audit mode runs focused sweeps for tests that re-assert source, duplicate stronger proof, couple behavior to implementation, or keep test-only production seams alive. Campaign mode reviews every test file with a per-test verdict when the maintainer asks to prune the whole suite; see Campaign mode. Optimize for confidence, not deletion count. Land one coherent batch per PR; continue broad audits as separate follow-ups.
The repository's own rules live in the "Testing" section of AGENTS.md. This
skill is the procedure for applying them; when the two disagree, AGENTS.md
wins and this file needs an update.
Authoring gate
Before adding a test, answer four questions. A missing answer means do not add it yet:
- What observable behavior, invariant, or independent contract does it protect?
- What credible regression makes it fail?
- Why does existing coverage not already catch that failure? Each contract has
one primary owner at the strongest boundary (usually the service or the MCP
tool handler, not the repository or a private helper). Another layer needs
its own distinct risk. Prefer extending a table-driven case or a shared
factory (
ga4-test-fixtures.ts,tool-test-support.ts) over a near-duplicate test, and consolidate duplicated setup in the same change. - Does it need a production seam (export, flag, wrapper, injection hook) that
no production caller needs? If yes, test at the real boundary instead.
Grep the whole repo for callers, not just
src/;scripts/counts.
Then check the test against every junk pattern; a match fails the gate unless the retention bar names the contract it independently guards. A test that would break under behavior-preserving refactoring is asserting implementation, not behavior; rewrite it at the owning boundary before landing it.
