Skip to content
Templates/Bug Fix
Bug FixMedium risk

Bug Fixing Loop

Reproduce a bug, fix the smallest cause, and verify with a regression test.

What this Loop Engineering template does

Reproduce the reported bug, fix the smallest root cause, and prove it with a regression test.

Start by reproducing the bug. Write a failing regression test first, then fix until it passes.

When to use it

Reproducible bugs
Regression-testable fixes
Localized defects

When not to use it

Vague “it feels slow” reports
Bugs needing product decisions
Large refactors

Validation checks

validation
Bug is reproduced before fix
Regression test fails before fix and passes after fix
Full relevant test suite passes

Boundaries & stop rule

!Do not rewrite unrelated modules
!Do not hide errors
!Do not change expected behavior without documenting why
Stop rule — Stop when the regression test passes and the suite is green, or after 5 failed attempts. If the root cause is unclear, summarize the reproduction, hypotheses tried, and recommended next step.

Copy the loop prompt

claude-goal.txt
/goal Reproduce the reported bug, fix the smallest root cause, and prove it with a regression test.
 
Task type: Bug Fix
Target tool: Claude Code
 
Work toward this goal until all validation checks pass or the stop rule is reached.
 
Design hypothesis:
This bug fixing loop can produce a safer result if the scope stays narrow, validation is explicit, and a checker can reject shortcut work.
 
Smallest useful run:
Run one bounded pass on the newest relevant signal before expanding scope or adding a schedule.
 
Loop cycle:
1. Discovery — Read the latest signal for this template before acting: CI output, issue detail, review comment, dataset report, or content brief.
2. Handoff — Hand the work to one agent in an isolated branch, worktree, or clearly scoped session. Keep final approval with a human.
3. Verification — Use an independent review pass to confirm the result, inspect the diff or artifact, and reject shortcut work.
4. Persistence — Save a short run note with the signal reviewed, actions taken, validation result, and next recommended step.
5. Scheduling — Run manually until the loop is reliable; only then consider a scheduled or event-triggered run.
 
Context:
Start by reproducing the bug. Write a failing regression test first, then fix until it passes.
 
Validation:
Bug is reproduced before fix
Regression test fails before fix and passes after fix
Full relevant test suite passes
 
Validation evidence:
Record the original signal, checks run, final result, changed files or artifacts, and any checker rejection.
 
Independent checker:
Use an independent review pass to confirm the result, inspect the diff or artifact, and reject shortcut work.
 
Boundaries:
Do not rewrite unrelated modules
Do not hide errors
Do not change expected behavior without documenting why
 
Stop rule:
Stop when the regression test passes and the suite is green, or after 5 failed attempts.
Maximum iterations: 6
 
Budget:
Example only: stop before exceeding the agreed per-run token budget.
 
Human approval:
Required before merge, deploy, delete, purchase, or external communication.
 
Fallback:
If the root cause is unclear, summarize the reproduction, hypotheses tried, and recommended next step.
 
Loop Validation Log:
- Hypothesis: This bug fixing loop can produce a safer result if the scope stays narrow, validation is explicit, and a checker can reject shortcut work.
- Smallest useful run: Run one bounded pass on the newest relevant signal before expanding scope or adding a schedule.
- Expected evidence: Record the original signal, checks run, final result, changed files or artifacts, and any checker rejection.
- Actual evidence: [fill in after the run]
- Passed? [yes / no / partial]
- Feedback: After the run, note what the loop learned, what failed, and what should change before the next pass.
- Next step: [stop / adjust the loop / run the next pass]
 
Do not delete tests, bypass checks, or modify unrelated files just to satisfy the validation condition. If blocked, stop and summarize the blocker, attempted fixes, and recommended next action.

Failure modes to watch

Agent fixes a symptom, not the cause
Agent skips the regression test
Agent broadens scope unnecessarily
Agent suppresses the error
Worked scenario review · maintained by TianMingAI · 2026-07-21

Review receipt

This is a bounded review exercise for the template, not a claim about a production deployment.

Scenario

A saved budget estimate resets its output-token value when the browser back button restores the calculator page.

Baseline evidence

The reviewer records the browser steps, entered values, expected restored state, actual reset value, and a failing state-restoration test before touching the calculator logic.

Validation result

The regression test fails against the prior state, passes after the focused hydration fix, and the calculator produces unchanged totals for fresh visits and direct URL loads.

Shortcut rejected

Removing browser restoration support or forcing a full reload hides the symptom while degrading navigation, so neither is accepted as a bug fix.

Human gate

A person checks the restored interaction in a real browser and confirms that retaining entered values is the intended privacy and usability behavior before release.

Final decisionPass

Loop Engineering FAQ

A test that fails before the fix and passes after proves the bug was real and the fix addresses it — not just that the code changed.