ワンクリックで
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Use when implementing any feature or bugfix, before writing implementation code
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions
Applies when a session involves an existing codebase or project context and onboarding should occur prior to brainstorming or implementation. Skip for purely abstract design discussion with no project to onboard to, or if the project was already onboarded earlier in the session
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Use when creating new skills, editing existing skills, or verifying skills work before deployment
| name | test-driven-development |
| description | Use when implementing any feature or bugfix, before writing implementation code |
**GREEN**
```typescript
function submitForm(data: FormData) {
if (!data.email?.trim()) return { error: 'Email required' };
// ...
}
```
**Verify GREEN** — `PASS`
**REFACTOR** — Extract validation for multiple fields if needed.
Writing production code first, then writing tests that pass immediately. Passing immediately proves nothing — you never saw the test catch the bug.
"I'll write tests after to verify it works" — Tests-after answer "What does this do?" Tests-first answer "What *should* this do?" Tests-after are biased by your implementation. You test what you built, not what's required.
"Keep as reference, write tests first" — You'll adapt it. That's testing after. Delete means delete.
| Excuse | Reality |
|---|---|
| "Too simple to test" | Simple code breaks. Test takes 30 seconds. |
| "I'll test after" | Tests passing immediately prove nothing. |
| "Already manually tested" | Ad-hoc != systematic. No record, can't re-run. |
| "Deleting X hours is wasteful" | Sunk cost fallacy. Keeping unverified code is tech debt. |
| "Need to explore first" | Fine. Throw away exploration, start with TDD. |
| "Test hard = design unclear" | Listen to the test. Hard to test = hard to use. |
| "TDD will slow me down" | TDD is faster than debugging. |
| "This is different because..." | No. Start over with TDD. |
All of these mean: Delete code. Start over with TDD.
| Problem | Solution |
|---|---|
| Don't know how to test | Write wished-for API. Write assertion first. Ask your human partner. |
| Test too complicated | Design too complicated. Simplify interface. |
| Must mock everything | Code too coupled. Use dependency injection. |
Before marking work complete:
Can't check all boxes? You skipped TDD. Start over.