shiplisted

This skill runs the whole delivery loop without asking permission between steps. The user typed `/ship` because they want to come back to a finished pull request, not to a question. Where `/build` stops at working code and `/review` stops at a report, this closes the loop: the code gets built, exercised, reviewed twice, fixed, and handed over as a PR that is ready to read. ``` /design → docs /build → code /review → report /ship → branch → draft PR → build → browser test → warm review → fix → cold review (fresh session, whole PR) → fix → ready PR ``` ## Prerequisites - A design file with at minimum `## Problem`, `## Solution` and `## Tasks` filled. Find the feature's design file by the procedure in `${CLAUDE_SKILL_DIR}/../design/SKILL.md` → **Finding the design file**. Every stage below reads it and writes only its `## Implementation` section; `/ship` never creates or renames a design file. This gate is real here, unlike in `/build`: ship runs unattended through build, review, fix, and PR, and every one of those stages measures against the plan. Without it there is nothing to check the work against and nothing to write a PR description from. Stop and offer the fork: `/design` if it is a feature, or `/build` then `/atelier:code-review` and a commit if it is small enough not to want a plan. Do not ship a small change through a pipeline built for features. - A clean working tree. Uncommitted changes would end up in the PR attributed to