// Use when completing a TDD step and wanting a quality check. Reviews test quality after RED, implementation correctness after GREEN, and scenario completeness after REFACTOR.
Deep code review with web research. Use when double-checking code against latest docs, verifying dependency versions, or reviewing security concerns. Complements automatic quality hook with ecosystem verification.
Run comprehensive code audit for architecture, dead code, and test quality. Use when reviewing overall codebase health, checking for architectural violations, or before marking a feature complete.
Safeword semver commitment and release discipline. Use when bumping versions, cutting releases, deciding what goes in a patch vs minor vs major, or reviewing changelog entries. Also use when auto-upgrade logic needs to know what's safe to apply silently.
Behavior-first feature development — use when building new capabilities, continuing feature work, or when work introduces new state or multiple user flows. Discovers desired behavior through examples and scenarios before implementation. Do NOT use for bug fixes, typos, or small isolated changes.
Root cause debugging before fixes. Use when investigating bugs, diagnosing test failures, troubleshooting unexpected behavior, or when previous fix attempts failed. Enforces investigate-first discipline.
Explore and debate options with fresh documentation and research before committing. Use when facing a real decision with multiple plausible approaches — library/framework choice, architecture call, API or schema design, algorithm selection, or any communication / strategy call where being wrong has cost. Enumerates relevant research domains, looks up current docs and evidence-based methods, weighs options on correctness and elegance, resists bloat. Do NOT use for divergent ideation (brainstorm), extracting user intent (elicit), or reviewing already-written code (quality-review).
| name | tdd-review |
| description | Use when completing a TDD step and wanting a quality check. Reviews test quality after RED, implementation correctness after GREEN, and scenario completeness after REFACTOR. |
| allowed-tools | * |
Step-aware quality review at TDD phase boundaries. Fires when a sub-checkbox is marked in test-definitions.md during implement phase.
Read the gate message to determine which TDD step is next:
| Gate triggered | Step just completed | Review focus |
|---|---|---|
tdd:green | RED (test written) | Review test quality |
tdd:refactor | GREEN (implementation passes) | Review implementation |
tdd:red | REFACTOR (cleanup done) | Review completed scenario |
Focused review (~1 minute). Check the test that was just written:
.toBeTruthy() or .not.toThrow().If issues found: fix before implementing. If clean: commit and proceed to implementation.
Moderate review (~1-2 minutes). Check the implementation:
If issues found: fix before refactoring. If clean: run /refactor, commit, proceed.
Full review (~2-3 minutes). The entire scenario is done. Review the complete unit:
If issues found: address before starting next scenario. If clean: commit and proceed to next [ ] RED.
Context: Agent just wrote a failing test for scenario 2 (verbose shows passing files). The tdd:green gate fires.
Agent review:
Atomic? Yes — tests one behavior (passing files appear in verbose output). Right assertions?
expect(output).toContain('src/index.ts: pass')— asserts on observable output, not internals. Good. Behavior, not implementation? Yes — checks CLI output string, not internal formatter state. Fails for the right reason?Expected string to contain 'src/index.ts: pass'— verbose output doesn't include passing files yet. Correct failure. Right test type? Integration — needs real linter execution to produce output. Unit wouldn't cover the formatter→CLI pipeline. Correct scope. Coverage gaps? Test only checks one file. Could miss edge case where zero files pass. Acceptable for now — boundary cases are in scenario 3.Clean.
Next: implement minimum code in
packages/cli/src/lint.tsto makeexpect(output).toContain('src/index.ts: pass')pass, then commit.
Every review ends with a Next: line on its own line — imperative, name the file/command/scenario. Don't end with "proceed" or "commit and move on" alone; name what to do.
**Next:** implement minimum code in {file} to make this test pass.**Next:** rewrite assertion in {file}:{line} to check observable output, then re-review.**Next:** run /refactor on {file}, then commit and mark next [ ] RED.**Next:** commit, then start scenario {N} — write the failing test in {file}.A review without a Next: line is incomplete.
[x] is marked in test-definitions.mdVoice: plainspoken and concise — write to be scanned.