ralph-review-loop

name	ralph-review-loop
description	Run a Ralph-style loop that repeatedly triggers Codex /review, fixes accepted bugs, and re-runs review until no actionable issues remain. Use when the user asks for “looped review,” “run /review until clean,” or “keep reviewing until no bugs are found.”

Ralph Review Loop

Overview

Run a tight review/fix loop using Codex’s /review command. Each pass collects findings, applies fixes, and re-runs review until the latest pass produces zero actionable bugs or a stop condition is reached.

Workflow

1. Set loop parameters (confirm before starting).

   • Ask the user to confirm: scope and whether to include uncommitted changes.
   • Ask whether to change the model/effort. If yes, instruct them to run /model and select gpt-5.2-codex with reasoning effort xhigh (or high if xhigh isn’t available).
   • If the user says they already changed the model, do not ask for exact values; proceed using the current session model.

2. Run /review inside the current Codex session (do not spawn a new Codex process).

   • Use the in-session /review command, not codex review in a shell.
   • If an external codex review command is running, stop it and re-run /review in-session.
   • When /review prompts for scope, select:
     • Unpushed commits → diff vs upstream (e.g., origin/main).
     • Base branch → select the branch you want to compare against.
     • Single commit → pick the commit from the list.
     • Uncommitted → include staged/unstaged/untracked.
   • Capture findings (file/line + severity).
   • If there are no findings, stop and report success.

3. Triage findings.

   • Accept: real, actionable bugs/regressions.
   • Reject: false positives or out-of-scope.
   • Defer: requires user input; stop and ask.
   • Keep a short checklist of accepted/rejected items.

4. Fix accepted items.

   • Apply minimal, targeted changes.
   • Update/add tests if needed.
   • Summarize fixes briefly.

5. Re-run /review only if code changed.

6. Stop conditions.

   • Latest pass has zero accepted findings.
   • User asks to stop or needs input before continuing.

Checkpoints

• Before starting: ask the user to confirm scope and model/effort.
• After the first pass: ask if they want to change scope or model/effort before continuing. If they already changed the model, do not ask for exact values—just proceed.

Output expectations

• For each pass, report: pass number, accepted/rejected counts, and what changed (files/patches).
• On completion, explicitly state why the loop stopped (clean pass or needs input).

Guardrails

• Do not loop forever. Stop when the review is clean or the user asks to stop.
• Do not re-run /review without code changes.
• Do not broaden scope without user approval.