Ss Ship

---
name: ss-ship
description: Take a feature request from idea to reviewed, ready-to-commit code in one run — spec → plan → coding → review (+ debug on defects) — without asking at each stage. Use when given a request like "/ss-ship implement login", "ship this feature", "do the whole flow for X", "làm hết flow cho chức năng X". Orchestrator over the stage skills; never runs ss-explore-source.
---

# Ship

Goal: given a feature request (e.g. `/ss-ship thực hiện chức năng login`), drive the task through the **whole pipeline** in a single run — **spec → plan → coding → review**, attaching `debug` whenever a defect appears — stopping only when genuinely blocked.

`ss-ship` is an **orchestrator, not a stage**: it doesn't replace the stage skills, it invokes them in order and carries the user's consent across the handoffs where each stage would normally stop and ask. Invoking `ss-ship` *is* that consent, granted once for the whole task.

## When to use
- The user hands you a feature request, ticket, or PRD — anything the `ss-spec` skill could consume — and wants it taken all the way to reviewed code.
- Also works mid-pipeline: if the task already has artifacts (a confirmed `spec.md`, an approved `plan.md`), start from the first incomplete stage instead of redoing finished ones.
- Not for codebase exploration: this skill never runs `ss-explore-source`. If `docs/onboarding/*` is missing and the codebase is unfamiliar, tell the user to run it first rather than shipping blind.

## Shared task state
Part of the task pipeline — see `../WORKFLOW.md` for the full contract. Every rule there (artifacts, IDs, preconditions, traces, lessons) applies unchanged; the only thing `ss-ship` overrides is the per-handoff "ask the user" step.
- **Hydrate:** if the request matches an existing task (explicit `TASK-<ID>`, or one in conversation), resume it from its current stage; otherwise the `spec` stage will open a new task. If that named task is shelved (`status: paused`, or found under `tasks/archive/`), un-shelve it first exactly as `ss-resume-task` does (restore the folder and/or flip `paused`→`active`, with the dated log trace) before advancing. Read `tasks/LESSONS.md` if present.
- **Checkpoint:** each stage skill does its own checkpointing. Additionally, log every auto-advance as a dated Pipeline Log line in `task.md`, e.g. `- <YYYY-MM-DD HH:MM +TZ> ship: auto-advanced spec → plan` — carrying your agent label (format: `../WORKFLOW.md` → Agent handoff).

## Method — run the stages
Invoke each stage skill via the Skill tool, in order, starting from the first incomplete stage. Follow its playbook fully — artifacts, templates, gates, traces — **except its "ask the user" points, which `ss-ship` overrides as follows:**

1. **`ss-spec`** — formalize the request into `tasks/TASK-<ID>/spec.md` (opens the task). Resolve what the request and the codebase answer; anything underspecified but non-blocking becomes an entry in **Assumptions** (or a non-blocker `Q#` with its proposed default taken). Set `status: confirmed` and continue. An open **blocker** `Q#` is a hard stop — blocker questions are the one thing autopilot never answers itself. **Verifiability gate (replaces the skipped human confirmation):** before auto-advancing, every `AC#` must carry a concrete `verify:` check **and every `R#` must be covered by at least one `AC#`** (per the `ss-spec` skill's confirmation gate). Autopilot has no human sign-off to lean on here, so these objective checks stand in for it — an `AC#` with no runnable verify or an uncovered `R#` is a hard stop, not an auto-advance.
2. **`ss-plan`** — produce `plan.md` as the skill specifies. Approval is delegated: set `status: approved` directly (don't use EnterPlanMode) and log it. If planning surfaces something that changes the spec's scope, that's a hard stop, not a silent re-plan. **Verifiability gate:** before auto-advancing to `coding`, every `S#` must list at least one `covers:` ID **and an executable `verify:`** (a runnable command/test, not prose), and — coverage running both ways per the `ss-plan` skill's approval gate — **every `R#`/`AC#` in `spec.md` must be covered by at least one step**. A step whose check can't be run, or a spec ID no step covers, is a hard stop — autopilot won't hand the coding loop a blurry target.
3. **`ss-coding`** — don't ask TDD vs conventional: apply the skill's own default (whatever the codebase already does). Implement every `S#`, verify, tick. **Deviation under autopilot:** small deviations follow the `ss-coding` skill unchanged (inline note + Change History). A **structural** deviation (the approach doesn't work) triggers the plan re-approval the `ss-coding` skill requires — under `ss-ship` that re-approval is delegated like the original: re-run `ss-plan` for the affected steps, log `ship: re-planned (approach change)`, and continue. **Once per run** — a second structural re-plan means the spec's ground truth is off, and that's a hard stop, not another silent pivot. If the deviation touches the spec's scope, it's a hard stop regardless.
4. **`ss-debug`** — on a non-obvious failure at any point, invoke `ss-debug`, fix to root cause, then resume the interrupted stage directly — no "resume?" question.
5. **`ss-review`** — full gate + `AC#` verification.
   - `approved` → done.
   - `changes-requested` → loop back to `ss-coding` (or `ss-debug` for a defect) automatically with the Findings as input, then re-run `ss-review`. **Cap: 2 loop-backs.** A third `changes-requested` is a hard stop.

## Hard stops — hand back to the user
Stop, checkpoint, and report (never push through) when:
- A **blocker `Q#`** is open, or a stage reveals the spec's scope is wrong.
- The request is **too big for one run**: the spec turns out to hold multiple unrelated goals, or the plan balloons past what one review can meaningfully verify (roughly >10 steps). Propose a split into separate `TASK-<ID>`s with a suggested order instead — small verifiable increments beat one mega-run whose review rubber-stamps.
- The **structural re-plan budget** is spent (one per run — see `ss-coding` above).
- The **verifiability gate fails**: an `AC#` with no runnable `verify:`, or an `S#` with no executable `verify:` — autopilot can't self-confirm an unverifiable criterion, so it hands back instead of advancing blind.
- The next action is **destructive or hard to reverse**: data/schema migrations on real data, deleting things the task didn't create, anything outward-facing.
- The **review loop cap** is hit, or a gate can't be made green.
- As always: **never run `git add` / `commit` / `push`** — `review.md` carries the drafted commit/PR message for the user.

On a hard stop, make sure `task.md` reflects the true stage/status and the Pipeline Log says why autopilot stopped — any stage skill can then resume manually from that state.

## Not an external phase
`ss-ship` is autopilot: it deliberately runs the *whole* pipeline in one go. That makes it the opposite of external orchestration, where the launcher owns the pipeline and each agent runs exactly one phase and stops (`../WORKFLOW.md` → External phase execution). An orchestrator therefore never launches `ss-ship`, and `ss-ship` is never a value of `--phase` — it launches `spec`/`plan`/`coding`/`review`/`debug` individually instead. Nothing here changes for interactive users: `ss-ship` stays the normal autopilot entry point.

## When done
One final report covering the whole run: stages executed, key assumptions made in the spec, `AC#` verification results, gate results, files changed, bugs hit (`BUG#`), deviations from the plan, the drafted commit message from `review.md`, and follow-ups. The task is `done` only when `review` says `approved`.