@modus-ai/modus 0.2.3 → 0.2.5

package/templates/skills/modus-spec/SKILL.md

@@ -1,26 +1,39 @@
 ---
 name: modus-spec
-description: Use this skill when executing /modus:spec command for OpenSpec-style spec-driven development. Generates delta specs (ADDED/MODIFIED/REMOVED requirements with GIVEN/WHEN/THEN scenarios), design, and tasks. Supports --lite flag to skip design-brief for low-risk changes. Trigger on /modus:spec command or when user wants behavior specifications before coding.
+description: Use this skill when executing /modus:spec command for spec-driven development. Loads and updates business Skills, generates delta specs (ADDED/MODIFIED/REMOVED requirements with GIVEN/WHEN/THEN scenarios), technical design, and task list. Detects conflicts against existing spec library. Archives delta specs by merging into the main spec library. Post-archives knowledge back to Skills. Trigger on /modus:spec command or when user wants specification-driven development with testable acceptance criteria.
 allowed-tools: Read, Write, Glob, Bash
 disable: false
+supported_platforms:
+  claude:
+    status: full
+    notes: "全功能支持。delta specs 生成、冲突检测、归档合并均完整执行。"
+  codebuddy:
+    status: full
+    notes: "全功能支持，与 Claude 能力对等。"
+  cursor:
+    status: partial
+    notes: "核心 spec 流程可用（Steps 1-8），Step 9 归档后 Skill 写回需手动触发。"
+    limitations:
+      - "Step 9 知识写回：Cursor 无 post-commit hook，需手动运行 /modus:commit 触发"
+  copilot:
+    status: minimal
+    notes: "spec 流程退化为基础文档生成，无 Skill 前置更新和后置写回。"
 ---
 
-# modus-spec（OpenSpec 规范驱动开发）
+# modus-spec（规范驱动开发）
 
 **触发条件：** 用户运行 `/modus:spec [需求描述]` 时使用此 Skill。
 
-支持轻量模式：`/modus:spec --lite [描述]` 跳过 design-brief，适用于低风险小变更。
+---
 
 ## 职责
 
-规范驱动开发入口。在 `/modus:plan` 的基础上增加 OpenSpec 风格的行为规格（delta specs），明确「系统的 WHAT」而非「HOW」。通过**三级渐进加载**获取业务上下文，产出物包含 proposal、delta specs、design、tasks，归档前可选执行实现验证（verify），归档时自动检测规格冲突，合并 delta specs 到主规格库，并从中提取带类型标签的知识回写到 Skill。
-
-### 规格级别
+规范驱动开发的执行引擎。在需求实现前，先生成结构化的行为规格文档（delta specs），包含可直接转化为测试用例的 GIVEN/WHEN/THEN 场景。规格稳定后归档合并到主规格库（`modus/specs/`），作为后续 vibe/harness 的知识来源。
 
-| 模式 | 标志 | 产出物 | 适用场景 |
-|------|------|--------|---------|
-| Full（默认） | 无 | proposal + delta specs + design + design-brief + tasks | 接口契约变更、高风险、跨域需求 |
-| Lite | `--lite` | proposal + delta specs + tasks（无 design-brief） | 低风险内部逻辑变更、简单新增 |
+**适用场景：**
+- 涉及对外接口契约变更（新增/修改/废弃接口）
+- 需要可测试验收标准的功能需求
+- 高风险变更（支付/权限/多租户）需要先规格再编码
 
 ---
 
@@ -29,419 +42,250 @@ disable: false
 ### Step 0：读取项目宪法 + 断点续跑检查
 
 **读取 constitution：**
-读取 `modus/config.yaml` 的 `constitution` 字段，作为 Spec 编写的最高优先级约束。`hard_rules` 中的规则必须体现在 Scenario 的 THEN 断言中。
+读取 `modus/config.yaml` 的 `constitution` 字段，将 `hard_rules` 作为最高优先级约束贯穿整个规范流程。
 
 **断点续跑检查：**
