galvanize git:20260906.f0d3db4A

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

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