ship

Ship

Plan it. Build it. Review it. Fix it. Push it. One command.

Purpose

Runs the full cycle — plan, implement, review, fix, push — without stopping for human feedback between steps. For well-understood incremental tasks where you trust the system and just want it done.

This is /plan + /work + /review + /pr-push composed into a single uninterrupted flow. The agent makes all intermediate decisions. You review the final PR on GitHub.

Usage

/ship "add a /health endpoint that returns 200 with {status: ok}"
/ship "fix the date formatting bug in the orders page — dates show UTC instead of local time"
/ship "add pagination to the /api/users endpoint using cursor-based pagination"

When to Use

• Well-scoped incremental tasks — new endpoint, bug fix, small feature
• Tasks that follow existing patterns — the KB has examples of similar work
• When you trust the compound loop — the KB is well-seeded, the one-shot rate is high
• When you want to review the PR, not babysit the process

When NOT to Use

• Novel architecture — use /brainstorm then /plan separately
• Ambiguous requirements — if you're not sure what you want, /brainstorm first
• High-risk changes — auth, payments, data migrations — use the manual cycle with human checkpoints
• Your first week — until the KB is seeded and you trust the system, use the manual cycle

Process

Step 1: Plan (Silent)

Run the /plan skill's process internally:

1. Load KB context and learnings
2. Research codebase with parallel sub-agents (existing types, similar implementations, test patterns)
3. Design implementation steps with verification strategy
4. Define PR stack boundaries (single PR for /ship unless the task clearly needs multiple)

Do NOT ask the user questions. Make your best judgment call on any decision points. If something is genuinely ambiguous (two equally valid approaches with different trade-offs), pick the simpler one.

Save the plan to .plans/ as usual — it's useful for the compound loop later even if the user never reads it.