Enable

---
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.
argument-hint: "a work slug to coordinate all slices, or 'slug, slice N' to build one"
---

# 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.

Coordinating multiple slices? Hand each builder the snapshot's path **and, where Galvanizing wrote one, the `CONTRACT.md` beside it** — the seams, the pinned values and what earlier slices established live in that file now, and the snapshot's Contract section is a pointer at it, so a builder given the snapshot alone builds against a pointer. Then verify each returned slice against real output yourself, and stay awake until they're done — a builder's word is not evidence.

**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 now**: 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.)

Write the log entry 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). It goes in the log and not the commit message; the work-file discipline names why a message can't serve as the record. 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.

Start each slice by reading the snapshot's slice list, so 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. And a discovery worth its own piece of work — spotted mid-build, not this slice's job — takes its one line in `.genius/BACKLOG.md` before momentum buries it (`genius-file` skill).

**A slice earns its close under fresh eyes, not just green tests.** Before the closing commit, hand the slice's diff to a fresh, context-isolated reviewer, judged against the slice's acceptance criteria and the contract — under the same rules as Tenacity's close-out review: 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.

**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; where they 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.

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.