Triage a Single Review Comment

One pasted comment, verified against the code. Escalate to adversarial debate only when a correctness claim survives the cheap checks — two subagents with opposite briefs beat one reader carrying the bot's framing, but most comments never get that far.

Step 1 — Get the comment

• Pasted text: use it as-is. Extract the claimed file/line from the comment body or its diff hunk.
• Permalink (...#discussion_r<id> or ...#issuecomment-<id>): fetch the body, path, and line via gh api repos/{owner}/{repo}/pulls/comments/{id} (or issues/comments/{id}).

If the comment names no location, find the code it's talking about before judging anything.

Step 2 — Cheap checks, in order

Staleness gate first — before reading anything else:

git log --oneline -- <path>   # commits touching the cited file
git diff HEAD~<n> -- <path>   # did a later commit change the cited lines?

Already fixed → rule stale, name the commit, stop. Nearly free, and it settles a large share of bot comments.

Then:

• Nit — cosmetic (naming, typo, formatting); no behavior at stake. Fix only if trivial.
• Decidable in one or two reads — the claim hinges on one checkable fact (the field is not nullable, the guard is two lines up). Confirm it and rule.

Escalate only when the claim concerns correctness and the decisive fact is not settled by a couple of reads.

Step 3 — Evidence pack

Gather it once, in the main thread; the subagents must not each pay to rediscover it:

• the cited hunk plus its enclosing function
• direct callers of that function
• guards, validators, type constraints, or config bearing on the claim

Pass the same pack inline to every brief below.

Step 4 — Prosecutor

Prove this review comment describes a real defect. Build a concrete failure scenario: specific inputs or state → the wrong behavior, with a file:line citation for every step. The evidence pack is a starting point, not a boundary — read further if the answer isn't in it. If you cannot construct a failure scenario from the actual code, say so plainly; do not manufacture a strained one. "I could not build a failure scenario" is a valid and valuable answer.

Return ≤200 words: claim · trace with file:line · confidence · what would change your mind.

Concedes → rule false positive and stop. No Defender; the concession is the verdict.

Step 5 — Defender (only if a trace was built)

The trace below claims a defect. Prove it cannot occur. Name the specific invariant, guard, config, or commit preventing it, with file:line citations. The evidence pack is a starting point, not a boundary. If you find no protecting mechanism, say so plainly; do not hand-wave. "I found no protection" is a valid and valuable answer.

Return ≤200 words: which trace step fails and why · invariant with file:line · confidence · what would change your mind.

Rebutting a named trace is bounded; searching the repo for any protection is not. That is why it runs second.

Step 6 — Judge and rule

Weigh only verifiable claims:

• A traced failure scenario beats generalities; a cited invariant beats a hypothetical.
• Concessions dominate: prosecutor built nothing → false positive; defender found no protection → valid.
• Spot-check the decisive citation yourself before ruling. The judge grades evidence, not rhetoric.
• Both briefs weak, or contradictory readings of the same code → read that code yourself and rule directly.

Report one compact verdict, not a table:

• Claim — one line, in your own words.
• Verdict — valid / false positive / stale / nit.
• Proof — the decisive evidence (file:line), and which side conceded, if either.
• Proposed fix — only if valid; the smallest change that resolves it.

The user decides from this; stop here unless approved or invoked with --fix.

Step 7 — Fix

On approval (or immediately when invoked with --fix):

• Minimal, targeted fix only — exactly what the finding requires. If the comment asked for one line, change one line; do not "improve" neighbors.
• Check the fix introduces no regression or behavior change beyond the finding.
• Commit atomically per global commit rules. Push only when asked.
• Where useful, draft a reply comment (fix reference if valid, a short justification if false positive).