# Test Audit

Invoke whenever writing, changing, reviewing, or sweeping Vitest tests in this repo.

- Repository: https://github.com/every-app/open-seo (25988 stars)
- Category: Testing
- License: MIT
- Last updated: 2026-10-31
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add every-app/open-seo --skill test-audit -g -a claude-code -y`
Codex: `npx skills add every-app/open-seo --skill test-audit -g -a codex -y`
Cursor: `npx skills add every-app/open-seo --skill test-audit -g -a cursor -y`
Gemini CLI: `npx skills add every-app/open-seo --skill test-audit -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add every-app/open-seo`

## Description

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.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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](#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:

1. What observable behavior, invariant, or independent contract does it protect?
2. What credible regression makes it fail?
3. 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.
4. 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](#junk-patterns); a match fails
the gate unless the [retention bar](#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.

The rest: https://github.com/every-app/open-seo/blob/HEAD/.agents/skills/test-audit/SKILL.md