audit-tests

Audit Tests

Audit independent proof: what bug would escape if this test disappeared? The result is a map of contracts to their surviving tests, with evidence for what to keep, repair, combine, or remove. Fewer tests is not the objective; less maintenance for the same or better confidence is.

write-tests owns how to write and falsify a test. This skill owns whether that test adds proof and where that proof belongs. review owns closing out the resulting changes.

Workflow

1. Bound the audit. Read the repository and scoped instructions, then pick a production responsibility. Find its tests, fixtures, shared suites, and CI selection rules. Record the starting revision, local changes, and test results before editing. Distinguish existing failures from checks that could not run. For a focused audit, choose a few substantiated candidates; for a subsystem sweep, use the completeness rules below.
2. Trace the claim. Read each candidate in full, including parameter rows, beside the production entry point and the code it reaches. Inspect callers, sibling implementations, overlapping coverage, and the history explaining why the test exists. Inspect dependency code or types when the claim rests on dependency behavior. Write down what the assertions actually detect, even when the test's name promises something else.
3. Record a disposition before editing. Use the evidence record below. Share findings as they become clear; the workflow must not hold back a material discovery. An audit-only request ends with this evidence and a proposed batch, not with deletions.
4. Choose the surviving owner. Look across the records for whole redundant layers, not just individual weak assertions. Name the suite that will own each contract and every unique case it must absorb. Prefer a real path with controlled external dependencies over replaying internal collaborators. Another layer earns coverage only for a failure the chosen owner cannot expose, such as routing or lifecycle behavior.
5. Change one coherent boundary. When implementation is in scope, carry unique cases into the surviving suite using write-tests before removing their old home. Extend existing cases and fixtures instead of cloning setup. Remove newly unneeded test hooks and support code in the same batch; verify production consumers before deleting an export, wrapper, reset function, global, or injection parameter. Update test discovery and CI registration when moving suites.
6. Prove preservation. Compare the removed assertions with the survivors, looking for lost contracts and assertions that cannot fail for the intended reason. Falsify repaired or transferred regression coverage using write-tests. Isolate temporary production changes, restore the original bytes without disturbing other work, and confirm the targeted proof passes. Report baseline failures separately; investigate any new failures. Run owner and sibling suites, then required repository checks. When replacing static checks, exercise the actual command or dry-run whose contract they claimed. Keep files stable while a runner reads them.
7. Close the batch. Run review, then reconcile the evidence record with what shipped. Report unresolved failures and unrun checks explicitly. A clean smaller suite does not prove removed coverage was redundant; the contract map and preservation evidence do.