メニュー
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 職業分類に基づく
| 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.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.