Menu
Use when implementing any feature or fix using TDD, before writing any implementation code
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| 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.
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:
NEVER insert a placeholder assertion. It produces false RED evidence regardless of language.
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. |
| "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. |
assert.fail(), Assert.Fail(), Assert.True(false), fail(), throw new NotImplementedException()) — tests no behavior, produces false RED evidenceAny 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: 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 outside-in-tdd:
gherkin-gate defines WHAT (observable behavior)mutation-testing validates test quality after GREEN (before merge)Pair with domain-specific testing skills for patterns and examples.
Use when reviewing DISTILL artefacts (Gherkin scenarios, test plans, implementation plans) for quality, completeness, and alignment. Contains the gate definitions and scoring rubric for the acceptance-designer-reviewer lenses.
Use when reviewing DESIGN artefacts (event models, ADRs, component diagrams, context maps, interface contracts) for quality, DDD compliance, and architectural correctness. Contains gate definitions and scoring rubric for the solution-architect-reviewer lenses.
Use when capturing E2E test evidence (screenshots, videos, traces) and storing them in .copilot-tracking/skraft-plans/{projectSlug}/changes/{date}/evidence/{story}/evidence/ for agents to consume. Covers Playwright setup, on-failure capture, trace collection, and evidence manifest generation.
Use when writing, reviewing, or structuring BDD scenarios in Gherkin format. Covers Given/When/Then conventions, scenario outline patterns, background usage, tag strategies, and domain language alignment. Load before any Gherkin authoring.
Use when designing test coverage matrices, assigning tests to Clean Architecture layers, planning the outside-in implementation order, or applying the Walking Skeleton strategy. Ensures every behaviour is tested at the right level with no redundancy. Load after writing Gherkin scenarios.
Use when completing a TDD phase or before committing — self-discipline checkpoints the software-engineer runs against their own output. Not a review contract. The reviewer verifies artifacts independently.