git:20260905.b7b7ca3 to git:20260906.c24fbe5

---

name: enable

description: Build one slice at a time with red-before-green tests at the agreed seams, tight feedback loops, and fresh-eyes review at every slice close. Use when a tracked piece of work is at its enablement stage and a slice needs building — or when small work that never cut slices needs building against its confirmed problem.

argument-hint: "a work slug to coordinate all slices, or 'slug, slice N' to build one"

allowed-tools: Bash(python3 ${CLAUDE_SKILL_DIR}/../genius-file/measure.py *)

hooks:

Stop:

- hooks:

- type: command

command: python3 "${CLAUDE_PLUGIN_ROOT}/skills/genius-file/stop-judge.py"

timeout: 90

SubagentStop:

- matcher: builder

hooks:

- type: command

command: python3 "${CLAUDE_PLUGIN_ROOT}/skills/genius-file/stop-judge.py"

timeout: 90

---

# Enablement

The genius of doing the work the work needs. Its failure mode is flying blind: code produced without feedback until a big-bang reveal at the end.

The concept: **build one slice at a time, in a fresh context, with reality voting every few minutes.** Tests lead the code — write the failing test at the agreed seam and watch it fail before the implementation exists; this is the one discipline a capable model still talks itself out of (measured 0/3 baseline), so hold it even when momentum says skip it. Test behavior through public seams, not implementation. Some criteria can't be red-green — verify those against the real thing and record what you observed; the rule is feedback, not ceremony.

## How it runs

1. Decide your role from the invocation (below): builder, coordinator, fresh session per slice, or small work with no cut.

2. Read the slice list and the `CONTRACT.md` it points at; run the verify commands once and record a dirty baseline.

3. Mark the slice in progress at the first red test; red → green at the agreed seams; each criterion's evidence written as it runs.

4. A discovery that changes the shape stops the slice: to the user in one exchange, or back to the coordinator where you are its builder.

5. Fresh-eyes review by the `reviewer` agent; close in one commit; drain Open; then dispatch, or name, what the close unblocked.

## Who builds

The invocation decides your role.

- **Only the work named, more than one slice open** → you are the **coordinator**. One fresh `builder` agent per slice ([agents/builder.md](agents/builder.md)). Its task message carries the snapshot's path **and the `CONTRACT.md` beside it** — the seams, the pinned values and what earlier slices established live in that file, and a builder given the snapshot alone builds against a pointer — the slice's number and name, the pinned verify commands, where to build, and whether it closes the slice itself. Never a pasted summary: it anchors the builder on your reading and rots as slices land. Dispatch in the order the slice list states — a slice runs only when everything it waits on has closed (the `genius-file` format's `after:` rule). Slices that wait on nothing still open and touch disjoint parts of the tree may run in parallel, each in its own worktree; when in doubt, sequential — slow and safe beats a merge nobody planned. You write no product code: coordinating and building do not share a context. When a builder returns, read its evidence, **re-run the slice's verification yourself** — every criterion, the seam tests on every edge into the slice among them, in the tree the slice lands in, which for a parallel builder's branch is the tree it merges into — and close the slice (below) before dispatching what it unblocked — a builder's word is not evidence. **The coordinator runs; the reviewer reads.** A diff or a source file the coordinator opens to judge a slice is paid for again on every turn until the work is done, and reading the diff is exactly the context the reviewer is spawned to spend. **Coordinating means staying awake.** Never end your turn while a builder you must verify is still running: measured three times, "I'll wait for it to return" followed by ending the turn *is* the stall, not a wait. Where you cannot be certain the harness wakes you when a child finishes, dispatch synchronously. And dispatching is doing: "next I'll dispatch slice N" ends with slice N dispatched, not announced.

- **No subagents, or the user wants to drive each slice** → fresh session per slice: tell the user to open one and type `/enable <slug>, slice N`.

- **No Slices section at all** — small work built straight after Wonder, the cut skipped by choice → build it here, against the Problem section's success criteria, by the same loop, and close it the way one slice closes, under a log entry keyed `build`. Skipping Galvanizing skipped the cut, never the discipline; `/tenacity` then verifies fresh against those same criteria.

## The loop

Start by reading the snapshot's slice list — a slice that closed without marking itself is caught by the next slice rather than at close-out — and the `CONTRACT.md` its Contract section points at, because what the earlier slices established binds this one and your memory of that file is not that file. Verify commands are the ones the project's `## Working Genius` section pins; discover them once from the task runner where it pins none. **If a verify command's baseline is already dirty** — failures that predate this work — record the baseline in the slice's log entry and hold the line at **no new failures**: don't adopt the dirt, and don't fix unrelated code on the way past. That discovery takes its one line in `.genius/BACKLOG.md`, like any other worth its own piece of work spotted mid-build (`genius-file` skill), before momentum buries it.

**Mark the slice in progress at the first red test.** The slice line's box becomes `[~]`, and it gains a link to a log entry keyed `slice-N-wip` that says what is red, what is green, and what is still owed — appended to as the loop moves, never rewritten. A slice is closed once, at its end, but a session dies whenever it dies: a snapshot still reading `[ ]` over half-built code sends the next session to rebuild what exists, or to build on it blind. The close replaces the mark; the entry stays, one more link the closed line carries. A coordinator dispatching a builder into a worktree writes the mark itself at dispatch, since the builder's tree is not the one the snapshot lives in.

Then red → green, at the agreed seams, until the slice's criteria are covered: the failing test first, watched failing; the minimal code that passes; typecheck (and lint, where it is fast) after each green. Write each criterion's evidence while the output is still on screen — under the slice's own anchor, one line per criterion: the command and its result, data not prose (the `record-prose` skill's rule).