-扫描 `modus/changes/` 目录，检查是否存在同名的 `.modus-state.yaml`：
-- 若存在且 `status: in-progress`，提示用户恢复或重新开始
-- 若用户选择继续，跳到对应未完成步骤
-
-### Step 1：Level 1 加载——读知识目录（~200 tokens）
-
-读取 `modus/knowledge-catalog.md`，了解当前可用 Skill 及状态。
-若不存在，与 vibe/plan 模式相同的降级提示。
-
-### Step 2：域匹配与确认（有则更新，无则新增）
-
-基于 catalog 目录信息，结合用户 prompt，判断涉及的业务域：
-
+扫描 `modus/changes/` 目录，检查是否存在同名的未完成变更：
 ```
-根据你的需求，我认为涉及以下业务域：
-
-✓ order（订单域）    [verified] → 将在前置步骤中更新
-✓ payment（支付域）  [proven]  → 将在前置步骤中更新
-? export（导出域）   [未初始化] → 将在前置步骤中新建
+检测到未完成的变更：{name}
+已完成：{completed 列表}
+待完成：{pending 列表}
 
-确认？
+是否继续上次的规范，还是重新开始？
 ```
 
-### Step 3：澄清用户意图（AskUserQuestion）
-
-确认域后，在规范编写前，提出 1-3 个关键澄清问题。
-
-**Spec 模式特别关注的澄清方向：**
-
-```
-为了写出准确的行为规格，我需要确认：
+---
 
-1. [行为边界] {具体业务场景的边界情况}，系统应该怎么处理？
-   （直接影响 GIVEN/WHEN/THEN 场景的编写）
+### Step 1：Level 1 加载——读知识目录（~200 tokens）
 
-2. [MODIFIED vs ADDED] 这是修改 {已有需求名称} 的行为，
-   还是新增一个独立的需求？（影响 delta spec 使用 MODIFIED 还是 ADDED）
+读取 `modus/knowledge-catalog.md`，了解当前可用 Skill 及其状态。
 
-3. [REMOVED 确认] 原有的 {已有功能} 是否明确废弃，
-   还是保留并共存？
+若不存在，输出降级提示并继续（使用平台规则文件扫描替代）。
 
-4. [验收标准] 你期望的测试 Scenario 中，有哪些边界情况必须覆盖？
+---
 
-5. [已知风险] ⚠️ Skill 中记录了：{pitfall}，Spec 中是否需要为此添加保护性场景？
-```
+### Step 2：域匹配与确认
 
-等待用户回答后，输出意图摘要：
+基于 catalog 和用户 prompt，判断涉及的业务域，展示确认：
 
 ```
-理解已确认：
-- 核心行为变更: {ADDED/MODIFIED/REMOVED 各几条}
-- 关键 Scenario: {用户明确提及的测试场景}
-- 废弃内容: {若有}
-- 项目约束: {来自 constitution 的关键规则}
-
-开始前置更新 Skill，然后生成规范文档。
+根据你的需求，以下域相关：
+✓ order（订单域）    [verified] → 将前置更新后使用
+? payment（支付域）  [proven]  → 请确认是否涉及
 ```
 
-### Step 4：前置 Skill 更新（Level 2 加载，含 hash 检查，同 /modus:plan Step 5）
-
-对每个涉及的业务域执行以下流程（**先 hash 检查，再决定是否全量更新**）：
-
-#### Step 4a：读取 Skill frontmatter（轻量操作，仅读前 20 行）
-
-读取 `.codebuddy/skills/modus-biz-{domain}/SKILL.md` 的 YAML frontmatter，提取：
-- `last_hash`：上次记录的 key_files 内容摘要
-- `key_files`：关键源文件列表
+---
 
-若 Skill 不存在，跳到 Step 4d（新建）。
+### Step 3：Skill 前置更新（hash 检查，仅 hash 不一致时全量更新）
 
-#### Step 4b：计算当前 key_files 的 hash
+对每个确认的业务域：
+1. 读取 Skill frontmatter 的 `last_hash` 和 `key_files`
+2. 计算当前 key_files 的 SHA-1 摘要
+3. hash 一致 → 跳过，仅更新 `last_referenced`
+4. hash 不一致 → 调用 `modus-skill-creator` 模式 B 增量更新
 
-使用 Bash 对 `key_files` 列出的文件内容做 SHA-1 摘要：
+---
 
-```bash
-shasum -a 1 {file1} {file2} ... | awk '{print $1}' | sort | shasum -a 1 | awk '{print $1}'
-```
+### Step 4：复杂度评估与规格级别选择
 
-- 若某个文件不存在，视为「已变化」，强制更新
-- 若 `key_files` 为空或缺失，视为「已变化」，强制更新
+评估需求复杂度，推荐规格级别：
 
-#### Step 4c：对比 hash，决定是否跳过
+| 规格级别 | 适用场景 | 产出物 |
+|---------|---------|-------|
+| **Full**（默认）| 接口契约变更、高风险变更 | proposal.md + delta specs + design-brief.md + tasks.md |
+| **Lite**（`--lite`）| 内部逻辑变更、低风险功能 | proposal.md + delta specs（精简版）|
 
+复杂度为 Complex 时，建议升级为 `/modus:harness`：
 ```
-当前 hash == last_hash（且 last_hash 非空）
-  → ✓ modus-biz-{domain} Skill 无变化（hash 匹配），跳过前置更新（节省 ~2000 tokens）
-  → 仅更新 last_referenced 日期，继续 Step 5
-
-当前 hash != last_hash  OR  last_hash 为空
-  → 进入 Step 4d 执行完整更新
+⚠️ 此需求复杂度较高（跨 3+ 域 / 涉及数据迁移），建议考虑：
+  A. 继续使用 /modus:spec（生成完整规格文档）
+  B. 升级为 /modus:harness（全自动双 Loop 流程）
 ```
 
-#### Step 4d：完整前置更新（仅在 hash 不匹配时执行）
-
-调用 `modus-skill-creator` 模式 B，执行：
-
-1. **Level 2 加载**：读取完整 SKILL.md 文件
-2. 扫描该域相关的最新代码文件（近期变更的文件）
-3. 对比 Skill 内容与代码现实，识别差异
-4. 更新 Skill 文件中过时的信息，更新 `last_referenced`、`usage_count` 和 `last_hash`
-5. 输出更新摘要：`✓ modus-biz-order Skill 已更新（新增: OrderStatus.PENDING_REVIEW | maturity: draft→verified）`
-
-若有未初始化的域，调用模式 A 新建 Skill（`last_hash` 留空，`key_files` 由 AI 填写）。
-
-### Step 5：生成规范文档
-
-基于已澄清的意图，生成文档到 `modus/changes/{name}/`。
-
-**写入状态文件：**
-创建 `modus/changes/{name}/.modus-state.yaml`：
-```yaml
-mode: spec
-name: {name}
-status: in-progress
-lite_mode: false        # --lite flag 时为 true，跳过 design-brief
-domains: [{domain1}]
-delta_stats:
-  added: 0
-  modified: 0
-  removed: 0
-tasks_completed: "0/?"
-scenarios_covered: "0/?"
-verify_status: skipped  # skipped | passed | passed_with_warnings
-completed: []
-pending: [proposal, specs, design, design-brief, tasks]  # lite_mode 时 pending 不含 design-brief
-created: {ISO8601时间戳}
-```
+---
 
-**产出物依赖：**
+### Step 5：读取现有主规格库（冲突检测准备）
 
-```
-proposal.md
-    │
-    ├──► specs/{domain}/spec.md  (delta specs)
-    │
-    └──► design.md
-              │
-              ▼
-         design-brief.md  ← 设计方案（代码开发前的精确实现指南）
-              │
-              ▼
-           tasks.md
-```
+读取 `modus/specs/{domain}/spec.md`（若存在），为后续冲突检测做准备：
+- 了解现有 Requirements 的编号体系
+- 识别可能被新需求影响的已有 Scenario
 
-**1. proposal.md** — 意图与范围（同 /plan）
+---
 
-**2. specs/{domain}/spec.md** — Delta 规格（核心差异）
+### Step 6：精准澄清问（≤ 3 个，需求清晰时可为 0）
 
-使用 ADDED/MODIFIED/REMOVED 三段式描述行为变更：
+基于已加载的 Skill 和需求描述，提出真正有歧义的问题：
 
