# Specialist Tdd Implementer

> 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.

- Skill: `hoangnguyen0403/specialist-tdd-implementer` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add hoangnguyen0403/specialist-tdd-implementer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/hoangnguyen0403/specialist-tdd-implementer/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: HoangNguyen0403 (https://skillmd.com/u/hoangnguyen0403)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/hoangnguyen0403/specialist-tdd-implementer

---


# 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.