메뉴
Red→green→refactor discipline for new behavior — forces a failing test before implementation and a passing test before any claim of done.
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/coreindustries/core-ai-template --skill tdd명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SKILL.md 표시 중
SOC 직업 분류 기준
| name | tdd |
| description | Red→green→refactor discipline for new behavior — forces a failing test before implementation and a passing test before any claim of done. |
Red→green→refactor for new behavior. This skill exists to fix one specific, observable agent failure mode: writing a lot of code, visually checking it, and claiming success without running the tests. Capturing a failing test before the implementation, then the same test passing after, makes that failure mode impossible to sustain.
/tdd <description of the new behavior>
Invoke when the work adds new observable behavior with a testable contract:
TDD hurts when no meaningful test can be written first. Skip it — with a documented reason — for:
/refactor — it writes characterization tests first, then refactors.For any of these, state explicitly: "Deferring TDD because . Will verify by ." Do not silently skip.
<reason><what you'll do instead>Agents consistently exhibit this pattern:
Visual inspection is not proof. A test that was never observed to fail cannot prove the implementation made it pass — maybe it was always green, maybe it never actually ran against the new code. The red→green transition is the proof.
Before writing any implementation:
{test_command} tests/unit/test_<feature>::<specific_test_name>
If the test doesn't fail, the test is wrong. The behavior already exists, or the assertion is tautological, or you're asserting against a mock that isn't exercised.
Write the minimum implementation that makes the failing test pass. Not "the ideal implementation." Not "handle all the edge cases." The smallest change that turns the assertion from fail to pass.
Run the same test again. Capture the output. Confirm it passes.
If other tests break, stop. You introduced a regression. Fix or revert before continuing.
With tests passing, improve the implementation:
After each change, re-run the test suite. If green stays green, keep the refactor. If something breaks, revert the refactor — never the green test.
When you report a TDD cycle complete, you MUST include:
1 failed / N passed)N+1 passed)"I wrote the test and the implementation and it works" is not acceptable evidence. Report with actual run output.
For new behavior with multiple cases (happy path + 2 error paths + edge case), loop the cycle once per case:
Do not write all the tests first, then all the implementation. That breaks the red→green observation — you can't tell which implementation change made which test go green, and "I wrote them all, they all pass" reintroduces the exact failure mode this skill prevents.
If the work genuinely can't be TDD'd (see "When NOT to Use"), write a two-line note in the PR description or commit body:
TDD deferred. Reason: <why>
Verification plan: <what will verify the behavior instead>
Deferral without a note is the same as skipping — and skipping is exactly what this skill exists to prevent.
.claude/rules/testing.md — project-level test coverage minimums and organization/refactor — refactor with a test-first safety net when tests already exist/debug — systematic debugging when a test is already failing and you need to find out why