kimchi:tdd

Use when implementing any feature, bugfix, or behavior change — before writing implementation code. Enforces RED-GREEN-REFACTOR cycle.

7 stars

Best use case

kimchi:tdd is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Use when implementing any feature, bugfix, or behavior change — before writing implementation code. Enforces RED-GREEN-REFACTOR cycle.

Teams using kimchi:tdd should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/tdd/SKILL.md --create-dirs "https://raw.githubusercontent.com/Tromml/kimchi/main/plugins/kimchi/skills/tdd/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/tdd/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How kimchi:tdd Compares

Feature / Agentkimchi:tddStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

Use when implementing any feature, bugfix, or behavior change — before writing implementation code. Enforces RED-GREEN-REFACTOR cycle.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# Test-Driven Development

## Overview

Write the test first. Watch it fail. Write minimal code to pass.

**Core principle:** If you didn't watch the test fail, you don't know if it tests the right thing.

**Violating the letter of the rules is violating the spirit of the rules.**

## When This Applies

**Always** when writing code that has behavior:
- New features
- Bug fixes
- Refactoring
- Behavior changes

**Exceptions (ask your human partner):**
- Pure configuration files
- Database migrations (tested via schema verification)
- Static content
- Throwaway prototypes

Thinking "skip TDD just this once"? Stop. That's rationalization.

## The Iron Law

```
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
```

Write code before the test? Delete it. Start over.

**No exceptions:**
- Don't keep it as "reference"
- Don't "adapt" it while writing tests
- Don't look at it
- Delete means delete

Implement fresh from tests. Period.

## Red-Green-Refactor

### RED — Write Failing Test

Write one minimal test showing what should happen.

<Good>
```ruby
it "rejects file over 5MB with clear error" do
  large_file = fixture_file("6mb.jpg")

  result = AvatarUploadService.call(large_file, user_id: user.id)

  expect(result).to be_failure
  expect(result.error).to eq("File too large (max 5MB)")
end
```
Clear name, tests real behavior, one thing
</Good>

<Bad>
```ruby
it "works" do
  mock = double("s3", upload: true)
  allow(S3Client).to receive(:new).and_return(mock)
  result = AvatarUploadService.call(file, user_id: 1)
  expect(mock).to have_received(:upload)
end
```
Vague name, tests mock not code
</Bad>

**Requirements:**
- One behavior per test
- Clear name describing the behavior
- Real code (no mocks unless unavoidable)

### Verify RED — Watch It Fail

**MANDATORY. Never skip.**

```bash
# Run the test, expect failure
bundle exec rspec spec/services/avatars/upload_service_spec.rb
```

Confirm:
- Test fails (not errors)
- Failure message is expected
- Fails because feature missing (not typos)

**Test passes?** You're testing existing behavior. Fix test.

**Test errors?** Fix error, re-run until it fails correctly.

### GREEN — Minimal Code

Write simplest code to pass the test.

<Good>
```ruby
def call(file, user_id:)
  return failure("File too large (max 5MB)") if file.size > 5.megabytes

  url = s3_client.upload(file, key: "avatars/#{user_id}/#{SecureRandom.uuid}")
  success(url: url)
end
```
Just enough to pass
</Good>

<Bad>
```ruby
def call(file, user_id:, options: {})
  strategy = options.fetch(:resize_strategy, :vips)
  validator = ValidatorFactory.for(file.content_type)
  pipeline = ProcessingPipeline.new(strategy: strategy)
  # YAGNI
end
```
Over-engineered
</Bad>

Don't add features, refactor other code, or "improve" beyond the test.

### Verify GREEN — Watch It Pass

**MANDATORY.**

```bash
bundle exec rspec spec/services/avatars/upload_service_spec.rb
```

Confirm:
- Test passes
- Other tests still pass
- Output pristine (no errors, warnings)

**Test fails?** Fix code, not test.

**Other tests fail?** Fix now.

### REFACTOR — Clean Up

After green only:
- Remove duplication
- Improve names
- Extract helpers

Keep tests green. Don't add behavior.

### REPEAT

Next failing test for next feature.

## Common Rationalizations

| Excuse | Reality |
|--------|---------|
| "Too simple to test" | Simple code breaks. Test takes 30 seconds. |
| "I'll test after" | Tests passing immediately prove nothing. |
| "Tests after achieve same goals" | Tests-after = "what does this do?" Tests-first = "what should this do?" |
| "Already manually tested" | Ad-hoc ≠ systematic. No record, can't re-run. |
| "Deleting X hours is wasteful" | Sunk cost fallacy. Keeping unverified code is technical debt. |
| "Keep as reference, write tests first" | You'll adapt it. That's testing after. Delete means delete. |
| "Need to explore first" | Fine. Throw away exploration, start with TDD. |
| "Test hard = design unclear" | Listen to test. Hard to test = hard to use. |
| "TDD will slow me down" | TDD faster than debugging. Pragmatic = test-first. |
| "Existing code has no tests" | You're improving it. Add tests for the code you touch. |

