Skip to content
cccskills
FreePublished on GitHub

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.

The English summary is being prepared. Showing the original description.

heliohq/ship
See how to install

Files included (1)

  • SKILL.md2.4 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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

NeedRoute
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.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

arch-design

Free

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).

The English summary is being prepared. Showing the original description.

heliohq/ship93Updated Jul 4, 2026

auto

Free

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.

The English summary is being prepared. Showing the original description.

heliohq/ship93Updated Jul 4, 2026

design

Free

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.

The English summary is being prepared. Showing the original description.

heliohq/ship93Updated Jul 4, 2026

dev

Free

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.

The English summary is being prepared. Showing the original description.

heliohq/ship93Updated Jul 4, 2026

e2e

Free

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.

The English summary is being prepared. Showing the original description.

heliohq/ship93Updated Jul 4, 2026

handoff

Free

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.

The English summary is being prepared. Showing the original description.

heliohq/ship93Updated Jul 4, 2026

See all skills by heliohq

Report a problem with this skill