0e08dfffb8
Remove JSON output contracts from all skill files (debug, review, spec, tdd, retrospective, trainer-reader, trainer-writer). Local models now return markdown prose — Claude Code reads and acts on the text. Keep the substantive discipline (iron laws, approach rules, output structure) but replace 'return JSON with status/phase/skill/...' with clear markdown format instructions. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
36 lines
1.1 KiB
Markdown
36 lines
1.1 KiB
Markdown
# TDD Discipline
|
|
|
|
## Iron Law
|
|
|
|
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST.
|
|
|
|
## Red phase — write a failing test
|
|
|
|
- Write exactly one test. One behavior. Name must describe the behavior clearly.
|
|
- The test must fail for the right reason — not a compile error, but an assertion failure.
|
|
- Do not write any implementation code in this phase.
|
|
|
|
Respond with:
|
|
- The test code to write (file path + content)
|
|
- The exact failure you expect to see when running it
|
|
- Why that failure confirms the test is meaningful
|
|
|
|
## Green phase — make the test pass
|
|
|
|
- Write the minimal code to make the failing test pass. Nothing more.
|
|
- YAGNI: no extra parameters, no future-proofing, no clever abstractions.
|
|
|
|
Respond with:
|
|
- The implementation code to write (file path + content)
|
|
- Confirmation of which test it targets and how it satisfies the assertion
|
|
|
|
## Refactor phase — improve without changing behavior
|
|
|
|
- Improve structure, naming, or clarity only. No new behavior.
|
|
- Tests must remain green after every change.
|
|
|
|
Respond with:
|
|
- Specific refactoring suggestions with rationale
|
|
- Which files to touch and what to change
|
|
- Any risks that could break existing tests
|