## Red Flags — STOP and Start Over

- Code before test
- Test after implementation
- Test passes immediately
- Can't explain why test failed
- Tests added "later"
- Rationalizing "just this once"
- "I already manually tested it"
- "Keep as reference" or "adapt existing code"
- "Already spent X hours, deleting is wasteful"
- "This is different because..."

**All of these mean: Delete code. Start over with TDD.**

## Verification Checklist

Before marking work complete:

- [ ] Every new function/method has a test
- [ ] Watched each test fail before implementing
- [ ] Each test failed for expected reason (feature missing, not typo)
- [ ] Wrote minimal code to pass each test
- [ ] All tests pass
- [ ] Output pristine (no errors, warnings)
- [ ] Tests use real code (mocks only if unavoidable)
- [ ] Edge cases and errors covered

Can't check all boxes? You skipped TDD. Start over.

## Debugging Integration

Bug found? Write failing test reproducing it. Follow TDD cycle. Test proves fix and prevents regression.

Never fix bugs without a test.

## When Stuck

| Problem | Solution |
|---------|----------|
| Don't know how to test | Write wished-for API. Write assertion first. Ask your human partner. |
| Test too complicated | Design too complicated. Simplify interface. |
| Must mock everything | Code too coupled. Use dependency injection. |
| Test setup huge | Extract helpers. Still complex? Simplify design. |

## Final Rule

```
Production code → test exists and failed first
Otherwise → not TDD
```

No exceptions without your human partner's permission.

Related Skills

kimchi:verification-before-completion

7
from Tromml/kimchi

Use when about to claim work is complete, fixed, or passing — before committing or creating PRs. Evidence before assertions, always.

kimchi:validate

7
from Tromml/kimchi

This command should be used to validate bead YAML files for standalone executability. Runs 4 validators (context completeness, deliverables clarity, test specification, isolation) and enriches failing beads. Eighth stage of the Kimchi planning pipeline.

kimchi:systematic-debugging

7
from Tromml/kimchi

Use when encountering any bug, test failure, or unexpected behavior — before proposing fixes. Enforces 4-phase root cause analysis.

kimchi:status

7
from Tromml/kimchi

This command should be used to check the current state of the Kimchi planning pipeline, including which stages have completed, what artifacts exist, and bead validation status.

kimchi:simplicity-enforcement

7
from Tromml/kimchi

Use when designing solutions, implementing features, or considering abstractions. Enforces YAGNI, minimal code, and preferring duplication over wrong abstraction.

kimchi:review

7
from Tromml/kimchi

This command should be used to run multi-persona review of the implementation plan. Five specialized personas critique the plan for scope creep, complexity, premature optimization, and test coverage. Fifth stage of the Kimchi planning pipeline. Produces .kimchi/PLAN-REVIEWED.md.

kimchi:reset

7
from Tromml/kimchi

This command should be used to clear the Kimchi working directory (.kimchi/) and start fresh. Preserves .beads/ directory. Use when starting a new planning session or recovering from a bad state.

kimchi:research

7
from Tromml/kimchi

This command should be used to investigate codebase patterns, frameworks, and existing implementations before planning. Third stage of the Kimchi planning pipeline. Produces .kimchi/RESEARCH.md.

kimchi:requirements

7
from Tromml/kimchi

This command should be used to extract and categorize requirements from CONTEXT.md into v1 (must have), v2 (next iteration), and out of scope. Second stage of the Kimchi planning pipeline. Produces .kimchi/REQUIREMENTS.md.

kimchi:refine

7
from Tromml/kimchi

This command should be used to iteratively improve the plan until quality threshold is reached or diminishing returns detected. Sixth stage of the Kimchi planning pipeline. Produces .kimchi/PLAN-DRAFT.md.

kimchi:plan

7
from Tromml/kimchi

This command should be used to run the Kimchi planning pipeline through refinement, transforming a vague idea into a draft plan ready for cross-model analysis. Orchestrates 6 stages: clarify, requirements, research, generate, review, refine. Use --full-auto to also run beads + validate after manual revise/synthesize.

kimchi:plan-synthesize

7
from Tromml/kimchi

This command should be used to synthesize multiple cross-model plan revisions into a superior hybrid plan. Eighth stage of the Kimchi planning pipeline. Reads PLAN-REVISED-*.md files and outputs PLAN-SYNTHESIZED.md — the TRUE final plan.