La interfaz está localizada; las descripciones y documentos de las Skills se traducen automáticamente con IA a su idioma. El código, los comandos, rutas y términos técnicos se mantienen en el original, y prevalece el documento del autor.
Explorar Skills
Desarrollo · SKILL.md

specialist-tdd-implementer

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.

Independent GitHub snapshot · Automated classification · Original documentation governs

Documentación de la Skill

GitHub

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. risk_tier: L2 metadata: internal: true 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

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