원클릭으로
test-driven-development
Use before changing behavior or fixing a bug when a focused test can prove the change.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Use before changing behavior or fixing a bug when a focused test can prove the change.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when waiting for servers, jobs, files, tests, queues, or external processes.
Use when a bounded subtask is summarization, mechanical review, fixture inspection, proposal triage, verification, or boilerplate.
Use when locating where a symbol, function, type, command, or constant is defined or referenced, instead of grep/find/read chains.
Use when tempted to add broad abstractions, future-proofing, or extra product surface beyond the requested change.
Use before asking the user about infrastructure, preferences, conventions, prior decisions, or past incidents.
Use when evaluating reviewer feedback, review delegates, or suggested code changes.
| name | test-driven-development |
| description | Use before changing behavior or fixing a bug when a focused test can prove the change. |
| source | bundled |
| triggers | {"tool":["Write","Edit","MultiEdit"],"path_pattern":["_test.","test_"]} |
Use this when behavior is changing and the system can express the desired result as a test.
Work in this order:
Do not treat a compile error, unrelated fixture failure, or unrun test as a valid red phase. The red phase must show the behavior gap you intend to close.