Menu
RED-GREEN-REFACTOR execution discipline for AI agents. Use when implementing any feature or bugfix that has (or should have) tests — forces a failing test confirmed for the right reason before any production code. Loaded by add.build and add.test.
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
Consolidated view of the add-pro ecosystem - commands, skills, relationships and dependencies. Loaded by /add as source of truth.
Source of truth for ADD doc rules, depth floors, IDs, refs, validation gate. Load before any doc write.
Use when running agent-judged QA validation (read-PNG by default; the playwright plugin adds live driving) — the Level C judge rubric, severity taxonomy, dual-judge (@ux-agent review ∥ @qa-agent) method, report schema/template, and the config.json/screens.json formats. Consumed by /add.qa and both judges.
Use when a state-materializing command starts or is asked to upgrade — reads the setup receipt, compares the recorded contract against the shipped one, executes the declared upgrade deltas sequentially, and rewrites the receipt even on a verified-current no-op. Consumed by /add.qa-setup STEP 1.5 and STEP 11.
Internal skill for developing ADD framework artefacts (commands, skills, agents, scripts). Use when add-framework--plan analyzes viability of new framework features, when add-framework--build implements framework artefacts, or when creating/modifying commands, skills, or agents. Always use this skill before proposing or implementing changes to the framework itself.
Use when building, styling, or theming UI components, pages, layouts, dashboards, charts, tables, or forms for SaaS products.
| name | add-tdd |
| description | RED-GREEN-REFACTOR execution discipline for AI agents. Use when implementing any feature or bugfix that has (or should have) tests — forces a failing test confirmed for the right reason before any production code. Loaded by add.build and add.test. |
LANG: Respond in user's native language. Tech terms in English.
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST.
If you wrote implementation before its test: delete it, start over from RED. "Keep it as reference" is testing-after — delete means delete.
Then loop to RED for the next behavior. One test ↔ one implementation step. Do not write all tests first then all implementation (horizontal slicing produces tests for imagined, not actual, behavior).
| Rationalization | Reality |
|---|---|
| "I'll add the test right after" | You won't, and the code will shape the test. Test first, always. |
| "I need to see the design first" | The test IS the design. Let it drive the interface. |
| "Already wrote it, deleting is wasteful" | Sunk cost. Delete it. Start from RED. |
| "The test passes immediately, good" | It proves nothing — it never failed. Fix the test or pick new behavior. |
| "Syntax error counts as RED" | No. It must fail because the behavior is missing. |
| "I'll batch these trivial features" | Trivial enough to batch = trivial enough to skip TDD; use a plain task. |
When a bug is reported: do not start by fixing it. First write a test that reproduces it (RED), then fix to GREEN.
