ship

System architecture and design thinking — requirements analysis, component design, data modeling, scaling strategy, and trade-off analysis. Use when: "design this system", "what's the architecture for", "trade-offs for X", "how should we architect", "system design for", "API design", "data model for", "service boundaries", "architecture doc", "create an ADR". When the design thinking is done, this skill hands off to /ship:write-docs to write the design document. Note: this is NOT for visual design (use /ship:visual-design) or implementation planning (use /ship:design).

Full pipeline orchestrator: design → dev → E2E → review → QA → simplify → handoff. Auto-detects scope from the description — refactor-shaped tasks (refactor, simplify, optimize, rename, extract, dedupe, restructure) run a lighter design phase that skips the execution drill but keeps adversarial peer investigation. Code-driven coordinator — all state management, artifact validation, phase transitions, and retry logic live in scripts/auto-orchestrate.sh. You are a thin relay that dispatches Agent() calls and interprets sub-skill responses. Use when: "ship this", "build this feature end to end", "ship this refactor", "refactor and ship", "implement and ship", "full pipeline", or any scoped code change that should go through the complete design-to-handoff workflow. This is the default entry point for any work the user wants shipped in one flow (PR + CI green), whether feature or refactor. For local refactor without shipping, use /ship:refactor. For individual phases only, invoke /ship:design, /ship:dev, /ship:review, /ship:qa, /ship:e2e, or /ship:handoff directly.

Adversarial pre-coding planning: the host agent and a peer agent independently investigate the codebase, diff specs, and validate the final plan with an execution drill. Use when: "plan this", "design the approach", "how should we implement", "write a plan", "scope the work", "what's the best approach", or any task that needs investigation and planning before writing code. This is the default for tasks that need a plan but not the full pipeline. Note: this is for implementation planning, NOT visual design (use /ship:visual-design) or full pipeline execution (use /ship:auto).

Execute implementation stories from a plan via parallel waves. Host (Claude) is the primary implementer; peer (Codex) is the independent reviewer. Dependency analysis groups file-independent stories into waves that can run in parallel on the current branch — single-story waves are implemented by the host; multi-story waves dispatch Claude Agent subagents in parallel. Each story is reviewed by the peer before the wave advances. Use when: "implement this plan", "execute the stories", "code this up", "build from the plan", or when a plan/stories already exist and need implementation. Note: if no plan exists yet, use /ship:design first. For the full pipeline (plan → code → e2e → review → QA → ship), use /ship:auto.

Codify the change's user-facing behavior as persistent end-to-end tests that live in the repo and run in CI. Detects the existing E2E framework (Playwright, Cypress, pytest-playwright, etc.) or scaffolds one when absent, then writes or extends tests that lock in the spec's acceptance criteria. Use when: "add e2e tests", "write a playwright test", "codify this behavior", "regression test for this flow", or after QA passes in the auto pipeline. Note: this writes persistent test code — it is NOT the same as /ship:qa (which runs one-off exploratory checks and produces reports, not test code).

Use when code is ready to ship: creates a PR, waits for CI/CD, addresses review comments and merge conflicts, and iterates until the PR is ready. Use when: "ship it", "create a PR", "open a pull request", "push and merge", "handoff", or when code changes are complete and need to go through PR creation and CI. Called by /ship:auto at the end, or invoked directly via /ship:handoff after manual work.

Capture learnings from sessions to prevent repeating mistakes. Reflects on what went wrong or was discovered, routes each learning to .learnings/LEARNINGS.md (and hookify/design docs when applicable). Use when: learn, what did we learn, capture learning, session retro, avoid this mistake, remember this, show learnings, list learnings, what do we know, current learnings. Auto-invoked at the end of /ship:auto pipelines.

Independent QA: starts the application, tests the code changes against the spec, and explores beyond the spec for edge cases. Reports verdict with evidence. All testing logic lives in reference files. Use when: "test this", "QA the changes", "does it actually work", "run QA", "exploratory testing", or after code review to verify runtime behavior. Note: this runs the app and tests behavior end-to-end, not just code correctness (use /ship:review for static review).

Make code better — simpler, less duplication, clearer structure. Four-lens parallel scan (structure, reuse, quality, efficiency) detects smells across all dimensions. Applies Fowler techniques, verifies each change. Use when: refactor, clean up, simplify, reduce duplication, extract method, dead code, code smells, make this cleaner. Local cleanup only — no PR. For refactor + PR + CI in one flow, use /ship:auto instead.

Review the active change scope, report concrete correctness findings, rank them P1/P2/P3, and add diagnosis only when it explains multiple findings. Use when: "review the code", "check for bugs", "review my changes", "is this correct", "code review", or after implementation to verify correctness before QA. Note: this checks code correctness via static analysis, not runtime behavior (use /ship:qa for runtime testing).

Bootstrap repo infrastructure and AI harness. Detects languages and tooling, installs missing tools, configures CI/CD and pre-commit hooks, discovers semantic constraints from code and git history, generates AGENTS.md and learnings, and sets up hookify safety rules. Audits existing harness for staleness if one already exists. Use when: setup, init, bootstrap, setup harness, setup infra, install tools, configure CI, add pre-commit, enforce conventions.

Create DESIGN.md files — structured markdown visual design systems (colors, typography, spacing, components) that AI coding agents read to generate consistent UI. Use when the user mentions DESIGN.md, visual design, design system, design tokens, extracting a design from a website, or documenting UI tokens. Also triggers on 'make it look like [brand]', 'capture the design of [site]', 'extract design tokens'. Note: this is NOT for architectural design docs (use /ship:write-docs for those) or system design thinking (use /ship:arch-design for that).

Write, edit, and manage structured project documentation under docs/ — enforces frontmatter format, category conventions, numbering, status lifecycle, and writing rules. Use when: "write a doc", "document this", "create a guide", "write a design doc", "write a troubleshooting guide", "create a reference doc", "update the docs", "document this decision", or when capturing guides, troubleshooting playbooks, reference material, or design decisions as docs. Note: for system design thinking (architecture, trade-offs, scaling), use /ship:arch-design first, then come here to write it up. For visual design (DESIGN.md), use /ship:visual-design.

4 hooks across 4 events