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.