Ship

Take something — existing changes, a ticket, or just a description — and get it onto a clean, reviewed PR stack. Handle the review loop yourself: fix the real bugs, ignore the noise, and report what you did. Stop when it's green. The user merges on their own time.

The whole skill runs on two habits: keep the user in the loop on the one judgment call that's theirs (how to split complex work), and handle the mechanical parts — including the entire review loop — yourself.

What's being shipped

The invocation tells you. Three flavors:

• Changes already exist locally — the working tree is the implementation. Skip straight to deslop + stack.
• A Linear ticket is referenced — read it via the Linear MCP to understand what to build. The ticket is just the spec here: read it, build it, done. Leave the ticket itself alone (status, comments, assignee) unless the user asks. If the invocation references Linear and the Linear MCP isn't available, stop and tell the user — don't guess at the ticket's contents.
• A plain-text ask — the prompt itself describes the change. Just build it.

One special case: if the working tree holds a skeleton from the probe skill (stub files sketching the change's load-bearing decisions — schema, interfaces, signatures, module layout), that skeleton is the agreed architecture — the user already reviewed it, possibly after shaping the whole thing with advisor first (advisor → probe → ship is the pipeline for very complex changes). Fill in the details on top of it; don't redesign the shape it laid down, and raise it explicitly if implementation genuinely forces a deviation.

Tools

Nothing is strictly required. Linear MCP, Graphite (gt), and gh all help, but work with what's installed: