// Enforces disciplined RED-GREEN-REFACTOR cycle—write failing test first, watch it fail, write minimal code to pass, then refactor.
Model the end-to-end system, constraints, and failure modes before touching code; use whenever a change spans multiple layers or unclear requirements.
Decompose work into safe, observable increments with feature flags, rollbacks, and communication baked in.
Design every change with traceability, diagnostics, and fast incident triage in mind across mobile, web, and web3 stacks.
Guard latency, memory, battery, bandwidth, and gas/compute budgets by measuring before and after every change.
Deliver changes with clear communication, reviewer-ready context, and follow-up accountability.
Enforce reproducible testing, automated verification, and evidence-driven sign-off before merging any change.
| name | eng-tdd |
| description | Enforces disciplined RED-GREEN-REFACTOR cycle—write failing test first, watch it fail, write minimal code to pass, then refactor. |
Write the test first. Watch it fail. Implement just enough to pass. Refactor while staying green. If you didn’t see the test fail, you don’t know whether it tests the right behavior.
Iron Law
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
Wrote code before the test? Delete it. Start from tests.
| Good | Bad |
|---|---|
| Tests one thing | Vague “does work” |
| Clear name | test1 |
| Real behavior | Asserts on mocks |
| Excuse | Response |
|---|---|
| “Too simple” | Simple code breaks—test anyway. |
| “I’ll test later” | Tests-after confirm existing behavior, not requirements. |
| “Manual testing is enough” | No record or rerun; automation is required. |
| “Deleting work is wasteful” | Sunk cost; untested code is debt. |
| “Being pragmatic” | TDD prevents debugging hell; pragmatism = reliability. |
Failed any item? You skipped TDD—start over.
Production code exists only alongside a test that failed before the code was written. Otherwise, redo it with TDD.