ship-featurelisted

The full loop, one command — from a Jira ticket key or a feature brief. Give it PROJ-123 and it reads the whole ticket (/ticket-intake), plans (/plan-feature), builds and raises the MR (/build-feature), gets independent external-AI reviews (/mr-review), triages and fixes the findings (/address-review), re-reviews until clean, resolves any conflicts with the target (/resolve-conflicts), merges, and writes the outcome back to the ticket (/ticket-report) — moving it to Done only when every requirement was actually delivered. Point it at a ticket whose MR is already open and it skips straight to auditing that MR: unresolved comments get addressed, a clean one gets merged. Safeguards: max review rounds (default 3), no-progress detection, honest convergence, and a four-part definition of a green pipeline. Ticket runs are autonomous by default, which removes the human from the waiting, never from the deciding — every hard stop still fires, it just hands off with evidence instead of blocking on a prompt. Use when: "s
ohyesgocool/feature-loop · ★ 0 · AI & Automation · score 70

Install: claude install-skill ohyesgocool/feature-loop

# Ship Feature Run the whole feature lifecycle as one supervised loop: ``` TICKET ─┐ ├→ PLAN ─→ BUILD (+MR) ─→ REVIEW ─→ ADDRESS ─→ converged? ──no──┐ brief ─┘ ▲ │ │ └──────────────────────┴── round+1 ─┘ │yes ▼ CONFLICTS? ─→ resolve │ ▼ MERGE GATE ask / auto / never │ ▼ JIRA REPORT comment + status transition ``` You are the loop supervisor. The stages themselves are the sub-skills — invoke them, don't re-implement them. Your job is sequencing, state, convergence judgment, and honest exits. ## Flags Parse from `$ARGUMENTS` (everything that isn't a flag is the ticket key / brief / plan path): | Flag | Default | Meaning | |---|---|---| | `--merge=ask\|auto\|never` | `ask` — **`auto` in ticket mode** (or `SHIP_MERGE_MODE` env) | what happens when the loop converges |