ship

ship — the ladder, without stops

Run every step from intent to a reviewed branch in one go, asking nothing along the way. This is the same ladder as the individual commands — it does not reimplement any step, it runs them back to back and takes on itself every decision the interactive path would have handed to the maintainer.

Announce at start: "Shipping this end to end — I'll decide open questions and record each one."

The steps

Run these in order, each per its own skill. Follow that skill's instructions exactly; the only difference is that you never stop to ask.

1. propose — write proposal.md with acceptance criteria. If a change folder already exists for this work, start from it instead of writing a new one.
2. plan — decide the scope, write tasks.md and, above low, design.md, then pass the handoff-readiness validator.
3. implement — work the task list, quality gate, runtime verification.
4. review — review the branch, fix what the findings justify, iterate to lgtm.

Then set status: shipped and the shipped: date in proposal.md, tick the criteria that were verified, and commit on the change's own branch.

Decide, then record

Every question the interactive ladder would have asked, you answer. Two rules:

Prefer the reversible option. When two designs are defensible, take the one that is cheaper to undo. An autonomous run is not the place to make an expensive bet on the maintainer's behalf.

Record every decision in proposal.md. Under ## Decisions and discoveries, one bullet each, saying what was chosen, why, and what was rejected:

- **[decision]** Used cursor pagination instead of offset — the ticket did not
  specify and the table exceeds a million rows. Rejected: offset, which degrades
  with depth.

That section is the entire audit trail of an unattended run. A decision you took and did not write down is indistinguishable from one you never noticed — treat an unrecorded decision as a defect, not as tidiness.