-```markdown
-# Delta: {域名} — {功能名称}
+**必须提问的条件：**
+1. Skill 中有关联 `[pitfall]`，需确认对策
+2. 存在接口向后兼容性决策（v1 保留 or 废弃）
+3. 验收标准缺少明确的边界条件（如批量上限、并发策略）
 
-## ADDED Requirements（新增行为）
+等待用户回答后，输出意图确认摘要。
 
-### Requirement: {需求名称}
-系统 SHALL {可观测的行为描述，不涉及实现细节}。
+---
 
-#### Scenario: Happy Path — {场景名称}
-- GIVEN {前置条件}
-- WHEN {触发动作}
-- THEN {预期结果}
-- AND {附加结果}
+### Step 7：生成规格文档
 
-#### Scenario: 边界条件 — {上限/下限场景}
-- GIVEN {处于边界的前置条件}
-- WHEN {触发动作}
-- THEN {边界行为}
+确定 change 名称（kebab-case），创建目录 `modus/changes/{name}/`，生成以下文件：
 
-#### Scenario: 异常场景 — {错误处理}
-- GIVEN {前置条件}
-- WHEN {错误触发}
-- THEN 系统 SHALL 返回 {错误码} 和明确的错误提示
+#### 7-1：proposal.md（意图说明）
 
-## MODIFIED Requirements（修改行为）
+```markdown
+# Proposal: {功能名称}
 
-### Requirement: {已有需求名称}
-{新的完整描述}
-（原描述：{原来的描述}）
+## 业务意图
+{2-3 句话，说明做什么、为什么做}
 
-## REMOVED Requirements（废弃行为）
+## 影响范围
+- 域: {domain1}, {domain2}
+- 变更类型: {接口新增 / 逻辑修改 / 数据结构变更}
 
-### Requirement: {已废弃需求}
-（废弃原因：{原因}）
+## 关键约束
+{来自 constitution.hard_rules + 业务 Skill pitfall 的约束}
 ```
 
-生成 delta specs 后更新 `.modus-state.yaml` 的 `delta_stats`。
+#### 7-2：specs/{domain}/spec.md（delta specs，核心产出物）
 
-**3. design.md** — 技术方案（同 /plan）
+```markdown
+# Delta Spec: {功能名称} — {domain}
 
-**4. design-brief.md** — 设计方案（代码开发前的精确实现指南）
+## ADDED Requirements
 
-**跳过条件：** `--lite` 模式时直接跳过此步骤，在 `.modus-state.yaml` 中标记 `lite_mode: true`。
+### REQ-{domain}-{N+1}: {需求标题}
+{需求描述}
 
-调用 `modus-design-brief` Skill，传入：
-- `mode: spec`
-- `output_path: modus/changes/{name}/design-brief.md`
-- `analysis_doc: proposal.md + specs/{domain}/spec.md 内容`
-- `business_skills: 已加载的 Skill 内容`
-- `constitution: constitution 字段`
+#### Scenario: {场景名}
+- GIVEN {前置条件}
+- WHEN {操作，含具体输入}
+- THEN {预期结果，含具体输出字段和值}
 
-重点：spec 模式的 design-brief 需在节 6（边界条件）中覆盖所有 delta spec 里的 Scenario 失败路径，节 9（追踪矩阵）中每个 ADDED/MODIFIED Requirement 都必须出现。
+#### Scenario: {失败场景名}
+- GIVEN {前置条件}
+- WHEN {无效输入}
+- THEN {错误码 + 错误消息}
 
-生成后更新 `.modus-state.yaml`，追加 `design-brief` 到 `completed`。
+## MODIFIED Requirements
 
-**5. tasks.md** — 实现清单（含场景驱动的规格验证章节）
+### REQ-{domain}-{已有编号}: {需求标题}（修改）
+{修改前后对比}
 
-在 tasks.md 末尾加入**场景驱动的验证章节**——每个 TODO 项直接追踪到 delta spec 中对应的 Scenario：
+## REMOVED Requirements
 
-```markdown
-## N. 规格验证（场景驱动）
-# 每一项对应 delta spec 中的一个 Scenario，确保代码与规格一致
-
-- [ ] N.1 [Happy Path] {Scenario名称} 有对应单元测试（GIVEN: X, WHEN: Y, THEN: Z）
-- [ ] N.2 [边界条件] {上限=50} 的边界场景有单元测试，超出时返回 {错误码}
-- [ ] N.3 [异常场景] {失败回滚} 场景有集成测试，验证事务完整性
-- [ ] N.4 [接口一致性] {POST /api/v1/{domain}/xxx} 接口行为与 Scenario 一致（通过 API 测试验证）
-- [ ] N.5 [宪法约束] {constitution.hard_rules 中与本次相关的规则} 在代码中得到体现
+### REQ-{domain}-{已有编号}: {废弃理由}
 ```
 
