// Use when implementing any feature or fix using TDD, before writing any implementation code
Use when domain logic leaks into API/Infrastructure, project references violate layer boundaries, or you need to decide between CQS (always), CQRS bus (complex domains), and DDD patterns (invariants and events).
Use when configuring Git hooks in .NET projects before team commits occur, to enforce commit message standards and code formatting automatically
Use before writing any test or implementation task, when observable behavior needs to be captured in business language scenarios and approved by the user before code begins
Use when running mutation testing, killing mutants, verifying test quality, checking mutation score, or analyzing survivors after the test baseline is green
Use when writing tests from the outside-in, defining behavior before code, or any feature where tests should start from observable business behavior and let internal design emerge
Use when understanding project composition by language, measuring code change impact, or generating code statistics for CI/CD metrics
| name | red-synthesize-green |
| description | Use when implementing any feature or fix using TDD, before writing any implementation code |
2-step cycle replacing traditional 3-step TDD. Optimized for AI synthesis.
Architectural guidance is mandatory between steps.
Hard rule: No implementation code before RED is a clean behavior failure.
Write the failing test. Run it.
Programming by Wishful Thinking: When your test won't compile, you're discovering the API you need. Stub just enough to compile, then confirm the test fails on behavior.
Hard rule: This step is not skippable. Do not proceed to SYNTHESIZE GREEN without completing it.
Developer must review and explicitly validate the test before continuing. AI pauses here and waits for developer confirmation that the test correctly captures the intended behavior.
Orient design before synthesis:
Implement complete, clean, production-ready solution in one shot.
No iteration after SYNTHESIZE GREEN unless RED was wrong or architectural guidance changed.
| Excuse | Reality |
|---|---|
| "Compilation error IS red" | No. Compilation = wishful thinking. RED = behavior failure. |
| "I'll write dirty code then refactor" | That's 3-step TDD. SYNTHESIZE GREEN produces clean code. |
| "I can skip RED, I know it'll fail" | Run it. RED proves your test catches real failures. |
Any of these mean: Delete code, start over with proper RED.
| Phase | What | Success Criteria |
|---|---|---|
| RED | Write test, stub until compiles, run | Test fails on behavior (assertion), not compilation |
| Guidance (MANDATORY) | Orient architectural approach + developer validates test | Design direction clear, developer has confirmed test |
| SYNTHESIZE GREEN | Synthesize complete clean solution | Tests green, architecture respected, production-ready |
If you are an orchestrating agent using subagent-driven-development:
NEVER put RED and SYNTHESIZE GREEN in the same subagent prompt.
Split every TDD task into two separate dispatches:
The mandatory human validation checkpoint is the orchestrator's responsibility. It cannot be delegated to the subagent.
Red flags — you are violating this rule if:
PAUSE in a plan comment but included all steps in one prompt| Rationalization | Reality |
|---|---|
| "The pause is in the plan text" | Plans are documentation. Dispatch boundaries are enforcement. |
| "The subagent will stop and ask" | Subagents execute what they receive. Split the prompt. |
| "It's more efficient in one shot" | Efficiency that skips developer validation is not efficiency. |
REQUIRED BACKGROUND: superpowers-whetstone:outside-in-tdd — defines the two test streams (Application + Domain) that this cycle drives.
This skill owns the strict TDD quality gate for business logic layers:
If one of these conditions is not met, work is not complete.
Behavior-first workflow: When used with superpowers-whetstone:outside-in-tdd:
superpowers-whetstone:gherkin-gate defines WHAT (observable behavior)superpowers-whetstone:mutation-testing validates test quality after GREEN (before merge)Pair with domain-specific testing skills for patterns and examples.