메뉴
Internal TDD implementer fork — invoked exclusively by /dev-process-toolkit:tdd via context:fork pairing with the tdd-implementer subagent, once per AC. Implements the minimum code to turn one AC's failing test GREEN. Do not invoke directly.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Implement a feature or fix end-to-end. Analyzes the request, builds in TDD order, runs gate checks, self-reviews with bounded loops, and reports for human approval before committing.
Bundle the Release Checklist + /docs --commit --full into one atomic, human-approved release commit. Reads specs/plan/M<N>.md, bumps the four release files, regenerates docs, prompts once for approval, commits on `y`, does not push.
Guide the user through writing or completing spec files (requirements, technical spec, testing spec, plan). Use after /setup to fill in specs before implementation, or to update existing specs.
Set up SDD/TDD development process for the current project. Creates CLAUDE.md, configures settings, and optionally creates spec files. Use when starting a new project or adding process to an existing one.
Socratic design session for greenfield features with open solution spaces. Clarifies goals one question at a time, proposes 2-3 approaches with tradeoffs, gets design approval, then feeds into /spec-write.
Run the project gate checks and report results. Use after completing any feature, before creating a PR, or to verify project health.
| name | tdd-implement |
| description | Internal TDD implementer fork — invoked exclusively by /dev-process-toolkit:tdd via context:fork pairing with the tdd-implementer subagent, once per AC. Implements the minimum code to turn one AC's failing test GREEN. Do not invoke directly. |
| context | fork |
| agent | tdd-implementer |
| user-invocable | false |
| argument-hint | <AC-id> + failing-test command |
You are running as the tdd-implementer subagent inside a forked context spawned by /dev-process-toolkit:tdd. The orchestrator runs you once per AC. You see only this AC's text and the failing-test command — not the full AC list, not the test-writer's reasoning, not other ACs' implementations.
The orchestrator passes you (in its prompt body):
```tdd-result block as the last thing in your turn.role: implementer
status: ok
files:
- src/foo.ts
command: bun test tests/foo.test.ts
output_excerpt: |
PASS tests/foo.test.ts
1 of 1 passing
notes: optional one-liner
Required fields: role, status, files, command, output_excerpt. notes is optional.
status: ok — test is GREEN.status: failed — could not reach GREEN within maxTurns: 8. Orchestrator counts this as mode B (or mode E on hard maxTurns exhaustion) and decides retry-vs-halt per the bounded-retry budget.status: failed and explain in notes — the orchestrator surfaces that to the operator.