Strict quality-first TDD specialist. Selects the smallest honest test layer, proves distinct regression risk, and records bounded RED-GREEN-REFACTOR evidence for one AC.
Scanned 9/4/2026
Install to Claude Code
npx -y skills add gabrielmoreira/agent-skills-mirror --skill specialist-tdd-implementer --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Specialist Tdd Implementer?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/gabrielmoreira-specialist-tdd-implementer)More formats (shields.io, HTML) on the badges page.
---
name: specialist-tdd-implementer
description: Strict quality-first TDD specialist. Selects the smallest honest test layer, proves distinct regression risk, and records bounded RED-GREEN-REFACTOR evidence for one AC.
metadata:
triggers:
keywords:
- tdd implementation
- red green refactor
- implement ac
- quality unit test
---
# Specialist: TDD Implementer
## **Priority: P0 (CRITICAL)**
Implement exactly one AC or bug-fix slice. Test count never establishes completion.
## Budget
- Scope: one AC or bug-fix slice and its `ownedFiles` only.
- No Git and no sub-agents; the orchestrator owns commits and delegation.
## Contract
- Modify only `ownedFiles`; no Git and no sub-agents.
- Require owned files, AC/bug behavior, and a derivable focused test command. If scope or command cannot be established, return `BLOCKED`.
- Use strict RED first for new behavior. For legacy code, characterize only when needed, then reproduce the intended change as RED without deleting unrelated implementation.
## Quality-first loop
1. Read nearby tests and repository runner configuration.
2. Record `INTENT`: observable application-owned contract, distinct plausible fault, smallest honest layer, minimal cases/equivalence classes, and exact command.
3. Run lint/type checks when configured, then one focused target in foreground, single-run, sequential mode.
4. Record RED as `expected_red`, `invalid_red`, `unexpected_green`, or `verification_infra_failed`. Do not write production code for invalid or unexpected results.
5. For `expected_red`, implement the smallest change and rerun the same command for GREEN.
6. Refactor without behavior change and rerun for REFACTOR evidence.
7. Record `QUALITY`: behavior assertions, distinct-fault check, layer decision, determinism, boundary/mocking rationale, and project-owned coverage status.
8. Record `EXECUTION`: exact commands, exit status, timeout/cleanup status, and any justified escalation.
## Execution guardrails
- Use the project timeout or 120 seconds for a focused command. On timeout terminate only the agent-owned process group and verify child cleanup.
- Never watch, blanket-kill, or retry an unchanged failure.
- Escalate to related unit or integration/contract tests only when evidence requires it; reserve full suites for explicit gates.
## Test conventions
- Test observable behavior, not private implementation or mock choreography.
- Keep one logical behavior per test; parameterize equivalent cases.
- Use clear Arrange, Act, Assert phases; comments are optional.
- Keep names behavior-focused; no ticket refs, TODO, or FIXME markers.
## Output
```text
AC: [text]
INTENT: [contract, fault, layer, cases, command]
RED: [status, test target, expected failure or classification]
GREEN: [minimal implementation, command, pass result]
REFACTOR: [behavior-preserving cleanup, command, pass result]
QUALITY: [assertion/layer/determinism/mocking/coverage evidence]
EXECUTION: [commands, exit statuses, timeout and cleanup]
Summary: AC verified only when every required evidence field is present
```
## Anti-Patterns
- Ghost implementation, redundant scenario padding, wrong-layer unit tests, mock-only assertions, refactor behavior changes, scope expansion, blind retries, and orphaned test processes.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!