ship

/ship — execute a shaped cycle, verify, review

Turn an approved pitch into production-quality code through a disciplined cycle. The organizing law: parallelize readers, serialize writers — research and review can fan out; only one writer touches the code at a time.

$ARGUMENTS points to the approved pitch/spec. Read it first.

0. Is the cycle warranted?

The filter below decides who does the work. This one decides whether the ceremony is worth paying for at all, and it is the one that gets skipped — because a process that has proved itself starts to feel free.

It isn't. A cycle costs three contexts (shape, write, review) plus the human attention to arbitrate between them, and that attention is usually the scarcest thing in the room. Spend it where being wrong is expensive to undo:

• Small and reversible — a doc fix, a stale number, a rename with no behavior change, a broken link: do it directly and report what you did. git revert is the whole safety net, and it is enough.
• Wide, outward-facing, or hard to undo — schema, public interface, anything that runs unattended or that other people build on: there the full cycle earns its cost several times over.

Severity × reversibility — the same rule you apply to what an agent may do on its own — turned on your own process. If you can describe the diff in one sentence and undo it with one command, stop reading and go do it.

1. Pre-spawn filter (decide who does the work)

Before delegating to an executor subagent, answer three questions. If any is "no", do NOT delegate — keep it human-driven / main-agent-driven:

1. Deterministic? Cleanup, inventory, zero-behavior refactor = yes. Behavior-altering (changes product behavior, identity, core flow) = no.
2. Closed scope? Finishable from a doc-bundle + this pitch without needing product judgment or user confirmations mid-flight.
3. Low / low-medium risk? High-risk (schema break, destructive migration) = no, or split into safe steps first.