メニュー
在 Trellis 子任务进入实现阶段时，用严格 TDD（红→绿→重构）逐条把验收标准落成代码。用于 Codex / Claude Code 等在 trellis-zero-to-mvp-zh 或 trellis-mvp-to-delivery-zh 生成主子任务后，按依赖顺序实现某个子任务，尤其当执行模型是 qwen3.6 35b 这类小参数本地模型时——把"理解并实现需求"转成"让这条失败测试变绿"的机械循环，每步都有客观信号。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Create a Trellis MVP task tree from a full requirements document. Use when Codex receives a product brief, requirements document, PRD, zero-to-MVP request, large capability-building request, or partially implemented project and must do read-only analysis, assign stable REQ/AC IDs, build full requirement and MVP coverage matrices, lock project contracts, identify existing implementation evidence, use progressive batch and sub-agent planning to form a complete MVP parent/child task tree, draft PRD/design/implementation artifacts, and create Trellis tasks only after user confirmation; do not write application code.
从完整需求文档创建 Trellis MVP 任务树。用于 Codex 收到产品说明、需求文档、PRD、从 0 到 MVP 的新项目需求、大型能力建设请求，或已经手工实现了一部分功能的项目时，先做只读分析，分配稳定 REQ/AC 编号，生成需求追踪矩阵和项目契约，识别已有实现证据，通过渐进式批次规划和子代理协作形成完整 MVP 父子任务树、PRD、设计/实现产物计划，并在用户确认后创建 Trellis 任务；不编写应用代码。
Audit an existing MVP against a source requirements document and run a sustainable Trellis delivery loop. Use when Codex is asked to continue after an MVP, complete remaining requirements, perform a first full gap audit, maintain a Requirements Traceability Matrix, classify DONE/PARTIAL/MISSING/UNTESTED/UNCLEAR items, initialize or update .trellis/delivery-state.md, choose full/delta/early-exit audit scope, plan bounded gap-closing batches, require worktree + verifier gates, design automated test coverage, classify discovered bugs, or run final acceptance before delivery.
根据源需求文档审计已有 MVP，并执行 Trellis 完整交付 loop 的审计、状态维护、批次规划和最终验收。用于 Codex 被要求在 MVP 后继续、补齐剩余需求、执行 full/delta 差距审计、维护 Requirements Traceability Matrix、分类 DONE/PARTIAL/MISSING/UNTESTED/UNCLEAR 条目、初始化或更新 .trellis/delivery-state.md、规划有边界的补缺批次、要求 worktree + verifier 门、设计自动化测试覆盖、分类发现的 bug，或在交付前执行最终验收的场景。若由 trellis-delivery-controller-zh 调用，则遵循控制器已选定的 loop 模式和审计范围；若单独调用，则按本技能的 delivery-loop-policy 自行判定。
Trellis requirements-to-delivery entrypoint and workflow controller. Use when the user wants to invoke one Trellis skill that detects the current stage and routes work across requirements analysis, MVP task planning, post-MVP gap audit, delivery loop, TDD implementation, systematic debugging, two-stage review, and final acceptance. Coordinates trellis-zero-to-mvp, trellis-mvp-to-delivery, trellis-implement-tdd, trellis-debug-systematic, and trellis-review-twostage while enforcing safety gates.
Trellis 需求交付总入口和流程控制器。用于用户希望只调用一个 Trellis skill 自动判断当前阶段，并在需求分析、MVP 任务规划、MVP 后差距审计、交付 loop、TDD 实现、系统调试、双阶段评审和最终验收之间进行路由、推进和安全门控制的场景。适合基于 trellis-zero-to-mvp-zh、trellis-mvp-to-delivery-zh、trellis-implement-tdd-zh、trellis-debug-systematic-zh 和 trellis-review-twostage-zh 形成端到端交付闭环。
| name | trellis-implement-tdd-zh |
| description | 在 Trellis 子任务进入实现阶段时，用严格 TDD（红→绿→重构）逐条把验收标准落成代码。用于 Codex / Claude Code 等在 trellis-zero-to-mvp-zh 或 trellis-mvp-to-delivery-zh 生成主子任务后，按依赖顺序实现某个子任务，尤其当执行模型是 qwen3.6 35b 这类小参数本地模型时——把"理解并实现需求"转成"让这条失败测试变绿"的机械循环，每步都有客观信号。 |
把一个已规划好的 Trellis 子任务，按其 prd.md 的验收标准（AC）逐条用 TDD 实现：先写失败测试看到红，再写最小代码看到绿，跑自检确认没弄坏别的，执行最小实现收敛，记录进度，进入下一条 AC。
本技能由编排会话（主会话，通常强模型）调用，去驱动实现执行体（可为 qwen3.6 35b 小模型）。流程由本技能"夹着走"，执行体只做有客观信号的机械步骤，不需要自己判断"做完没有"——测试变绿就是做完。
输入：一个 status 为进行中、依赖已满足的子任务目录（含 prd.md，可能含 design.md、implement.md、implement.jsonl、check.jsonl）。产出：通过测试的代码改动 + 回写到 <task-dir>/tdd-progress.md 的进度，不执行 git commit（Trellis 实现执行体禁止 commit/push/merge）。
prd.md 的验收标准、决策表、契约定死；执行体只负责让对应测试变绿。prd.md 文件清单 + design.md 的编排-计算分层决定；不要自行决定放哪个文件。git commit / git push / git merge。完成一条 AC 后只做暂存/记录。references/minimal-implementation-pass.md 删除不必要复杂度。trellis-debug-systematic-zh，不要在本循环里乱试。prd.md 缺少可执行的测试定义或自检命令（违反规划期质量门槛），停止并回报，要求先补规划产物，不要硬上。按顺序读取，只读"编辑前必须读"的稳定上下文，控制小模型上下文占用：
prd.md：重点读 验收标准、自动化测试要求、参考实现、文件清单、决策表、行为约束、自检命令、禁止事项。implement.jsonl：逐条预加载其中列出的稳定上下文（spec / 契约 / 调研）。design.md：读编排-计算分离与挂载点清单两节，确认每个新代码的落点。.trellis/spec/<相关层>：读与本任务直接相关的规范。开始编辑前，先把 references/tdd-progress-template.md 复制为 <task-dir>/tdd-progress.md。这个任务目录下的文件才是可写进度记录；skill 目录里的模板保持只读。
把 prd.md 的每条 AC-xxx 抽成一个待办测试清单，写入 <task-dir>/tdd-progress.md。
按 AC 顺序，对每一条执行 references/tdd-loop-protocol.md 的循环：
1. RED ── 照抄 prd.md「参考实现/测试范例」，为 AC-xxx 写一个测试，断言其期望可观察结果
2. 看红 ── 运行该测试，必须看到失败（客观证据）。没失败 → 测试没覆盖到行为，回到第1步修测试
3. GREEN ── 写"刚好让它变绿"的最小代码；落点按文件清单+编排分层，决策按决策表，不自由发挥
4. 看绿 ── 再次运行该测试，看到通过（客观信号）
5. 自检 ── 运行 prd.md「自检命令」全集，确认没弄坏已绿的 AC（无回归）
6. 收敛 ── 若本 AC 引入抽象/依赖/新文件/重复代码，按 `references/minimal-implementation-pass.md` 删除不必要复杂度
7. 记录 ── 在 `<task-dir>/tdd-progress.md` 里把 AC-xxx 标记为 done，暂存改动（不 commit）
8. 下一条 AC
任一步失败且不显然时 → 触发 trellis-debug-systematic-zh，修复后回到失败的那一步重跑。
所有 AC 变绿后：
prd.md 全部自检命令 + 项目 lint / type-check，全绿。references/minimal-implementation-pass.md，执行完整最小实现收敛：删除无用抽象、避免新依赖、优先标准库/平台/已有依赖，保留安全和验证。design.md 的挂载点清单逐项确认已接线（路由注册 / 配置项 / 事件订阅 / DI 绑定等），防止"写了实现没接线"。<task-dir>/tdd-progress.md 所有 AC 为 done，无遗留红灯，并记录最小实现收敛结果。实现自检全绿后，不要自行标记任务完成。交给 trellis-review-twostage-zh 做双阶段评审；评审通过后再由编排会话推进任务状态。
trellis-review-twostage-zh）。references/tdd-loop-protocol.md —— 每条 AC 的红绿循环详规、铁律与反模式，开始实现前读取。references/minimal-implementation-pass.md —— 绿灯后删除不必要复杂度、复用标准库/平台/已有依赖、保留安全验证边界时读取。references/tdd-progress-template.md —— <task-dir>/tdd-progress.md 的只读模板；全程更新任务目录下的副本。