/ship

Optimize the delivery path from completed work to working install. When execution is cheap, delivery is the work.

Ship is the final step of the Execution phase. Code that isn't in users' hands isn't delivering value.

When to Use

Invoke /ship when execution is complete, tests pass, review is done, and you need to get changes to users. Also usable as a standalone diagnostic: run /ship against a stalled delivery pipeline to surface delivery-path tax without deploying anything.

Do not use when: You're still building. Ship is for completed work.

The Ship Process

Step 1: Identify the Delivery Path

Map the path from code to working install:

"The delivery path for this change is: [local] → [PR/review] → [merge] → [CI/CD] → [staging/prod] → [user install]."

Be specific. Name each step and who/what owns it.

Step 2: Assess the Delivery-Path Tax

The delivery-path tax is friction that slows velocity. Identify where time is lost across: review queue, merge conflicts/stability, gate/scan time (serial vs parallel, flaky), approval bottlenecks, deploy duration, rollback readiness, and manual steps.

Step 3: Execute the Ship

With CI/CD Context

Reference the pipeline — point to the specific build/deploy configuration
Trigger the appropriate workflow — label PRs, push to deploy branches, etc.
Monitor the pipeline — watch for failures, report status
Verify deployment — confirm the change is live

Without CI/CD Context

List deployment steps — what needs to happen in order
Execute each step — or provide commands to execute
Verify each stage — confirm success before proceeding
Report final status — confirm user-facing change is live

Step 4: Post-Ship Verification

Shipping isn't done until you verify:

Is it running? — deployed and executing
Is it working? — intended behavior is present
Is it reachable? — users can access/use it
Were the promised characteristics delivered? — shipped result matches the declared success criteria from /execute

Create ad-hoc verification tests if needed — the point is confidence, not permanent infrastructure. Verification ties back to what the work claimed it would deliver, not only whether deployment completed.

Output Format

## Ship Report

**Shipped:** [what was shipped]
**Target:** [where it was shipped to]
**Path:** [the delivery path taken]

### Delivery-Path Tax Identified
- [Friction point 1]: [time/effort cost]
- [Friction point 2]: [time/effort cost]

### Ship Actions Taken
1. [Action 1 - result]
2. [Action 2 - result]

### Verification
- [x] Deployed successfully
- [x] Running in target environment
- [x] User-facing functionality confirmed

### Delivered Characteristics Validation
- [x] [Declared criterion/characteristic 1]
- [ ] [Declared criterion/characteristic 2, if not yet verified]

### Recommendations
[Any suggestions for reducing delivery-path tax in future]

Session Persistence

Reads: Aim, Solution Space, Execute status — including declared success criteria and deliverable characteristics.

Writes: Deployment status and delivered-characteristics validation:

## Ship
**Updated:** <timestamp>
**Status:** [staged | deployed | verified | rolled-back]

[shipping notes, verification results, delivered-characteristics validation]

Position in Framework

Comes after: /execute (the work is done, now deliver it). Leads to: /review (did the shipped change achieve the aim?), then back to /aim. This is the end of the line: Ship is where code becomes value.

Key Vocabulary

Delivery Path: The journey from merged code to working install
Delivery-Path Tax: Friction that slows delivery (review time, merge time, gate time, approval time)
Working Install: The code is running and users can interact with it