Claude Code TDD 閉環：先寫會失敗的測試，再寫剛好通過的程式，最後重構

We are building this feature using strict Test-Driven Development. Follow the Red-Green-Refactor cycle and do NOT skip steps. The discipline is non-negotiable: no production code gets written before there is a failing test that demands it.

FEATURE / BEHAVIOR TO BUILD:
{{FEATURE}}

TEST FRAMEWORK & COMMAND:
- Framework / runner: {{TEST_FRAMEWORK}}
- Command to run tests: {{TEST_COMMAND}}

Process for EACH behavior (work one behavior at a time, smallest first):

=== RED ===
1. Write exactly ONE focused test for the next small behavior, including the relevant edge cases for that behavior (empty input, boundary values, error paths) where they belong. Do not write the implementation yet.
2. Run `{{TEST_COMMAND}}` and SHOW me the actual output. The new test MUST fail, and it must fail for the RIGHT reason (asserting the missing behavior — not failing due to an import error, typo, or syntax mistake). If it fails for the wrong reason, fix the test and re-run before continuing.
3. State in one line: what behavior this test pins down.

=== GREEN ===
4. Write the MINIMUM production code needed to make that test pass. No extra features, no speculative abstraction, no handling of cases no test covers yet.
5. Run `{{TEST_COMMAND}}` again and SHOW the output. The target test must now pass AND every previously passing test must still pass. If anything else broke, fix it before moving on.

=== REFACTOR ===
6. With the tests green, look for cleanup: duplication, unclear names, dead code, awkward structure. Refactor WITHOUT changing behavior. Run `{{TEST_COMMAND}}` once more and SHOW output to prove everything is still green. If there is nothing worth refactoring, say so explicitly and move on.

Then repeat the cycle for the next behavior.

Hard rules:
- Never write production code in the same step as writing a test.
- Never edit a test just to make a failing implementation pass — if a test is genuinely wrong, say WHY out loud first, then fix the test, then re-run RED.
- Do not stub out tests to always pass, and do not delete assertions to get green. That is cheating and counts as failure.
- Always paste the REAL test runner output, never a summary like 'tests pass'. If a command cannot be run here, say so explicitly instead of pretending.
- Stop after every full cycle and give me a one-line status: which behavior is now done and what the next behavior will be.

Start with RED for the smallest meaningful behavior.

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

We are building this feature using strict Test-Driven Development. Follow the Red-Green-Refactor cycle and do NOT skip steps. The discipline is non-negotiable: no production code gets written before there is a failing test that demands it.

FEATURE / BEHAVIOR TO BUILD:
{{FEATURE}}

TEST FRAMEWORK & COMMAND:
- Framework / runner: {{TEST_FRAMEWORK}}
- Command to run tests: {{TEST_COMMAND}}

Process for EACH behavior (work one behavior at a time, smallest first):

=== RED ===
1. Write exactly ONE focused test for the next small behavior, including the relevant edge cases for that behavior (empty input, boundary values, error paths) where they belong. Do not write the implementation yet.
2. Run `{{TEST_COMMAND}}` and SHOW me the actual output. The new test MUST fail, and it must fail for the RIGHT reason (asserting the missing behavior — not failing due to an import error, typo, or syntax mistake). If it fails for the wrong reason, fix the test and re-run before continuing.
3. State in one line: what behavior this test pins down.

=== GREEN ===
4. Write the MINIMUM production code needed to make that test pass. No extra features, no speculative abstraction, no handling of cases no test covers yet.
5. Run `{{TEST_COMMAND}}` again and SHOW the output. The target test must now pass AND every previously passing test must still pass. If anything else broke, fix it before moving on.

=== REFACTOR ===
6. With the tests green, look for cleanup: duplication, unclear names, dead code, awkward structure. Refactor WITHOUT changing behavior. Run `{{TEST_COMMAND}}` once more and SHOW output to prove everything is still green. If there is nothing worth refactoring, say so explicitly and move on.

Then repeat the cycle for the next behavior.

Hard rules:
- Never write production code in the same step as writing a test.
- Never edit a test just to make a failing implementation pass — if a test is genuinely wrong, say WHY out loud first, then fix the test, then re-run RED.
- Do not stub out tests to always pass, and do not delete assertions to get green. That is cheating and counts as failure.
- Always paste the REAL test runner output, never a summary like 'tests pass'. If a command cannot be run here, say so explicitly instead of pretending.
- Stop after every full cycle and give me a one-line status: which behavior is now done and what the next behavior will be.

Start with RED for the smallest meaningful behavior.