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, demoable on its own, its acceptance criteria verifiable by a stranger. One shape of work refuses the vertical cut: a mechanical change whose blast radius spans the codebase; plan that as expand → migrate → contract, the migration batches its slices, each still landing 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 a number: one with nothing named to show it gets checked in somebody's head, and absences are the usual trap. Where no instrument can reach, say whose eyes decide; where those eyes are the user's, the slice closes with that criterion as an owed: line in Open (the genius-file format's Open rule). Each agreed seam names the test that proves it, and that test is a criterion at both ends of every after: edge that crosses it (the format holds the rule), so the edge is verified by a run at the waiting slice's close and not by a reviewer's eyes at close-out. The cut states its own order: the slice list's order is the build order, and a slice that waits on less than everything above it says so with after: — that line is what lets a coordinator run two slices at once, and what stops a fresh session grabbing a slice whose seam is not built yet. Pressure-test the cut with the user before finalizing; approval of a breakdown nobody pushed on is approval of nothing. Then put the blindspot skill's question to the contract before it binds — what would a stranger do to this system that no criterion mentions: an empty request, an unknown id, the one cell everything routes through taken offline, the state after the last job — because the contract binds the builder to what it says and frees it from what it doesn't, so what a competent engineer would do unasked is not built unless it is written.

Record base: and commit the plan as contract v1 — its full text in CONTRACT.md in the work's folder, contract: v1 in the snapshot's frontmatter, one pointer line in the snapshot's Contract section. Each slice's acceptance criteria are written once, there, under the slice's own heading; the snapshot's slice line carries the mark, the name, its after: and a link to that heading, never a second copy. This file is born here and nowhere else: a work that never ran Galvanizing has none. When the plan meets reality it changes by whole versions (genius-file skill). base: is 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 recorded. 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 building starts: one parent issue for the work — its body the brief, the work file path, a task list of the slice issues — then one issue per slice, linked under the parent as sub-issues where the tooling allows. All wear one shared working-genius label, created if the repo lacks it; per-work grouping is the parent's job. Write the numbers back: — issue: #N on each slice line, **Parent issue:** #N in the snapshot's Slices section, where the format's template puts it. The work file stays the source of truth; issues mirror it.

How it runs

1. Read the Decision, and CONTRACT.md where one already exists (an imported plan that /discern attacked). Where /architect ran, its walking skeleton is S1 and its contracts across boundaries are the first test seams; where /designer ran, DESIGN.md's token roles bind every slice that shows a screen.
2. Write the brief; agree the test seams with the user as contracts, each naming its test; cut the slices — each through every layer, demoable alone, its criteria carrying an instrument, every value a number, the order stated and after: written where a slice waits on less than everything above it.
3. Pressure-test the cut with the user, then the blindspot question of what no criterion mentions. The push and what it changed is this stage's log entry, under ## galvanizing.
4. Write CONTRACT.md as v1 — brief, seams with their tests, pinned values, one block per slice with its criteria and the seam tests of its edges — with contract: v1 and base: in the snapshot's frontmatter, the roster in its Slices section, each line linking its criteria.
5. Where the repo tracks issues, publish: the parent, one issue per slice, the shared label, the numbers written back.
6. Read each slice cold. next: names /enable <slug> or its first slice.

Then /enable — one fresh context per slice. Done when a fresh session could grab any slice with only the snapshot and the CONTRACT.md it points at — 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.