ship

name	ship
description	Umbrella skill that drives the full happy delivery pipeline end-to-end for one request or ticket — plan → track → implement → review → open-pr — stopping before merge. Use when the user wants a change shipped with one command, or to resume a ticket's pipeline from where it left off.
model	opus
effort	high
allowed-tools	["Read","Edit","Write","Grep","Glob","Bash","Task"]
argument-hint	<request or ticket id>
triggers	["ship this","take this end to end","run the pipeline","build and open a pr"]
tags	["pipeline","orchestration","delivery","ship"]

Ship

Drive one change through the whole pipeline. You orchestrate the step skills; you do not do their work inline. Stop at the PR — a human merges.

Pipeline order: plan-feature → track-work → implement → review-changes → open-pr.

Start

1. Recall, then resolve the target:

node "${CLAUDE_PLUGIN_ROOT}/hooks/memory.mjs" reply "<keywords>"
node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" list

• Argument looks like a ticket id (e.g. HZ-3) → resume that ticket.
• Otherwise → new request: run plan-feature on it, which creates the ticket.

Pick the next step from state — not memory

The pipeline store, not your recollection, decides what runs next:

node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" next <ticket-id>   # -> plan | track | implement | review | pr | complete

Map the result to the skill and run it:

next	Run skill
plan	plan-feature
track	track-work (skip for a single small ticket — mark it done and move on)
implement	implement
review	review-changes
pr	open-pr
complete	go to Finish

Re-check next after every step. A step left in_progress/failed is simply re-run — the step skill reconciles reality itself.

Running a step

Follow each step skill to completion as its coordinator (load it and do it, or dispatch a subagent for it). Apply per-role model + effort via model-router: plan/review on the strong model at high effort, implement on the mid model. Keep what you carry between steps tiny — the ticket id and the last step's status are enough; everything else is in the store and memory.

Handling a step outcome

• done → re-check next, continue.
• blocked / failed → STOP the pipeline. Surface the step's reason, where state lives (pipeline show <id>), and how to resume (ship <ticket-id>). Do not paper over a failed review or a red suite.
• needs input → ask the user (batch questions), then re-run the same step.

Rules

• State drives the order, never your memory of what you did.
• Never skip review, never merge, never force-push.
• One ticket at a time. For a multi-ticket feature, run track-work to split, then ship each ticket (parallel ones belong in separate branches).
• Record standing decisions with memory-keeper as you go, so the next session resumes cleanly.

Finish

Report the per-step status (pipeline show <id>) and the PR URL. End with: the PR is open and ready for human review + merge. On a stopped pipeline, give the resume command and what needs fixing.