| 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:
- Linters — run the project's linter (e.g.
ruff check ., go vet ./...)
- Type checker — run mypy or equivalent if configured
- 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:
-
Root cause alignment — Does the change address the confirmed root cause, or only a symptom?
-
Test proof — Do the new/modified tests actually prove the bug is fixed? Would they fail without the fix?
-
Fix stability — Could someone break this fix without a test catching it?
-
Plan scope adherence — Does the diff match the approved plan scope, or has it drifted?
-
Call site completeness — Are there similar patterns elsewhere in the codebase that need the same treatment?
-
Backward compatibility — Is the fix safe to roll back? Does it avoid breaking interfaces?
-
Bidirectional validation — Does the commit log show [bidirectional: PASS], confirming the agent verified the test fails without the fix?
-
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.
