| name | tenacity |
| description | Drive the work to actually-done — fresh verification of every claim, two-axis diff review, cleanup, commit, post-mortem. Use when a tracked piece of work has all slices built and is at its tenacity stage. |
Tenacity
The genius of finishing. Its failure mode is the false "done": satisfaction declared on stale evidence, or on no evidence at all. Tenacity's one law: "done" is a claim about evidence, and evidence expires with the session — if the command didn't run here, its result doesn't exist.
Run the genius-file skill: read the work file. Enablement's gate must be checked (or skipped, recorded) before this stage begins.
Process
1. Re-read the contract
Read the entire work file top to bottom — the problem, the scope edges, the chosen design, every slice's acceptance criteria. The file is the contract; your memory of it is not.
Collect every assumed: line while reading: each is a decision nobody reviewed. Walk them with the user if present; otherwise attack each one yourself against the brief and the success criteria, exactly as Discernment would. An assumption that contradicts the brief is a defect, however green the tests.
2. Verify line by line
For every acceptance criterion in every slice:
- Name the command that proves it.
- Run it, fresh, in full.
- Read the output — exit code, failure count, the actual numbers.
- Only then check it off, noting the evidence.
Then the project-wide sweep, each run fresh, each output read: full test suite, typecheck, lint/format — using the commands pinned in the ## Working Genius section of CLAUDE.md/AGENTS.md if present, else whatever the project has. "It passed earlier" is not a pass. "Should pass" is not a pass.
3. Review the diff on two axes
Review the full diff of the work — from the base: commit recorded in the work file's frontmatter to the current tree (fall back to asking the user for the baseline if base: is missing). For anything sizable, spawn one fresh reviewer subagent, isolated from this session's history so it judges the work, not your reasoning about the work. A mid-tier model reads a diff as well as a frontier one — reserve the expensive model for building, not reviewing. Hand it the diff and the work file as files, never pasted summaries, and scope it to them: the reviewer judges the diff against the brief, it does not re-drive the app or re-explore the repo — an unscoped reviewer was the most expensive single step in measured runs, at no gain over a scoped one. Spawn it so its result reaches you — synchronously (foreground) unless you are certain the harness re-wakes you when it finishes; ending your turn to "await the reviewer" in a context that won't be woken is a stall, not a wait. Ask for both verdicts:
- Spec — does the diff faithfully implement the brief? Anything asked-for missing? Anything present that nobody asked for (scope creep — check it against Wonder's no-list)?
- Standards — does the diff follow this repo's conventions and documented standards? Skip anything tooling already enforces.
Don't tell the reviewer what not to flag. When findings come back: verify before implementing, push back with reasons where a finding is wrong — findings are claims to evaluate, not orders. Fix what's real; re-run step 2's sweep after any fix.
4. Clean up
- Debug logs, tracing prints, commented-out experiments — grep and remove.
- Prototypes and scratch files — deleted or absorbed.
- The work file — every gate section reflects reality.
5. Commit and close
- Before the user accepts, offer the
blindspot skill's quiz — a behavior-level summary of what changed, then a few consequence questions. In delegated or auto mode this is the returning user's catch-up: they watched none of the build; don't let them accept a map they don't hold.
- Commit anything not yet committed, with a message that states the problem and the chosen approach (the Discernment one-liner is usually the perfect body). Slices were committed as they closed; if the history would read better squashed or reworded, offer it — don't just do it.
- Set
stage: done in the work file.
- Write the post-mortem line: which genius was weakest this run? (Wonder that missed a requirement? Discernment that let a wounded option through? Enablement that drifted from the seams?) One honest sentence — but written against the record, not in a vacuum: first grep
**Post-mortem:** across the done files in the work dir (the lines, not the files). Only lines that name a genius vote in the tally — template placeholders and abandoned — <reason> lines don't count toward "weakest". If this run's weakest genius has been weakest before, say so to the user and put the adjustment in the line, not just the diagnosis: "Wonder weakest again; next interview walks scope edges before offering express" teaches the next run something.
6. Promote a lesson — sparingly
Post-mortems live in their work files; /genius reads them as a set. Promote a lesson up into a Lessons: list in the ## Working Genius section of CLAUDE.md/AGENTS.md — where every future session sees it without asking — only when all three hold:
- It recurred — the same weakness or surprise across two or more pieces of work
- It changes behavior — a future run acting on it would concretely act differently
- It has no better home — not a term (glossary), not a decision (ADR or work file), not a command (verify commands)
Any of the three missing → the post-mortem line already carries it; don't promote. One line per lesson, created lazily (no empty Lessons: list, and no section at all if setup never ran — offer /setup-working-genius instead). When adding one, reread the ones already there: a lesson that stopped changing behavior gets pruned — the list only compounds if every future session actually reads all of it.
Gate — Tenacity
Only when every box is checked may you tell the user the work is done — and say it with the evidence, not instead of it.
If you catch yourself writing "should pass", "probably fine", "seems to work", or "passed earlier" — that's the tell. Each of those words means a command you haven't run in this session. Run it.
