Menu
Use when strict test-first discipline is explicitly requested or required for a change.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Systematic analysis and reasoning workflows. Use when performing audits, investigation, requirements analysis, risk analysis, scenario/edge-case enumeration, or design analysis that demands evidence-based, comprehensive coverage.
Code quality and safety standards. Activates when editing or reviewing code. Use for quality priorities, safety checks, and code correctness verification.
Use when performing coding tasks (implement features, fix bugs, refactor code). Orchestrates language detection, mode switching (normal/autopilot/full-auto), quality enforcement, and verification.
Break a problem into atomic, testable subproblems. Use when facing complex tasks, unclear requirements, or planning implementation strategy.
Start structured feature implementation workflow. Use when implementing new features, adding functionality, or building complete user-facing capabilities.
Use when starting work that needs isolated branches or parallel feature development using git worktrees.
| name | tdd-enforce |
| description | Use when strict test-first discipline is explicitly requested or required for a change. |
| allowed-tools | ["shell","read_file","apply_patch","update_plan"] |
| metadata | {"short-description":"Strict TDD (opt-in)"} |
Read these references:
~/.config/agent/domain/testing/unit.md - Unit testing strategy~/.config/agent/domain/testing/coverage.md - Coverage expectationsThis is strict TDD. It is opt-in: use only when explicitly requested. Default guidance elsewhere is to encourage TDD, not require it.
Core principle: If you didn't watch the test fail, you don't know if it tests the right thing.
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
If code was written before the failing test, delete it and start over.
If tests fail unexpectedly or behavior is unclear, switch to systematic-debugging.
Read testing-anti-patterns.md before adding mocks or test utilities.
Target: ${ARGUMENTS}