galvanize

Galvanizing

The genius of rallying work into motion. Its failure mode is the vague plan: a decision everyone agrees with and nobody can start.

The concept: convert the decision into slices a fresh session can pick up cold. A short behavioral brief, test seams agreed with the user as contracts, and vertical slices — each cutting through every layer the change touches, each demoable on its own, each with acceptance criteria a stranger could verify. One shape of work refuses the vertical cut: a mechanical change whose blast radius spans the codebase, where no narrow slice can land green. Plan that as expand → migrate → contract — the migration batches, sized by blast radius, are its slices, and each still lands green. A value the plan leaves "sensible" is a decision deferred to a session that can't ask — write the number. A criterion needs an instrument as much as it needs a number: one with nothing named to show it gets checked in somebody's head, which is where criteria go to pass. Absences are the usual trap, because the instrument that proves a thing is there rarely expresses that it isn't — and where no instrument can reach, say whose eyes decide rather than letting it read as checkable. Pressure-test the cut with the user before finalizing; approval of a breakdown nobody pushed on is approval of nothing.

Record base: and commit the plan as contract v1 — contract: v1 in the snapshot's frontmatter, because this plan will meet reality and change, and when it does it changes by whole versions, never by accumulated patches (genius-file skill holds the discipline). base: is where the work starts — HEAD as you write the line, never the plan's own commit: a commit cannot carry its own id, and amending one to add it orphans the sha you just recorded, so Tenacity's diff finds nothing on any fresh clone. The plan's slice list is the work's progress view — each line marked done in the commit that closes that slice, linked to the log entry that commit wrote. That holds whether or not the repo tracks issues; a tracker mirrors this list, it never replaces it. The pressure test itself — what the user pushed on, what it changed — is this stage's log entry, so the contract stays the contract rather than the transcript. Where the repo tracks work in issues (Issue tracking: pinned, or the user asks), publish the approved breakdown before any building starts. One parent issue for the work, titled with the work's title, its body carrying the brief, the work file path, and a task list of the slice issues — the tracker's mirror of the plan's list. Then one issue per slice, linked under the parent as sub-issues where the tooling allows, held by the parent's task list alone where it doesn't. Parent and slices all wear one shared working-genius label, created if the repo lacks it — the one-click filter for everything the flow published; per-work grouping is the parent's job, so no per-work labels pile up. Write the numbers back: — issue: #N on each slice line, **Parent issue:** #N in the Galvanizing section. The work file stays the source of truth; issues mirror it.

Then /enable — one fresh context per slice. Done when a fresh session could grab any slice with only the snapshot — proven by reading each slice cold: every value a number, every criterion checkable by a stranger. A slice that still raises a question only you can answer isn't done being planned.