## When the build changes the requirements

**The plan re-enters the flow at minute scale: pause, confirm, re-version, resume.** A discovery that moves the work's shape — criteria, scope, slices, seams — is the normal case, not an erratum: the contract was right for the world it was written in; the build just made the world clearer. Never silently improvise around it. Pause the slice and put the change to the user in one exchange — what was discovered, what it changes, which slices it touches, with your recommendation, **and a recommendation that re-cuts is written as the cut it proposes**: the slice lines in the roster's shape, each with its `after:`, the criteria it takes from the slice it replaces, the seam test between the parts — because a re-cut confirmed as a sentence still gets cut afterwards, by someone, out of the user's sight, which is the shape change improvising itself one exchange later, and a cut the user confirmed is the bump, written at once; where they genuinely can't be reached, an `assumed:` line, flagged for next contact. Then bump the contract (`genius-file` skill): the new version whole in `CONTRACT.md`, the old version whole to the log with what overturned it, one changelog line left in the snapshot between them. Re-cut the slices only where the change reaches — a reshaped slice leaves no corpse in the snapshot; the reshape and its reason are a log entry, its issue closed with the reason, its replacement joining the work's parent issue and label like any other. Then resume, building against the version that now binds. Ten churns cost ten log entries and a snapshot the same size it started — which is the point: a plan that gets more expensive to change gets defended instead of corrected.

**A builder subagent cannot reach the user, so for it the pause is a return.** It stops, hands back what it found, what it changes and its recommendation — a re-cut in the roster's shape, as above — and the coordinator checks that against the contract and puts it to the user. An `assumed:` improvised inside a context that could have asked through one that can is the silent workaround wearing a record's clothes; `assumed:` is the coordinator's line to write, and only for a user who is actually unreachable.

## Closing a slice

**Closing a slice is one commit with four effects** (`genius-file` skill): the code, the slice's log entry, the compacted snapshot, and the close of its issue if it carries one — **five where the slice left something binding, since `CONTRACT.md` is its own file**: a constraint that misses this commit is one the next slice builds without. The record updates as a side effect of an action you had to take anyway, never as bookkeeping someone must remember. (An issue closes via `closes #N` in the message where that commit lands on the default branch, and directly, pointing at the commit, where it won't; where `.genius/` is gitignored, the files are written at that same moment all the same.)

**A criterion whose instrument is the user's eyes, and whose eyes have not looked, closes as an `owed:` line in Open** — `owed: S2 <criterion> → the user's eyes` — with the slice's log entry saying so; the slice still closes on the evidence it has, and the line waits in Open until they look (the `genius-file` format's Open rule). Checked in the builder's head instead, the roster's `[x]` is earlier than the fact, and the one reader who would catch it is the user who verifies at the end.

**One close at a time, by whoever holds the snapshot.** Two builders closing in parallel rewrite the same snapshot and the same `CONTRACT.md` in two commits, and the second lands on a file the first already changed. So a parallel builder does not close: it returns its branch, its per-criterion evidence and what it established, and the coordinator closes each returned slice in turn. A solo builder closes its own.

The evidence goes in the log and not the commit message; the work-file discipline names why a message can't serve as the record. The entry is appended and linked without opening the log: `python3 ${CLAUDE_SKILL_DIR}/../genius-file/measure.py anchors <slug>` lists the keys that exist and what already links them (the `genius-file` skill says what a whole read costs), and the close is composed first and written once per file. Compact the snapshot to current truth in the same commit, which means putting the work-file discipline's question to each line — *does this line still constrain work that isn't finished?* — and routing each answer to the destination that discipline names. ⚠ **A convention this slice introduced lands in `CONTRACT.md` even where it never became a snapshot line.** The question is asked of the snapshot, and something the build settled at the keyboard was never written there — but it binds the slices not yet built all the same, and the next builder opens that file, not this slice's log. Two more things a slice close owes beyond the routing itself: the closed slice's line collapses to its resting shape, and **Open is drained here rather than left for close-out** — a line the slice consumed leaves with what consumed it, and one that turned out to be work in its own right leaves as a seed in `.genius/BACKLOG.md`. What the build merely disproved — a stated fact, a value that measured differently — is the `errata` skill's line-level correction, made by whoever makes the commit, in that slice's issue too where it carries one.

**A slice earns its close under fresh eyes, not just green tests.** Before the closing commit, hand the slice's diff to the plugin's `reviewer` agent ([agents/reviewer.md](../tenacity/agents/reviewer.md)), its task message naming the diff, the slice's acceptance criteria and the contract it is judged against, and where the record lives — don't tell it what not to flag, and treat its findings as claims to verify, not orders. Fix what's real before the commit; what's real but not this slice's job goes to `.genius/BACKLOG.md` or an Open line. The slice's log entry notes the outcome in one line — `reviewed → 2 findings fixed, 1 to backlog` — so close-out can trust the slice was reviewed without re-reading its diff. Reviewing only at close-out means someone eventually reads a diff no one can hold in their head — slice-sized review catches problems while the context that produced them is still warm, and leaves Tenacity's reviewer free for what slice-sized eyes cannot see: the seams between slices.

Then `/tenacity`. Done when every slice is built and every criterion checked against output that actually ran — its log entry naming, per criterion, what ran and what it showed. A criterion checked in your head has not been checked.