-生成每份文档后更新 `.modus-state.yaml` 的 `completed` 列表和 `scenarios_covered`。
-
-### Step 6：可选实现验证（verify）
-
-文档生成后，询问用户是否执行实现验证（适用于代码已开发完成、准备归档前的场景）：
+**每个 Scenario 必须包含：**
+- 具体输入值（不能只说"合法数据"）
+- 具体预期输出（状态码、关键响应字段）
+- 关键的前置条件（数据库状态、权限）
 
+**冲突检测：**
+若新 delta spec 中的 MODIFIED/REMOVED 涉及主规格库中的已有 Requirement：
 ```
-规范文档已生成。是否对当前代码实现执行验证？
-
-  Y — 执行验证（推荐：确保代码与规格一致）
-  N — 跳过验证，直接进入归档（文档阶段可跳过）
+⚠️ 检测到规格冲突：
+  - REQ-order-042 (已有) 与 本次 MODIFIED 冲突
+  - 建议：将已有 REQ-order-042 标记为 deprecated，并在本次 spec 中说明替代关系
 ```
 
-若用户选择执行验证，从三个维度检查：
+#### 7-3：design-brief.md（技术方案，Full 级别）
 
-#### 维度一：完整性（Completeness）
+调用 `modus-design-brief` Skill（mode: spec，落盘输出到 design-brief.md）。
 
-检查内容：
-- `tasks.md` 中的规格验证章节每一项是否已有对应测试或代码
-- delta spec 中每个 ADDED/MODIFIED Requirement 是否有对应实现
-- 每个 Scenario 是否有对应的测试用例（单元测试或接口测试）
+#### 7-4：tasks.md（任务清单，Full 级别）
 
-```bash
-# 扫描近期修改的测试文件
-git diff --name-only HEAD~3 | grep -E 'Test\.java|Spec\.java|test.*\.py'
-```
-
-输出格式：
-```
-完整性检查：
-✓ 12/12 tasks.md 任务已完成
-✓ 3/3 ADDED Requirements 有对应代码
-⚠ Scenario "边界条件 — 批量上限 50 条" 未找到对应测试
-```
-
-#### 维度二：正确性（Correctness）
-
-检查内容：
-- 代码中的主要逻辑是否与 Scenario 的 THEN 断言一致
-- 错误处理是否覆盖 Scenario 中的异常路径
-- constitution 的 `hard_rules` 是否在代码中得到体现
+```markdown
+# Tasks: {功能名称}
 
-#### 维度三：一致性（Coherence）
+## 实现任务
 
-检查内容：
-- design.md 中的架构决策是否反映在代码结构中
-- 命名约定是否与 design.md 一致
-- 若有 design-brief.md，其追踪矩阵中每个 Requirement 是否均已实现
+- [ ] Sprint 1：{数据层任务}
+- [ ] Sprint 2：{服务层任务}
+- [ ] Sprint 3：{接口层任务}
 
-**验证输出摘要：**
+## 规格验证任务（必须，用于确认 Scenario 实现正确）
 
+- [ ] 验证 Scenario: {场景名}（测试命令: `{测试命令}`）
+- [ ] 验证 Scenario: {错误场景名}（预期: HTTP 400 + {错误码}）
 ```
-📋 实现验证结果 — {name}
-─────────────────────────────────────────
-完整性  ✓  12/12 任务已完成 | 3/3 需求有实现 | ⚠ 1 个 Scenario 缺测试
-正确性  ✓  主要逻辑与规格一致 | ✓ 错误处理完整
-一致性  ✓  架构决策已反映 | ⚠ design.md 提到事件驱动但代码使用同步调用
-
-严重问题: 0 | 警告: 2
-建议：
-1. 为 "边界条件 — 批量上限 50 条" 添加单元测试
-2. 更新 design.md 说明改为同步调用的原因，或重构为事件驱动
-
-可以归档（有警告）[Y/n]
-```
-
-验证不阻断归档，但警告需用户显式确认后方可继续。
 
-### Step 7：规格冲突检测 + 询问归档 ⏸️ 【人工审批节点】
-
-**归档前冲突检测（自动执行）：**
-
-在执行归档前，检查主规格库中是否存在冲突条目：
+---
 
-```bash
-# 检查主规格库是否存在同名 Requirement
-grep -l "### Requirement:" modus/specs/{domain}/spec.md 2>/dev/null
-```
+### Step 8：归档确认 ⏸️ 【人工审批节点】
 
-对 delta spec 中每个 MODIFIED/REMOVED Requirement，在主规格库 `modus/specs/{domain}/spec.md` 中查找同名条目：
+文档生成后，展示结果并等待用户决定：
 
 ```
