dev-playbooks-cn 1.2.5 → 1.2.7

package/README.md

@@ -145,7 +145,7 @@ DevBooks 使用两个目录根：
 **4. Archive 阶段**
 
 ```
-请运行 devbooks-spec-gardener skill，变更 ID：add-oauth2
+请运行 devbooks-archiver skill，变更 ID：add-oauth2
 ```
 
 ---
@@ -184,7 +184,7 @@ DevBooks 使用两个目录根：
 
 | Skill | 说明 |
 |-------|------|
-| `devbooks-spec-gardener` | 规格维护与去重 |
+| `devbooks-archiver` | 规格维护与去重 |
 | `devbooks-delivery-workflow` | 完整交付闭环 |
 
 ### 独立技能

package/bin/devbooks.js

@@ -644,7 +644,7 @@ ${DEVBOOKS_MARKERS.start}
 - \`/devbooks-implementation-plan\`：编码计划（tasks.md）
 - \`/devbooks-test-owner\`：验收测试与追溯（独立对话）
 - \`/devbooks-coder\`：按 tasks 实现（禁止改 tests/）
-- \`/devbooks-spec-gardener\`：归档前规格修剪
+- \`/devbooks-archiver\`：归档前规格修剪
 
 ## 核心约束（必须遵守）
 
@@ -806,7 +806,7 @@ ${DEVBOOKS_MARKERS.start}
 | \`devbooks-proposal-author\` | 创建变更提案 |
 | \`devbooks-design-doc\` | 创建设计文档 |
 | \`devbooks-test-owner / devbooks-coder\` | 执行实现 |
-| \`devbooks-spec-gardener\` | 归档变更包 |
+| \`devbooks-archiver\` | 归档变更包 |
 
 ${DEVBOOKS_MARKERS.end}
 `;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dev-playbooks-cn",
