Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 31 additions & 1 deletion .claude/rules/tdd.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,12 +4,19 @@ globs: ["skills/setup/scripts/**", "tests/**"]
# MANDATORY: Test-Driven Development (TDD) First

**EVERY feature request MUST start with writing tests before any implementation.**
**EVERY bug fix MUST start by reproducing the bug in a failing test.**

When receiving ANY feature request, your FIRST response should be:
1. "Following TDD - I'll write tests first to define what success looks like"
2. Write comprehensive failing tests using the Red-Green-Refactor cycle
3. Only then proceed with implementation to make tests pass

When receiving ANY bug report, your FIRST response should be:
1. "Reproducing the bug first - writing a test that triggers the exact error"
2. Write a test that demonstrates the reported failure
3. Run it and confirm it FAILS (proves you captured the bug)
4. Only then write the fix

## TDD Process - ALWAYS FOLLOW

1. **Red Phase** (REQUIRED FIRST STEP):
Expand All @@ -24,6 +31,28 @@ When receiving ANY feature request, your FIRST response should be:
- Clean up and optimize without changing behavior
- Run tests after each refactor

## Bug Fix Workflow — Reproduce First

**EVERY bug fix MUST start by reproducing the bug in a test.**

1. **Reproduce** (REQUIRED FIRST STEP):
- Write a test that triggers the exact error or behavior reported
- Run the test and confirm it FAILS — this proves you've captured the bug
- If you cannot reproduce it, investigate further before writing any fix

2. **Fix**:
- Implement the minimal change that makes the reproduction test pass
- Do NOT merge or commit the fix before the reproduction test exists

3. **Validate**:
- Run the full test suite to check for regressions
- Confirm the reproduction test passes with the fix applied

**Red Flags — STOP immediately if:**
- Editing source/config files before a reproduction test exists
- Theorizing about root cause without confirming it with a failing test
- Merging a fix that was never verified against the actual error

## TDD Enforcement Checklist

**Before writing ANY implementation code, Claude MUST:**
Expand All @@ -39,5 +68,6 @@ When receiving ANY feature request, your FIRST response should be:

TDD may be relaxed ONLY for:
- Documentation-only changes (*.md files)
- Configuration files (settings.json, plugin.json)
- Simple refactoring with existing test coverage

Bug fixes are NEVER exempt — always reproduce first, even for configuration file changes.
33 changes: 30 additions & 3 deletions skills/setup/templates/rules/tdd.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,12 +4,19 @@ globs: ["src/**", "lib/**"]
# MANDATORY: Test-Driven Development (TDD) First

**EVERY feature request MUST start with writing tests before any implementation.**
**EVERY bug fix MUST start by reproducing the bug in a failing test.**

When receiving ANY feature request, your FIRST response should be:
1. "Following TDD - I'll write tests first to define what success looks like"
2. Write comprehensive failing tests using the Red-Green-Refactor cycle
3. Only then proceed with implementation to make tests pass

When receiving ANY bug report, your FIRST response should be:
1. "Reproducing the bug first - writing a test that triggers the exact error"
2. Write a test that demonstrates the reported failure
3. Run it and confirm it FAILS (proves you captured the bug)
4. Only then write the fix

## TDD Process - ALWAYS FOLLOW

1. **Red Phase** (REQUIRED FIRST STEP):
Expand Down Expand Up @@ -46,11 +53,31 @@ When receiving ANY feature request, your FIRST response should be:
5. **Only then write implementation**
6. **Run tests again and show GREEN output** proving tests pass

**Red Flags - STOP immediately if:**
**Red Flags STOP immediately if:**
- Creating files in `src/` before creating tests
- Using `Write` tool for implementation before tests exist
- Planning describes implementation details before test strategy
- User asks for feature and you immediately start coding
- Editing source/config files before a reproduction test exists for a bug fix
- Theorizing about root cause without confirming it with a failing test
- Merging a fix that was never verified against the actual error

## Bug Fix Workflow — Reproduce First

**EVERY bug fix MUST start by reproducing the bug in a test.**

1. **Reproduce** (REQUIRED FIRST STEP):
- Write a test that triggers the exact error or behavior reported
- Run the test and confirm it FAILS — this proves you've captured the bug
- If you cannot reproduce it, investigate further before writing any fix

2. **Fix**:
- Implement the minimal change that makes the reproduction test pass
- Do NOT merge or commit the fix before the reproduction test exists

3. **Validate**:
- Run the full test suite to check for regressions
- Confirm the reproduction test passes with the fix applied

## TDD Self-Check Questions

Expand All @@ -65,8 +92,8 @@ If the answer to ANY of these is "no", STOP and write tests first.

TDD may be relaxed ONLY for:
- Documentation-only changes (*.md files)
- Configuration files (package.json, tsconfig.json)
- Simple refactoring with existing test coverage
- Emergency hotfixes (with tests added immediately after)

Bug fixes are NEVER exempt — always reproduce first, even for configuration file changes.

**All other code changes require tests first.**
Loading