--- name: fix-loop description: Iterative review-fix cycle that eliminates all critical issues. Runs code-reviewer, fixes critical findings, verifies tests pass, and repeats until clean or max iterations reached. Use when the user says "review and fix", "find and fix bugs", "clean up the code", "fix all issues", "review then fix", or any request that combines finding problems with resolving them automatically. credit: "Adapted from channingwalton/dotfiles (https://github.com/channingwalton/dotfiles)" --- # Fix Loop Autonomous review-fix cycle that iterates until all critical issues are resolved. The value of this skill is that it separates *finding* problems from *fixing* them. The code-reviewer agent operates read-only with a disconfirmation mindset — it actively looks for flaws. The fixer agent then applies minimal, targeted changes. This separation prevents the common failure mode where a fixer rationalises away problems it finds in code it's about to change. ## Input One of: - File path(s) to review - Directory to scan - No argument — automatically determines scope ## Execution ### Step 1: Determine Scope Determine which files to review, in priority order: 1. If the user specified files/directories, use those 2. If there are uncommitted changes: `git diff --name-only` (unstaged) + `git diff --name-only --staged` (staged) 3. If there are recent commits: `git diff --name-only HEAD~3` 4. If none of the above apply, ask the user what to review ### Step 2: Baseline Test Check Run the project's test suite before making any changes. Auto-detect the test command by inspecting the project for build/config files. If the detected command fails on first run, **ask the user** for the correct test command. Once confirmed, write the command to the CLAUDE.md file for the project. Record the result — this is needed later to distinguish pre-existing failures from regressions introduced by fixes. ### Step 3: Review-Fix Loop Set `iteration = 1` and `scope = `. HARD GATE - Iteration Cap: → `iteration` reaches 6 → STOP loop unconditionally. Report final status. Do not allow "just one more cycle." **LOOP** while `iteration <= 5`: Five iterations is the cap because experience shows that if critical findings persist beyond 3-4 cycles, the remaining issues typically need human judgement rather than automated fixing. 1. **REVIEW (iteration N)** — Announce: `Review iteration N/5` - Spawn the `code-reviewer` agent with scope as its input - Receive the findings report 2. **TRIAGE** → Report received → Extract only 🔴 Critical findings. Discard all warnings and suggestions. → Zero critical findings? → Break loop, report clean. → N critical findings? → List for visibility, pass to fixer. Only critical findings are actioned because warnings and suggestions are judgement calls best left to the author. 3. **FIX (iteration N)** — Announce: `Fix iteration N/5 — addressing N critical issue(s)` - Spawn the `fixer` agent, passing it: - The list of critical findings (with file paths and line numbers) - The review context - Receive the fix report (fixed, unfixable, files modified, test status) 4. **NARROW SCOPE** — Set `scope` to the files listed in the fixer's "Files Modified" output - If the fixer modified files *not* in the original scope, include those too — fixes can introduce issues in new files - If no files were modified (all findings were unfixable), break to the final report 5. **INCREMENT** — `iteration += 1` **END LOOP** ### Step 4: Final Report Announce: `Fix loop complete` ```markdown # Fix Loop Report ## Iterations: N/5 ## Resolved (Critical) - [file:line] [issue] — fixed in iteration N ## Remaining (Critical) - [file:line] [issue] — reason not fixed ## Noted (Warning / Suggestion) - [file:line] [issue] — from iteration N (not actioned) ## Test Status [Compare against baseline from Step 2. Report regressions vs pre-existing failures.] ``` ### Step 5: Commit Ask the user: **Commit these changes?** If yes, use `/commit` or create a conventional commit directly.