-冲突检测结果：
-✓ 主规格库存在 "单个审批接口" → MODIFIED 操作可正常执行
-✓ 主规格库存在 "Remember Me"  → REMOVED 操作可正常执行
-⚠ 主规格库不存在 "批量审批订单" 的 MODIFIED 目标 → 建议改为 ADDED
-  （若此需求是全新的，请将 delta spec 中 MODIFIED 改为 ADDED）
-```
+✅ 规格文档已就绪：modus/changes/{name}/
+   proposal.md | specs/{domain}/spec.md | design-brief.md | tasks.md
 
-若检测到冲突，询问用户如何处理（修改 delta spec 或强制执行）。
+你可以：
+  [修改] 提出修改意见，更新规格文档
+  [归档] 将 delta specs 合并到主规格库 modus/specs/
+  [跳过归档] 仅保留 changes/ 下的文档，不合并主规格库
 
+等待你的指令。
 ```
-规范文档已生成：
-  modus/changes/{name}/proposal.md
-  modus/changes/{name}/specs/{domain}/spec.md  ← delta specs（ADDED:{A} MODIFIED:{M} REMOVED:{R}，共{N}个场景）
-  modus/changes/{name}/design.md
-  modus/changes/{name}/design-brief.md         ← 设计方案（{N}节 | 追踪矩阵 {N}行）[lite 模式时不生成]
-  modus/changes/{name}/tasks.md
-  modus/changes/{name}/.modus-state.yaml
-
-实现验证: {passed_with_warnings / passed / skipped}  [Step 6 结果]
-冲突检测: {通过 / N 项需确认}
-
-是否归档？归档后：
-  1. delta specs 将合并到 modus/specs/{domain}/spec.md（主规格库）
-  2. 变更文件夹移动到 modus/changes/archive/{YYYY-MM-DD}-{name}/
-```
-
-⏸️ **等待人工确认**（支持异步：可以在任意时间回复）
-
-**归档时的 delta 合并规则：**
-- `## ADDED Requirements` → 追加到主 spec 对应章节末尾
-- `## MODIFIED Requirements` → 替换主 spec 中对应的 Requirement
-- `## REMOVED Requirements` → 从主 spec 中删除对应 Requirement
 
-如果主 spec 不存在，创建新文件并填入所有 ADDED 内容。
+**归档执行（用户选择归档时）：**
+1. 将 `specs/{domain}/spec.md` 中的 ADDED 追加到 `modus/specs/{domain}/spec.md`
+2. MODIFIED 更新对应的已有 Requirement（追加修订记录，不删除原内容）
+3. REMOVED 在主规格库对应条目追加 `~~deprecated: {YYYY-MM-DD}~~` 标记
+4. 将变更目录移动到 `modus/changes/archive/{YYYY-MM-DD}-{name}/`
+5. 输出归档摘要：
+   ```
+   📚 归档完成：
+     新增 {N} 条 Requirement
+     修改 {N} 条 Requirement
+     废弃 {N} 条 Requirement
+     主规格库已更新: modus/specs/{domain}/spec.md
+   ```
 
-归档完成后更新 `.modus-state.yaml`：`status: archived`。
-
-### Step 8：后置 Skill 更新（知识提取与回写）
+---
 
-归档完成后，调用 `modus-skill-creator` 模式 C，从 delta specs 中系统性提取知识：
+### Step 9：后置 Skill 知识写回（归档后执行）
 
-1. `## ADDED Requirements` 中的新业务流程 → `[process]` 追加到业务 Skill
-2. 新增实体/字段/枚举 → `[model]` 追加到业务 Skill
-3. 新约束规则（SHALL/SHALL NOT 描述） → `[guideline]` 追加到业务 Skill
-4. Scenario 中暴露的边界条件/失败模式 → `[pitfall]` 追加到业务 Skill
-5. 更新 `modus/knowledge-catalog.md` 的 `last_referenced`
+从 proposal.md + design-brief.md 中提取可沉淀的知识，**请求用户确认后**写回 Skill（调用 `modus-skill-creator` 模式 C）：
 
