heliohq

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.

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.

Runtime QA of a change: start the app, test acceptance criteria and edge cases, and report evidence. Use for "test this", "QA", "does it work", exploratory checks, or post-review runtime verification. Not static code review.

Improve existing code without changing behavior: scan smells, simplify, dedupe, reuse utilities, and verify after edits. Use for refactor, cleanup, simplify, reduce duplication, extract method, dead code, or code smells. No PR.

Static code review of the active diff: trace changed paths and report concrete P1/P2/P3 correctness, security, or spec bugs with file:line evidence. Use for code review or bug checks. Not runtime QA.

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.

Create or extract DESIGN.md visual design systems from scratch, a URL, or a codebase, with tokens, components, and preview HTML. Use for visual design, design tokens, or brand/style capture. Not architecture docs.

Create or update structured docs under docs/ with frontmatter, numbering, lifecycle status, and index regeneration. Use for guides, references, troubleshooting, decisions, and architecture docs after /ship:arch-design.

Think through architecture, API/data design, service boundaries, trade-offs, and assumptions. Use for system design, ADRs, API plans, and architecture docs; then hand off to /ship:write-docs. Not visual or implementation planning.

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 visual/system design or full /ship:auto.