/ship

description: "Use when the user wants an idea taken from concept to a shipped, reviewed product, or when the /team router picks ship. Runs six build stages, seven hard verification gates, then PR open, with one approval gate after the plan."

/team ship — Idea to Shipped Product Pipeline

> Called by team.md router when action is `ship`. > The ultimate automation: takes a natural language idea and delivers a built, reviewed, verified product. > Uses Option B: one approval gate after plan, then full autonomy for build+verify.

Role Selection Bias

All roles are selected dynamically per stage. The ship pipeline runs 6 build stages, then 7 hard verification gates (Stages 7–13), then PR-open (Stage 14), each using the appropriate /team action's role selection.

Pipeline: 6 Stages + 7 Hard Gates + PR Open

Stage 1: Research

• Runs: `/team research <idea>`
• Purpose: Competitive landscape, technical feasibility, existing tools
• Writes: `.team-ship/RESEARCH-BRIEF.md`
• Record the architecture baseline for the conformance gate. **This step never spawns

agents and never reconciles the index.** Read `.arch/pinned-commit` if it exists, record it alongside `git rev-parse HEAD`, and continue. That is the whole step.

| State at Stage 1 | What Stage 1 does | Cost | |---|---|---| | `--no-arch` passed | Nothing. Gate later reports `DISABLED (--no-arch)`. | Free | | No `.arch/index.json` | Nothing. Gate later reports `NOT APPLICABLE`. | Free | | Pin equals HEAD | Record `CURRENT`. | Free | | Pin behind HEAD | Record `STALE` plus the pin. Gate later reports `UNVERIFIED`. | Free |

Stage 1 deliberately does **not** run `/team arch build` or `/team arch drift`. An earlier version did, which meant every ship after a few commits silently paid for a full index reconciliation before any product work started. Rebuilding the index is a separate, explicit act: run `/team arch build` or `/team arch drift` yourself when you want the baseline refreshed. A stale baseline degrades the gate to `UNVERIFIED`, which is the honest outcome and costs nothing.

• Autonomy: Full — no approval needed

Stage 2: Think

• Runs: `/team think <idea with research context>`
• Purpose: Architecture options, evaluate trade-offs
• Writes: `.team-ship/ARCHITECTURE-OPTIONS.md`, and records the chosen option in the brain decisions store via `/brain:update`
• Autonomy: Full — no approval needed

Stage 3: Plan

• Runs: `/team plan <idea with chosen architecture>`
• Purpose: Detailed implementation plan with phases, tasks, dependencies
• Writes: `.team-ship/PLAN.md`
• **Also declares the intended architecture** to `.team-ship/ARCH-PLAN.json`. This is the

forward counterpart to `.arch/index.json`: where the index records what exists, the plan records what this ship intends to build and where it intends to put it. Skip when `--no-arch` is passed.

Each component carries an `id`, a `title` using the `[Business Function] + [Implementation Context]` formula, a `status` of `new`, `modified`, or `unchanged`, the `intendedPaths` it will occupy, and a rationale. The plan also records `declaredAtCommit` (the current HEAD, before anything is built) and an `outOfScope` list of paths this ship must not touch. Schema and worked examples live in `skills/arch-index/references/arch-plan.md`.

Then run the declaration check, which validates shape only:

  python3 skills/arch-index/scripts/verify_arch_plan.py \
    .team-ship/ARCH-PLAN.json --declare

It deliberately does **not** check whether the declared paths exist, because nothing has been built yet. A non-zero exit here is a BLOCK: an unsatisfiable plan (a path that also appears in `outOfScope`, an asymmetric connection, an invalid status) cannot be checked later, so it is worth catching before the approval gate rather than after the build.

• Autonomy: Full — no approval needed

Stage 4: Review Plan

• Runs: `/team review <plan>`
• Purpose: Specialist review of the plan before building
• Writes: `.team-ship/REVIEW-FINDINGS.md`
• Autonomy: Full — no approval needed

═══════════════════════════════════════════════

APPROVAL GATE

═══════════════════════════════════════════════

###

Present to user, reading each item from the artifact that produced it:

- Research summary (key findings) — from .team-ship/RESEARCH-BRIEF.md

- Architecture decision (chosen option + rationale) — from

.team-ship/ARCHITECTURE-OPTIONS.md

- Plan overview (phases, estimated effort) — from .team-ship/PLAN.md

- Intended architecture (components, where each will live, what is out of

scope) — from .team-ship/ARCH-PLAN.json. Present it as a table of

component, status, and intended paths. This is the thing the build will

be held to afterwards, so it is the most useful item on this gate to

disagree with. Omit only when --no-arch was passed.

- Review findings (any critical/major issues) — from

.team-ship/REVIEW-FINDINGS.md

###

If any of those four artifacts is missing, the gate cannot be presented

honestly. Report which stage did not write its artifact and stop.

###

Ask: "Plan ready. Proceed with build? [Y/n]"

###

If user says no → stop, save all artifacts for later

If user says yes → full autonomy from here

═══════════════════════════════════════════════

Stage 5: Fix Plan

• Runs: `/team fix <plan issues from review>`
• Purpose: Address review findings before building
• Autonomy: Full (post-approval)

Stage 6: Build

• Runs: `/team develop <scope from plan>`
• Purpose: Build the actual product
• Autonomy: Full (post-approval) — bypassPermissions mode

─── HARD GATES (Stages 7–13) ───

Between Build and PR-open, run seven hard gates. Each gate follows the **Test Evidence Protocol** (`team:evidence.md`), writes its results to `.team-ship/EVIDENCE.md`, and can **BLOCK**. A BLOCK loops back to Build for a fix (bounded to a max