Menu
Use when a feature, bugfix, or behavior change has a testable contract and implementation is about to begin.
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
Use when routed repo work still has meaningful ambiguity about behavior, constraints, taste, or acceptance intent, and that ambiguity would make planning or execution unsafe.
Use when a new request might involve repo work, tracked changes, workspace-specific decisions, or durable coordination and you must decide whether Superplan should engage before exploring or implementing.
Use when tracked work is already shaped and the next move is to execute, verify, block, or request feedback without replanning from scratch.
Use when the target is understood but the work still needs an execution path, task breakdown, or proof strategy before implementation begins.
Use when Superplan may engage and you need to decide whether to stay lightweight, create one tracked task, gather context first, or shape deeper structure before execution begins.
Use when Superplan has decided to engage and the work still needs plans, specs, proof paths, or multiple tracked tasks shaped before bounded execution can start.
| name | superplan-tdd |
| description | Use when a feature, bugfix, or behavior change has a testable contract and implementation is about to begin. |
Write the test or equivalent check first. Watch it fail. Write the minimal code to pass.
No production code without a failing test or failing check first.
If code was written before the proof path, delete the shortcut and start from the failing test.
Do not treat "I can add tests after" as equivalent. If the proof was not red first, it is not guiding the implementation.
Use when:
superplan-review will later judgeAfter green, execution continues through the normal shaped path and later review still flows through superplan-review.