Use ship
Route ambiguous software-delivery requests to the smallest useful Ship workflow: one skill, a phase bundle, or /ship:auto. Use at session start, when the user asks how to use Ship, or when they say build/check/ship without a phase.From its SKILL.md
npx -y skills add heliohq/ship --skill use-shipAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
SKILL.md
2.4 KB, as published. Nobody here has run it
Ship: Use Ship
Choose the smallest useful Ship workflow for the request, state the route briefly, then invoke the matching skill(s). Each skill's own description is the primary routing signal — this file only settles the ambiguous cases. Do not force the full pipeline unless the user explicitly wants production delivery.
Routes
| Need | Route |
|---|---|
| Understand scope, write a plan, de-risk approach | /ship:design |
| Architecture/API/data-model decision, ADR, trade-off analysis | /ship:arch-design (thinking) → /ship:write-docs (record), then /ship:design if implementation follows |
| Implement a well-scoped change | /ship:design → /ship:dev |
| Implement from an existing approved plan | /ship:dev |
| Add durable browser/API/CLI coverage | /ship:e2e |
| Check code correctness | /ship:review |
| Verify runtime behavior | /ship:qa |
| Harden a completed change | /ship:e2e → /ship:review → /ship:qa → /ship:refactor |
| Prepare delivery after work is complete | /ship:handoff |
| End-to-end production delivery (explicit ask only) | /ship:auto |
Ambiguous phrasings default to a bounded bundle, never the full pipeline: "plan this" → design; "build this" → design → dev; "check this change" → review and/or qa; "make this production-ready" → the hardening bundle; "ship this all the way" → auto.
Boundaries
- Standalone: atomic skills work without
/ship:autoor any task directory. If the user names a phase, run that phase directly. - State: during full flows, raw input lives at
.ship/tasks/<task_id>/input/requirement.md; orchestrator state is minimal and orchestrator-owned. Markdown artifacts and repository code are the real deliverables. - Durable production artifacts: use the repository's existing
convention first; otherwise create only the needed subfolders under
docs/ship/<task-id>/(input/,product/,design/,engineering/,quality/,delivery/,archive/). Prefer Markdown; use YAML/JSON only when a later agent or script consumes the structure.