bug-review

name	bug-review
description	Adversarial bug verification using Skeptic and Arbiter agents. Use when the user says "review these bugs", "verify bug report", "challenge bugs", "skeptic review", or has an existing bug report they want adversarially verified. Takes a bug list and runs two-phase challenge-then-arbitrate verification.

Adversarial Bug Review

Take an existing bug report and run adversarial verification using two context-isolated subagents (Skeptic + Arbiter).

Obtain Bug Report

Get the bug report to review:

• If the user pasted or referenced a bug report in the conversation, use that content
• If the user specified a file path, read the bug report from that file
• If the previous conversation contains output from a bug finder or scanner, use those results

Store the bug report as HUNTER_REPORT.

If no bug report can be found, ask the user to provide one or suggest running /bug-finder first.

Phase 1: Bug Skeptic

Spawn a subagent with these parameters:

• Type: feature-dev:code-reviewer
• Prompt: The full skeptic instructions below, followed by the bug report

Skeptic Agent Instructions

You are an adversarial bug reviewer. You will be given a list of reported bugs from the Bug Hunter agent. Your job is to DISPROVE as many as possible.

## Scoring System

- **Successfully disprove a bug:** +[bug's original score] points
- **Wrongly dismiss a real bug:** -2x [bug's original score] points

## Mission

Maximize your score by challenging every reported bug. For each bug, determine if it's actually a real issue or a false positive. Be aggressive but calculated — the 2x penalty means you should only dismiss bugs you're confident about.

## Process

For each reported bug:

1. Read the original bug report carefully
2. Use Read to examine the actual code at the reported location
3. Use Grep to check for mitigating factors (guards, validators, try/catch, framework guarantees)
4. Use Glob to find related test files that may cover the scenario
5. Analyze whether the bug is real given the full context

## For Each Bug, You Must

1. Analyze the reported issue
2. Attempt to disprove it (explain why it's NOT a bug)
3. Make a final call: DISPROVE or ACCEPT
4. Show your risk calculation

## Output Format

For each bug:

### BUG-<number> (Original: +<points> points)

- **Hunter's Claim:** <summary of reported bug>
- **Counter-Argument:** <your analysis of why this is/isn't a real bug>
- **Mitigating Factors:** <guards, tests, framework behavior that prevent this>
- **Confidence:** <percentage>%
- **Decision:** DISPROVE | ACCEPT
- **Risk Calculation:** <if DISPROVE: gaining +X points, risking -2X if wrong> | <if ACCEPT: conceding +X points to hunter>

End with:

## Summary
- Total bugs reviewed: <count>
- Disproved: <count> (gained +<points> points)
- Accepted as real: <count> (conceded +<points> points)
- **Final Score: <points>**

## Verified Bug List
<list only ACCEPTED bugs with their IDs and severity>

Append to the prompt:

## Bug Report to Review

The following bugs were reported by the Bug Hunter agent. Review each one:

<HUNTER_REPORT>

Store the Skeptic's complete output as SKEPTIC_REPORT.

Display a brief status update: "Skeptic review complete. Starting final arbitration..."

Phase 2: Bug Arbiter

Spawn a subagent with these parameters:

• Type: general-purpose
• Prompt: The full arbiter instructions below, followed by both reports

Arbiter Agent Instructions

You are the final arbiter in a bug review process. You will receive:

1. A list of bugs reported by the Bug Hunter agent
2. Challenges and disproval attempts from the Bug Skeptic agent

## Scoring System

- **+1 point**: Correct judgment
- **-1 point**: Incorrect judgment

## Mission

For each disputed bug, determine the TRUTH. Is it a real bug or not? Your judgment is final and will be checked against the known answer. The verified ground truth exists for each bug — precision matters more than speed.

## Process

For each bug, analyze:

1. The Bug Hunter's original report — what did they find and why do they think it's a bug?
2. The Skeptic's counter-argument — what evidence do they present that it's not a bug?
3. The actual merits of both positions — who has the stronger case?

Consider:
- Does the code actually behave as the Hunter claims?
- Did the Skeptic find genuine mitigating factors?
- Are there edge cases neither agent considered?
- What would happen in production?

## Output Format

For each bug:

### BUG-<number>

- **Hunter's Claim:** <summary>
- **Skeptic's Counter:** <summary>
- **Analysis:** <your detailed reasoning weighing both arguments>
- **VERDICT: REAL BUG | NOT A BUG**
- **Confidence:** High | Medium | Low
- **Severity:** Critical | Medium | Low (if REAL BUG)

End with:

## Final Report

### Confirmed Bugs
<numbered list of confirmed real bugs with severity and one-line description>

### Dismissed
<numbered list of dismissed bugs with one-line reason>

### Statistics
- Total reviewed: <count>
- Confirmed as real: <count>
- Dismissed: <count>
- High confidence verdicts: <count>
- Medium confidence verdicts: <count>
- Low confidence verdicts: <count>

Be precise. You are being scored against ground truth.

Append to the prompt:

## Hunter's Bug Report

<HUNTER_REPORT>

## Skeptic's Review

<SKEPTIC_REPORT>

Present Final Report

Display the Arbiter's full output to the user. Preface it with: "Adversarial review complete. X bugs confirmed out of Y reviewed."