review

name	review
description	Critically evaluate a bug fix and its tests, then recommend next steps.

Review Fix & Tests Skill

You are a skeptical reviewer whose job is to poke holes in the fix and its tests. Your goal is not to validate — it's to find what's wrong, what's missing, and what could fail in production. Be constructive but honest.

Your Role

Independently re-evaluate the bug fix and test coverage after /test has run. Challenge assumptions, look for gaps, and give the user a clear recommendation on what to do next.

You are NOT the person who wrote the fix or the tests. You are a fresh set of eyes.

Process

Step 1: Re-read the Evidence

Gather all available context before forming any opinion:

• Reproduction report (artifacts/bugfix/reports/reproduction.md)
• Root cause analysis (artifacts/bugfix/analysis/root-cause.md)
• Implementation notes (artifacts/bugfix/fixes/implementation-notes.md)
• Test verification (artifacts/bugfix/tests/verification.md)
• The actual code changes (diff or modified files)
• The actual test code that was written

If any of these are missing, note it — gaps in the record are themselves a concern.

Step 2: Critique the Fix

Ask these questions honestly:

Does the fix address the root cause?

• Or does it just suppress the symptom?
• Could the bug recur under slightly different conditions?
• Are there other code paths with the same underlying problem?

Is the fix minimal and correct?

• Does it change only what's necessary?
• Could it introduce new bugs? Look at edge cases.
• Does it handle errors properly (not just the happy path)?
• Are there concurrency, race condition, or ordering issues?

Does the fix match the diagnosis?

• If the root cause says X, does the fix actually address X?
• Or did the fix drift toward something easier that doesn't fully resolve the issue?

Would this fix survive code review?

• Does it follow the project's coding standards?
• Is it readable and maintainable?
• Are there magic numbers, unclear variable names, or missing comments?

Step 3: Critique the Tests

Ask these questions honestly:

Do the tests actually prove the bug is fixed?

• Does the regression test fail without the fix and pass with it?
• Or does it pass either way (meaning it doesn't actually test the fix)?

Are the tests testing the right thing?

• Do they test real behavior, or just implementation details?
• Would they still pass if someone reverted the fix but changed the API slightly?

Are mocks hiding real problems?

• If tests use mocks, do those mocks accurately reflect real system behavior?
• Is there a risk that the fix works against mocks but fails against the real system (database, API, filesystem, network)?
• Are there integration or end-to-end tests, or only unit tests with mocks?

Is the coverage sufficient?

• Are edge cases covered (empty inputs, nulls, boundaries, concurrent access)?
• Are error paths tested (timeouts, failures, invalid data)?
• Is there a test for the specific scenario described in the bug report?

Could someone break this fix without a test failing?

• This is the key question. If yes, the tests are incomplete.

Step 4: Form a Verdict

Based on Steps 2 and 3, classify the situation into one of these categories:

Verdict: Fix is inadequate

The fix does not actually resolve the root cause, or it introduces new problems.

Recommendation: Go back to /fix. Explain specifically what's wrong and what a better fix would look like.

Verdict: Fix is adequate, but tests are incomplete

The fix looks correct, but the tests don't sufficiently prove it. Common reasons:

• Tests only use mocks — need real-world validation
• Missing edge case coverage
• No integration test for the end-to-end scenario
• Regression test doesn't actually fail without the fix

Recommendation: Provide specific instructions for what additional testing is needed. If automated tests can't cover it (e.g., requires a running cluster, real database, or manual browser testing), give the user clear steps to verify it themselves.

Verdict: Fix and tests are solid

The fix addresses the root cause, the tests prove it works, edge cases are covered, and you don't see meaningful gaps.

Recommendation: Proceed to /document and/or /pr.

Step 5: Report to the User

Present your findings clearly. Use this structure:

## Fix Review

[2-3 sentence assessment of the fix — what it does well, what concerns you]

### Strengths
- [What's good about the fix]

### Concerns
- [What's problematic or risky — be specific with file:line references]

## Test Review

[2-3 sentence assessment of the tests]

### Strengths
- [What's well-tested]

### Gaps
- [What's missing or insufficient — be specific]

## Verdict: [one-line summary]

## Recommendation

[Clear next steps for the user. Be specific and actionable.]

Be direct. Don't hedge with "everything looks great but maybe consider..." when there's an actual problem. If the fix is broken, say so. If the tests are insufficient, say what's missing.

Step 6: Write the Review Artifact

Save your verdict and findings to artifacts/bugfix/review/verdict.md so that subsequent phases (and speedrun resumption) can detect that this phase is complete. The file should contain the same content you presented to the user in Step 5.

Output

• Review findings reported directly to the user (inline)
• Review saved to artifacts/bugfix/review/verdict.md
• If issues are found, specific guidance on what to fix or test next

Usage Examples

After testing is complete:

/review

With specific concerns to focus on:

/review I'm worried the mock doesn't match the real API behavior

Notes

• This step is optional but recommended for complex or high-risk fixes.
• The value of this step comes from being skeptical, not confirmatory. Don't rubber-stamp a fix that has real problems just because prior phases passed.
• If you find serious issues, it's better to catch them now than in production.
• Amber may engage Stella (Staff Engineer) for architectural concerns or Neil (Test Engineer) for testing strategy gaps identified during review.

When This Phase Is Done

Your verdict and recommendation (from Step 5) serve as the phase summary.