Review Fix
Run a review → fix → verify loop. Preserve review independence and stay within the requested change.
1. Review
- Establish the review target, fixed point, source issue or spec when one exists, and relevant repo instructions.
- Load
code-review and follow it. Tell it that documentation added or strengthened by the diff is implementation under review and cannot expand the source issue or spec; when it promises more than required, recommend narrowing the documentation. Let its fresh Standards and Spec reviewers report before editing.
- Classify every finding as
fix, not-actionable, out-of-scope, or blocked. Treat judgment-call smells as actionable only when the evidence supports changing them, and do not broaden implementation solely to satisfy documentation added or strengthened by the diff.
Continue when every finding has a disposition.
2. Fix
Fix each actionable finding within the reviewed scope:
- For behavior that can be covered at an agreed test seam, load
tdd and use a red → green cycle.
- Apply clear documentation, configuration, naming, and refactoring fixes directly.
- Load
diagnosing-bugs when the cause is unclear, the failure is difficult to reproduce, flaky, or performance-related, or a first fix fails.
Run the smallest relevant check after each fix. Continue when every actionable finding is verified or blocked with evidence.
3. Verify
- Run the review target's relevant checks.
- Inspect the final diff against the findings. Rerun
code-review when fixes materially changed the design or scope.
- Commit only when assigned commit ownership.
- Return
passed, fixed, or blocked, with finding dispositions, changed files, checks, commits when applicable, and remaining blockers.
Finish only when every finding is accounted for and every fix has verification evidence.
1---2name: review-fix3description: Reviews code changes and fixes actionable findings. Use when the user asks to review and repair a branch, pull request, commit range, or completed implementation.4---56# Review Fix78Run a review → fix → verify loop. Preserve review independence and stay within the requested change.910## 1. Review11121. Establish the review target, fixed point, source issue or spec when one exists, and relevant repo instructions.132. Load `code-review` and follow it. Tell it that documentation added or strengthened by the diff is implementation under review and cannot expand the source issue or spec; when it promises more than required, recommend narrowing the documentation. Let its fresh Standards and Spec reviewers report before editing.143. Classify every finding as `fix`, `not-actionable`, `out-of-scope`, or `blocked`. Treat judgment-call smells as actionable only when the evidence supports changing them, and do not broaden implementation solely to satisfy documentation added or strengthened by the diff.1516Continue when every finding has a disposition.1718## 2. Fix1920Fix each actionable finding within the reviewed scope:2122- For behavior that can be covered at an agreed test seam, load `tdd` and use a red → green cycle.23- Apply clear documentation, configuration, naming, and refactoring fixes directly.24- Load `diagnosing-bugs` when the cause is unclear, the failure is difficult to reproduce, flaky, or performance-related, or a first fix fails.2526Run the smallest relevant check after each fix. Continue when every actionable finding is verified or blocked with evidence.2728## 3. Verify29301. Run the review target's relevant checks.312. Inspect the final diff against the findings. Rerun `code-review` when fixes materially changed the design or scope.323. Commit only when assigned commit ownership.334. Return `passed`, `fixed`, or `blocked`, with finding dispositions, changed files, checks, commits when applicable, and remaining blockers.3435Finish only when every finding is accounted for and every fix has verification evidence.