Autonomous, goal-seeking controller — pursue a stated goal by running a phase, reading its STRUCTURED results, and re-planning the next phase FROM those results, looping until a goal predicate, convergence, human gate, or budget backstop fires. The pipeline is chosen by an LLM planner each iteration, not baked in — this is the generalized, more powerful sibling of /full-work (which flies a fixed issue→PR path). Persists across turns (ScheduleWakeup) and pauses at human gates (AskUserQuestion). Use when the user says "/autopilot <goal>", "pursue this goal autonomously", "keep working until <X> is true", or wants an open-ended objective driven to done with result-driven re-planning. NOT /loop (which re-fires a fixed prompt) and NOT a raw Workflow (which can't pause for humans or persist across turns).
Author a house-style bug issue and file it. Locate the offending code with an Explore agent and cite exact file:line, confirm the bug where feasible (build the failing snippet / reason the edge case) and label it BUILD-CONFIRMED vs SUSPECTED honestly, then open it via gh issue create. Use when the user says "/bug-report <description>", "file a bug for …", or wants a defect turned into a clean issue. Sits upstream of /understand — its output should be consumable by /understand <new#> immediately.
Author a house-style enhancement issue and file it. Frame the use-case, sketch an API surface consistent with house idioms (the (value, ok) contract, generic-first, non-mutating standard), note alternatives/trade-offs, cross-reference related packages/issues/standards, then open it via gh issue create with the enhancement label. Flags RFC-sized directions that should be a discussion, not one issue. Use when the user says "/feature-request <description>", "propose a feature for …", or wants a capability turned into a clean issue. Sits upstream of /understand — its output feeds /full-work directly.
Autonomously drive an open PR to merge-ready by reacting to whichever fires first — a CI failure, a new review comment (Copilot/bot/human), or a base-branch merge conflict. On green it keeps the branch current with base and arms auto-merge so the PR lands before it can go stale. Loops up to N iterations (default 15), dedups handled comments, detects stuck loops, and stops on success/cap/human-needed. Use when the user says "/pr-watch", "/pr-babysit", "babysit the PR", "watch the PR", or "get this PR to green".
Phase 2 of the delivery pipeline — turn a scope statement (or an issue) into an implementation plan: ordered steps, the exact files to touch, risks, and any decisions that need a human. The judgement phase; use the strongest model. Use when the user says "/design <issue#>", "plan out this change", or hands over a scope artifact. Produces a plan — writes no code.
Drive a GitHub issue through the whole delivery lifecycle — understand → design → implement → test → verify → review → PR — by composing focused skills/agents, each run in its own context fork so the parent stays lean. Mechanical phases use cheaper models; judgement phases use the strongest. Pauses at human gates (design approval, ambiguous/oversized scope). Use when the user says "/full-work <issue#>", "take issue N to a PR", or wants a routine issue delivered end-to-end.
Phase 4 of the delivery pipeline — run the Go test suite (root + nested modules, race, vet, gofmt, and the coverage floor) and return a compact pass/fail verdict, not raw logs. Use when the user says "/test", "run the tests", "check the suite", or before pushing. Diagnoses failures briefly; fixing them is /code's job.
Phase 1 of the delivery pipeline — read a GitHub issue (plus its linked issues/PRs), locate the relevant code, and restate scope + acceptance criteria as a compact artifact. Flags issues too big/vague for an autonomous run. Use when the user says "/understand <issue#>", "scope out issue N", or wants an issue triaged before planning. Reads only — writes no code.