메뉴
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.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
System-design thinking before any doc or code: goals/non-goals, back-of-envelope numbers, components and contracts, failure modes, operability, security, trade-offs. Use for "design this system", "architecture for X", "trade-offs for X", "how should we architect", "API design", "data model for", "service boundaries", or before an ADR. Hands off to /ship:write-docs to record the decision. Not implementation planning (/ship:design — that turns a decided design into stories).
Run Ship's full production workflow from raw requirement to PR: design, dev, E2E, review, QA, refactor, and handoff. Use only for explicit /ship:auto, auto pipeline requests, or end-to-end delivery.
Plan implementation before coding: investigate the repo, write spec and plan, and validate with a peer. Use for "plan", "design approach", "scope", or any coding task needing a plan. Not system-design thinking (/ship:arch-design) or full /ship:auto.
Implement from a spec or plan: extract stories, build in safe waves, test, commit, and get peer review per story. Use for "implement", "build/code this plan", or targeted fix findings. If no plan exists, use /ship:design first.
Add durable end-to-end tests for user/API-visible behavior. Detect or scaffold the E2E framework, write tests, run the app, and store evidence. Use for E2E, Playwright/Cypress, regression tests, or quality gates. Not exploratory QA.
Ship completed work: verify locally, commit related changes, push, create or update the PR, watch CI/reviews, and fix until merge-ready or escalated. Use for "ship it", "create PR", "handoff", or finished code needing delivery.
| name | use-ship |
| version | 0.2.0 |
| description | 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. |
| allowed-tools | ["Read","Bash","Agent"] |
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.
| 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.
/ship:auto or any task
directory. If the user names a phase, run that phase directly..ship/tasks/<task_id>/input/requirement.md; orchestrator state is
minimal and orchestrator-owned. Markdown artifacts and repository code
are the real deliverables.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.