QA Triage Batch

QA Triage Batch

Run the open qa-labeled reports as a parallel batch: one background subagent per report runs /qa-triage's analysis to its draft, a cross-report pass reconciles all the drafts at once, and a single consolidated gate replaces the N separate per-report STOPs. On approval, the orchestrator creates the tech issues, closes the not-a-bugs, and recommends /resolve-issue for trivial-cosmetics.

Use this when a backlog of QA reports has accumulated. For a single report, use /qa-triage directly — the batch only earns its keep when there are several, because its real value is cross-report reconciliation: a single run is blind to the others, so it can't see that several reports share one root cause. A batch is the only vantage that sees all N at once.

Sibling to /autopilot-batch in the autopilot family (Phase 3). It mirrors that skill's shape — announce → fan out → gate → act → report, plus the escape hatch — but its back half differs on purpose (it creates issues rather than merging PRs, gates before creation rather than after, and reconciles across items). The two share conventions, not code.

Where this runs (read first)

Run this from the target application repository — the repo whose qa reports and app code these are (e.g. the Rails app). Not from dotfiles. You need the reports and the code, because /qa-triage confirms every symptom against the source. Unlike /autopilot-batch, there is no worktree dependency — the fan-out is read-only code investigation (no server, no port 3000, no shared DB, no file writes), so all subagents share the one working tree safely. If the cwd is dotfiles (or any repo that doesn't own these reports), stop and say so.

Arguments

• (no args) — triage every open qa-labeled report (minus any already in-flight; see Step 1).
• [report# …] — scope to the listed reports only (e.g. 503 511 488). Everything else is untouched. Use this to re-run a subset without re-triaging the whole backlog.

The model policy — "Opus analyzes, Fable reconciles"

Analysis runs at Opus 5; the reconcile runs at Fable. Unlike /autopilot-batch's fan-out scale — where cheaper builds under a gating review floor save real latency and limit headroom — a QA batch is low-volume (a handful of reports), so there is no cost case for going below Opus on analysis, and classification ("is this a bug or intended behavior?") is judgment work. There is no review floor behind the analysis the way /autopilot-batch has one; the human gate is the only safety net, so favor quality. The reconcile is the genuinely hard cross-report judgment — the whole reason to batch — and it is a single subagent, so running it at Fable buys the best judgment exactly where it matters most, for a negligible cost delta. Earn a Sonnet-analyze split later (rule of three) only if the volume grows or an obviously-bounded report pattern emerges.

Escape hatch (batch-level)

A single report that can't be confidently triaged must not halt the batch. If an analysis subagent can't reproduce the symptom in the code, or the report is genuinely ambiguous, it stops and reports — that report is surfaced at the consolidated gate as "needs your eyes," never silently dropped, and nothing is drafted for it. One uncertain report never stops the rest. Halt the whole batch only for a systemic problem: the cwd is the wrong repo, or there are no open qa reports to triage.

Your task

Announce the run first: how many qa reports are open, how many are being triaged vs. skipped as already in-flight (Step 1), and that you will fan out one background subagent per report.

Step 0 — Preconditions

• Confirm the cwd is the target app repo (see "Where this runs"), on a clean default branch, then git pull.
• Resolve the invoker once: gh api user --jq .login. Each report's analysis needs it to decide the verification @-mention (skip the mention when author == invoker), and the orchestrator needs it again when acting.

Step 1 — Assemble the batch (self-healing)

• gh issue list --label qa --state open --json number,title,author,body. If scoped by arg, restrict to those numbers.

• Skip reports already in-flight. A report that has already been triaged carries a tech issue back-referencing it (Triggered by QA report #<n>). Drop those — they are being handled, not pending. Use search only to narrow, then confirm the exact back-reference client-side — GitHub full-text search tokenizes #<n> loosely, so it neither guarantees the exact number nor an exact phrase, and matching on it alone would both miss links and skip the wrong reports:

  # Fetch every issue carrying the back-reference phrase, then filter by exact substring.
  gh issue list --state all --search 'Triggered by QA report in:body' \
    --json number,body \
    --jq '[.[] | select(.body | contains("Triggered by QA report #<n>")) | .number]'

  A non-empty result means report <n> is already linked — skip it. This mirrors /autopilot-triage's self-heal (which keys on a structured headRefName match for existing PRs), keyed here on an exact body substring instead. Report what was skipped and why.

• If nothing remains: stop — the QA queue is clear.

Step 2 — Fan out the analysis

For each report, spawn a background subagent:

• model: opus, run_in_background: true. No isolation: worktree — read-only investigation, shared tree is safe.

• prompt: run /qa-triage <n> through its analysis and draft (steps 1–5) and STOP at its decision gate (step 6). Create, comment on, close, and edit nothing — you have no human to approve, and the skill's gate is exactly where you halt. Then return, as the final message, a structured triage record (not prose):

  report:        #<n> — <title>
  author:        <login>   (mention: <@author | skip: == invoker | skip: bot>)
  bucket:        not-a-bug | trivial-cosmetic | one-issue | multiple
  root_cause:    <one-line root cause grounded in the code>
  files:         <the file(s)/surface the fix touches>   ← the clustering key
  drafts:        <for each proposed tech issue: title, full body, labels, closing plan>
  ambiguities:   <anything to raise at the gate — or "none">
  escape_hatch:  <"" | "STOPPED — <why>: couldn't confirm / genuinely ambiguous">

Spawn them together so they run in parallel. Since they create nothing, there is no per-report label lifecycle to manage and no worktree to reclaim.