Use after completing any unit of work in a repo that has a real test suite — before starting the next task, compacting context, or declaring done. Runs the FULL suite (not just the tests near the change), in the background and parallelized when it's slow, and 'banks' a green state: honest pass/fail counts, pre-existing failures explicitly carved out by name, no moving on while red is unexplained. Use when the agent only ran the two tests it just wrote, when a long suite keeps getting skipped 'for speed', when failures are described vaguely ('a few unrelated tests fail'), or when work is about to stack on top of an unverified base.
Use before any context boundary — a context compaction, the end of a long session, a handoff to another agent or a future session — on multi-session work. Writes the resume state DOWN, outside the conversation: a working doc with what's done, what's in flight, the numbered remaining tasks in order, the standing constraints (the rules that must survive verbatim), and the files worth re-reading first. The test: a cold session with zero conversational memory could pick up the next task without asking a single question. Use when the user says they're about to compact, when context is getting long mid-project, when pausing a phased effort, or when work will continue 'tomorrow' (it never continues in the same window).
Use immediately after fixing a bug or improving a pattern in one place — before reporting done. Asks the question agents never ask themselves: 'did you do that anywhere else?' Enumerates the full population of sibling sites (other templates, scenarios, endpoints, components, fixtures, configs that share the same pattern), audits every one for the same defect, and applies the fix across the population — or explicitly reports which siblings were checked and found clean. Use when a fix was just applied to one instance of a repeated structure, when a codebase has N parallel implementations of anything, or when a report says 'fixed' but only one file changed.
Use the moment a real bug is found during any task — an audit, a review, a test wave, unrelated feature work — and the temptation appears to document it and move on. Defaults to fixing confirmed bugs in the current pass: a found bug is work surfaced, not work deferred. If a fix genuinely can't happen now (out of scope, needs a decision, blocked), the deferral must be explicit and accepted by the user — never a silent TODO buried in a report. Also fires on the half-kept feature: anything kept in the codebase gets finished properly or removed; there is no 'mostly works' tier. Use when an audit produced findings, when a report contains 'known issue', or when a bug was written down instead of fixed.
Use whenever code contains a numeric constant, threshold, default, rate, capacity, tolerance, or coefficient — especially one the agent just introduced. Enforces the rule: every number is either derived (from real data or first principles, traceably) or cited (to a spec, datasheet, standard, or documented decision) — never invented, never tuned to make a test or demo pass. Real data is the truth; an assumption is the explicitly-labeled backup, used only when the data genuinely doesn't exist. Use when reviewing AI-generated code for magic numbers, when a value was 'picked to look reasonable', when a test was made green by adjusting a constant, or when building anything where the output's credibility depends on its inputs.
Use at every 'are we ready?' moment — before declaring a task done, shipping, demoing, advancing to the next phase, or answering 'so everything works and we're good?'. Replaces vibes-based confidence ('should work now', 'looks good') with an explicit, evidence-backed go/no-go: what was verified and how, what was NOT verified, what changed, and the honest residual risk. Calibrates certainty to evidence — never asserts '100% sure' beyond what was actually tested, and never truncates the findings to fit a tidy summary. Use when reporting completion of any unit of work, when the user asks for a readiness check against a spec or checklist, or when you catch yourself about to say 'this should work'.
Use whenever code produces an output someone will read — a report, a metric, a chart, a calculation result, a dashboard value — and especially when a result is surprising, suspiciously clean, or just changed a lot. Treats every implausible number as guilty until root-caused: all-zeros, -0, a value at 1858% of its physical limit, a metric that moved 40x from one run to the next, a flagship case that suddenly fails, an output that's perfectly smooth where reality is noisy. The bug is found and explained — never cosmetically hidden, clamped, or filtered out of the display. Use when reviewing simulation/analytics output, after a big refactor changes results, or when something 'works' but the numbers feel wrong.
Use after building any feature, model, or fix that the team has to trust — before calling it done. Replaces smoke tests and tests-written-to-pass with an adversarial test wave: tests designed to BREAK the thing (invariants, conservation laws, edge regimes, reference cross-checks, hostile inputs), where findings are expected and get fixed, not explained away. Use when the agent (or you) just wrote tests alongside the code it's testing, when a suite passes suspiciously fast, when coverage exists but confidence doesn't, or when someone says 'tests pass' and you still wouldn't bet on it in production.