メニュー
Use when changing behavior so the agent drives the edit through a failing test, preserves existing tests, follows the selected TDD mode, and verifies red-green-refactor evidence.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when debugging a failing test, broken build, runtime error, or unexpected system behavior. Drives hypothesis-based investigation, root-cause fixes, verification, and reusable learning capture.
Use when a claim, plan, spec, doc, or design must be attacked against source evidence before implementation or approval. Uses write tools, shell execution, and may spawn subagents. Invoke with enable_write_tools=true and enable_subagent_tools=true.
Use when fixing broken behavior and the priority is reproduce, root cause, regression proof, and the smallest safe repair. Uses write tools, shell execution, and may spawn subagents. Invoke with enable_write_tools=true and enable_subagent_tools=true.
Use when reviewing code changes with explicit stage, target, and focus so own-code checks and others’ PR reviews stay distinct but share one contract. Uses write tools, shell execution, and may spawn subagents. Invoke with enable_write_tools=true and enable_subagent_tools=true.
Use when the deliverable is docs or reference material and every claim must stay tied to observed behavior or cited source evidence. Uses write tools, shell execution, and may spawn subagents. Invoke with enable_write_tools=true and enable_subagent_tools=true.
Use when adding or changing product behavior that must ship with explicit purpose, scenarios, and verification. Uses write tools, shell execution, and may spawn subagents. Invoke with enable_write_tools=true and enable_subagent_tools=true.
| name | test-first-change |
| description | Use when changing behavior so the agent drives the edit through a failing test, preserves existing tests, follows the selected TDD mode, and verifies red-green-refactor evidence. |
Use this skill for behavior changes, bug fixes, parser changes, validation logic, public API changes, and non-trivial refactors where behavior can be expressed as a test.
Skip only for documentation-only changes, generated-output-only changes, mechanical renames, or an explicitly approved exemption.
Behavior changes need a failing test first unless explicitly exempt; existing tests must not be deleted, skipped, weakened, or rewritten to pass without approval.
Use canonical/tdd-planning.md to select the mode before editing:
lightweight — low-risk narrow change; record test intent in the task plan.medium — normal implementation; add ## TDD Plan to the plan.heavy-aggressive — critical or high-regression work; create standalone specs/tdd/<slug>.md or equivalent spec section.required — implementation is blocked until red test exists or exemption is approved.Test-first exemption: <why a failing test is not practical>
Approval source: <user | plan | spec | existing repo constraint>
Validation instead: <command or manual check that proves the behavior>
Risk: <what this does not cover>
Prefer tests that observe behavior through the public seam already used by callers.