ship

Ship

A feature-centric development framework for Claude Code.

Ship guides every piece of work — feature or fix — through a structured flow: brainstorm → plan → build → QA → verify. Each feature gets its own directory with full context.

Install

claude plugin install ship

Or from the marketplace:

/plugin marketplace add dilhanz/ship

No dependencies, no build step — just Claude Code's native plugin system. Skills are auto-namespaced as ship:skill-name.

Legacy Installation

cd your-project
npx github:dilhanz/ship

Note: The npx installer is deprecated. Use the plugin system for automatic updates and clean uninstall.

Usage

/ship:start "your idea"     Brainstorm → CONTEXT.md
/ship:design                Compare architecture approaches (optional)
/ship:plan                  Plan tasks → PLAN.md
/ship:plan-verify           Verify plan against codebase patterns
/ship:build                 Implement with atomic commits
/ship:qa                    Adversarial QA — writes tests, finds bugs → QA.md
/ship:verify                Check against acceptance criteria → VERIFY.md
/ship:finish                Complete feature (create PR, merge, or keep branch)
                            Use --accept-inconclusive "reason" to override INCONCLUSIVE verdicts

Or let Ship run everything automatically:

/ship:start "your idea"     Brainstorm first (interactive)
/ship:go                    Then auto-run: plan → plan-verify → build → qa → verify
/ship:finish                Complete the feature

Utility Commands

/ship:status            Show all features and their status
/ship:resume            Pick up where you left off
/ship:help              Full command reference

What Ship Does

Start / Brainstorm: Asks 5-10+ questions to deeply understand what you want to build. Reads your codebase directly to ask smarter questions, including an adaptive NFR probe: when infrastructure signals are detected (Dockerfile, CI workflows, kubernetes, terraform, Procfile, or a Node package with start/bin), the brainstormer also asks 2-3 targeted questions on performance, observability, rollout/migration, security, or error handling. Pure libraries and CLIs skip the NFR probe. Captures everything in a CONTEXT.md with problem statement, decisions, acceptance criteria, and scope boundaries.

Design (optional): Launches 3 parallel architect sub-agents — each with a different philosophy (minimal changes, clean architecture, pragmatic balance) — and presents the trade-offs. You choose the approach before planning.

Plan: Launches 3 parallel exploration sub-agents to map similar features, architecture, and conventions. Asks targeted follow-up questions informed by what the explorers found. Then writes a concrete task list with specific file paths and runnable verify commands. Self-validates plan quality (acceptance coverage, task completeness, verify command quality, scope). Plan is independently verified against the codebase before building.

Build: Reads key files from the plan to build rich context before starting. Implements tasks sequentially with test-driven development (RED-GREEN-REFACTOR) when tasks have test-based verify commands. Runs the verify command after each task, commits atomically (feat(feature-name): description) with specific files staged. Larger plans (>4 tasks) are automatically grouped into phases — build executes one phase at a time. If the builder exhausts its turn limit mid-phase, Ship auto-continues it up to 2 times via SendMessage (preserving full context), for an effective 120-turn maximum per phase. Applies 3 deviation rules when reality diverges from plan, with structured debugging (read error → trace cause → one fix at a time) before each retry. The builder reports 4 statuses: COMPLETE, COMPLETE_WITH_CONCERNS (done but flagging doubts), NEEDS_CONTEXT (triggers AskUserQuestion — the orchestrator collects the missing info and SendMessages it back to the still-alive builder, capped at 2 rounds per phase), and CHECKPOINT (hard block). After the builder claims COMPLETE, the orchestrator runs a trust-but-verify pass (re-runs every task's verify command) and then a per-phase review gate (a read-only ship-reviewer agent reviews the phase diff; critical/high findings go back to the builder for one fix round; all findings persist to REVIEW.md).