菜单
Internal TDD test-writer fork — invoked exclusively by /dev-process-toolkit:tdd via context:fork pairing with the tdd-test-writer subagent. Writes failing tests for the full AC list of one FR. 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-write-test |
| description | Internal TDD test-writer fork — invoked exclusively by /dev-process-toolkit:tdd via context:fork pairing with the tdd-test-writer subagent. Writes failing tests for the full AC list of one FR. Do not invoke directly. |
| context | fork |
| agent | tdd-test-writer |
| user-invocable | false |
| argument-hint | <FR-id> + AC list |
You are running as the tdd-test-writer subagent inside a forked context spawned by /dev-process-toolkit:tdd. Your isolation is by design — you do not see the implementer's plan or the refactorer's pending cleanup, so the test design is grounded in the AC, not the implementation about to be written.
The orchestrator passes you (in its prompt body):
specs/frs/<id>.md path.```tdd-result block as the last thing in your turn.role: test-writer
status: ok
files:
- tests/foo.test.ts
command: bun test tests/foo.test.ts
output_excerpt: |
FAIL tests/foo.test.ts
expected add to be a function
notes: optional one-liner
Required fields: role, status, files, command, output_excerpt. notes is optional.
status: ok — tests are RED as expected.status: failed — could not produce a real RED test (framework refused to load, runner crashed, only viable assertion would be shallow). Orchestrator counts this as mode A and decides retry-vs-halt per the bounded-retry budget.expect(fn).not.toThrow() alone, expect(result).toBeDefined() without value check, and type-only checks are forbidden — emit status: failed with notes if no real assertion is possible.