Drive the work to actually-done — fresh verification of every claim, context-isolated diff review, cleanup, commit, post-mortem. Use when a tracked piece of work is ready to close out, whether it moved through slices or was built directly after Wonder without them.
Scanned 9/1/2026
Install to Claude Code
npx -y skills add donald-ada/workinggenius --skill tenacity --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Tenacity?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/donald-ada-tenacity)More formats (shields.io, HTML) on the badges page.
---
name: tenacity
description: Drive the work to actually-done — fresh verification of every claim, context-isolated diff review, cleanup, commit, post-mortem. Use when a tracked piece of work is ready to close out, whether it moved through slices or was built directly after Wonder without them.
---
# 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 whole snapshot and, where Galvanizing wrote one, 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, where each slice named what it ran and what that showed; the rest of the log holds process, not claims to verify — then run everything fresh and read the output: the suite, the checks, every acceptance criterion. Where there's no Slices section — the work was built directly after Wonder, ceremony skipped by choice — there's no per-slice evidence to re-check either: verify fresh against the Problem section's success criteria instead, the same discipline aimed at the whole change rather than a cut of it. "Should pass", "passed earlier", "seems to work" are each a command you haven't run in this session — run it.
Have a fresh, context-isolated reviewer judge the diff from `base:` against the brief — spec, standards, and anything else worth blocking on, or against the Problem section's success criteria where no Contract was ever written. Don't tell it what not to flag, and treat its findings as claims to verify, not orders. Where slices were reviewed at their closes (`enable`), this reviewer's weight falls on what slice-sized eyes could not see — the seams between slices, drift of the whole against the brief — not on re-litigating each slice. Where `base:` was never pinned (Galvanizing never ran), pin it now — the commit before this work's changes began — so the diff has a start and the record is complete for whoever reads it next.
Walk the recorded `assumed:` lines — an assumption that contradicts the brief is a defect however green the tests. Whatever the fresh run disproves — a slice's recorded result, a pinned number, an `assumed:` that was wrong — is corrected rather than quietly dropped (`errata` skill): the binding copy rewritten, the record that carried the wrong line appended to with what overturned it and what made it wrong. Before the user accepts, name the `blindspot` skill's quiz and let them call it — a behaviour-level summary of what changed, then the consequences they will live with; built work nobody absorbed is next month's surprise.
Then close out, each move its own act. Write this stage's log entry: the evidence as it ran — every command, its output, the reviewer's report whole; the snapshot keeps the findings and their resolution, one line each. Clean up debug artifacts. Write the decision index line for anything this work settled that a future stranger would re-fight (`decision-record` skill). Close any slice issues still open. Compact the snapshot to its resting shape by putting the work-file discipline's question to each line one last time (`genius-file` skill), with the Open section emptied: each line resolved and consumed into the log, or moved to `.genius/BACKLOG.md` where it's work worth doing that this work won't do. ⚠ **`CONTRACT.md` is not drained at done.** The tie-break that kept its content binding lapses, but what replaces it is the distillation below, applied to the log alone: the contract stays whole as the final version that the work was verified against, and a reader asking what this work committed to reads it there. Emptying it into the log would only hand the same lines to a pass whose job is deleting what the repo now answers. Commit, and mark the work done. Close the work's parent issue last, if it has one: its open/closed state is the work's live status in the tracker, and it closes only when the work truly is.
Then distill the log — the one deliberate deletion this flow has. Done, freshly verified work no longer needs its log to say what the repo now says better: per-criterion evidence goes (the tests are in the tree and just re-ran under your eyes), full bodies of superseded contract versions go (the final contract binds; each version keeps its one-line why), the interview's play-by-play goes (the confirmed problem lives in the snapshot), and the reviewer's report shrinks to its one-line stub — that it ran, what it found — because the findings and their resolutions already live in the snapshot, one line each. What stays is everything code cannot answer: decisions and their kill-reasons, corrections with what overturned them, the user's words as they said them, why the contract moved when it moved. One rule — *does the repo answer this now?* — applied once, at this moment only, and announced: the log's first line becomes `distilled at close-out, <date>`. Links that pointed at what left, leave with it — a slice line keeps its check and its words, never a dead anchor, so `/reconcile` finds no holes. Links that stay behind are the exception: a pointer inside `.genius/BACKLOG.log.md` cannot follow what it named, because that file is append-only — which is why it is the first place to check below, not the last. ⚠ **And what something still points at does not leave at all**, whatever its category: `.genius/BACKLOG.log.md` first, for the reason just given, then `.genius/DECIDED.md`, `.genius/BACKLOG.md`, and the work's own `CONTRACT.md`, whose established layer links the source entry of every block a slice established. The contract is the one file this close-out deliberately keeps whole, so its links are the ones nothing later will repair — deleting an entry it points at leaves a dead anchor in the file a reader opens to find out what the work committed to. Never silent, never on in-flight work, never a second pass on a log already distilled — work that closed before this rule existed catches up through `/distill`; the ban on silent removal (`errata` skill) loses nothing here.
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, never a sweep of every done snapshot), because a repeat weakness names its adjustment, not just the diagnosis. Append the new line there — `- **<slug>** (<date>) — <the post-mortem line>. [<slug>](<slug>/<slug>.md)`, relative to `.genius/` where `HISTORY.md` sits, and carrying the work's path **as that work actually sits**: the folder form shown here, or a bare `<slug>.md` where the work is still flat and closed flat, which it may legitimately be (the format's link rule). A template followed past the work in front of you writes a door into a directory that does not exist. A lesson that keeps recurring and would change behavior may earn a line in the project's `## Working Genius` section — sparingly, and in the file the section actually lives in, so every agent reads it; most lessons already have a home.
Done when the evidence is fresh — the reviewer's report in the log among it: 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.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!