PR Comment Response

Respond to pull request review comments using a test-driven, verify-first approach. Never blindly accept reviewer suggestions — prove they're right with a failing test before changing code.

When to Use

• •After receiving code review comments on a PR
• •When a reviewer claims code has a bug, edge case, or incorrect behavior
• •When you need to systematically work through multiple PR comments
• •Invoke with: /pr-comment-response <PR-number>

Core Principle

Reviewers can be wrong. Treat every bug claim as a hypothesis, not a fact. The workflow is:

1. •Read the comment
2. •Understand the claim
3. •Write a test that would fail if the claim is true
4. •Run the test — does it actually fail?
5. •Only fix code if the test fails
6. •If the test passes, the reviewer was wrong — respond with evidence

Workflow

Step 1: Fetch PR Comments

# Get all review comments on the PR
gh pr view <PR-number> --json reviews,comments
gh api repos/{owner}/{repo}/pulls/<PR-number>/comments

Collect every comment. Categorize each one:

Focus the verify-first workflow on bug reports and correctness claims. These are the comments where blind trust is most dangerous.

Step 2: Analyze Each Bug Claim

For each comment claiming a bug or incorrect behavior:

1. •Read the code the comment refers to — understand it fully before proceeding
2. •Identify the claim — what specific behavior does the reviewer say is wrong?
3. •Identify the trigger — what input, state, or condition would expose the bug?
4. •Assess plausibility — does the claim make logical sense given the code?

Document your analysis before writing any test:

### Comment: [reviewer quote or summary]
- **File**: path/to/file.rs:LINE
- **Claim**: [what the reviewer says is wrong]
- **Trigger condition**: [input/state that would expose the bug]
- **Plausibility**: [high/medium/low — your initial assessment and why]

Step 3: Write a Failing Test

Write a test that directly targets the claimed bug. The test should:

• •Use the exact trigger condition the reviewer described (or a minimal reproduction)
• •Assert the correct behavior (what the code should do)
• •Be placed in the appropriate test module for the file under review
• •Have a clear, descriptive name referencing the issue

#[test]
fn handles_empty_input_without_panic() {
    // Reviewer claimed: empty input causes panic at line 42
    // This test verifies that claim
    let result = function_under_review(&[]);
    assert!(result.is_ok(), "empty input should not panic");
}

Do NOT touch the production code yet.

Step 4: Run the Test

cargo test <test_name> -- --nocapture

Two outcomes:

Test FAILS — Reviewer was right

The bug is confirmed. Proceed to Step 5.

Record:

- **Verdict**: CONFIRMED — test fails with: [error message]

Test PASSES — Reviewer was wrong

The code already handles this case correctly. Do not change the code.

Record:

- **Verdict**: NOT REPRODUCED — test passes, code already handles this correctly
- **Response**: [draft reply to reviewer explaining why the code is correct]

Skip to Step 6 for this comment.

Step 5: Fix the Code (Only After Confirmed Failure)

Now — and only now — fix the production code:

1. •Make the minimal change needed to pass the test
2. •Run the specific test to confirm it passes
3. •Run the full test suite to check for regressions

# Confirm the fix
cargo test <test_name> -- --nocapture

# Check for regressions
cargo test

If the full suite passes, the fix is good. If new failures appear, investigate — the fix may have been too broad or revealed a deeper issue.

Step 6: Respond to the Reviewer

Draft responses for each comment:

For confirmed bugs:

Good catch! Confirmed — wrote a regression test (`test_name`) that reproduces this.
Fixed in [commit SHA]. The issue was [brief explanation].

For unconfirmed claims:

I investigated this and wrote a test (`test_name`) targeting the scenario you described.
The test passes against the current code — [brief explanation of why the code is correct].
I've kept the test as it documents this edge case. Let me know if I'm missing something.

For non-bug comments (style, refactor, questions): Address directly without the test workflow.

Handling Multiple Comments

When a PR has many comments:

1. •Triage first — categorize all comments before acting on any
2. •Prioritize bug claims — handle these with full verify-first workflow
3. •Batch style/nitpick fixes — apply these together in one pass
4. •Group related comments — if multiple comments point at the same underlying issue, write one comprehensive test

Output Format

After processing all comments, produce a summary:

## PR Comment Response Summary — PR #<number>

### Bug Claims Investigated

| # | Comment | File | Verdict | Test | Fix |
|---|---------|------|---------|------|-----|
| 1 | [summary] | path:line | CONFIRMED | test_name | commit SHA |
| 2 | [summary] | path:line | NOT REPRODUCED | test_name | N/A |

### Other Changes

- [Style fix]: renamed `foo` to `bar` per reviewer suggestion
- [Refactor]: extracted helper function for clarity
- [Reply]: explained why X is intentional

### Test Results

- New tests added: N
- All tests passing: yes/no
- Regressions found: none / [details]

Anti-Patterns to Avoid

• •Blind application: Never change code just because a reviewer said to
• •Skipping the test: Always write the test before fixing, even if the bug seems obvious
• •Fixing without failing: If your test passes, the "bug" isn't a bug — don't fix it
• •Over-scoping fixes: Fix only what the test proves is broken, nothing more
• •Deleting the test on pass: Keep passing tests — they document edge cases
• •Arguing without evidence: If you disagree with a reviewer, show a passing test, don't just assert correctness

Related Skills

• •/test-strategy - Choose appropriate test type (unit, property, fuzz, Kani)
• •/security-reviewer - For security-related review comments
• •/bench-compare - If reviewer flags a performance issue