Ship a ticket (orchestrator)

Ship a ticket (orchestrator)

You drive a ticket through the whole pipeline. Each phase is its own skill — invoke them in order and advance the tracker status as you go. The argument is a ticket reference (#123, ENG-123) or a path to a ticket file: $ARGUMENTS

Before anything, read ${CLAUDE_PLUGIN_ROOT}/references/trackers.md and determine the active tracker (GitHub Issues or Linear). Use its operations for every status change, comment, and PR link below.

The non-negotiable rule

Review and alignment happen at the plan stage, NOT the PR stage.

There is exactly one human gate: after the plan is written, you STOP and wait for explicit human approval before any code is written. Do not skip it. Do not infer approval. Wait for the user to say "approved" (or to request changes).

Sequence

1. Capture — if the input is a rough idea, run the ticket skill first to create a proper ticket with a "Problem to solve". If it's already a ticket ref, read it. → status: triage
2. Research — run the research skill. It maps the codebase and writes findings to thoughts/shared/research/. → status: research
3. Plan — run the plan skill. It produces a phased plan with success criteria in thoughts/shared/plans/. → status: plan-review
4. ⛔ HUMAN GATE — present the plan path and a short summary. Then literally stop:

   Plan is ready: thoughts/shared/plans/<slug>.md
   Reply "approved" to start implementation, or tell me what to change.
   

   Do not proceed until the user approves. → on approval, status: ready-for-dev
5. Implement — run the worktree skill to create an isolated worktree, then the implement skill against the plan inside it. → status: in-dev
6. Validate — run the validate skill. If it fails, fix and re-validate.
7. Ship — commit, open a PR with the gh CLI, and link it back to the ticket (GitHub: Closes #<num> in the PR body; Linear: comment the PR URL on the issue). → status: code-review

Keep the ticket status in sync at every step. Report progress concisely between phases.