Review Fix — Plan & Execute from Last Review

Read the most recent .reviews/YYYY-MM-DD-review.md, plan fixes for all findings grouped by priority, then execute every planned fix with atomic commits. Produces two artifacts: a review-plan and a review-execution log.

Instructions

Phase 0 — Find the Latest Review

1. Glob for .reviews/*-review.md and pick the most recent file by date.
2. Read the full review file. Parse every finding into a list of { severity, reviewer, file, line, description } entries.
3. If no review file exists, tell the user to run /code-review first and stop.

Phase 1 — Plan

Spawn 4 parallel planning agents (Task tool, subagent_type: Plan) that each receive the full findings list filtered to their scope. Each agent returns a structured list of fix actions.

Agent scopes

Findings that span multiple scopes go to every relevant agent.

Each planning agent must:

• Group related findings that can be fixed together (same file, same pattern).
• For each group, produce:
  • What: one-line summary of the change
  • Files: list of files to modify
  • How: 2-3 sentence implementation approach
  • Severity: highest severity in the group (Fix > Improve > Note)
  • Risk: Low / Medium / High (does this change behavior or just style?)
  • Depends on: other group IDs this group must wait for (if any)
• Order groups by: Fix severity first, then by dependency order.
• Skip any finding rated Note — notes are informational only.

After all 4 agents return, compile results into .reviews/YYYY-MM-DD-review-plan.md:

markdown
1# Review Fix Plan — YYYY-MM-DD
2
3**Source review:** `.reviews/YYYY-MM-DD-review.md`
4**Generated:** YYYY-MM-DD HH:MM
5
6## Stats
7
8| Severity | Findings | Planned groups |
9|----------|----------|----------------|
10| Fix      | N        | N              |
11| Improve  | N        | N              |
12| Note     | N        | (skipped)      |
13
14## Execution Waves
15
16Wave 1 (no dependencies):
17- [B1] Backend: <summary>
18- [F1] Frontend: <summary>
19
20Wave 2 (depends on wave 1):
21- [B2] Backend: <summary> (depends on B1)
22
23...
24
25## Detailed Plan
26
27### [B1] <Summary>
28- **Severity:** Fix
29- **Risk:** Low
30- **Files:** `path/to/file.py`
31- **How:** Description of the fix approach
32- **Findings addressed:**
33  - Tina: `path/to/file.py:42` — original finding text
34  - Marcus: `path/to/file.py:50` — original finding text

Print the plan summary (wave count, group count, severity breakdown) to the user, then immediately proceed to Phase 2 without waiting for approval.

Phase 2 — Execute

Read the plan file. Execute fixes wave by wave — all groups in a wave run in parallel, but waves run sequentially (wave 2 waits for wave 1 to finish).

For each group, spawn a Task agent (subagent_type: general-purpose) with:

• The group's detailed plan (What, Files, How)
• The original finding text for context
• Instruction to read each file before editing
• Instruction to make the minimal change that addresses the finding
• Instruction to run ruff check --fix and ruff format on any modified Python file
• Instruction to run npm run lint -- --fix on any modified TypeScript file (from frontend/)
• Instruction to NOT create new files unless the plan explicitly says to
• Instruction to NOT add tests (Derek findings are tracked but test writing is a separate task)

After each wave completes:

1. Verify no lint errors remain (ruff check cachibot/ and cd frontend && npm run lint).
2. If lint fails, spawn a fix agent for the failing files before continuing.
3. Stage all changed files and create one commit per wave:

   Review fixes wave N: <comma-separated group IDs>
   
   Addresses findings from YYYY-MM-DD code review.
   Groups: [B1] summary, [F2] summary, ...
   
   Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
   

After all waves complete, write .reviews/YYYY-MM-DD-review-execution.md:

markdown
1# Review Fix Execution — YYYY-MM-DD
2
3**Plan:** `.reviews/YYYY-MM-DD-review-plan.md`
4**Source review:** `.reviews/YYYY-MM-DD-review.md`
5
6## Results
7
8| Wave | Groups | Status  | Commit  |
9|------|--------|---------|---------|
10| 1    | B1, F1 | Done    | abc1234 |
11| 2    | B2     | Done    | def5678 |
12
13## Findings Addressed
14
15| Severity | Planned | Fixed | Skipped | Reason          |
16|----------|---------|-------|---------|-----------------|
17| Fix      | N       | N     | N       |                 |
18| Improve  | N       | N     | N       |                 |
19
20## Group Details
21
22### [B1] <Summary> — Done
23- **Commit:** abc1234
24- **Files changed:** `path/to/file.py`
25- **Findings fixed:**
26  - Tina: `path/to/file.py:42` — fixed
27  - Marcus: `path/to/file.py:50` — fixed
28
29### [F1] <Summary> — Skipped
30- **Reason:** File was recently refactored, finding no longer applies
31- **Findings skipped:**
32  - Zoe: `frontend/src/Component.tsx:100` — N/A after refactor
33
34## Remaining Work
35
36- Derek's test coverage findings were not addressed (test writing is separate)
37- N findings skipped due to: ...

Phase 3 — Summary

Print a final summary to the user:

Review fix complete.

Waves executed: N
Commits created: N
Findings fixed: N / M planned (X Fix, Y Improve)
Skipped: N (reasons listed in execution log)

Plan:      .reviews/YYYY-MM-DD-review-plan.md
Execution: .reviews/YYYY-MM-DD-review-execution.md

Important Rules

• Never skip a Fix-severity finding without logging a clear reason.
• Read before edit — every agent must read the target file before modifying it.
• Minimal changes — fix exactly what the finding describes, nothing more.
• No new features — this is a fix pass, not a feature pass.
• No test writing — Derek's findings are logged as "remaining work" but not executed here. Test creation deserves its own focused session.
• Preserve behavior — if a fix would change external API behavior, mark it as Risk: High in the plan and add a note in the execution log.
• If the review file has a "Previous Reviews" section noting still-open findings from prior reviews, include those in the plan too.