ship

/ship

Ships a ticket that has passed /review — and warns, waits, and records it when one has not. Split into a safe Phase A (local, no approval) and a gated Phase B (every external side effect), honoring hard_halt_before_external_posts. Reads the merged config (tools/effective_config.py, never raw stack.yaml — a raw read misses every personal and machine override); routes through the docstore / tracker / chat / vcs adapters, so it works regardless of the underlying tools.

THE MODEL-INVOCATION CONFIRM GATE — /ship is model-invocable. When the model reaches for /ship on its own initiative (the user did not explicitly invoke it), it must stop and confirm before Phase A's first durable action. Phase A finalizes in the repo — it tidies and overwrites deliverable files and refreshes the committed ticket-index entry — so a model-initiated run must not mutate the ticket before the human has said to ship it. Print the ticket and what Phase A will do, then ask it as one question, "Ship it" or "Not now", and wait. An explicit user invocation authorizes Phase A as normal, and so does a ship reply (or "Approve and ship") to /review's sign-off question for this ticket, given as the answer to that question: the person asked for the ship. This gate is separate from — and earlier than — the Phase B external-post HARD HALT below, which always applies regardless of who invoked the skill; it is an instruction the agent follows, not a mechanical block.

How this skill asks the person something

The kit's one question rule, the same in every skill that asks:

• Read capabilities from this skill's kit_paths.py --json probe the first time a question comes up, and keep the result.
• capabilities.structured_questions is yes and capabilities.question_tool is not none → ask with that tool, within capabilities.question_limits (when that says unknown: one question per call, at most four options). Group up to the limit only questions that do not depend on each other's answers; ask a dependent question after the one it depends on.
• Otherwise (no / unknown, or the probe failed) → ask in chat as a short numbered list, one question at a time unless this skill says a set goes in one round, and wait for an explicit answer.
• The question content is the same either way; only how it is shown changes. No skill names a runtime's tool: the runtime's own adapter (adapters/runtime/<name>.md) does. A question tool is not available inside a subagent, so the main session asks.
• Never invent an option. Options come from what this run found or the fixed choices a step names. A recommended option goes first, marked recommended, with where it came from; the person still picks. Each option says what choosing it changes, and free text is always possible (the tool's own "Other", or "or tell me something else" in prose).
• Whatever the person needs to answer is already in chat before the question, so a picker never hides it.
• A reply the kit asks for word for word (ship unreviewed, the yes before destructive SQL) stays typed: an unreviewed ship or an irreversible write is never one click. The external-send gate (go ahead) is asked like any other question once the full delivery plan is in chat: its first option is "Go ahead", which delivers exactly the printed plan, and with no question tool the person types go ahead.