-输出知识提取摘要：
 ```
-📚 知识已提取并回写到 Skill：
-- [process] order 域：新增批量审批流程（提交→校验→执行→通知）
-- [guideline] order 域：批量操作上限 50 条（来自 Scenario: 边界条件）
-- [pitfall] order 域：全批失败回滚逻辑需配合 @Transactional + 分布式锁
-- knowledge-catalog.md 已更新（order 域 maturity: draft→verified）
+📚 发现 {N} 条可沉淀到 Skill 的新知识，是否写入？[Y/n]
+  · [decision] tech-wiki：{技术决策摘要}
+  · [process] order 域：{新增业务流程}
+  · [guideline] order 域：{接口规范约束}
 ```
 
-### Step 9：多平台 Skill 同步（后置）
-
-知识提取与回写完成后，对本次涉及的业务域执行多平台同步。
-
-**逻辑：**
-
-1. 读取 `modus/config.yaml` 的 `platforms` 字段
-2. 对 Step 4 前置更新 / 新建的每个业务域，按以下规则同步：
-   - **Claude** → 写入 `.claude/agents/modus-biz-{domain}.md`（覆盖旧版本）
-   - **Cursor** → 写入 `.cursor/rules/modus-biz-{domain}.mdc`（带 frontmatter，覆盖旧版本）
-   - **Copilot** → 在 `.github/copilot-instructions.md` 中替换对应域的标记段落
-3. 若 `platforms` 只含 `codebuddy`（或字段不存在），跳过
+---
 
-**输出示例：**
+### Step 10：多平台 Skill 同步（后置）
 
-```
-📡 多平台 Skill 同步：
-✓ Claude   .claude/agents/modus-biz-order.md（已更新）
-✓ Cursor   .cursor/rules/modus-biz-order.mdc（已更新）
-✓ Copilot  .github/copilot-instructions.md（order 域段落已更新）
-```
+与 `modus-plan` Step 10 相同逻辑，对本次更新/新建的业务 Skill 执行多平台同步（根据 `modus/config.yaml` 的 `platforms` 字段）。
 
 ---
 
-## 主规格库结构
+## 产出物目录结构
 
 ```
 modus/
-├── specs/                        ← 当前系统行为的真相来源
-│   ├── order/spec.md
-│   └── payment/spec.md
-├── changes/                      ← 进行中的变更
-│   └── add-batch-approve/
-│       ├── .modus-state.yaml     ← 状态文件（断点续跑）
-│       ├── proposal.md
-│       ├── specs/order/spec.md   ← delta specs
-│       ├── design.md
-│       ├── design-brief.md       ← 设计方案（代码开发前的实现指南）
-│       └── tasks.md
-└── changes/archive/
-    └── 2026-04-20-add-batch-approve/
-        ├── .modus-state.yaml     ← status: archived
-        └── ...
+├── changes/
+│   ├── {name}/                       ← 活跃变更（未归档）
+│   │   ├── proposal.md
+│   │   ├── specs/{domain}/spec.md    ← delta specs（核心）
+│   │   ├── design-brief.md           ← 技术方案（Full 级别，由 modus-design-brief 生成）
+│   │   └── tasks.md                  ← 任务清单（Full 级别）
+│   └── archive/
+│       └── {YYYY-MM-DD}-{name}/      ← 已归档变更
+│
+└── specs/
+    └── {domain}/
+        └── spec.md                   ← 主规格库（唯一权威来源）
 ```
 
 ---
 
-## Spec 质量原则
+## 规格质量标准
 
-- Spec 描述「什么」，design 描述「怎么做」
-- 每个 Scenario 必须可测试（可直接写成自动化测试）
-- 使用 SHALL（必须）、SHOULD（应该）、MAY（可以）
-- 避免在 spec 中出现类名、方法名、框架名
-- tasks.md 的规格验证章节**必须与 Scenario 一一对应**，不得遗漏
-- constitution 的 hard_rules 必须在 Scenario 中得到体现
+- 每个 Scenario 必须有具体输入值，不能写「合法数据」
+- GIVEN/WHEN/THEN 三步缺一不可
+- 错误场景必须覆盖：必填为空、格式错误、权限不足、资源不存在
+- delta specs 中的 REQ 编号必须与主规格库保持连续不重复
+- **归档操作不可逆**，执行前必须等待用户明确确认