Use when applying any deliberate-engineering lens or standing rule. Reads ~/.claude/deliberate-engineering/overrides.md before applying catalog lenses or standing rules, honors disable/modify/add overrides, and declares each deviation. Stays silent when no override file exists or no override matches.
Use on software-engineering work — writing, reviewing, debugging, planning, migrating, shipping, or operating code, specs, schemas, or deploys. Establishes the standing rules of deliberate practice — calibrate autonomy and ceremony to consumers, risk, and reversibility; keep a human gate on irreversible and outward-facing actions; verify claims against primary evidence before endorsing; and treat trust as earned by convergence, not granted on a single pass. Skip for research, prose, ad-hoc analysis, disposable no-consumer scripts, and non-technical work.
Use when a live system behaves unexpectedly and you must diagnose under uncertainty or respond to an incident — error rates climbing, a flow broken with no known cause, a page you have to act on. You don't yet hold a reliable expectation; you're discovering what's true while the system may be degraded. Classifies the evidence quality and how irreversible being wrong is, then selects strategies from the catalog and dispatches superpowers for the debugging method. Distinct from verify: verify confirms an expectation you already hold; this is discovery under failure.
Use on demand to drive a pending candidate into the catalog systematically. Runs the leak-audit gate, classifies isolated vs structural, then (isolated) edits the catalog append-only + runs skill-reviewer or (structural) stops and recommends the proper design cycle. This is the promotion step of the author contribution flow — it drives a candidate into the shared catalog (working tree only, gated). It is not the contribute skill, which captures candidates, nor the adopter capture skill, which writes your personal override file. Stays silent unless invoked.
Use at the start of an engineering task when you're not sure which phase you're in, or for broad or multi-phase work — building a feature, changing a live system, chasing an incident, reviewing a diff, or shaping a design. It classifies the work, names the phase sequence and ceremony band, and routes to the matching selector (plan / review / verify / debug-operate), conducting between phases and stopping at the irreversible action. Skip for research, prose, and ad-hoc analysis.
Use when work spans phases or sessions and process state must survive — the current phase and phase sequence, the chosen ceremony band and rituals, open pendings, and the decisions made and why. Reads and rehydrates a per-work-unit working-note at the start of a session or phase, and rewrites it at Rule 6 checkpoints with a changed-since-read safety check. Delegates to a tracker or superpowers when one is present; falls back to its own note otherwise. Consulted by the router and Rule 6, not invoked directly; stays silent when there is no state to record.
Use after any baseline code review, or when reviewing a change, to deliberately select the right review lenses for THIS change instead of running a generic pass. Classifies by risk, reversibility, requirement clarity, and size, then applies matching strategies from the catalog. Less vibe coding, more deliberate craft.
Use when you need to establish that something is actually true in reality — not just plausible on paper: verifying a claim, number, or assumption against primary evidence; getting a change ready to merge; promoting across environments; confirming production behavior after a deploy; or mutating production data safely. Classifies what's being verified and how irreversible being wrong is, then selects the right strategies from the catalog. Distinct from code review: review asks 'does this look correct?', verification asks 'is it correct, and what's my evidence?'