/qa-triage-batch

name: qa-triage-batch
description: Fan out /qa-triage across a queue of qa-labeled reports in parallel, reconcile them across reports to cluster shared root causes, present one consolidated decision gate, and — on approval — create the resulting tech issues.
disable-model-invocation: true
argument-hint: "[report# …]"

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,