ワンクリックで
test-driven-development
Use when implementing a feature, behavior change, or bugfix that requires production code.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Use when implementing a feature, behavior change, or bugfix that requires production code.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when following the Super Compound BRD -> PRD -> FSD -> GOAL -> IMPLEMENTATION -> VERIFICATION delivery path, artifact traceability, FSD authority, optional ADR handling, zero context bloat issue slicing, or OPEN-* stop conditions.
Use when an approved FSD goal or lightweight issue pointer is ready for implementation.
Use when multi-component work needs cross-component verification of API contracts, data flow, events, auth, config, UI, background jobs, or tests.
Use when /sc-plan needs FSD GOAL-* packets turned into lightweight issue pointers, local Markdown Kanban boards, blocker DAGs, or multi-agent task contracts.
Use when a plan or issue board has 2+ independent execution streams whose time saving exceeds coordination overhead. Dispatches agents in isolated git worktrees only after required delivery gates pass.
Use when an FSD and goal issue board need requirement coverage, goal quality, dependency DAG, sizing, and verification validated before execution.
| name | test-driven-development |
| description | Use when implementing a feature, behavior change, or bugfix that requires production code. |
Tests specify observable behavior through public interfaces. If a test never failed for the intended reason, it has not proved that it detects missing behavior.
Use before production implementation in strict or balanced mode; balanced is the default.
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
In strict and balanced modes: code written first? Delete it. Start over. Do not keep it as reference, adapt it while testing, or look at it while recreating the behavior.
Core cycle:
Do not write all tests and then all implementation. Each RED-GREEN pair must cross the system vertically and teach the next interface decision.
| Thought | Required response |
|---|---|
| "The test passes immediately" | Correct the test until it proves missing behavior. |
| "I manually tested it" | Manual checks do not replace RED. |
| "It is too simple" | Write the small test. |
| "I need the implementation as reference" | Delete it in strict/balanced mode. |
| "Everything must be mocked" | Improve the seam; mock only system boundaries. |
| "Prototype first" | Throw exploration away, then restart test-first. |
executing-plans applies this cycle per goal.systematic-debugging supplies reproducible regression cases.architecture-enforcement improves hard-to-test seams and module boundaries.verification-before-completion requires fresh RED/GREEN and suite evidence.state-management keeps behavior names aligned with durable project language.