red-synthesize-green

name	red-synthesize-green
description	Use when implementing any feature or fix using TDD, before writing any implementation code

RED → SYNTHESIZE GREEN (AI TDD Cycle)

Overview

2-step cycle replacing traditional 3-step TDD. Optimized for AI synthesis.

• Traditional (3 steps): RED → green (dirty) → Refactor
• AI-Optimized (2 steps): RED (behavior failure) → SYNTHESIZE GREEN (clean synthesis)

Architectural guidance is mandatory between steps.

Hard rule: No implementation code before RED is a clean behavior failure.

Step 1: RED (Behavior Failure Only)

Write the failing test. Run it.

• Compilation errors = wishful thinking phase → implement stubs/empty returns to compile, rerun
• Assertion/behavior failure = RED ✓ → proceed to Step 2
• Never treat compilation errors as RED

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.

Placeholder assertions ARE NOT wishful thinking. assert.fail(), Assert.Fail(), Assert.True(false), fail(), assert False — any assertion designed to fail unconditionally — makes the test compile and fail, but asserts nothing about the API under test. A proper wishful thinking test calls the function you WISH existed and lets the build/runtime surface the failure naturally:

1. Reference the missing type/function → compile error or missing-symbol/module error
2. Stub just enough to compile (empty return / minimal implementation) → test fails on the real business assertion

NEVER insert a placeholder assertion. It produces false RED evidence regardless of language.

Between Steps: Architectural Guidance (MANDATORY)

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:

• Which pattern? (specification, factory, builder)
• Which layer owns the logic?
• Immutability, return values vs mutations?

Step 2: SYNTHESIZE GREEN (Clean Synthesis)

Implement complete, clean, production-ready solution in one shot.

• Follows all architectural rules and coding standards
• No dirty-then-refactor — synthesize properly from the start
• Idiomatic code, domain semantics, SOLID principles
• If test was misunderstood → revise test, restart from RED

No iteration after SYNTHESIZE GREEN unless RED was wrong or architectural guidance changed.

Common Rationalizations

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.
"The placeholder fails, so it's RED"	No. assert.fail() / Assert.Fail() / Assert.True(false) assert nothing about the API. Write the real call; let the missing symbol cause a compile error, then stub past it.

Red Flags — STOP and Restart

• Implementation code before RED is a behavior failure
• Compilation errors treated as RED
• Placeholder assertion in test body (assert.fail(), Assert.Fail(), Assert.True(false), fail(), throw new NotImplementedException()) — tests no behavior, produces false RED evidence
• Skipping RED entirely
• Skipping the Between Steps architectural guidance
• Proceeding to SYNTHESIZE GREEN without developer test validation
• Refining code after SYNTHESIZE GREEN instead of revising RED

Any of these mean: Delete code, start over with proper RED.

Quick Reference

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

When Orchestrating Subagents (MANDATORY)

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:

1. Dispatch 1 — RED only: subagent writes test, stubs to compile, runs to confirm behavior failure, reports the failing test output
2. YOU pause — show the failing test to the developer, wait for explicit confirmation ("ok, proceed")
3. Dispatch 2 — SYNTHESIZE GREEN: only after developer approves the test

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:

• Your subagent prompt contains both "write the failing test" AND "implement the solution"
• You wrote PAUSE in a plan comment but included all steps in one prompt
• You assumed the developer would confirm via the plan document

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.

Integration

REQUIRED BACKGROUND: outside-in-tdd — defines the two test streams (Application + Domain) that this cycle drives.

Quality Gate Ownership

This skill owns the strict TDD quality gate for business logic layers:

1. Application and Domain logic must reach 100% code coverage before completion.
2. Mutation testing on Application and Domain logic must end with 0 non-equivalent surviving mutants.
3. Any equivalent mutant must be explicitly documented with justification.

If one of these conditions is not met, work is not complete.

Behavior-first workflow: When used with outside-in-tdd:

1. gherkin-gate defines WHAT (observable behavior)
2. Acceptance tests map scenarios to executable tests (RED phase)
3. This skill enforces the RED → validation → SYNTHESIZE GREEN cycle
4. mutation-testing validates test quality after GREEN (before merge)

Pair with domain-specific testing skills for patterns and examples.