Menu
Use when implementing any feature or bugfix, before writing implementation code
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
Use when the user provides a GitHub PR link with a "deep review" trigger inside a locally cloned repo, to perform a thorough multi-dimensional code review grounded in ARCS DAG context, AGENTS.md conventions, and optional codegraph coupling analysis, then post findings as inline GitHub review comments under explicit user gate
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Use when initializing a new ARCS project — bootstrapping a repo into the DAG with metadata, docs, and structural knowledge entries. Covers gather → present summary → init → codegraph ingestion → fan-out analysis across typed sub-agents.
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Use when you have a spec or requirements for a multi-step task, before touching code
Use when capturing a knowledge entry, before writing its body — to author a substantive per-kind body, not a summary-only stub
| name | test-driven-development |
| description | Use when implementing any feature or bugfix, before writing implementation code |
Implementing any feature, bugfix, or behavior change. No production code without a failing test first.
Note: This skill is loaded DIRECTLY by the orchestrator when test-first is a hard requirement (the decision tree's "test-first valuable" trigger). It is also available as a sub-flow within
code-agent, which invokes TDD when new non-trivial behavior needs test-first implementation.
flowchart TD
A[Write ONE failing test] --> B{Run test}
B -->|Fails correctly| C[Write minimal code to pass]
B -->|Wrong failure| A
B -->|Passes immediately| D[Test is wrong — fix or delete]
D --> A
C --> E{Run test}
E -->|Your tests pass| F[Refactor — keep green]
E -->|Fails| C
F --> G{More behavior needed?}
G -->|Yes| A
G -->|No| H[Done — your test files green, scoped VERIFY passes]
Code written before a test? Delete it. No "reference", no "adapting". Start fresh from tests.
npm test -- path/to/test.test.ts — confirm fails for the right reasonnpm test -- path/to/test.test.ts) — confirm they pass, output pristine. Never the unscoped suite; the devil-advocate completion gate owns full-project verification.| Excuse | Reality |
|---|---|
| "Too simple to test" | Simple code breaks. Test takes 30 seconds. |
| "I'll test after" | Tests passing immediately prove nothing. |
| "Need to explore first" | Fine. Throw away exploration, then TDD. |
| "Test hard = design unclear" | Hard to test = hard to use. Listen to the test. |
| "TDD will slow me down" | TDD faster than debugging. |
| Problem | Solution |
|---|---|
| Don't know how to test | Write wished-for API. Assertion first. |
| Test too complicated | Design too complicated. Simplify interface. |
| Must mock everything | Code too coupled. Use dependency injection. |
Code before test, test passes immediately, can't explain why test failed, rationalizing "just this once".
See tdd-rationalizations-and-examples.md for expanded examples and rebuttals.