メニュー
devbooks-proposal-author：撰写变更提案 proposal.md（Why/What/Impact + Debate Packet），作为后续 Design/Spec/Plan 的入口。对设计性决策会呈现选项给用户选择。用户说"写提案/proposal/为什么要改/影响范围/坏味道重构提案"等时使用。
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-proposal-author |
| description | devbooks-proposal-author：撰写变更提案 proposal.md（Why/What/Impact + Debate Packet），作为后续 Design/Spec/Plan 的入口。对设计性决策会呈现选项给用户选择。用户说"写提案/proposal/为什么要改/影响范围/坏味道重构提案"等时使用。 |
| recommended_experts | ["Product Manager","System Architect"] |
| allowed-tools | ["Glob","Grep","Read","Write","Edit"] |
目标：明确本 Skill 的核心产出与使用范围。 输入：用户目标、现有文档、变更包上下文或项目路径。 输出：可执行产物、下一步指引或记录路径。 边界：不替代其他角色职责，不触碰 tests/。 证据：引用产出物路径或执行记录。
适用：需要细化策略、边界或风险提示时补充。
适用：需要与外部系统或可选工具协同时补充。
<truth-root>：当前真理目录根<change-root>：变更包目录根执行前必须按以下顺序查找配置（找到后停止）：
.devbooks/config.yaml（如存在）→ 解析并使用其中的映射dev-playbooks/project.md（如存在）→ Dev-Playbooks 协议，使用默认映射project.md（如存在）→ template 协议，使用默认映射关键约束：
agents_doc（规则文档），必须先阅读该文档再执行任何操作变更包 ID（change-id）必须遵循以下命名规范：
<日期时间>-<动词开头的语义描述>
| 组成部分 | 规则 | 示例 |
|---|---|---|
| 日期时间 | YYYYMMDD-HHMM 格式 | 20240116-1030 |
| 分隔符 | 日期时间与语义之间用 - 分隔 | - |
| 语义描述 | 必须以动词开头，使用小写和连字符 | add-oauth2, fix-login-bug |
# ✅ 正确
20240116-1030-add-oauth2-support
20240116-1430-fix-user-auth-bug
20240116-0900-refactor-payment-module
20240115-2200-update-api-docs
# ❌ 错误
add-oauth2 # 缺少日期时间
20240116-oauth2 # 语义不是动词开头
2024-01-16-add-oauth2 # 日期格式错误（不应有 -）
oauth2-20240116 # 顺序错误
| 动词 | 用途 |
|---|---|
add | 添加新功能 |
fix | 修复缺陷 |
update | 更新现有功能 |
refactor | 重构代码 |
remove | 删除功能 |
improve | 提升性能/体验 |
migrate | 迁移数据/系统 |
在确定 change-id 后，调用脚手架脚本初始化变更包：
change-scaffold.sh <change-id> --project-root <repo-root> --change-root <change-root> --truth-root <truth-root>
<change-root>/<change-id>/proposal.md~/.claude/skills/_shared/references/AI行为规范.md（可验证性 + 结构质量守门）。references/提案撰写提示词.md。本 Skill 在执行前自动检测上下文，选择合适的运行模式。
检测规则参考：skills/_shared/上下文检测模板.md
proposal.md 是否已存在| 模式 | 触发条件 | 行为 |
|---|---|---|
| 新建提案 | 变更包不存在或 proposal.md 不存在 | 创建完整提案文档 |
| 修订提案 | proposal.md 存在，Judge 要求 Revise | 根据裁决意见修改提案 |
| 补充 Impact | proposal.md 存在但缺少 Impact 章节 | 补充影响分析部分 |
检测结果：
- 变更包状态：存在
- proposal.md：存在
- 裁决状态：Revise（需要修改）
- 运行模式：修订提案
参考：skills/_shared/工作流下一步.md
完成 proposal-author 后，下一步取决于具体情况：
| 条件 | 下一个 Skill | 原因 |
|---|---|---|
| 跨模块影响不明确 | devbooks-impact-analysis | 先明确影响范围 |
| 高风险/有争议 | devbooks-proposal-challenger | 先质疑再继续 |
| 影响明确，准备设计 | devbooks-design-doc | 创建设计文档 |
关键：绝不在 proposal-author 后直接推荐 devbooks-test-owner 或 devbooks-coder。工作流顺序是：
proposal-author → [impact-analysis] → design-doc → [spec-contract] → implementation-plan → test-owner → coder
完成 proposal-author 后，输出：
## 推荐的下一步
**下一步：`devbooks-design-doc`**（最常见）
或
**下一步：`devbooks-impact-analysis`**（如果跨模块影响不明确）
或
**下一步：`devbooks-proposal-challenger`**（如果高风险，可选）
原因：提案已完成。下一步是[明确影响 / 创建设计文档]。
### 如何调用
运行 devbooks- skill 处理变更
在完成提案草案后，执行 Challenger 审视，重点检查遗漏的约束与不确定性，并参考完备性方法论。