Auto-invokedSkill
arch-design
System-design thinking before any doc or code: goals/non-goals, back-of-envelope numbers, components and contracts, failure modes, operability, security,…
/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.
Install
$ npx -y skills add heliohq/ship --skill use-ship --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/use-ship
Context preview
The summary Claude sees to decide when to auto-load this skill.
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.
SKILL.md
use-ship.SKILL.mdname: 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
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:auto` or 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.
Read more
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
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:auto` or 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.
Ships withship
An agentic development harness for Claude Code & Codex: agent-routed workflows from raw requirement to green PR.
Get the whole plugin, auto-invoked
Other skills on ship.
Auto-invokedSkill
auto
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…
Auto-invokedSkill
design
Plan implementation before coding: investigate the repo, write spec and plan, and validate with a peer. Use for "plan", "design approach", "scope", or any…
Auto-invokedSkill
dev
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",…
Auto-invokedSkill
e2e
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,…