Command
Flagship/ship-issue
autonomous ticket delivery
One GitHub issue in, a reviewed CI-green pull request out.
See it run
/ship-issue runs, in order.How to run it
Run it in your harness
/ship-issue <issue-number>... | next [epic <epic-number>] [optional extra guidance]<angle brackets> = required · [square brackets] = optional
How it works
The architect reads the issue and sets flags. Those flags decide who else sits — a UI story pulls a designer, a schema change pulls an architect. Product-manager and principal-engineer always review.
Plan
The architect reads the issue, writes the plan, and sets the flags that pick every later specialist.
Crew
Build
Engineers implement in an isolated worktree. Any specialist flagged in Plan writes a spec first; the build follows it.
Always
Also sit when
ux-ui-designerthe story changes on-screen UIart-directorthe story changes rendered artarchitectthe story changes structure or schema
PR + CI
Open a pull request. The SDET runs the test plan; if checks go red, an engineer fixes until they are green.
Crew
Review
Two reviewers sit on the first pushed head. After a fixer, failers sit again; a prior ACCEPT carries unless the delta can invalidate it.
Also sit when
architectnew subsystem, schema, or a change that crosses many modulesux-ui-designeron-screen UI — screens, flows, componentsart-directorrendered art (games, illustration), not app chromesdetthe plan asks for a specialist test reviewdevops-engineerpipeline, images, or how the project shipstechnical-writerdocumented behaviour or a public API/CLI
Hand off
You get a PR to merge — or it merges if you asked.
No extra spawn — the run closes out.
When to use
- A tracked ticket (or a small related bundle) is ready to build.
- Whole epic? Use /ship-epic. A defect? Use /shipmates-fix-bug.
The skill
The installer ships the full skill — stages, gates, config — from commands/ship-issue.md.