ship
/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]."
More from open-horizon-labs/skills
dissent
Devil's advocate. Seek contrary evidence before locking in. Use when about to make a significant decision, when confidence is high but stakes are higher, or when the team is converging too quickly.
88review
Check work and detect drift before committing. A second opinion that catches misalignment early. Use at natural pause points, before PRs, or when something feels off.
81problem-space
Map what we're optimizing and what constraints we treat as real. Use before jumping to solutions, when hitting repeated blockers, or when patches keep accumulating.
79execute
Do the work. Pre-flight, build, detect drift, salvage if needed. Use when you have a clear aim and are ready to implement.
78problem-statement
Define the framing of a problem. Change the statement, change the solution space. Use when starting work, when solutions feel wrong, or when you suspect an X-Y problem.
77solution-space
Explore candidate solutions before committing. Use when you have a problem statement and need to evaluate approaches - band-aid, optimize, reframe, or redesign.
75