Tdd

Skill ialameh/sift-coder/skills/coding/tdd

Use when the user invokes TDD discipline, says "write test first", "test-driven", "/tdd". Strict red-green-refactor. Refuses to write production code before a failing test exists.From its SKILL.md

Install

npx -y skills add ialameh/sift-coder --skill tdd

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.8 KB, as published. Nobody here has run it

tdd

Strict TDD. Test first, fail first, then code, then refactor. Non-negotiable order.

Method

For each unit of behaviour:

Red. Write one test that asserts the desired behaviour. Run it. It must fail — verify the failure mode is the absent behaviour, not a syntax error or wrong import.
Green. Write the simplest code that makes the test pass. Hardcoded values are fine if the test only asserts one input. Run all tests. All green.
Refactor. With all tests green, improve structure. Extract, rename, dedup. Run tests after every change — must stay green.
Next. New test that triggers a generalisation. Repeat.

Rules — non-negotiable

No production code without a failing test. If you find yourself writing code and there's no failing test for it, stop, write the test.
Test must have actually failed. If you wrote a test and it passed immediately, you wrote the wrong test or the code was already there. Diagnose; don't claim done.
Tests are first-class. Bad test names, no assertions, mocking the thing under test = same as no test.
Refactor only when green. Never refactor on a failing test (you lose your ground truth).
One test at a time. Don't write three tests then implement all three.

Output shape per cycle

Cycle N
  Behaviour:  <one sentence>
  Red:        <test path>:<line>  ← failed with: <quoted error>
  Green:      <smallest change to make it pass>
  Tests:      M passing
  Refactor:   <what changed>  | tests: M passing

Anti-patterns

Writing the production code "in your head" before the test (cheating)
Test that asserts implementation detail (e.g. private method called) instead of behaviour
Big-bang test that asserts 5 behaviours — split it
Refactoring during red (you have no safety net)
Skipping refactor because "it works" (debt accumulates fast)

When NOT to use

Spike / exploration code (use /siftcoder:dream or scratch)
Pure config / data file changes
Generated code (e.g. graphql codegen) — test the inputs, not the output

Subagent dispatch

tester agent (if installed) — knows behaviour-coverage gates, not just line coverage
Plan to break a feature into TDD-shaped units of behaviour before starting

Memory capture

Each red-green-refactor cycle is a captured event. Future "how do we test X" queries surface prior TDD cycles in the same module.

Value over native CC

CC will write tests if asked. CC won't refuse to write code first if you ask it for code first. This skill enforces the order. The discipline IS the value.