Claude Code 抓蟲閉環：重現 → 定位根因 → 最小修復 → 回歸測試驗證

You are fixing a bug. Follow this four-phase loop strictly: REPRODUCE → ISOLATE → FIX → VERIFY. The rule is: no fix without a failing test first, and the fix must be the narrowest change that addresses the ROOT CAUSE, not the symptom.

BUG REPORT:
{{BUG_REPORT}}

KNOWN CONTEXT (stack trace, when it happens, what changed recently, how often):
{{CONTEXT}}

HOW TO RUN THE PROJECT / TESTS:
{{RUN_COMMAND}}

=== PHASE 1: REPRODUCE ===
- First, reproduce the bug reliably. Determine the exact steps, inputs, or command that triggers it.
- If you can, write a failing automated test (or a minimal script/command) that demonstrates the bug. Run it and SHOW the actual failing output.
- If you genuinely cannot reproduce it, STOP and tell me precisely what information or access you are missing. Do not guess at a fix for a bug you cannot trigger.

=== PHASE 2: ISOLATE (root cause) ===
- Narrow down where the defect actually lives. Read the relevant code paths; trace the data/flow from the trigger to the failure. Minimize the reproduction to the smallest case that still fails.
- State the ROOT CAUSE in plain language: the specific line(s)/logic responsible and WHY it produces the observed behavior. Distinguish the root cause from the symptom.
- If recent changes are suspected, inspect the relevant history. List 1-3 candidate causes ranked by likelihood, then commit to the most likely one with your reasoning. If you are uncertain, say so rather than asserting.
- Heavy read-only investigation (searching, reading many files, tracing) is a good place to delegate to a read-only Explore subagent so it doesn't bloat this conversation — but the root-cause conclusion must come back here.

=== PHASE 3: FIX ===
- Make the SMALLEST change that fixes the root cause. Do not refactor unrelated code, do not 'improve' things nearby, do not widen scope. If you spot other issues, note them separately at the end — don't fix them now.
- Explain in one or two lines why this change addresses the root cause identified in Phase 2.

=== PHASE 4: VERIFY ===
- Run the failing test/repro from Phase 1 and SHOW it now passes.
- Run the FULL test suite (not just the one test) via {{RUN_COMMAND}} and SHOW the output, to prove you didn't break anything else.
- Keep the regression test in place permanently — it documents the bug and prevents it from coming back. Confirm it is committed alongside the fix.

Output discipline:
- Always paste REAL command output, never 'it passes now'. If a command can't be run in this environment, say so explicitly.
- End with a short summary: root cause (1 line), the fix (1 line), the regression test added, and any unrelated issues you noticed but deliberately did NOT touch.
- Do not declare the bug fixed unless Phase 1's repro passes AND the full suite is green.

把方括號 [ ] 內的變數換成你的內容，丟進 Claude Code。

You are fixing a bug. Follow this four-phase loop strictly: REPRODUCE → ISOLATE → FIX → VERIFY. The rule is: no fix without a failing test first, and the fix must be the narrowest change that addresses the ROOT CAUSE, not the symptom.

BUG REPORT:
{{BUG_REPORT}}

KNOWN CONTEXT (stack trace, when it happens, what changed recently, how often):
{{CONTEXT}}

HOW TO RUN THE PROJECT / TESTS:
{{RUN_COMMAND}}

=== PHASE 1: REPRODUCE ===
- First, reproduce the bug reliably. Determine the exact steps, inputs, or command that triggers it.
- If you can, write a failing automated test (or a minimal script/command) that demonstrates the bug. Run it and SHOW the actual failing output.
- If you genuinely cannot reproduce it, STOP and tell me precisely what information or access you are missing. Do not guess at a fix for a bug you cannot trigger.

=== PHASE 2: ISOLATE (root cause) ===
- Narrow down where the defect actually lives. Read the relevant code paths; trace the data/flow from the trigger to the failure. Minimize the reproduction to the smallest case that still fails.
- State the ROOT CAUSE in plain language: the specific line(s)/logic responsible and WHY it produces the observed behavior. Distinguish the root cause from the symptom.
- If recent changes are suspected, inspect the relevant history. List 1-3 candidate causes ranked by likelihood, then commit to the most likely one with your reasoning. If you are uncertain, say so rather than asserting.
- Heavy read-only investigation (searching, reading many files, tracing) is a good place to delegate to a read-only Explore subagent so it doesn't bloat this conversation — but the root-cause conclusion must come back here.

=== PHASE 3: FIX ===
- Make the SMALLEST change that fixes the root cause. Do not refactor unrelated code, do not 'improve' things nearby, do not widen scope. If you spot other issues, note them separately at the end — don't fix them now.
- Explain in one or two lines why this change addresses the root cause identified in Phase 2.

=== PHASE 4: VERIFY ===
- Run the failing test/repro from Phase 1 and SHOW it now passes.
- Run the FULL test suite (not just the one test) via {{RUN_COMMAND}} and SHOW the output, to prove you didn't break anything else.
- Keep the regression test in place permanently — it documents the bug and prevents it from coming back. Confirm it is committed alongside the fix.

Output discipline:
- Always paste REAL command output, never 'it passes now'. If a command can't be run in this environment, say so explicitly.
- End with a short summary: root cause (1 line), the fix (1 line), the regression test added, and any unrelated issues you noticed but deliberately did NOT touch.
- Do not declare the bug fixed unless Phase 1's repro passes AND the full suite is green.