executing-plans
executing-plans
Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available
tddTDD deprecated shim
Independent GitHub snapshot · Automated classification · Original documentation governs
Hard-deprecated. Do not invoke or route this skill. Keep test-first discipline inside the active implementation workflow and verify with the project test suite.
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
Write code before test? DELETE IT. Start over. No exceptions.
| If You See | Action |
|---|---|
| Code written before test | STOP. Delete code. Write test first. |
| Test passes on first run | Test is wrong. Fix it to fail first. |
| Multiple features in one cycle | STOP. One test, one feature. |
| Skipping refactor | Go back. Clean up before next feature. |
Before each implementation:
# Run the project's test command - should have ONE new failure
After implementation:
# Run the project's test command - new test should pass, all others still pass
When guiding TDD:
## TDD Cycle: [Feature Name]
### RED Phase
Test: [test code]
Expected failure: [what error you expect]
Actual: [run result showing failure]
### GREEN Phase
Implementation: [minimal code]
Result: [run result showing pass]
### REFACTOR Phase
Changes: [what was cleaned up]
Result: [tests still pass]
The tdd-guide agent SHOULD consult Codex for test strategy validation.
Prefer native test-engineer consultation or CLI-backed ask surfaces when available. Optional MCP compatibility ask tools may be used only when already enabled. If consultation tools are unavailable, fall back to the test-engineer agent.
Remember: The discipline IS the value. Shortcuts destroy the benefit.