Execute

→ False-positive entry on a native-direct-skill host? → Exit immediately unless the user explicitly asked for TDD or the conversation already contains TDD Route: strict. In off mode, do not start RED / GREEN / REFACTOR from generic bugfix, contract, shared-module, or risky-code wording alone. Hand control back to using-aegis, systematic-debugging, writing-plans, or the fast path with verification. → Implementing a feature or bugfix under TDD Route strict? → No production code without a failing test first. Gate: medium/high complexity? → route to brainstorming or writing-plans first. Mode: default off disables automatic TDD, not completion verification; auto chooses strict/light/skipped by risk. Change Necessity: before strict RED/GREEN enters production edits, confirm the slice really needs a code change. Cycle: RED (write test → watch it fail) → GREEN (minimal code → watch it pass) → REFACTOR (clean up → keep green) Regression: shared module → related tests. contract change → producer + consumer. core logic → old + new tests. Ripple signal hit → cover producer+consumer or real user path before claiming green. GREEN proves the currently expressed behavior slice only. GREEN does not by itself prove parent-task acceptance, business-value completion, or final completion. → Done when: chosen TDD Route is recorded, strict-route tests pass, TDD preflight gate passed when applicable, pre-edit complexity risk was checked for non-trivial source edits, and verification-before-completion has fresh evidence.

Test-Driven Development (TDD)

Overview

Under TDD Route: strict, write the test first. Watch it fail. Write minimal code to pass.

If you didn't watch the test fail, you don't know if it tests the right thing.