Test audit

Preserve useful regression protection and remove redundant proof within the agreed scope. Load BEFORE writing new development tests or changing existing test/fixture meaning. Running tests alone does not trigger this skill. Whole existing inventory/pruning requires explicit user scope. It adds no product requirement, independent review or subsystem sweep.

Contract and necessity

Before a new or meaning-changing case, identify the protected spec/caller-visible behavior or independent contract, the plausible regression it catches, and why existing coverage misses it. Cases sharing a contract can share the reasoning. Do not invent unnecessary production interfaces or tests merely to complete an audit checklist. Clocks, randomness, durations and thresholds may be real options with production defaults; do not add test-only exports, flags, globals or hooks that no production caller uses. Do not mock the behavior being asserted.

Prove caller-visible contracts through the production owner: prefer a focused integration over mocked internal decisions or a whole-product launch, pin external I/O to fixed fixtures, derive expectations independently, and name what the test does not prove. Use synthetic data; keep credentials out of captures and fixtures.

Read the actual test, production owner/callers and overlapping coverage before consolidation/deletion. Preserve configuration, protocol, permission, persistence, migration and real behavior contracts. A name, slow runtime or refactor-sensitive assertion alone does not justify removal. Source checks can be meaningful for promised bytes/keys/paths; prose matches do not prove agent behavior.

Signals to examine include self-comparisons, expected values generated by the code under test, duplicated fixtures/contracts, mocks that implement the expected behavior, and negative cases failing at an unrelated guard. Scoped fault injection at an OS or external boundary is fine when restored. Keep uncertain cases and describe the evidence gap; test counts/deleted lines are not success measures.

When a new or changed test waits on time, spawns processes, touches env/files/ports, is slow or flaky, or adds a test file, read RELIABILITY.md; it is authoring guidance, not a checklist or gate.

For inventory/pruning, use INVENTORY.md only within the subsystem and scope authorized by the user. An approved task brief can supply that authorization; do not request it again. Missing optional tooling is a limit, not a reason to stop available scoped checks.

Evidence and completion

Record the changed contract, removed candidate and remaining owner/coverage in existing work notes or the result report; no separate per-case document or fixed receipt is required. Run the smallest checks capable of disproving the change. A necessary behavior/regression test needs demonstrated RED/GREEN; low-impact prose/config needs appropriate verification, not mirror tests. Disclose missing RED rather than inventing evidence or deleting an existing case on that basis. Baseline failures can be product defects and do not automatically widen the task.

Once required checks pass, finish. Additional checks/review need a concrete change, failure or unresolved risk. This skill adds no separate audit reviewer or review loop; use the review the project or host already requires. Reviewers apply the same standard to new/changed tests; counts/deletion are not performance measures. This skill does not itself authorize staging, committing, publishing or merging.

Source

Criteria adapted from OpenClaw at 3195fba90643c3897c538f2f6891c405331bee9c: test-audit, audit reference and writing tests. RELIABILITY.md adapts anomalyco/opencode at 28907e89c067fe1148758366929b43fa294ebcc3 (sources listed there).