tenacity git:20261104.19ad3b7A

Immutable. This exact content never changes and is served at /api/v1/blob/22b1690e1a67be8f.

---
name: tenacity
description: Drive the work to actually-done — fresh verification of every claim, context-isolated diff review, cleanup, commit, post-mortem. Use when the user asks to close out a tracked piece of work (`/tenacity`, or in words), whether it moved through slices or was built directly after Wonder without them. A work whose `next:` names this stage, or whose last slice just closed, is not that ask, because the flow never advances itself.
allowed-tools: Bash(python3 ${CLAUDE_SKILL_DIR}/../genius-file/measure.py *)
---

# Tenacity

The genius of finishing. Its failure mode is the false "done": satisfaction declared on stale evidence, or on no evidence at all.

The concept: **"done" is a claim about fresh evidence, and evidence expires with the session.** If the command didn't run here, its result doesn't exist. Re-read the snapshot, the `CONTRACT.md` it points at (that file is the contract; your memory of it is not), and, of the log entries it links, the slices' evidence alone — the `slice-N` entries, each in its slice's branch; the other branches hold process, not claims to verify. Then run everything fresh and read the output: the suite, the checks, every acceptance criterion; where there is no Slices section, the Problem section's success criteria instead. "Should pass", "passed earlier", "seems to work" are each a command you haven't run in this session.

Where the slices recorded a dirty baseline, the fresh run is held to the same line, no new failures, and the baseline is named in this stage's evidence. Have the plugin's `reviewer` agent ([agents/reviewer.md](agents/reviewer.md)) judge the diff from `base:` against the brief — its task message naming the diff, what it is judged against, where the record lives, and which slices already carried their own review, so its weight falls on the joints between slices no seam test reaches and the drift of the whole against the brief. Where the work cut more than one slice, spawn three in parallel, blind to each other, each told where its weight falls: the joints between slices, the drift of the whole against the brief, the inputs and states no criterion mentions. Three, each with a focus, because one reviewer spends its reading on whichever it meets first, and a focus is a place to start, never a limit on what it may flag. Don't tell it what not to flag, because the joint you didn't think to name is the one it is there for; treat its findings as claims to verify, because a review sent looking will find something and a finding fixed unchecked costs the fix. Start it before the fresh run, because both only read and the run fills the time the review takes. Spawn it synchronously where you cannot be certain the harness wakes you, and never end your turn while it runs — a review nobody reads did not run. Where `base:` was never pinned, pin it now — the commit before this work's changes began.

Walk the recorded `assumed:` and `owed:` lines — an assumption that contradicts the brief is a defect however green the tests, and an `owed:` line is a criterion nobody's eyes have checked: put it to the user now, before done is said, and drain it with what they saw. Whatever the fresh run disproves is corrected rather than quietly dropped — and the `errata` skill is loaded before the correction is proposed, not after, because the first move to hand is to fix the false line itself, and a log line that recorded a false result is a record, corrected only by what is appended below it. Before the user accepts, the close says what changed at the behavior level — what they will now see happen, and the consequences they will live with — because built work nobody absorbed is next month's surprise. It offers no quiz and asks no closing question, because an offer made at every close is a prompt the user waves off every time; the `blindspot` skill's quiz runs when they ask for it.

## How it runs

1. Re-read the snapshot, its `CONTRACT.md`, and the slices' evidence entries alone, one branch each. Pin `base:` where Galvanizing never did.
2. Spawn the `reviewer` agent against the diff from `base:` — three, one per focus, where the work cut more than one slice — naming which slices were already reviewed.
3. While they read, run everything fresh — the suite, the checks, every criterion — and read the output; a recorded dirty baseline is held at no new failures and named. Stay awake until every reviewer returns; verify their findings; resolve what is real.
4. Walk the `assumed:` and `owed:` lines — the latter put to the user's eyes now; load the `errata` skill, then propose and make the correction the run calls for. Before the user accepts, say what changed at the behavior level; offer no quiz.
5. Close out, each move its own act (below): the log entry, one line per criterion and per finding, cleanup, the decision index, slice issues, the snapshot compacted with Open emptied, `stage: done`.
6. The post-mortem line, checked against and appended to `.genius/HISTORY.md`; then the commit, which carries it, because a history line written after it is left uncommitted; the parent issue last.

Close-out. Write this stage's log entry, in `log/tenacity.md`, once, in the shape the format gives that branch: one line per criterion from the fresh run, `command → result`, and each reviewer finding with its resolution, one line each. Never a command's whole output or a report whole, because the repo answers those and nothing cuts the log later. Anchors come from `python3 ${CLAUDE_SKILL_DIR}/../genius-file/measure.py anchors <slug>`, never from opening the log's branches, and the diff is the reviewer's to read: what this stage reads it carries to its last turn. Clean up debug artifacts. Write the decision index line for anything this work settled that a future stranger would re-fight (`decision-record` skill) — the contract's established layer first, block by block, since a seam or convention a slice introduced is what the next work re-derives unless a line lets it search. Close any slice issues still open. Compact the snapshot to its resting shape by the format's question, with Open emptied: each line resolved into the log, or, where it's work this work won't do, to its log verbatim with a seed in `.genius/BACKLOG.md` pointing there. ⚠ **`CONTRACT.md` is not drained at done**: it stays whole as the final version the work was verified against. Mark the work done; the commit waits for the post-mortem line below, so that it carries it, because a `HISTORY.md` written after the commit is a change nobody committed (where `.genius/` is gitignored, it is written at that same moment all the same).

Then one honest post-mortem line: which genius was weakest this run — checked against `.genius/HISTORY.md` (one line per finished work; a bounded read), because a repeat weakness names its adjustment, not just the diagnosis. Append it there — `- **<slug>** (<date>) — <the post-mortem line>. [<slug>](<slug>/<slug>.md)`, relative to `.genius/`. A lesson that keeps recurring may earn a line in the project's `## Working Genius` section, sparingly. Then commit, one commit carrying the close whole, and close the parent issue last, if there is one: its open state is the work's live status in the tracker.

Done when the evidence is fresh — the reviewer's findings in the log among it, one line each, because those lines record that the review ran and what it found: a close-out whose review never ran is not done, however green everything else looks — and the findings are resolved. Say it with the evidence, not instead of it.