local-review-bug

name	local-review-bug
description	Qualitative code review for bug fixes — verifies root-cause alignment and test coverage before PR creation. Use after implement-task completes for bug tickets.

Bug Fix Local Review Skill

Review the implemented changes against the approved RCA and plan. You have access to the workspace and codebase. Run git diff origin/main...HEAD to see what changed.

Step 1 — Mechanical Checks

Run these first and fix any failures before proceeding to the qualitative review:

1. Linters — run the project's linter (e.g. ruff check ., go vet ./...)
2. Type checker — run mypy or equivalent if configured
3. Test suite — run all tests and confirm they pass

If any mechanical check fails and cannot be fixed, report it in the feedback.

Step 2 — Qualitative Checklist

Evaluate the diff against each item:

1. Root cause alignment — Does the change address the confirmed root cause, or only a symptom?

2. Test proof — Do the new/modified tests actually prove the bug is fixed? Would they fail without the fix?

3. Fix stability — Could someone break this fix without a test catching it?

4. Plan scope adherence — Does the diff match the approved plan scope, or has it drifted?

5. Call site completeness — Are there similar patterns elsewhere in the codebase that need the same treatment?

6. Backward compatibility — Is the fix safe to roll back? Does it avoid breaking interfaces?

7. Bidirectional validation — Does the commit log show [bidirectional: PASS], confirming the agent verified the test fails without the fix?

8. Ordering invariants — Find the ## Ordering Invariants section in the approved plan above. For each entry, locate the relevant calls in the diff (git diff origin/main...HEAD) and verify the stated order is preserved in the implementation. If the section says "None identified.", spot-check the diff for operation pairs with non-obvious side effects (e.g. a call that deletes or resets shared state before a call that depends on it). Flag any reversal as a blocking issue in your feedback.

Output

The verdict format is a forge protocol constraint — use it exactly:

verdict: adequate

or

verdict: tests_incomplete

or

verdict: symptom_only

Followed by:

feedback: <specific, actionable description of what needs to change — or "All checks passed." if adequate>

Only these three verdict values are valid. Do not use any other string.