Galvanize

---
name: galvanize
description: Turn the chosen design into mobilized work — a brief, vertical slices with acceptance criteria, and agreed test seams. Use when the user asks to run galvanizing on a tracked piece of work (`/galvanize`, or in words). A work whose `next:` names this stage is not that ask, because the flow never advances itself.
---

# 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 dependency everything routes through gone offline, the state after the last piece of work is done. Ask it 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 — for a plan handed in from outside, the plan as `/discern` left it; such a plan has no `CONTRACT.md` yet, because this stage writes the first one. Where the work already ran Galvanizing and `/discern` attacked its contract, read that `CONTRACT.md` too: what comes out is its next whole version, not a fresh v1 (`genius-file` skill). 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.