From n360-engineering
Use when implementing any new feature, endpoint, service method, or critical flow. Enforces strict RED-GREEN-REFACTOR cycles where tests must fail before implementation exists. Does NOT trigger for quick bug fixes, config changes, documentation, single-line patches, or UI tweaks with no logic.
How this skill is triggered — by the user, by Claude, or both
Slash command
/n360-engineering:tddThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
The default behaviour of AI coding agents is to write implementation first and tests after. This produces tautological tests that confirm the code works as written, not as intended. This protocol prevents that.
The default behaviour of AI coding agents is to write implementation first and tests after. This produces tautological tests that confirm the code works as written, not as intended. This protocol prevents that.
RED: Write ONE failing test that defines the expected behaviour.
Run it. Confirm it FAILS for the right reason (missing feature, not syntax error).
If it passes immediately → the test is wrong. Delete it and try again.
GREEN: Write the MINIMUM code to make that one test pass.
No speculative code. No "while I'm here" additions. Just enough to go green.
Run the test. Confirm it passes.
REFACTOR: With the test green, clean up.
Extract helpers, improve naming, remove duplication.
Run the test after every change. It must stay green.
REPEAT: Next behaviour → next failing test → next minimal implementation.
Claude will attempt to skip TDD with seemingly reasonable excuses. These are the common ones and the correct response to each:
| Excuse | Response |
|---|---|
| "This is too simple to need a test" | Simple code is the easiest to test. Write the test. It takes 30 seconds. |
| "I'll write the tests after" | No. Tests written after implementation confirm what you built, not what was needed. That defeats the purpose. |
| "I already tested it manually" | Manual testing is not repeatable. Write the automated test. |
| "The existing code has no tests so TDD doesn't apply" | Write the test for your change. You are not responsible for legacy gaps, but you do not add to them. |
| "This is just a refactor, no new behaviour" | If there's no new behaviour, there should be existing tests that stay green. If there are no existing tests, write one for the current behaviour before refactoring. |
| "It's faster to write it all at once" | Faster to write, slower to debug. The cycle is non-negotiable for features. |
Not everything needs full TDD ceremony. Use judgement:
| Change Type | TDD Level |
|---|---|
| New feature / endpoint / service method | Full RED-GREEN-REFACTOR cycle |
| Bug fix | Write a test that reproduces the bug (RED), then fix it (GREEN) |
| Refactor with existing test coverage | Run existing tests after every change (REFACTOR only) |
| Config, docs, copy changes | No TDD required |
| UI-only with no logic | No TDD required, but snapshot/visual test encouraged |
| Safety-critical flow | Full TDD + end-to-end test. No exceptions. |
npx claudepluginhub jpvt1977/n360-marketplace --plugin n360-engineeringEnforces RED-GREEN-REFACTOR TDD cycle: write a failing test first, then minimal code to pass, then refactor. Use when implementing features or fixing bugs during the implement phase.
Red-Green-Refactor cycle for test-first development. Write failing test, implement minimal code, refactor safely. Use when developing new features or fixing bugs in test-driven projects.