-  "version": "1.2.5",
+  "version": "1.2.7",
   "description": "AI-driven spec-based development workflow",
   "keywords": [
     "devbooks",

package/skills/Skills/344/275/277/347/224/250/350/257/264/346/230/216.md

@@ -245,7 +245,7 @@
 
 ---
 
-## `devbooks-spec-gardener`（Spec Gardener）
+## `devbooks-archiver`（Archiver）
 
 - 作用：归档前修剪与维护 `<truth-root>`（去重合并/删除过时/目录整理/一致性修复），避免 specs 堆叠失控。
 - 使用场景：
@@ -253,7 +253,7 @@
   - 发现 `<truth-root>` 里重复/重叠/过时条目
 - 使用话术：
   ```text
-  你现在是 Spec Gardener。请点名使用 `devbooks-spec-gardener`。
+  你现在是 Archiver。请点名使用 `devbooks-archiver`。
   输入：`dev-playbooks/changes/<change-id>/specs/**` + `dev-playbooks/specs/**` + `dev-playbooks/changes/<change-id>/design.md`（如有）
   只允许修改 `dev-playbooks/specs/**` 做合并/去重/归类/删除过时；不要修改 change 包内容。
   输出按顺序：变更操作清单（CREATE/UPDATE/MOVE/DELETE）→ 每个 CREATE/UPDATE 的完整文件内容 → 合并映射摘要 → Open Questions（<=3）。

package/skills/Skill/345/274/200/345/217/221/346/214/207/345/215/227.md

@@ -20,7 +20,7 @@
 |------------|------------|------|
 | **验证/检查类** | 必须幂等（不修改文件） | `change-check.sh`、`guardrail-check.sh`、`devbooks-code-review` |
 | **生成类** | 必须明确"覆盖/增量"行为 | `change-scaffold.sh`、`devbooks-design-doc`、`devbooks-proposal-author` |
-| **修改类** | 必须可安全重跑 | `devbooks-spec-gardener`、`devbooks-design-backport` |
+| **修改类** | 必须可安全重跑 | `devbooks-archiver`、`devbooks-design-backport` |
 
 **验证/检查类 Skill 必须遵守**：
 - [ ] 不修改任何文件（只读操作）
@@ -95,7 +95,7 @@ echo "ok: verification passed"
 
 ### 1.5 真理源分离原则
 
-- **只读真理源**：Skill 只能读取 `<truth-root>/`，不能直接修改（除了 `spec-gardener` 等归档类 Skill）
+- **只读真理源**：Skill 只能读取 `<truth-root>/`，不能直接修改（除了 `archiver` 等归档类 Skill）
 - **写入工作区**：Skill 的写入目标是 `<change-root>/<change-id>/`
 - **归档即合并**：归档操作将工作区内容合并回真理源
 

package/skills/_shared/mcp-enhancement-template.md

@@ -66,7 +66,7 @@
 - devbooks-proposal-challenger（纯评审）
 - devbooks-proposal-judge（纯裁决）
 - devbooks-design-backport（文档回写）
-- devbooks-spec-gardener（文件整理）
+- devbooks-archiver（文件整理）
 - devbooks-test-reviewer（测试评审）
 
 对于这些 Skills，MCP 增强章节应写：

package/skills/_shared/references//345/201/217/347/246/273/346/243/200/346/265/213/344/270/216/350/267/257/347/224/261/345/215/217/350/256/256.md

@@ -128,7 +128,7 @@ deviation-log.md 是**持久化文件**，不受 compact 影响。即使对话
 | coder | HANDOFF (测试问题) | `devbooks-test-owner` |
 | test-owner | COMPLETED | `devbooks-coder` |
 | test-owner | HANDOFF (设计问题) | `devbooks-design-backport` |
-| code-review | COMPLETED (有 spec delta) | `devbooks-spec-gardener` |
+| code-review | COMPLETED (有 spec delta) | `devbooks-archiver` |
 | code-review | COMPLETED (无 spec delta) | 归档完成 |
 | 任意 | BLOCKED | 记录断点，等待用户 |
 | 任意 | FAILED | 修复后重试当前 skill |

package/skills/_shared/workflow-next-steps.md

@@ -25,7 +25,7 @@
                               ↓
 ┌─────────────────────────────────────────────────────────────────┐
 │                     归档阶段 (ARCHIVE)                           │
-│                     spec-gardener                                │
+│                         archiver                                 │
 └─────────────────────────────────────────────────────────────────┘
 ```
 
@@ -45,11 +45,11 @@
 | `devbooks-implementation-plan` | `devbooks-test-owner` | 始终（必须单独会话） |
 | `devbooks-test-owner` | `devbooks-coder` | Red 基线后（必须单独会话） |
 | `devbooks-coder` | `devbooks-code-review` | 所有任务完成后 |
-| `devbooks-code-review` | `devbooks-spec-gardener` | 如果有 spec deltas |
+| `devbooks-code-review` | `devbooks-archiver` | 如果有 spec deltas |
 | `devbooks-code-review` | 归档完成 | 如果无 spec deltas |
 | `devbooks-test-reviewer` | `devbooks-coder` | 如果发现测试问题，交回 |
 | `devbooks-design-backport` | `devbooks-implementation-plan` | 设计更新后重跑计划 |
-| `devbooks-spec-gardener` | 归档完成 | 始终 |
+| `devbooks-archiver` | 归档完成 | 始终 |
 
 ## 关键约束
 

package/skills/devbooks-archiver/SKILL.md

@@ -0,0 +1,315 @@
+---
+name: devbooks-archiver
+description: devbooks-archiver：归档阶段的唯一入口，负责完整的归档闭环（自动回写→规格合并→文档同步检查→变更包归档移动）。用户说"归档/archive/收尾/闭环/合并到真理"等时使用。
+allowed-tools:
+  - Glob
+  - Grep
+  - Read
+  - Write
+  - Edit
+  - Bash
+---
+
+# DevBooks：归档器（Archiver）
+
+## 工作流位置感知（Workflow Position Awareness）
+
+> **核心原则**：Archiver 是归档阶段的**唯一入口**，负责完成从代码评审到变更包归档的所有收尾工作。
+
+### 我在整体工作流中的位置
+
+```
+proposal → design → test-owner(P1) → coder → test-owner(P2) → code-review → [Archiver]
+                                                                                  ↓
+                                               自动回写 → 规格合并 → 文档检查 → 移动归档
+```
+
+### 为什么重命名为 Archiver？
+
+| 旧名称 | 新名称 | 变更原因 |
+|--------|--------|----------|
+| `spec-gardener` | `archiver` | 职责已扩展，不仅是规格合并，而是完整的归档闭环 |
+
+### Archiver 的完整职责
+
+| 阶段 | 职责 | 说明 |
+|------|------|------|
+| 1 | 自动回写检测与处理 | 检测 deviation-log.md，自动回写设计文档 |
+| 2 | 规格合并 | 将 specs/contracts 合并到 truth-root |
+| 3 | 架构合并 | 将 design.md 的 Architecture Impact 合并到 c4.md |
+| 4 | 文档同步检查 | 检查 design.md 的 Documentation Impact 是否已处理 |
+| 5 | 变更包归档移动 | 将变更包移动到 `<change-root>/archive/` |
+
+---
+
+## 前置：配置发现（协议无关）
+
+- `<truth-root>`：当前真理目录根
+- `<change-root>`：变更包目录根
+
+执行前**必须**按以下顺序查找配置（找到后停止）：
+1. `.devbooks/config.yaml`（如存在）→ 解析并使用其中的映射
+2. `dev-playbooks/project.md`（如存在）→ DevBooks 2.0 协议，使用默认映射
+3. `project.md`（如存在）→ template 协议，使用默认映射
+4. 若仍无法确定 → **停止并询问用户**
+
+**关键约束**：
+- 如果配置中指定了 `agents_doc`（规则文档），**必须先阅读该文档**再执行任何操作
+- 禁止猜测目录根
+- 禁止跳过规则文档阅读
+
+---
+
+## 归档完整流程
+
+### 第 1 步：前置检查
+
+```markdown
+前置检查清单：
+- [ ] 变更包存在（<change-root>/<change-id>/）
+- [ ] verification.md Status = Ready 或 Done
+- [ ] evidence/green-final/ 存在且非空
+- [ ] tasks.md 所有任务已完成（[x]）
+- [ ] 代码评审已通过（verification.md Status = Done 由 Reviewer 设置）
+```
+
+若检查失败 → 停止并输出缺失项，建议用户先完成前置步骤。
+
+### 第 2 步：自动回写检测与处理
+
+> **设计决策**：归档阶段自动处理所有未回写的偏离，用户无需手动调用 design-backport。
+
+**检测流程**：
+
+```
+1. 读取 <change-root>/<change-id>/deviation-log.md
+2. 检查是否有 "| ❌" 未回写记录
+   → 有：执行自动回写（步骤 3-5）
+   → 无：跳过，直接进入合并阶段
+
+3. 对每条未回写记录，判断是否为 Design-level 内容：
+   - DESIGN_GAP, CONSTRAINT_CHANGE, API_CHANGE → 需要回写
+   - 纯实现细节（文件名/类名/临时步骤） → 不回写，标记为 IMPL_ONLY
+
+4. 执行设计回写：
+   - 读取 design.md
+   - 按 design-backport 协议的"可回写内容范围"更新
+   - 在 design.md 末尾添加变更记录
+
+5. 更新 deviation-log.md：
+   - 将已回写的记录标记为 ✅
+   - 记录回写时间和归档批次
+```
+
+**自动回写的内容范围**（继承自 design-backport）：
+
+| 可回写 | 不可回写 |
+|--------|----------|
+| 对外语义/用户可感知行为 | 具体文件路径、类名/函数名 |
+| 系统级不可变约束（Invariants） | PR 切分、任务执行顺序 |
+| 核心数据契约与演进策略 | 过细的算法伪代码 |
+| 跨阶段治理策略 | 脚本命令 |
+| 关键取舍与决策 | 表名/字段名 |
+
+### 第 3 步：规格合并
+
+将变更包中的规格产物合并到 `<truth-root>`：
+
+| 源路径 | 目标路径 | 合并策略 |
+|--------|----------|----------|
+| `<change-root>/<change-id>/specs/**` | `<truth-root>/specs/**` | 增量合并 |
+| `<change-root>/<change-id>/contracts/**` | `<truth-root>/contracts/**` | 版本化合并 |
+
+### 第 4 步：架构合并
+
+> **设计决策**：C4 架构变更通过 design.md 的 Architecture Impact 章节记录，由 Archiver 在归档时合并到真理。
+
+**C4 合并流程**：
+
+1. **检测架构变更**：解析 `design.md` 中的 "Architecture Impact" 章节
+2. **判断是否需要合并**：
+   - 若 "无架构变更" 被勾选 → 跳过合并
+   - 若 "有架构变更" → 执行合并
+3. **执行合并**：
+   - 读取 `<truth-root>/architecture/c4.md`（若不存在则创建）
+   - 根据 Architecture Impact 中的变更描述更新对应章节
+   - 更新 Container/Component 表格
+   - 更新依赖关系
+   - 更新分层约束（如有变更）
+4. **记录合并日志**：在 c4.md 末尾添加变更记录
+
+### 第 5 步：文档同步检查
+
+检查 design.md 的 "Documentation Impact" 章节：
+
+```markdown
+检查项：
+- [ ] 若声明了"需要更新的文档"，验证这些文档已更新
+- [ ] 若勾选了"无需更新"，确认合理性
+- [ ] 输出文档同步状态报告
+```
+
+**若有未处理的文档更新**：
+- 输出警告，列出需要更新的文档
+- 不阻塞归档，但在归档报告中标记为 "文档待更新"
+
+### 第 6 步：变更包归档移动（新增）
+
+将已完成的变更包移动到归档目录：
+
+```bash
+# 源路径
+<change-root>/<change-id>/
+
+# 目标路径
+<change-root>/archive/<change-id>/
+```
+
+**移动流程**：
+
+1. **创建归档目录**（如不存在）：`<change-root>/archive/`
+2. **设置最终状态**：在 verification.md 中设置 `Status: Archived`
+3. **添加归档时间戳**：在 verification.md 末尾添加 `Archived-At: <timestamp>`
+4. **移动变更包**：`mv <change-root>/<change-id>/ <change-root>/archive/<change-id>/`
+5. **输出归档完成报告**
+
+**verification.md 归档状态更新**：
+
+```markdown
+---
+status: Archived
+archived-at: 2024-01-16T10:30:00Z
+archived-by: devbooks-archiver
+---
+```
+
+---
+
+## 执行方式
+
+1) 先阅读并遵守：`_shared/references/通用守门协议.md`（可验证性 + 结构质量守门）。
+2) 严格按完整提示词执行：`references/归档器提示词.md`。
+
+---
+
+## 上下文感知
+
+本 Skill 在执行前自动检测上下文，选择合适的运行模式。
+
+检测规则参考：`skills/_shared/context-detection-template.md`
+
+### 检测流程
+
+1. 检测 `<truth-root>/` 目录状态
+2. 若提供 change-id，检测变更包归档条件
+3. 检测重复/过时规格（维护模式）
+
+### 本 Skill 支持的模式
+
+| 模式 | 触发条件 | 行为 |
+|------|----------|------|
+| **归档模式** | 提供 change-id 且闸门通过 | 执行完整归档流程（6步） |
+| **维护模式** | 无 change-id | 执行 truth-root 去重、清理、整理 |
+| **检查模式** | 带 --dry-run 参数 | 只输出计划，不实际修改/移动 |
+
+### 归档模式完整流程图
+
+```
+┌─────────────────────────────────────────────────────────────┐
+│                      归档模式流程                            │
+├─────────────────────────────────────────────────────────────┤
+│                                                             │
+│  1. 前置检查                                                 │
+│     ├─ 变更包存在？                                          │
+│     ├─ verification.md Status = Ready/Done？                │
+│     ├─ evidence/green-final/ 存在？                          │
+│     └─ tasks.md 全部完成？                                   │
+│              │                                               │
+│              ▼                                               │
+│  2. 自动回写                                                 │
+│     ├─ 读取 deviation-log.md                                │
+│     ├─ 检测未回写记录                                        │
+│     └─ 执行回写 → 更新标记                                   │
+│              │                                               │
+│              ▼                                               │
+│  3. 规格合并                                                 │
+│     ├─ specs/** → truth-root/specs/**                       │
+│     └─ contracts/** → truth-root/contracts/**               │
+│              │                                               │
+│              ▼                                               │
+│  4. 架构合并                                                 │
+│     └─ Architecture Impact → c4.md                          │
+│              │                                               │
+│              ▼                                               │
+│  5. 文档同步检查                                             │
+│     └─ 检查 Documentation Impact 是否已处理                  │
+│              │                                               │
+│              ▼                                               │
+│  6. 变更包归档移动                                           │
+│     ├─ 设置 Status: Archived                                │
+│     └─ mv <change-id>/ → archive/<change-id>/               │
+│              │                                               │
+│              ▼                                               │
+│  ✅ 输出归档完成报告                                         │
+│                                                             │
+└─────────────────────────────────────────────────────────────┘
+```
+
+### 检测输出示例
+
+```
+检测结果：
+- truth-root：存在，包含 12 个 spec 文件
+- 变更包：存在，闸门全绿
+- 回写状态：2 条待回写记录
+- 运行模式：归档模式（完整流程）
+```
+
+---
+
+## 归档报告模板
+
+归档完成后，输出以下报告：
+
+```markdown
+## 归档报告
+
+### 变更包信息
+- Change ID: <change-id>
+- 归档时间: <timestamp>
+
+### 执行摘要
+| 步骤 | 状态 | 说明 |
+|------|------|------|
+| 前置检查 | ✅ | 全部通过 |
+| 自动回写 | ✅ | 回写 2 条记录 |
+| 规格合并 | ✅ | 合并 3 个 spec 文件 |
+| 架构合并 | ⏭️ | 无架构变更 |
+| 文档检查 | ⚠️ | README.md 待更新 |
+| 归档移动 | ✅ | 已移动到 archive/ |
+
+### 归档位置
+`<change-root>/archive/<change-id>/`
+
+### 后续建议
+- [ ] 更新 README.md（文档检查警告）
+```
+
+---
+
+## 维护模式职责
+
+在维护模式下（无 change-id）执行：
+
+- 检测重复的规格定义
+- 清理过时/废弃的规格
+- 整理目录结构
+- 修复一致性问题
+
+---
+
+## MCP 增强
+
+本 Skill 不依赖 MCP 服务，无需运行时检测。
+
+MCP 增强规则参考：`skills/_shared/mcp-enhancement-template.md`

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

@@ -74,7 +74,7 @@ allowed-tools:
 | 技术债热点 | `architecture/hotspots.md` | `mcp__ckb__getHotspots` |
 | 分层约束 | `architecture/layering-constraints.md` | 代码分析（可选） |
 
-> **设计决策**：C4 架构地图现在由 brownfield-bootstrap 在初始化时生成，后续架构变更通过 design.md 的 Architecture Impact 章节记录，由 spec-gardener 在归档时合并。
+> **设计决策**：C4 架构地图现在由 brownfield-bootstrap 在初始化时生成，后续架构变更通过 design.md 的 Architecture Impact 章节记录，由 archiver 在归档时合并。
 
 ### 4. 基线变更包
 

package/skills/devbooks-code-review/SKILL.md

@@ -10,6 +10,34 @@ allowed-tools:
 
 # DevBooks：代码评审（Reviewer）
 
+## 工作流位置感知（Workflow Position Awareness）
+
+> **核心原则**：Code Review 在 Test Owner 阶段 2 验证之后执行，是归档前的最后一个评审步骤。
+
+### 我在整体工作流中的位置
+
+```
+proposal → design → test-owner(阶段1) → coder → test-owner(阶段2) → [Code Review] → archive
+                                                                          ↓
+                                                              可读性/一致性/依赖审查
+```
+
+### Code Review 的职责边界
+
+| 允许 | 禁止 |
+|------|------|
+| 审查代码可读性/一致性 | ❌ 修改代码文件 |
+| 设置 verification.md Status = Done | ❌ 讨论业务正确性（那是 Test Owner 的事） |
+| 提出改进建议 | ❌ 勾选 AC 覆盖矩阵（那是 Test Owner 的事） |
+
+### 前置条件
+
+- [ ] Test Owner 阶段 2 已完成（AC 矩阵已打勾）
+- [ ] 测试全绿
+- [ ] evidence/green-final/ 存在
+
+---
+
 ## 前置：配置发现（协议无关）
 
 - `<truth-root>`：当前真理目录根
@@ -144,7 +172,7 @@ override dispose() {
 
 | 条件 | 下一个 Skill | 原因 |
 |------|--------------|------|
-| 有 spec deltas | `devbooks-spec-gardener` | 归档前合并规格到真理 |
+| 有 spec deltas | `devbooks-archiver` | 归档前合并规格到真理 |
 | 无 spec deltas | 归档完成 | 无需其他 skill |
 | 发现重大问题 | 交回 `devbooks-coder` | 归档前修复问题 |
 
@@ -164,7 +192,7 @@ Review 通过后，Reviewer 必须执行：
 ```markdown
 ## 推荐的下一步
 
-**下一步：`devbooks-spec-gardener`**（如果有 spec deltas）
+**下一步：`devbooks-archiver`**（如果有 spec deltas）
 或
 **归档完成**（如果无 spec deltas）
 
@@ -172,7 +200,7 @@ Review 通过后，Reviewer 必须执行：
 
 ### 如何调用（如果有 spec deltas）
 ```
-运行 devbooks-spec-gardener skill 处理变更 <change-id>
+运行 devbooks-archiver skill 处理变更 <change-id>
 ```
 ```
 

package/skills/devbooks-coder/SKILL.md

@@ -12,6 +12,40 @@ allowed-tools:
 
 # DevBooks：实现负责人（Coder）
 
+## 工作流位置感知（Workflow Position Awareness）
+
+> **核心原则**：Coder 在 Test Owner 阶段 1 之后执行，完成后交给 Test Owner 阶段 2 验证。
+
+### 我在整体工作流中的位置
+
+```
+proposal → design → test-owner(阶段1) → [Coder] → test-owner(阶段2) → code-review → archive
+                                            ↓
+                                    实现代码、让测试变绿
+```
+
+### Coder 的职责边界
+
+| 允许 | 禁止 |
+|------|------|
+| 修改 `src/**` 代码 | ❌ 修改 `tests/**` |
+| 勾选 `tasks.md` 任务项 | ❌ 修改 `verification.md` |
+| 记录偏离到 `deviation-log.md` | ❌ 勾选 AC 覆盖矩阵 |
+| 运行测试验证 | ❌ 设置 verification.md Status |
+
+### Coder 完成后的流程
+
+1. **任务完成**：tasks.md 全部 `[x]`
+2. **测试全绿**：运行 `npm test` 确认通过
+3. **交付 Test Owner**：通知 Test Owner 进入阶段 2 验证
+4. **等待验证结果**：
+   - Test Owner 确认全绿 → 进入 Code Review
+   - Test Owner 发现问题 → Coder 修复
+
+**关键提醒**：Coder 完成后，**不是直接进入 Code Review**，而是先让 Test Owner 验证并打勾。
+
+---
+
 ## 前置：配置发现（协议无关）
 
 - `<truth-root>`：当前真理目录根
@@ -334,8 +368,8 @@ fi
 
 | 我的状态 | 下一步 | 原因 |
 |----------|--------|------|
-| COMPLETED | `devbooks-code-review` | 评审可读性/一致性 |
-| COMPLETED_WITH_DEVIATION | `devbooks-design-backport` | 先回写设计，再评审 |
+| COMPLETED | `devbooks-test-owner`（阶段 2 验证） | 任务完成，需要 Test Owner 验证并打勾 |
+| COMPLETED_WITH_DEVIATION | `devbooks-design-backport` | 先回写设计，再让 Test Owner 验证 |
 | HANDOFF (测试问题) | `devbooks-test-owner` | Coder 不能修改测试 |
 | BLOCKED | 等待用户 | 记录断点区 |
 | FAILED | 修复后重试 | 分析失败原因 |
@@ -344,6 +378,7 @@ fi
 - Coder **永远不能修改** `tests/**`
 - 如发现测试问题，必须 HANDOFF 给 Test Owner（单独会话）
 - 如有偏离，必须先 design-backport 再继续
+- **Coder 完成后必须先经过 Test Owner 阶段 2 验证，再进入 Code Review**
 
 ---
 

package/skills/devbooks-delivery-workflow/SKILL.md

@@ -28,6 +28,58 @@ allowed-tools:
 - 禁止猜测目录根
 - 禁止跳过规则文档阅读
 
+## 变更包命名规范（必须遵守）
+
+变更包 ID（change-id）**必须**遵循以下命名规范：
+
+### 格式
+
+```
+<日期时间>-<动词开头的语义描述>
+```
+
+### 规则
+
+| 组成部分 | 规则 | 示例 |
+|----------|------|------|
+| 日期时间 | `YYYYMMDD-HHMM` 格式 | `20240116-1030` |
+| 分隔符 | 日期时间与语义之间用 `-` 分隔 | `-` |
+| 语义描述 | **必须以动词开头**，使用小写和连字符 | `add-oauth2`, `fix-login-bug` |
+
+### 合法示例
+
+```bash
+# ✅ 正确
+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` | 迁移数据/系统 |
+
+### 为什么这样命名？
+
+1. **时间戳在前**：归档目录中自动按时间排序
+2. **动词开头**：清晰表达变更意图，方便代码审查
+3. **小写连字符**：避免跨平台文件名问题
+
 ## 参考骨架（按需读取）
 
 - 工作流：`references/交付验收工作流.md`

package/skills/devbooks-delivery-workflow/references//344/272/244/344/273/230/351/252/214/346/224/266/345/267/245/344/275/234/346/265/201.md

@@ -237,8 +237,8 @@ change-check.sh <change-id> --mode strict --project-root "$(pwd)" --change-root
 - 更新编码计划的进度表（只以锚点结果为准）
 - 更新价值流与度量口径：把本次“价值信号/排队点/稳定性指标”的证据链接写回 `verification.md`（建议落到 `evidence/`）
 - 若发现“计划错误/设计遗漏”：在下一版本修正 Design Doc / ADR，而不是靠口头约定
-- 活文档修剪（Spec Gardening）：
-  - 使用 `devbooks-spec-gardener` Skill 执行
+- 活文档修剪（Archiving）：
+  - 使用 `devbooks-archiver` Skill 执行
   - 去重合并：合并相似/重叠的 spec，避免追加式堆叠
   - 目录整理：按业务能力整理到 `<truth-root>/<capability>/`
   - 删除过时：被新功能替代的 spec 必须删除

package/skills/devbooks-design-backport/SKILL.md

@@ -11,6 +11,40 @@ allowed-tools:
 
 # DevBooks：回写设计文档（Design Backport）
 
+## 工作流位置感知（Workflow Position Awareness）
+
+> **核心原则**：Design Backport 现在**主要由 Archiver 在归档阶段自动调用**，用户通常不需要手动调用。
+
+### 我在整体工作流中的位置
+
+```
+proposal → design → test-owner → coder → test-owner(验证) → code-review → [Archive/Archiver]
+                                    ↓                                              ↓
+                             记录偏离到 deviation-log.md               自动调用 design-backport
+```
+
+### 设计决策：自动回写
+
+**旧流程**（需手动判断）：
+```
+coder 有偏离 → 用户手动调用 design-backport → 再归档
+```
+
+**新流程**（自动处理）：
+```
+coder 有偏离 → 归档时 archiver 自动检测并回写 → 归档
+```
+
+### 何时仍需手动调用
+
+| 场景 | 是否需要手动调用 |
+|------|------------------|
+| 正常流程（偏离记录在 deviation-log.md） | ❌ 归档时自动处理 |
+| 需要立即回写（不等归档） | ✅ 手动调用 |
+| 设计与实现严重冲突需要决策 | ✅ 手动调用并讨论 |
+
+---
+
 ## 前置：配置发现（协议无关）
 
 - `<truth-root>`：当前真理目录根

package/skills/devbooks-design-doc/SKILL.md

@@ -11,6 +11,28 @@ allowed-tools:
 
 # DevBooks：设计文档（Design Doc）
 
+## 工作流位置感知（Workflow Position Awareness）
+
+> **核心原则**：Design Doc 在 Proposal 批准后执行，是实现阶段的起点。
+
+### 我在整体工作流中的位置
+
+```
+proposal → [Design Doc] → spec-contract → implementation-plan → test-owner → coder → ...
+                 ↓
+        定义 What/Constraints/AC
+```
+
+### Design Doc 的产出
+
+- **What**：做什么（不是怎么做）
+- **Constraints**：约束条件
+- **AC-xxx**：验收标准（可测试的）
+
+**关键**：Design Doc 不写实现步骤，那是 implementation-plan 的职责。
+
+---
+
 ## 前置：配置发现（协议无关）
 
 - `<truth-root>`：当前真理目录根
@@ -78,7 +100,7 @@ allowed-tools:
 
 设计文档中**必须**包含「架构影响」章节，声明本次变更对系统架构的影响。这是确保架构变更走验证闭环的关键机制。
 
-> **设计决策**：C4 架构变更不再由独立的 `devbooks-c4-map` skill 直接写入真理目录，而是作为 design.md 的一部分，在变更验收通过后由 `devbooks-spec-gardener` 合并到真理。
+> **设计决策**：C4 架构变更不再由独立的 `devbooks-c4-map` skill 直接写入真理目录，而是作为 design.md 的一部分，在变更验收通过后由 `devbooks-archiver` 合并到真理。
 
 ### 模板
 

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

@@ -11,6 +11,42 @@ allowed-tools:
 
 # DevBooks：编码计划（Implementation Plan）
 
+## 工作流位置感知（Workflow Position Awareness）
+
+> **核心原则**：Implementation Plan 在 Design Doc 之后执行，为 Test Owner 和 Coder 提供任务清单。
+
+### 我在整体工作流中的位置
+
+```
+proposal → design → [Implementation Plan] → test-owner(阶段1) → coder → ...
+                            ↓
+                    tasks.md（任务清单）
+```
+
+### Implementation Plan 的职责
+
+| 允许 | 禁止 |
+|------|------|
+| 从 design.md 推导任务 | ❌ 参考 tests/（避免实现偏见） |
+| 绑定验收锚点 (AC-xxx) | ❌ 写实现代码 |
+| 拆分并行任务 | ❌ 执行任务 |
+
+### 产出：tasks.md 结构
+
+```markdown
+## 主线计划区
+- [ ] MP1.1 任务描述 (AC-001)
+- [ ] MP1.2 任务描述 (AC-002)
+
+## 临时计划区
+（紧急任务）
+
+## 断点区
+（中断续做信息）
+```
+
+---
+
 ## 前置：配置发现（协议无关）
 
 - `<truth-root>`：当前真理目录根

package/skills/devbooks-router/SKILL.md

@@ -195,7 +195,7 @@ skill 列表：
 - **风险/争议/取舍明显**：`devbooks-proposal-challenger` + `devbooks-proposal-judge`（独立对话，对辩后写回 Decision Log）
 - **对外行为/契约/数据不变量变化**：`devbooks-spec-contract` → `(<change-root>/<change-id>/specs/**)` + `design.md` Contract 章节
   - 若需要"确定性创建 spec delta 文件/避免路径写错"：`change-spec-delta-scaffold.sh <change-id> <capability> ...`
-- **模块边界/依赖方向/架构形态变化**：确保 `devbooks-design-doc` 输出完整的 Architecture Impact 章节 → 归档时由 `devbooks-spec-gardener` 合并到 `(<truth-root>/architecture/c4.md)`
+- **模块边界/依赖方向/架构形态变化**：确保 `devbooks-design-doc` 输出完整的 Architecture Impact 章节 → 归档时由 `devbooks-archiver` 合并到 `(<truth-root>/architecture/c4.md)`
 
 硬约束提醒：
 - proposal 阶段禁止写实现代码；实现发生在 apply 阶段并以测试/闸门为完成判据。
@@ -251,7 +251,7 @@ LSC（大规模同质化修改）建议：
 触发信号：用户说"归档/合并 specs/关账/收尾"等。
 
 默认路由：
-- 若本次产生了 spec delta：`devbooks-spec-gardener`（先修剪 `<truth-root>/**` 再归档合并）
+- 若本次产生了 spec delta：`devbooks-archiver`（先修剪 `<truth-root>/**` 再归档合并）
 - 若需要回写设计决策：`devbooks-design-backport`（按需）
 - 若影响用户文档：`devbooks-docs-sync`（确保文档与代码一致）
 
@@ -302,7 +302,7 @@ LSC（大规模同质化修改）建议：
 
 ## DevBooks Skill 适配
 
-DevBooks 使用 `devbooks-proposal-author skill`、`devbooks-test-owner/coder skill`、`devbooks-spec-gardener skill` 作为入口。
+DevBooks 使用 `devbooks-proposal-author skill`、`devbooks-test-owner/coder skill`、`devbooks-archiver skill` 作为入口。
 按上述 A/B/C/D 路由即可，产物路径以项目指路牌里 `<truth-root>/<change-root>` 的映射为准。
 
 ---

package/skills/devbooks-test-owner/SKILL.md

@@ -12,6 +12,46 @@ allowed-tools:
 
 # DevBooks：测试负责人（Test Owner）
 
+## 工作流位置感知（Workflow Position Awareness）
+
+> **核心原则**：Test Owner 在整体工作流中承担**双阶段职责**，确保与 Coder 的角色隔离。
+
+### 我在整体工作流中的位置
+
+```
+proposal → design → [Test Owner 阶段1] → coder → [Test Owner 阶段2] → code-review → archive
+                         ↓                           ↓
+                    Red 基线产出              Green 验证 + 打勾
+```
+
+### Test Owner 的双阶段职责
+
+| 阶段 | 触发时机 | 核心职责 | 产出 |
+|------|----------|----------|------|
+| **阶段 1：Red 基线** | design.md 完成后 | 编写测试、产出失败证据 | verification.md (Status=Ready)、Red 基线 |
+| **阶段 2：Green 验证** | Coder 完成后 | 验证测试通过、勾选 AC 覆盖矩阵 | AC 矩阵打勾、Status 保持 Ready（等 Reviewer 设 Done） |
+
+### 阶段 2 详细职责（关键！）
+
+当用户说"Coder 完成了，请验证"或类似请求时，Test Owner 进入**阶段 2**：
+
+1. **运行全部测试**：执行 `npm test` 或项目测试命令
+2. **验证 Green 状态**：确认所有测试通过
+3. **勾选 AC 覆盖矩阵**：在 verification.md 的 AC 覆盖矩阵中将 `[ ]` 改为 `[x]`
+4. **收集 Green 证据**：保存到 `evidence/green-final/`
+5. **输出验证报告**：总结测试结果和覆盖情况
+
+### AC 覆盖矩阵复选框权限（重要！）
+
+| 复选框位置 | 谁可以勾选 | 勾选时机 |
+|------------|-----------|----------|
+| AC 覆盖矩阵中的 `[ ]` | **Test Owner** | 阶段 2 验证 Green 状态后 |
+| Status 字段 `Done` | Reviewer | Code Review 通过后 |
+
+**禁止**：Coder 不能勾选 AC 覆盖矩阵，不能修改 verification.md。
+
+---
+
 ## 前置：配置发现（协议无关）
 
 - `<truth-root>`：当前真理目录根
@@ -339,28 +379,53 @@ devbooks change-evidence <change-id> --label red-baseline -- npm test
 
 ## 完成状态与下一步路由
 
-### 完成状态分类（MECE）
+### 阶段感知（关键！）
+
+Test Owner 有两个阶段，完成状态因阶段而异：
+
+| 当前阶段 | 如何判断 | 完成后下一步 |
+|----------|----------|--------------|
+| **阶段 1** | verification.md 不存在或 Red 基线未产出 | → Coder |
+| **阶段 2** | 用户说"验证/打勾"且 Coder 已完成 | → Code Review |
+
+### 阶段 1 完成状态分类（MECE）
 
 | 状态码 | 状态 | 判定条件 | 下一步 |
 |:------:|------|----------|--------|
-| ✅ | COMPLETED | Red 基线产出，无偏离 | `devbooks-coder`（单独会话） |
-| ⚠️ | COMPLETED_WITH_DEVIATION | Red 基线产出，deviation-log 有未回写记录 | `devbooks-design-backport` |
+| ✅ | PHASE1_COMPLETED | Red 基线产出，无偏离 | `devbooks-coder`（单独会话） |
+| ⚠️ | PHASE1_COMPLETED_WITH_DEVIATION | Red 基线产出，deviation-log 有未回写记录 | `devbooks-design-backport` |
 | ❌ | BLOCKED | 需要外部输入/决策 | 记录断点，等待用户 |
 | 💥 | FAILED | 测试框架问题等 | 修复后重试 |
 
-### 状态判定流程
+### 阶段 2 完成状态分类（MECE）
 
-```
-1. 检查 deviation-log.md 是否有 "| ❌" 记录
-   → 有：COMPLETED_WITH_DEVIATION
+| 状态码 | 状态 | 判定条件 | 下一步 |
+|:------:|------|----------|--------|
+| ✅ | PHASE2_VERIFIED | 测试全绿，AC 矩阵已打勾 | `devbooks-code-review` |
+| ❌ | PHASE2_FAILED | 测试未通过 | 通知 Coder 修复，或 HANDOFF |
+| 🔄 | PHASE2_HANDOFF | 发现测试本身有问题 | 修复测试后重新验证 |
 
-2. 检查 Red 基线是否产出
-   - verification.md 存在且有追溯矩阵
-   - evidence/red-baseline/ 存在
-   → 否：BLOCKED 或 FAILED
+### 阶段判定流程
 
-3. 以上都通过
-   → COMPLETED
+```
+1. 检查当前处于哪个阶段：
+   - verification.md 不存在 → 阶段 1
+   - verification.md 存在但 AC 矩阵全是 [ ] → 阶段 1 或 阶段 2（看用户请求）
+   - 用户明确说"验证/打勾/Coder 完成了" → 阶段 2
+
+2. 阶段 1 状态判定：
+   a. 检查 deviation-log.md 是否有 "| ❌" 记录
+      → 有：PHASE1_COMPLETED_WITH_DEVIATION
+   b. 检查 Red 基线是否产出
+      → 否：BLOCKED 或 FAILED
+   c. 以上都通过 → PHASE1_COMPLETED
+
+3. 阶段 2 状态判定：
+   a. 运行测试，检查是否全绿
+      → 否：PHASE2_FAILED
+   b. 检查测试本身是否有问题
+      → 是：PHASE2_HANDOFF
+   c. 全绿且无问题 → PHASE2_VERIFIED
 ```
 
 ### 路由输出模板（必须使用）
@@ -370,15 +435,21 @@ devbooks change-evidence <change-id> --label red-baseline -- npm test
 ```markdown
 ## 完成状态
 
-**状态**：✅ COMPLETED / ⚠️ COMPLETED_WITH_DEVIATION / ❌ BLOCKED / 💥 FAILED
+**阶段**：阶段 1（Red 基线）/ 阶段 2（Green 验证）
+
+**状态**：✅ PHASE1_COMPLETED / ✅ PHASE2_VERIFIED / ⚠️ ... / ❌ ... / 💥 ...
+
+**Red 基线**：已产出 / 未完成（仅阶段 1）
+
+**Green 验证**：全绿 / 有失败（仅阶段 2）
 
-**Red 基线**：已产出 / 未完成
+**AC 矩阵**：已打勾 N/M / 未打勾（仅阶段 2）
 
 **偏离记录**：有 N 条待回写 / 无
 
 ## 下一步
 
-**推荐**：`devbooks-xxx skill`（单独会话）
+**推荐**：`devbooks-xxx skill`
 
 **原因**：[具体原因]
 
@@ -390,8 +461,11 @@ devbooks change-evidence <change-id> --label red-baseline -- npm test
 
 | 我的状态 | 下一步 | 原因 |
 |----------|--------|------|
-| COMPLETED | `devbooks-coder`（单独会话） | Red 基线已产出，Coder 实现以变绿 |
-| COMPLETED_WITH_DEVIATION | `devbooks-design-backport` | 先回写设计，再交给 Coder |
+| PHASE1_COMPLETED | `devbooks-coder`（单独会话） | Red 基线已产出，Coder 实现以变绿 |
+| PHASE1_COMPLETED_WITH_DEVIATION | `devbooks-design-backport` | 先回写设计，再交给 Coder |
+| PHASE2_VERIFIED | `devbooks-code-review` | 测试全绿，可以进入代码评审 |
+| PHASE2_FAILED | 通知 Coder | 测试未通过，需要 Coder 修复 |
+| PHASE2_HANDOFF | 修复测试 | 测试本身有问题，Test Owner 修复 |
 | BLOCKED | 等待用户 | 记录断点区 |
 | FAILED | 修复后重试 | 分析失败原因 |
 
@@ -399,6 +473,7 @@ devbooks change-evidence <change-id> --label red-baseline -- npm test
 - **角色隔离**：Coder 必须在**单独的会话/实例**中工作
 - Test Owner 和 Coder 不能共享同一会话上下文
 - 如有偏离，必须先 design-backport 再交给 Coder
+- **阶段 2 的 AC 矩阵打勾只能由 Test Owner 执行**
 
 ---
 

package/templates/dev-playbooks/README.md

@@ -160,7 +160,7 @@ DevBooks 使用两个目录根：
 **4. Archive 阶段**
 
 ```
-请运行 devbooks-spec-gardener skill，变更 ID：add-oauth2
+请运行 devbooks-archiver skill，变更 ID：add-oauth2
 ```
 
 ---
@@ -199,7 +199,7 @@ DevBooks 使用两个目录根：
 
 | Skill | 说明 |
 |-------|------|
-| `devbooks-spec-gardener` | 规格维护与去重 |
+| `devbooks-archiver` | 规格维护与去重 |
 | `devbooks-delivery-workflow` | 完整交付闭环 |
 
 ### 独立技能

package/templates/dev-playbooks/docs/DevBooks/351/205/215/347/275/256/346/214/207/345/215/227.md

@@ -132,7 +132,7 @@ change_root: dev-playbooks/changes/ # 变更包目录根
 | Test Owner | `devbooks-test-owner` | `verification.md` + `tests/` |
 | Coder | `devbooks-coder` | 按 tasks 实现（禁止改 tests） |
 | Reviewer | `devbooks-code-review` | 评审意见 |
-| Spec Gardener | `devbooks-spec-gardener` | 归档修剪 + C4 合并 |
+| Archiver | `devbooks-archiver` | 归档修剪 + C4 合并 |
 | Design Backport | `devbooks-design-backport` | 回写设计缺口 |
 
 ### 按工作流

package/templates/dev-playbooks/docs/workflow-diagram.svg

@@ -115,7 +115,7 @@
     <text x="125" y="95" font-family="Arial, sans-serif" font-size="12" fill="#4a5568" text-anchor="middle">Code Review</text>
 
     <rect x="20" y="120" width="210" height="40" rx="8" fill="white" stroke="#8e2de2" stroke-width="2"/>
-    <text x="125" y="145" font-family="Arial, sans-serif" font-size="12" fill="#4a5568" text-anchor="middle">Spec Gardener</text>
+    <text x="125" y="145" font-family="Arial, sans-serif" font-size="12" fill="#4a5568" text-anchor="middle">Archiver</text>
 
     <rect x="20" y="170" width="210" height="40" rx="8" fill="white" stroke="#8e2de2" stroke-width="2"/>
     <text x="125" y="195" font-family="Arial, sans-serif" font-size="12" fill="#4a5568" text-anchor="middle">合并到 truth-root</text>
@@ -197,7 +197,7 @@
       <tspan>Test Owner 与 Coder 必须独立对话。"完成"由测试/构建证据定义，而非 AI 自我声明。</tspan>
     </text>
     <text x="0" y="35" font-family="Arial, sans-serif" font-size="10" fill="#a0aec0">
-      <tspan>Skills: devbooks-proposal-author → devbooks-design-doc → devbooks-implementation-plan → devbooks-test-owner → devbooks-coder → devbooks-code-review → devbooks-spec-gardener</tspan>
+      <tspan>Skills: devbooks-proposal-author → devbooks-design-doc → devbooks-implementation-plan → devbooks-test-owner → devbooks-coder → devbooks-code-review → devbooks-archiver</tspan>
     </text>
   </g>
 </svg>

package/skills/devbooks-spec-gardener/SKILL.md

@@ -1,128 +0,0 @@
----
-name: devbooks-spec-gardener
-description: devbooks-spec-gardener：归档前修剪与维护 <truth-root>（去重合并/删除过时/目录整理/一致性修复），避免 specs 堆叠失控。用户说"规格园丁/specs 去重合并/归档前整理/清理过时规范"，或在 DevBooks archive/归档前收尾时使用。
-allowed-tools:
-  - Glob
-  - Grep
-  - Read
-  - Write
-  - Edit
----
-
-# DevBooks：规格园丁（Spec Gardener）
-
-## 前置：配置发现（协议无关）
-
-- `<truth-root>`：当前真理目录根
-- `<change-root>`：变更包目录根
-
-执行前**必须**按以下顺序查找配置（找到后停止）：
-1. `.devbooks/config.yaml`（如存在）→ 解析并使用其中的映射
-2. `dev-playbooks/project.md`（如存在）→ DevBooks 2.0 协议，使用默认映射
-3. `project.md`（如存在）→ template 协议，使用默认映射
-4. 若仍无法确定 → **停止并询问用户**
-
-**关键约束**：
-- 如果配置中指定了 `agents_doc`（规则文档），**必须先阅读该文档**再执行任何操作
-- 禁止猜测目录根
-- 禁止跳过规则文档阅读
-
----
-
-## 核心职责
-
-### 1. 规格合并与维护
-
-在归档阶段，将变更包中的规格产物合并到 `<truth-root>`：
-
-| 源路径 | 目标路径 | 合并策略 |
-|--------|----------|----------|
-| `<change-root>/<change-id>/specs/**` | `<truth-root>/specs/**` | 增量合并 |
-| `<change-root>/<change-id>/contracts/**` | `<truth-root>/contracts/**` | 版本化合并 |
-
-### 2. C4 架构地图合并（新增）
-
-> **设计决策**：C4 架构变更现在通过 design.md 的 Architecture Impact 章节记录，由 spec-gardener 在归档时合并到真理。
-
-在归档阶段，检测并合并架构变更：
-
-| 检测源 | 目标路径 | 合并逻辑 |
-|--------|----------|----------|
-| `<change-root>/<change-id>/design.md` 的 "Architecture Impact" 章节 | `<truth-root>/architecture/c4.md` | 增量更新 |
-
-**C4 合并流程**：
-
-1. **检测架构变更**：解析 `design.md` 中的 "Architecture Impact" 章节
-2. **判断是否需要合并**：
-   - 若 "无架构变更" 被勾选 → 跳过合并
-   - 若 "有架构变更" → 执行合并
-3. **执行合并**：
-   - 读取 `<truth-root>/architecture/c4.md`（若不存在则创建）
-   - 根据 Architecture Impact 中的变更描述更新对应章节
-   - 更新 Container/Component 表格
-   - 更新依赖关系
-   - 更新分层约束（如有变更）
-4. **记录合并日志**：在 c4.md 末尾添加变更记录
-
-**合并输出格式**（追加到 c4.md）：
-
-```markdown
-## Change History
-
-| Date | Change ID | Impact Summary |
-|------|-----------|----------------|
-| <date> | <change-id> | <brief description of architecture changes> |
-```
-
-### 3. 去重与清理
-
-在维护模式下执行：
-
-- 检测重复的规格定义
-- 清理过时/废弃的规格
-- 整理目录结构
-- 修复一致性问题
-
-## 执行方式
-
-1) 先阅读并遵守：`_shared/references/通用守门协议.md`（可验证性 + 结构质量守门）。
-2) 严格按完整提示词执行：`references/规格园丁提示词.md`。
-
----
-
-## 上下文感知
-
-本 Skill 在执行前自动检测上下文，选择合适的维护模式。
-
-检测规则参考：`skills/_shared/context-detection-template.md`
-
-### 检测流程
-
-1. 检测 `<truth-root>/` 目录状态
-2. 若提供 change-id，检测变更包归档条件
-3. 检测重复/过时规格
-
-### 本 Skill 支持的模式
-
-| 模式 | 触发条件 | 行为 |
-|------|----------|------|
-| **归档模式** | 提供 change-id 且闸门通过 | 将变更包产物合并到 truth-root |
-| **维护模式** | 无 change-id | 执行去重、清理、整理操作 |
-| **检查模式** | 带 --dry-run 参数 | 只输出建议，不实际修改 |
-
-### 检测输出示例
-
-```
-检测结果：
-- truth-root：存在，包含 12 个 spec 文件
-- 变更包：存在，闸门全绿
-- 运行模式：归档模式
-```
-
----
-
-## MCP 增强
-
-本 Skill 不依赖 MCP 服务，无需运行时检测。
-
-MCP 增强规则参考：`skills/_shared/mcp-enhancement-template.md`