galvanize git:20260905.a7ea1b4A

Immutable. This exact content is served forever at /api/v1/blob/e48c94f8ef6abf4b.

---
name: galvanize
description: Turn the chosen design into mobilized work — a brief, vertical slices with acceptance criteria, and agreed test seams. Use when a tracked piece of work is at its galvanizing stage.
---

# 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 — and where those eyes are the user's, the slice closes with that criterion as an `owed:` line in Open, waiting for them (the `genius-file` format's Open rule), because a user who verifies once at the end is exactly who that line is written for. A seam needs an instrument too: 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 `genius-file` format holds the rule and its why), 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:` on its line (the `genius-file` format holds the mark and its default). That line is what lets a coordinator run two slices at once, and what stops a fresh session from grabbing a slice whose seam is not built yet; a cut that leaves the order to be inferred gets built sequentially, which is safe, or in the wrong order, which is not. 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 (measured: a contract-bound build shipped with no input validation and a 500 on every tick after one bad request, while the unbound build beside it validated by instinct).

Record `base:` and commit the plan as **contract v1** — its full text written to `CONTRACT.md` in the work's own folder, `contract: v1` in the snapshot's frontmatter, and one pointer line in the snapshot's Contract section. **Each slice's acceptance criteria are written once, there, under the slice's own heading in the plan layer**; the snapshot's slice line carries the mark, the name, its `after:` and a link to that heading, never a second copy of the criteria (the `genius-file` format says why one home). This file is born here and nowhere else: a work that never ran Galvanizing has none, and absence is the record. The 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 snapshot's Slices section, beside the list it mirrors — the format's template puts it there and names no Galvanizing section, so a parent number filed under one is a number the next session cannot find. 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 — the plan layer: brief, seams with their tests, pinned values, one block per slice with its criteria, the seam tests of its edges among them — 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.