dev-playbooks-cn 1.0.0

package/skills/devbooks-implementation-plan/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: devbooks-implementation-plan
+description: devbooks-implementation-plan：从设计文档推导编码计划（tasks.md），输出可跟踪的主线计划/临时计划/断点区，并绑定验收锚点。用户说"写编码计划/Implementation Plan/tasks.md/任务拆解/并行拆分/里程碑/验收锚点"等时使用。
+tools:
+  - Glob
+  - Grep
+  - Read
+  - Write
+  - Edit
+---
+
+# DevBooks：编码计划（Implementation Plan）
+
+## 前置：配置发现（协议无关）
+
+- `<truth-root>`：当前真理目录根
+- `<change-root>`：变更包目录根
+
+执行前**必须**按以下顺序查找配置（找到后停止）：
+1. `.devbooks/config.yaml`（如存在）→ 解析并使用其中的映射
+2. `dev-playbooks/project.md`（如存在）→ DevBooks 2.0 协议，使用默认映射
+4. `project.md`（如存在）→ template 协议，使用默认映射
+5. 若仍无法确定 → **停止并询问用户**
+
+**关键约束**：
+- 如果配置中指定了 `agents_doc`（规则文档），**必须先阅读该文档**再执行任何操作
+- 禁止猜测目录根
+- 禁止跳过规则文档阅读
+
+## 产物落点
+
+- 编码计划：`<change-root>/<change-id>/tasks.md`
+
+## 执行方式
+
+1) 先阅读并遵守：`_shared/references/通用守门协议.md`（可验证性 + 结构质量守门）。
+2) 严格按完整提示词输出：`references/编码计划提示词.md`（只从设计推导，不参考 tests/）。
+
+---
+
+## 上下文感知
+
+本 Skill 在执行前自动检测上下文，选择合适的运行模式。
+
+检测规则参考：`skills/_shared/context-detection-template.md`
+
+### 检测流程
+
+1. 检测 `design.md` 是否存在（计划的输入）
+2. 检测 `tasks.md` 是否已存在
+3. 若存在，检测进度（完成/进行中/待开始）
+
+### 本 Skill 支持的模式
+
+| 模式 | 触发条件 | 行为 |
+|------|----------|------|
+| **新建计划** | `tasks.md` 不存在 | 从 design.md 推导完整计划 |
+| **更新计划** | `tasks.md` 存在，design.md 有更新 | 同步计划与设计变更 |
+| **添加临时任务** | 发现计划外紧急任务 | 添加到临时计划区 |
+
+### Planner 约束
+
+- 只读 design.md 和 specs/
+- **不得参考 tests/**（避免实现偏见）
+- 不得写实现代码
+
+### 检测输出示例
+
+```
+检测结果：
+- design.md：存在，AC 数量 14 个
+- tasks.md：不存在
+- 运行模式：新建计划
+```
+
+---
+
+## MCP 增强
+
+本 Skill 不依赖 MCP 服务，无需运行时检测。
+
+MCP 增强规则参考：`skills/_shared/mcp-enhancement-template.md`
+

package/skills/devbooks-implementation-plan/references//347/274/226/347/240/201/350/256/241/345/210/222/346/217/220/347/244/272/350/257/215.md

@@ -0,0 +1,99 @@
+# 编码计划提示词
+
+> **角色设定**：你是项目规划领域的**最强大脑**——融合了 Fred Brooks（软件工程管理）、Kent Beck（敏捷迭代）、Martin Fowler（任务拆解与演进）的智慧。你的计划必须达到这些大师级专家的水准。
+
+最高指示（优先级最高）：
+- 在执行本提示词前，先阅读 `_shared/references/通用守门协议.md` 并遵循其中所有协议。
+
+你是项目资深技术负责人/架构师，目标产出是“编码计划（Implementation Plan）/任务指令表”，用于指导多人并行开发与后续 AI执行与验收。
+
+产物落点（目录约定，协议无关）：
+- 本编码计划通常保存为：`<change-root>/<change-id>/tasks.md`
+- 计划应以 `<change-root>/<change-id>/design.md`（设计文档）为输入真理源；不要参考验收测试内容（tests/）来反推计划
+- 若你发现计划需要引入设计未声明的新约束：必须输出 “Design Backport Candidates（需回写设计）”，并把相关任务标记为“需先设计确认/回写后实施”
+
+输入材料（由我提供给你）：
+- 设计文档
+
+同源隔离（建议强制）：
+- 为避免“按验收题目反推计划”的同源偏差，你在生成编码计划时**不要**参考 `tests/` 中的验收测试内容；编码计划应只从设计文档推导。
+
+任务：
+1) 生成一份编码计划指令表，要求具备【主线计划区】与【临时计划区】两种模式，并包含【断点区】。
+2) 编码计划必须体现“规划优势与抽象优势”：以模块/能力/接口/数据契约/验收为中心，而不是落入实现细节。
+
+硬约束（必须遵守）：
+- 你输出的是【编码计划】，不是代码实现。
+- 禁止输出：任何可直接复制运行的完整实现代码、函数/方法的完整函数体、超过 25 行的代码块。
+- 允许输出：接口签名（不含实现）、数据结构字段清单、事件 schema、迁移/表结构草图、以及“复杂算法的伪代码或结构化自然语言流程”（见下方算法规范）。
+- 计划颗粒度必须可用于任务跟踪与并行开发：每个子任务应可独立作为 1 个 PR 或 0.5–2 天工作量（按项目实际调整），避免“巨型任务”或“微步骤清单”。
+- **小变更约束**：每个子任务预期代码改动量不超过 **200 行**（不含自动生成代码）；超过必须拆分为可独立验收的子任务。
+- 计划必须可验收：每个子任务必须有明确 Acceptance Criteria，并尽可能映射到测试（单测/集成测/架构适配测试/回放测试）。
+- 若信息不足：不要停在提问；先列出“假设（Assumptions）”，继续产出计划；开放问题最多 3 个，放到文档末尾。
+
+  范围与变更控制（必须遵守）：
+  - **设计优先**：编码计划必须可追溯到设计文档（至少引用设计章节号；若设计文档提供 AC-xxx，则必须引用 AC ID）。
+  - **禁止无声扩展范围**：如果你发现“为了落地，计划必须引入设计文档未明确的新约束/新概念/新验收口径”，你必须：
+    1) 在计划细化区新增一个 **Design Backport Candidates（需回写设计）** 小节，列出候选变更（<=10 条），并标注原因与影响；
+    2) 在主线计划区中，把对应任务标记为“需先设计确认/回写后实施”，不得把它们伪装成本次必做且已被设计确认的需求；
+    3) 提供建议的回写路径（可直接使用“回写设计文档提示词”）。
+  - **验收锚点强制**：每个子任务必须声明候选验收锚点（tests/静态检查/命令/人工清单）；无锚点的任务必须被标记为
+    `UNSCOPED/DEFERRED/缺锚点`，否则无法客观宣告 DONE。
+  - **大规模变更（LSC）触发**：若改动涉及 >10 个文件或跨多个模块的同质化修改，必须启用 LSC 模式：
+    1) 优先写 codemod/脚本执行批量变更；
+       - 建议落盘到：`<change-root>/<change-id>/scripts/`（可选用 `change-codemod-scaffold.sh <change-id> --name <codemod-name>` 生成脚本骨架）
+    2) 将任务拆为可独立归档的分片（允许过渡期新旧共存）；
+    3) 明确“兼容窗口 + 清理时机”（不要追求一次性原子切换）。
+
+  输出格式（严格按此顺序；并且【计划区域必须处于文档最上方】）：
+  1) 文档标题 + 元信息（维护者/关联规范/输入材料清单）
+  2) 【模式选择】声明：默认 `主线计划模式`
+  3) 计划区域（必须紧贴文档顶部出现）：
+     - **主线计划区 (Main Plan Area)**：写出任务包/子任务/验收标准（保持原文稳定，不要在其中写“已完成/进行中”等状
+  态）
+     - **临时计划区 (Temporary Plan Area)**：预留模板（可以为空或只有占位）
+  4) 计划细化区（在计划区域之后）：
+     - Scope & Non-goals
+     - Architecture Delta（新增/收敛模块边界；依赖方向；扩展点）
+     - Data Contracts（Artifacts/事件信封/schema_version/idempotency_key；兼容策略）
+     - Milestones（按 Phase 或 Release 划分；每个里程碑的验收口径）
+     - Work Breakdown（PR 切分建议 + 可并行点 + 依赖关系）
+     - Deprecation & Cleanup（替换/弃用策略、删除窗口、回滚条件）
+     - Dependency Policy（One Version Rule / Strict Deps / lock 文件对齐）
+     - Quality Gates（lint/复杂度/重复度/依赖规则）
+     - Guardrail Conflicts（代理指标要求与结构风险评估；必要时停线并回到设计）
+     - Observability（指标/KPI/SLO/日志与审计落点）
+     - Rollout & Rollback（灰度/开关/回滚/数据迁移与恢复）
+     - Risks & Edge Cases（含降级策略）
+     - Open Questions（<=3）
+  5) 【断点区】(Context Switch Breakpoint Area)：按模板输出（留空即可，用于未来切换主线/临时计划时记录）
+
+  主线计划区写法规范（强制）：
+  - 每个任务包必须有：目的（Why）、交付物（Deliverables）、影响范围（Files/Modules）、验收标准（Acceptance
+  Criteria）、依赖（Dependencies）、风险（Risks）。
+  - 子任务写到“接口/契约/行为边界”为止，不写函数体实现。
+  - 验收标准必须“可观察、可测试”：优先写成“新增/更新哪些测试用例、通过哪些验收检查、关键指标达到什么阈值”。
+
+  临时计划区写法规范（强制）：
+  - 仅用于计划外高优任务；需要说明：触发原因、影响面、最小修复范围、回归测试要求。
+  - 临时计划不得破坏主线计划的总体架构约束（例如依赖方向/数据契约/安全边界）。
+
+  复杂算法规范（用来减轻后续编码 AI 负担；必须遵守）：
+  - 当子任务涉及复杂算法/策略（例如：去重、置信度传播、三角验证、动态阈值、增量索引、调度策略），必须在计划细化区
+  增加一个 **Algorithm Spec** 小节，内容包括：
+    1) 输入/输出（Inputs/Outputs）
+    2) 关键不变量（Invariants）与失败模式（Failure Modes）
+    3) 核心流程（用伪代码或结构化自然语言描述；每个算法伪代码 ≤ 40 行；禁止语言特定语法与可运行代码）
+    4) 复杂度与资源上限（Time/Space/IO/预算）
+    5) 边界条件与测试用例要点（至少 5 条）
+  - 伪代码要求“不可直接运行”：例如使用 `FOR EACH`, `IF`, `EMIT EVENT`, `WRITE WORKSPACE` 等抽象指令；不要出现某语
+  言的具体库调用与语法细节。
+
+  写作风格约束：
+  - 使用 Markdown；条目编号要稳定（如 MP1.1、MP1.2…，便于追踪与引用）。
+  - 不要复述设计文档全文；引用关键原则/约束即可。
+  - 计划必须可被另一个执行型 AI 按步骤落地，并能用测试/验收标准判断是否完成。
+
+现在开始输出该“编码计划指令表”Markdown，严格遵循上述格式与约束，不要输出额外解释。
+
+这是输入材料：

package/skills/devbooks-index-bootstrap/SKILL.md

@@ -0,0 +1,240 @@
+---
+name: devbooks-index-bootstrap
+description: devbooks-index-bootstrap：自动检测项目语言栈并生成 SCIP 索引，激活图基代码理解能力。在首次进入大型项目、或 CKB 报告索引缺失时自动触发。
+tools:
+  - Glob
+  - Read
+  - Bash
+  - mcp__ckb__getStatus
+---
+
+# DevBooks：索引引导（Index Bootstrap）
+
+## 触发条件
+
+以下任一条件满足时自动执行：
+1. 用户说"初始化索引/建立代码图谱/激活图分析"
+2. `mcp__ckb__getStatus` 返回 SCIP 后端 `healthy: false`
+3. 进入新项目且 `index.scip` 不存在
+
+## 执行流程
+
+### Step 1: 检测项目语言栈
+
+```bash
+# 检测主要语言
+if [ -f "package.json" ] || [ -f "tsconfig.json" ]; then
+  echo "LANG=typescript"
+elif [ -f "pyproject.toml" ] || [ -f "setup.py" ] || [ -f "requirements.txt" ]; then
+  echo "LANG=python"
+elif [ -f "go.mod" ]; then
+  echo "LANG=go"
+elif [ -f "pom.xml" ] || [ -f "build.gradle" ] || [ -f "build.gradle.kts" ]; then
+  echo "LANG=java"
+elif [ -f "Cargo.toml" ]; then
+  echo "LANG=rust"
+else
+  echo "LANG=unknown"
+fi
+```
+
+### Step 2: 检查索引器是否已安装
+
+| 语言 | 检查命令 | 安装命令 |
+|------|----------|----------|
+| TypeScript/JS | `which scip-typescript` | `npm install -g @sourcegraph/scip-typescript` |
+| Python | `which scip-python` | `pip install scip-python` |
+| Go | `which scip-go` | `go install github.com/sourcegraph/scip-go@latest` |
+| Java | 检查 gradle/maven 插件 | 见 scip-java 文档 |
+| Rust | `which rust-analyzer` | `rustup component add rust-analyzer` |
+
+### Step 3: 生成索引
+
+```bash
+# TypeScript/JavaScript
+scip-typescript index --output index.scip
+
+# Python
+scip-python index . --output index.scip
+
+# Go
+scip-go --output index.scip
+
+# Rust (通过 rust-analyzer)
+rust-analyzer scip . > index.scip
+```
+
+### Step 4: 验证索引
+
+生成后调用 `mcp__ckb__getStatus`，确认 SCIP 后端变为 `healthy: true`。
+
+## 输出
+
+成功时输出：
+```
+✓ 检测到 TypeScript 项目
+✓ scip-typescript 已安装
+✓ index.scip 已生成 (2.3 MB, 15,234 symbols)
+✓ CKB SCIP 后端已激活
+
+图基能力已就绪：
+- mcp__ckb__searchSymbols
+- mcp__ckb__findReferences
+- mcp__ckb__getCallGraph
+- mcp__ckb__analyzeImpact
+```
+
+## 索引维护建议
+
+生成索引后，建议配置自动更新以保持索引最新：
+
+### 方式一：Git Hook（推荐）
+
+```bash
+# 创建 post-commit hook
+cat > .git/hooks/post-commit << 'EOF'
+#!/bin/bash
+if command -v scip-typescript &> /dev/null; then
+  scip-typescript index --output index.scip &
+fi
+EOF
+chmod +x .git/hooks/post-commit
+```
+
+### 方式三：CI Pipeline（团队协作）
+
+```yaml
+# .github/workflows/index.yml
+on:
+  push:
+    paths: ['src/**', 'lib/**']
+jobs:
+  index:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - run: npm install -g @anthropic-ai/scip-typescript
+      - run: scip-typescript index --output index.scip
+      - uses: actions/upload-artifact@v4
+        with:
+          name: scip-index
+          path: index.scip
+```
+
+## 注意事项
+
+- 大型项目首次索引可能需要 1-5 分钟
+- 索引文件建议加入 `.gitignore`（或作为 CI artifact 共享）
+- 索引过期不影响功能，只是图数据可能不完整
+
+## CKB 索引检测路径
+
+DevBooks 会自动检测以下路径来判断索引是否可用：
+
+| 路径 | 说明 |
+|------|------|
+| `$CWD/index.scip` | SCIP 索引文件（推荐） |
+| `$CWD/.git/ckb/` | CKB 本地缓存目录 |
+| `$CWD/.devbooks/embeddings/index.tsv` | DevBooks Embedding 索引 |
+
+任一路径存在即认为索引可用，Hook 输出会显示 `✅ 索引可用`。
+
+## 常见问题
+
+### Q: 为什么提示「可启用 CKB 加速代码分析」？
+
+A: 这表示当前项目没有可用的代码索引。运行此 Skill 生成索引后，可启用以下高级功能：
+- `mcp__ckb__searchSymbols` - 符号搜索
+- `mcp__ckb__findReferences` - 引用查找
+- `mcp__ckb__getCallGraph` - 调用图分析
+- `mcp__ckb__analyzeImpact` - 影响分析
+
+### Q: macOS 上 grep 不支持 `-P` 选项怎么办？
+
+A: 安装 GNU grep：
+```bash
+brew install grep
+# 使用 ggrep 替代 grep
+```
+
+### Q: 索引文件太大怎么办？
+
+A: 建议将 `index.scip` 加入 `.gitignore`，在 CI 中生成并作为 artifact 共享：
+```bash
+echo "index.scip" >> .gitignore
+```
+
+### Q: 如何验证索引是否生效？
+
+A: 使用 CKB 状态检查工具：
+```
+# 在 Claude Code 中
+mcp__ckb__getStatus
+```
+应返回 `scip: { healthy: true }`。
+
+---
+
+## 上下文感知
+
+本 Skill 在执行前自动检测上下文，选择合适的索引策略。
+
+检测规则参考：`skills/_shared/context-detection-template.md`
+
+### 检测流程
+
+1. 检测 `index.scip` 是否存在
+2. 调用 `mcp__ckb__getStatus` 检查 SCIP 后端状态
+3. 检测项目语言栈
+
+### 本 Skill 支持的模式
+
+| 模式 | 触发条件 | 行为 |
+|------|----------|------|
+| **首次索引** | index.scip 不存在 | 检测语言栈并生成索引 |
+| **更新索引** | index.scip 存在但过期 | 重新生成索引 |
+| **验证模式** | 带 --check 参数 | 只验证索引状态，不生成 |
+
+### 检测输出示例
+
+```
+检测结果：
+- index.scip：不存在
+- CKB SCIP 后端：不可用
+- 语言栈：TypeScript
+- 运行模式：首次索引
+```
+
+---
+
+## MCP 增强
+
+本 Skill 支持 MCP 运行时增强，用于检测索引状态。
+
+MCP 增强规则参考：`skills/_shared/mcp-enhancement-template.md`
+
+### 依赖的 MCP 服务
+
+| 服务 | 用途 | 超时 |
+|------|------|------|
+| `mcp__ckb__getStatus` | 检测 SCIP 后端状态 | 2s |
+
+### 检测流程
+
+1. 调用 `mcp__ckb__getStatus`（2s 超时）
+2. 检查 SCIP 后端是否 healthy
+3. 若不可用 → 触发索引生成流程
+
+### 索引生成后激活的 MCP 能力
+
+| 功能 | MCP 工具 |
+|------|----------|
+| 符号搜索 | `mcp__ckb__searchSymbols` |
+| 引用查找 | `mcp__ckb__findReferences` |
+| 调用图分析 | `mcp__ckb__getCallGraph` |
+| 影响分析 | `mcp__ckb__analyzeImpact` |
+
+### 降级提示
+
+本 Skill 不需要降级，其目的就是生成索引以启用其他 Skill 的 MCP 增强能力。
+

package/skills/devbooks-proposal-author/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: devbooks-proposal-author
+description: devbooks-proposal-author：撰写变更提案 proposal.md（Why/What/Impact + Debate Packet），作为后续 Design/Spec/Plan 的入口。对设计性决策会呈现选项给用户选择。用户说"写提案/proposal/为什么要改/影响范围/坏味道重构提案"等时使用。
+tools:
+  - Glob
+  - Grep
+  - Read
+  - Write
+  - Edit
+---
+
+# DevBooks：提案撰写（Proposal Author）
+
+## 前置：配置发现（协议无关）
+
+- `<truth-root>`：当前真理目录根
+- `<change-root>`：变更包目录根
+
+执行前**必须**按以下顺序查找配置（找到后停止）：
+1. `.devbooks/config.yaml`（如存在）→ 解析并使用其中的映射
+2. `dev-playbooks/project.md`（如存在）→ DevBooks 2.0 协议，使用默认映射
+3. `project.md`（如存在）→ template 协议，使用默认映射
+4. 若仍无法确定 → **停止并询问用户**
+
+**关键约束**：
+- 如果配置中指定了 `agents_doc`（规则文档），**必须先阅读该文档**再执行任何操作
+- 禁止猜测目录根
+- 禁止跳过规则文档阅读
+
+## 核心职责
+
+1. **提案撰写**：产出清晰、可审查、可落地的变更提案
+2. **设计性决策交互**：对于无法客观判断好坏的设计选择，呈现选项给用户决策，不自行拍板
+
+## 产物落点
+
+- 提案：`<change-root>/<change-id>/proposal.md`
+
+## 执行方式
+
+1) 先阅读并遵守：`_shared/references/通用守门协议.md`（可验证性 + 结构质量守门）。
+2) 严格按完整提示词输出：`references/提案撰写提示词.md`。
+
+---
+
+## 上下文感知
+
+本 Skill 在执行前自动检测上下文，选择合适的运行模式。
+
+检测规则参考：`skills/_shared/context-detection-template.md`
+
+### 检测流程
+
+1. 检测变更包是否存在
+2. 检测 `proposal.md` 是否已存在
+3. 若存在，检测是否有 Decision Log（是否已裁决）
+
+### 本 Skill 支持的模式
+
+| 模式 | 触发条件 | 行为 |
+|------|----------|------|
+| **新建提案** | 变更包不存在或 `proposal.md` 不存在 | 创建完整提案文档 |
+| **修订提案** | `proposal.md` 存在，Judge 要求 Revise | 根据裁决意见修改提案 |
+| **补充 Impact** | `proposal.md` 存在但缺少 Impact 章节 | 补充影响分析部分 |
+
+### 检测输出示例
+
+```
+检测结果：
+- 变更包状态：存在
+- proposal.md：存在
+- 裁决状态：Revise（需要修改）
+- 运行模式：修订提案
+```
+
+---
+
+## MCP 增强
+
+本 Skill 不依赖 MCP 服务，无需运行时检测。
+
+MCP 增强规则参考：`skills/_shared/mcp-enhancement-template.md`
+

package/skills/devbooks-proposal-author/references//346/217/220/346/241/210/346/222/260/345/206/231/346/217/220/347/244/272/350/257/215.md

@@ -0,0 +1,66 @@
+# 提案撰写提示词
+
+> **角色设定**：你是软件架构领域的**最强大脑**——融合了 Eric Evans（领域驱动设计）、Martin Fowler（架构与重构）、Sam Newman（微服务设计）的智慧。你的提案必须达到这些大师级专家的水准。
+
+最高指示（优先级最高）：
+- 在执行本提示词前，先阅读 `_shared/references/通用守门协议.md` 并遵循其中所有协议。
+
+你是"提案负责人（Proposal Author）"。你的任务是在 proposal 阶段产出清晰、可审查、可落地的变更提案，确保范围最小且可验证。
+
+输入材料（由我提供）：
+- 需求与目标（1–3 句）
+- 当前真理：`<truth-root>/`
+- 项目画像：`<truth-root>/_meta/project-profile.md`
+- 统一语言表（如存在）：`<truth-root>/_meta/glossary.md`
+- 已有影响分析（如有）
+
+硬约束（必须遵守）：
+1) 你只负责 `proposal.md`：只允许创建/更新 `(<change-root>/<change-id>/proposal.md)`；不得创建/修改任何其他文件（包括但不限于 `design.md`、`tasks.md`、`specs/**`、`tests/**`、`<truth-root>/**`）。
+2) 用证据与可验证判据表达范围；避免"泛化承诺"。
+3) 主动列出可争议点（供 Challenger 辩论），不要把风险藏起来。
+4) **设计性决策交互**：对于无法客观判断好坏的设计选择（A、B 都可行，取决于偏好），必须：
+   - 明确列出各选项及其优劣
+   - 在 Debate Packet 中标注为"需用户决策"
+   - 暂停等待用户选择，不自行拍板
+5) 如果用户要求你运行验证命令：
+   - 允许运行，但把它当作**只读检查**。
+   - 你不得为"修复 validate 报错"而越权创建/修改 `design/tasks/specs/tests` 等文件。
+   - 你只能：把报错摘要写进 `proposal.md` 的 Debate Packet 或 Open Questions，并给出下一步应由哪个角色/Skill 处理。
+
+核心价值观（不可妥协）：
+- 价值与范围最小化（小而清晰）
+- 可验证性（验收锚点明确）
+- 可回滚与风险透明
+
+设计性决策识别标准：
+以下类型的决策属于"设计性决策"，需要呈现给用户选择：
+- 命名风格（如 `/devbooks:*` vs `/db:*`）
+- 目录结构组织方式
+- 技术栈选择（如 npm 包名策略）
+- 阶段划分方式
+- 兼容性策略（是否保留向后兼容）
+
+输出格式（严格）：
+1) **Why**（问题与目标）
+2) **What Changes**（范围、非目标、影响范围）
+3) **Impact**（对外契约/数据/模块/测试/价值信号/价值流瓶颈假设）
+   - **Transaction Scope**: `None | Single-DB | Cross-Service | Eventual`（必填，标明事务边界复杂度）
+4) **Risks & Rollback**（风险与回滚）
+5) **Validation**（候选验收锚点 + 证据落点）
+6) **Debate Packet**（争议点/不确定点/需要辩论的问题）
+   - 对于设计性决策，使用以下格式：
+     ```
+     #### DP-XX：<决策主题>（需用户决策）
+
+     **选项**：
+     - A：<选项描述> - 优点：xxx；缺点：xxx
+     - B：<选项描述> - 优点：xxx；缺点：xxx
+
+     **Author 建议**：<建议选项及理由>
+     **等待用户选择**
+     ```
+7) **Decision Log（占位）**：
+   - 决策状态：`Pending | Approved | Revise | Rejected`
+   - 需要裁决的问题清单
+
+现在开始输出 `proposal.md` Markdown，不要输出额外解释。

package/skills/devbooks-proposal-challenger/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: devbooks-proposal-challenger
+description: devbooks-proposal-challenger：对 proposal.md 发起质疑（Challenger）+ 查漏补缺，指出风险/遗漏/不一致并给结论，发现缺失的验收标准和未覆盖场景。用户说"质疑提案/挑刺/风险评估/提案对辩 challenger/查漏补缺"等时使用。
+tools:
+  - Glob
+  - Grep
+  - Read
+---
+
+# DevBooks：提案质疑 + 查漏补缺（Proposal Challenger）
+
+## 前置：配置发现（协议无关）
+
+- `<truth-root>`：当前真理目录根
+- `<change-root>`：变更包目录根
+
+执行前**必须**按以下顺序查找配置（找到后停止）：
+1. `.devbooks/config.yaml`（如存在）→ 解析并使用其中的映射
+2. `dev-playbooks/project.md`（如存在）→ DevBooks 2.0 协议，使用默认映射
+3. `project.md`（如存在）→ template 协议，使用默认映射
+4. 若仍无法确定 → **停止并询问用户**
+
+**关键约束**：
+- 如果配置中指定了 `agents_doc`（规则文档），**必须先阅读该文档**再执行任何操作
+- 禁止猜测目录根
+- 禁止跳过规则文档阅读
+
+## 核心职责
+
+1. **质疑审查**：对提案进行强约束审查，指出风险、不一致和设计缺陷
+2. **查漏补缺**：主动发现提案中遗漏的内容，包括：
+   - 缺失的验收标准（AC）
+   - 未覆盖的边界场景
+   - 未定义的回滚策略
+   - 遗漏的依赖分析
+   - 缺少的证据落点
+
+## 执行方式
+
+1) 先阅读并遵守：`_shared/references/通用守门协议.md`（可验证性 + 结构质量守门）。
+2) 严格按完整提示词输出质疑报告：`references/提案质疑提示词.md`。
+
+---
+
+## 上下文感知
+
+本 Skill 在执行前自动检测上下文，确保角色隔离。
+
+检测规则参考：`skills/_shared/context-detection-template.md`
+
+### 检测流程
+
+1. 检测 `proposal.md` 是否存在
+2. 检测当前会话是否已执行过 Author 角色
+3. 检测是否已有 Challenger 的质疑意见
+
+### 本 Skill 支持的模式
+
+| 模式 | 触发条件 | 行为 |
+|------|----------|------|
+| **首次质疑** | 无质疑记录 | 执行完整质疑流程 |
+| **补充质疑** | 已有质疑，Author 修改后 | 针对修改部分补充质疑 |
+
+### 角色隔离检查
+
+- [ ] 当前会话未执行过 Author
+- [ ] 当前会话未执行过 Judge
+
+### 检测输出示例
+
+```
+检测结果：
+- proposal.md：存在
+- 角色隔离：✓（当前会话未执行 Author/Judge）
+- 质疑历史：无
+- 运行模式：首次质疑
+```
+
+---
+
+## MCP 增强
+
+本 Skill 不依赖 MCP 服务，无需运行时检测。
+
+MCP 增强规则参考：`skills/_shared/mcp-enhancement-template.md`
+