Codex Bug-Fix Closed Loop: Reproduce First, Fix Second, With Rerunnable Verification
Forces Codex through a closed loop — write a failing test that reproduces the bug, find the root cause, make the minimal fix, watch that same test go from red to green, then run the full test suite to confirm no regressions — eliminating both 'fixed it without verifying' and 'changed a bunch of unrelated stuff along the way.'
Fix this bug using a strict reproduce-first, verify-after loop. Do not skip steps. Do not claim it's fixed without showing a passing test run.
## The bug
{{BUG_DESCRIPTION}}
Expected behavior: {{EXPECTED}}
Actual behavior: {{ACTUAL}}
How to trigger (if known): {{REPRO_STEPS}}
## Loop you MUST follow
**1. Reproduce FIRST (red).** Before changing any production code, write or identify a test that fails *because of this bug*. Run it and paste the real failing output. If you genuinely cannot write an automated test (e.g. it needs a live external service), say so explicitly and instead give the exact manual command + observed wrong output that demonstrates the bug. A bug you can't reproduce is not yet understood — keep investigating until you can.
**2. Find the root cause.** Trace from the failing symptom back to the line(s) responsible. State the root cause in 1-2 sentences: *what* is wrong and *why* it produces the observed behavior. Do not pattern-match a fix onto the symptom — explain the mechanism. If there are multiple plausible causes, name them and say how you ruled the others out.
**3. Apply the MINIMAL fix.** Change only what's needed to fix the root cause. No drive-by refactors, no reformatting unrelated lines, no renaming. If you spot adjacent issues, list them at the end as 'noticed but not changed' — do not fold them into this fix.
**4. Verify (green).** Re-run the SAME test from step 1 and paste the now-passing output. Then run the broader suite (`{{TEST_COMMAND}}`) and paste the result to prove no regression. If the suite was already partially failing before your change, note which failures are pre-existing and unrelated.
**5. Report.** Summarize: root cause, the one-line essence of the fix, files touched, and the verification command anyone can re-run.
## Hard rules
- Steps 1 and 4 MUST include actual command output, not a description of what you expect to happen. 'Should pass now' is not acceptable — run it.
- If after a reasonable effort you cannot reproduce, STOP and report what you tried and what info you need, rather than guessing at a fix.
- Keep the diff small and reviewable. The test added in step 1 stays in the codebase as a regression guard.
- Respect existing project conventions (read AGENTS.md / CLAUDE.md if present for the right test command and style).
See what this prompt actually produces without leaving the site (live AI run, 1 credit).
Don't just copy-paste — download and drop it at ~/.claude/skills/bug-reproduce-fix-verify-loop/SKILL.md and every future session can use it automatically.
mkdir -p ~/.claude/skills/bug-reproduce-fix-verify-loop && mv ~/Downloads/SKILL.md ~/.claude/skills/bug-reproduce-fix-verify-loop/SKILL.mdNew-Item -ItemType Directory -Force "$env:USERPROFILE\.claude\skills\bug-reproduce-fix-verify-loop" | Out-Null; Move-Item "$env:USERPROFILE\Downloads\SKILL.md" "$env:USERPROFILE\.claude\skills\bug-reproduce-fix-verify-loop\SKILL.md"When to use it: any bug that's been reported to you, or one you've hit yourself. Why it works: the two biggest ailments in AI bug-fixing are 'guessing at a fix without reproducing it' and 'claiming it's fixed without ever running it.' This prompt locks that down with TDD's red-to-green cycle: step 1 requires a failing test (reproducing = understanding), step 4 requires that same test to turn green plus a full regression run, and both steps require pasting the actual output. Technique: with Codex CLI, use `codex exec` to let it iterate on tests automatically (under a workspace-write sandbox it can rerun tests repeatedly until green); fill {{TEST_COMMAND}} with your project's command (npm test / pytest / go test ./...). If it can't reproduce the bug, it stops and asks you instead of changing things at random — which is exactly what you want.
1. Reproduce (red): $ pytest tests/test_dates.py::test_month_rollover -q FAILED — assert parse('2026-01-31' + 1mo) == '2026-02-28', got ValueError: day is out of range 2. Root cause: add_months() 直接把 month+1 後沿用原 day(31)，2 月無 31 日故 datetime 拋錯。應 clamp 到當月最後一天。 3. Fix: src/dates.py add_months() 加 day = min(day, last_day_of(year, month)) 4. Verify (green): $ pytest tests/test_dates.py::test_month_rollover -q 1 passed $ pytest -q 214 passed, 0 failed Report: 根因＝月份進位未夾日；修 1 檔 1 函式；回歸測試已留存於 test_month_rollover。
[BUG_DESCRIPTION]bug 的描述（症狀、出現在哪個功能/頁面）
[EXPECTED]預期的正確行為
[ACTUAL]實際發生的錯誤行為（含錯誤訊息/stack trace 若有）
[REPRO_STEPS]已知的重現步驟；不知道就填「未知」讓它自己找
[TEST_COMMAND]跑完整測試套件的指令，如 npm test、pytest -q、go test ./...
填下面的欄位，上方 prompt 會即時替換 [方括號] 內容。填好後按「複製組好的 prompt」直接丟進工具。
Fix this bug using a strict reproduce-first, verify-after loop. Do not skip steps. Do not claim it's fixed without showing a passing test run.
## The bug
{{BUG_DESCRIPTION}}
Expected behavior: {{EXPECTED}}
Actual behavior: {{ACTUAL}}
How to trigger (if known): {{REPRO_STEPS}}
## Loop you MUST follow
**1. Reproduce FIRST (red).** Before changing any production code, write or identify a test that fails *because of this bug*. Run it and paste the real failing output. If you genuinely cannot write an automated test (e.g. it needs a live external service), say so explicitly and instead give the exact manual command + observed wrong output that demonstrates the bug. A bug you can't reproduce is not yet understood — keep investigating until you can.
**2. Find the root cause.** Trace from the failing symptom back to the line(s) responsible. State the root cause in 1-2 sentences: *what* is wrong and *why* it produces the observed behavior. Do not pattern-match a fix onto the symptom — explain the mechanism. If there are multiple plausible causes, name them and say how you ruled the others out.
**3. Apply the MINIMAL fix.** Change only what's needed to fix the root cause. No drive-by refactors, no reformatting unrelated lines, no renaming. If you spot adjacent issues, list them at the end as 'noticed but not changed' — do not fold them into this fix.
**4. Verify (green).** Re-run the SAME test from step 1 and paste the now-passing output. Then run the broader suite (`{{TEST_COMMAND}}`) and paste the result to prove no regression. If the suite was already partially failing before your change, note which failures are pre-existing and unrelated.
**5. Report.** Summarize: root cause, the one-line essence of the fix, files touched, and the verification command anyone can re-run.
## Hard rules
- Steps 1 and 4 MUST include actual command output, not a description of what you expect to happen. 'Should pass now' is not acceptable — run it.
- If after a reasonable effort you cannot reproduce, STOP and report what you tried and what info you need, rather than guessing at a fix.
- Keep the diff small and reviewable. The test added in step 1 stays in the codebase as a regression guard.
- Respect existing project conventions (read AGENTS.md / CLAUDE.md if present for the right test command and style).
Suno Engineer's Mindset: 4 Steps to a Song That Doesn't Sound Like AI
A studio engineer's breakdown of Suno's fatal weaknesses (fried vocals, high-frequency artifacts), plus a 4-step DAW workflow and a Suno Studio cleanup prompt.
5 Claude Weekly Workflows That Stuck After 6 Months
Proposal generator / meeting processor / content repurposer / Friday review / shutdown reset — out of 40 I tried, only these 5 survived, each saving 30+ minutes per run.