菜单
devbooks-implementation-plan：从设计文档推导编码计划（tasks.md），输出可跟踪的主线计划/临时计划/断点区，并绑定验收锚点。用户说"写编码计划/Implementation Plan/tasks.md/任务拆解/并行拆分/里程碑/验收锚点"等时使用。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
devbooks-brownfield-bootstrap：存量项目初始化：在当前真理目录为空时生成项目画像、术语表、SSOT、基线规格与最小验证锚点，避免"边补 specs 边改行为"。用户说"存量初始化/基线 specs/项目画像/建立 glossary/初始化 SSOT/把老项目接入上下文协议"等时使用。
devbooks-delivery-workflow：完整闭环编排器，在支持子 Agent 的 AI 编程工具中调用，自动编排 Proposal→Design→Spec→Plan→Test→Implement→Review→Archive 全流程。用户说"跑一遍闭环/完整交付/从头到尾跑完/自动化变更流程"等时使用。
devbooks-ssot-maintainer：维护项目 SSOT 的"可寻址索引与派生进度视图"。用于"修改/同步 SSOT（上游或项目内）→ 生成可审计 delta → 同步 requirements.index.yaml →（可选）刷新 requirements.ledger.yaml"。通常由 `/devbooks:delivery` 在 `request_kind=governance` 路由下调用。注意：SSOT 初始化请使用 `brownfield-bootstrap`。
devbooks-knife：把 Epic 级需求切成可拓扑排序的 Slice 队列，并落盘机读 Knife Plan（用于高风险/史诗级变更的 G3 强制闸门）。
devbooks-archiver：归档阶段的唯一入口，负责完整的归档闭环（自动回写→规格合并→文档同步检查→变更包归档移动）。用户说"归档/archive/收尾/闭环/合并到真理"等时使用。
devbooks-coder：以 Coder 角色严格按 tasks.md 实现功能并跑闸门，禁止修改 tests/，以测试/静态检查为唯一完成判据。用户说"按计划实现/修复测试失败/让闸门全绿/实现任务项/不改测试"，或在 DevBooks apply 阶段以 coder 执行时使用。
| name | devbooks-implementation-plan |
| description | devbooks-implementation-plan：从设计文档推导编码计划（tasks.md），输出可跟踪的主线计划/临时计划/断点区，并绑定验收锚点。用户说"写编码计划/Implementation Plan/tasks.md/任务拆解/并行拆分/里程碑/验收锚点"等时使用。 |
| recommended_experts | ["System Architect","Product Manager"] |
| allowed-tools | ["Glob","Grep","Read","Write","Edit"] |
目标：明确本 Skill 的核心产出与使用范围。 输入：用户目标、现有文档、变更包上下文或项目路径。 输出：可执行产物、下一步指引或记录路径。 边界：不替代其他角色职责，不触碰 tests/。 证据：引用产出物路径或执行记录。
适用：需要细化策略、边界或风险提示时补充。
适用：需要与外部系统或可选工具协同时补充。
核心原则：Implementation Plan 在 Design Doc 之后执行，为 Test Owner 和 Coder 提供任务清单。
proposal → design → [Implementation Plan] → test-owner(阶段1) → coder → ...
↓
tasks.md（任务清单）
| 允许 | 禁止 |
|---|---|
| 从 design.md 推导任务 | ❌ 参考 tests/（避免实现偏见） |
| 绑定验收锚点 (AC-xxx) | ❌ 写实现代码 |
| 拆分并行任务 | ❌ 执行任务 |
## 主线计划区
- [ ] MP1.1 任务描述 (AC-001)
- [ ] MP1.2 任务描述 (AC-002)
## 临时计划区
（紧急任务）
## 断点区
（中断续做信息）
<truth-root>：当前真理目录根<change-root>：变更包目录根执行前必须按以下顺序查找配置（找到后停止）：
.devbooks/config.yaml（如存在）→ 解析并使用其中的映射dev-playbooks/project.md（如存在）→ Dev-Playbooks 协议，使用默认映射project.md（如存在）→ template 协议，使用默认映射关键约束：
agents_doc（规则文档），必须先阅读该文档再执行任何操作<change-root>/<change-id>/tasks.md~/.claude/skills/_shared/references/AI行为规范.md（可验证性 + 结构质量守门）。references/编码计划提示词.md（只从设计推导，不参考 tests/）。本 Skill 在执行前自动检测上下文，选择合适的运行模式。
检测规则参考：skills/_shared/上下文检测模板.md
design.md 是否存在（计划的输入）tasks.md 是否已存在| 模式 | 触发条件 | 行为 |
|---|---|---|
| 新建计划 | tasks.md 不存在 | 从 design.md 推导完整计划 |
| 更新计划 | tasks.md 存在，design.md 有更新 | 同步计划与设计变更 |
| 添加临时任务 | 发现计划外紧急任务 | 添加到临时计划区 |
检测结果：
- design.md：存在，AC 数量 14 个
- tasks.md：不存在
- 运行模式：新建计划
参考：skills/_shared/工作流下一步.md
完成 implementation-plan 后，必须的下一步是：
| 条件 | 下一个 Skill | 原因 |
|---|---|---|
| 始终 | devbooks-test-owner | Test Owner 必须先产出 Red 基线 |
关键：
devbooks-coderimplementation-plan → test-owner (会话A) → coder (会话B)
完成 implementation-plan 后，输出：
## 推荐的下一步
**下一步：`devbooks-test-owner`**（必须在单独的会话中）
原因：实现计划已完成。下一步是让 Test Owner 创建验证测试并产出 Red 基线。Test Owner 和 Coder 必须在不同会话中工作以确保角色隔离。
### 如何调用（在新会话中）
运行 devbooks-test-owner skill 处理变更
**重要**：Test Owner 产出 Red 基线后，在另一个单独的会话中启动 Coder：
运行 devbooks-coder skill 处理变更