一键导入
devbooks-design-doc
devbooks-design-doc:产出变更包的设计文档(design.md),只写 What/Constraints 与 AC-xxx,不写实现步骤。用户说"写设计文档/Design Doc/架构设计/约束/验收标准/AC/C4 Delta"等时使用。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
devbooks-design-doc:产出变更包的设计文档(design.md),只写 What/Constraints 与 AC-xxx,不写实现步骤。用户说"写设计文档/Design Doc/架构设计/约束/验收标准/AC/C4 Delta"等时使用。
用 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-design-doc |
| description | devbooks-design-doc:产出变更包的设计文档(design.md),只写 What/Constraints 与 AC-xxx,不写实现步骤。用户说"写设计文档/Design Doc/架构设计/约束/验收标准/AC/C4 Delta"等时使用。 |
| recommended_experts | ["System Architect","Product Manager"] |
| allowed-tools | ["Glob","Grep","Read","Write","Edit"] |
目标:明确本 Skill 的核心产出与使用范围。 输入:用户目标、现有文档、变更包上下文或项目路径。 输出:可执行产物、下一步指引或记录路径。 边界:不替代其他角色职责,不触碰 tests/。 证据:引用产出物路径或执行记录。
适用:需要细化策略、边界或风险提示时补充。
适用:需要与外部系统或可选工具协同时补充。
核心原则:Design Doc 在 Proposal 批准后执行,是实现阶段的起点。
proposal → [Design Doc] → spec-contract → implementation-plan → test-owner → coder → ...
↓
定义 What/Constraints/AC
关键:Design Doc 不写实现步骤,那是 implementation-plan 的职责。
<truth-root>:当前真理目录根<change-root>:变更包目录根执行前必须按以下顺序查找配置(找到后停止):
.devbooks/config.yaml(如存在)→ 解析并使用其中的映射dev-playbooks/project.md(如存在)→ Dev-Playbooks 协议,使用默认映射project.md(如存在)→ template 协议,使用默认映射关键约束:
agents_doc(规则文档),必须先阅读该文档再执行任何操作<change-root>/<change-id>/design.md设计文档中必须包含「文档影响」章节,声明本次变更对用户文档的影响。这是确保文档与代码同步的关键机制。
## Documentation Impact(文档影响)
### 需要更新的文档
| 文档 | 更新原因 | 优先级 |
|------|----------|--------|
| README.md | 新增功能 X 需要说明使用方法 | P0 |
| docs/使用说明书.md | 新增脚本 Y 需要补充用法 | P0 |
| CHANGELOG.md | 记录本次变更 | P1 |
### 无需更新的文档
- [ ] 本次变更为内部重构,不影响用户可见功能
- [ ] 本次变更仅修复 bug,不引入新功能或改变使用方式
### 文档更新检查清单
- [ ] 新增脚本/命令已在使用文档中说明
- [ ] 新增配置项已在配置文档中说明
- [ ] 新增工作流/流程已在指南中说明
- [ ] API/接口变更已在相关文档中更新
以下变更类型强制要求更新对应文档:
| 变更类型 | 需更新文档 |
|---|---|
| 新增脚本(*.sh) | 使用说明、README |
| 新增 Skill | README、Skills 列表 |
| 修改工作流程 | 相关指南文档 |
| 新增配置项 | 配置文档 |
| 新增命令/CLI 参数 | 使用说明 |
| 对外 API 变更 | API 文档 |
设计文档中必须包含「架构影响」章节,声明本次变更对系统架构的影响。这是确保架构变更走验证闭环的关键机制。
设计决策:C4 架构变更不再由独立的
devbooks-c4-mapskill 直接写入真理目录,而是作为 design.md 的一部分,在变更验收通过后由devbooks-archiver合并到真理。
## Architecture Impact(架构影响)
<!-- 必填:选择以下之一 -->
### 无架构变更
- [x] 本次变更不影响模块边界、依赖方向或组件结构
- 原因说明:<简要说明为什么无架构影响>
### 有架构变更
#### C4 层级影响
| 层级 | 变更类型 | 影响描述 |
|------|----------|----------|
| Context | 无变更 / 新增 / 修改 / 删除 | <描述> |
| Container | 无变更 / 新增 / 修改 / 删除 | <描述> |
| Component | 无变更 / 新增 / 修改 / 删除 | <描述> |
#### Container 变更详情
- [新增/修改/删除] `<container-name>`: <变更描述>
#### Component 变更详情
- [新增/修改/删除] `<component-name>` in `<container>`: <变更描述>
#### 依赖变更
| 源 | 目标 | 变更类型 | 说明 |
|----|------|----------|------|
| `<source>` | `<target>` | 新增/删除/方向改变 | <说明> |
#### 分层约束影响
- [ ] 本次变更遵守现有分层约束
- [ ] 本次变更需要修改分层约束(需在下方说明)
分层约束修改说明:<如有>
执行 design-doc skill 时,必须检测以下条件判断是否有架构变更:
| 检测项 | 检测方法 | 有架构变更 |
|---|---|---|
| 新增/删除目录 | 检查变更文件路径 | 可能影响模块边界 |
| 跨模块 import | 检查 import 语句变化 | 可能影响依赖方向 |
| 新外部依赖 | 检查 package.json/go.mod 等 | 影响 Container 层 |
| 新服务/进程 | 检查 Dockerfile/docker-compose | 影响 Container 层 |
| 新 API 端点组 | 检查路由定义 | 可能影响 Component 层 |
以下变更类型强制要求填写架构变更详情:
| 变更类型 | 要求 |
|---|---|
| 新增模块/目录 | 必须描述 Component 变更 |
| 新增服务/容器 | 必须描述 Container 变更 |
| 修改模块间依赖 | 必须描述依赖变更 |
| 引入新外部系统 | 必须描述 Context 变更 |
~/.claude/skills/_shared/references/AI行为规范.md(可验证性 + 结构质量守门)。references/设计文档提示词.md。本 Skill 在执行前自动检测上下文,选择合适的运行模式。
检测规则参考:skills/_shared/上下文检测模板.md
proposal.md 是否存在(设计文档的输入)design.md 是否已存在[TODO])| 模式 | 触发条件 | 行为 |
|---|---|---|
| 新建设计 | design.md 不存在 | 创建完整设计文档 |
| 补充设计 | design.md 存在但有 [TODO] | 补充缺失章节 |
| 添加 AC | 设计存在但 AC 不完整 | 补充验收标准 |
检测结果:
- proposal.md:存在
- design.md:存在,有 5 个 [TODO]
- AC 数量:8 个
- 运行模式:补充设计
参考:skills/_shared/工作流下一步.md
完成 design-doc 后,下一步取决于变更范围:
| 条件 | 下一个 Skill | 原因 |
|---|---|---|
| 有外部行为/契约变更 | devbooks-spec-contract | 必须先定义契约再做计划 |
| 无外部契约变更 | devbooks-implementation-plan | 直接进入任务计划 |
关键:绝不在 design-doc 后直接推荐 devbooks-test-owner 或 devbooks-coder。工作流顺序是:
design-doc → [spec-contract] → implementation-plan → test-owner → coder
完成 design-doc 后,输出:
## 推荐的下一步
**下一步:`devbooks-spec-contract`**(如果有外部行为/契约变更)
或
**下一步:`devbooks-implementation-plan`**(如果无外部契约变更)
原因:设计已完成。下一步是[定义外部契约 / 创建实现计划]。
### 如何调用
运行 devbooks- skill 处理变更