@modus-ai/modus 0.2.10 → 0.2.11

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

@@ -1,8 +1,17 @@
 ---
 name: modus-init
-description: Use this skill when executing /modus:init command (or /modus:init --help/--enhance/--migrate/--dry-run etc.) to scan the codebase, classify business domains, generate Business Skill files in modus/knowledge/, update knowledge-catalog.md, and sync to multi-platform adapters. Trigger on /modus:init or any of its parameter variants. (Modus v3.2)
+description: Use this skill when executing /modus:init command (or /modus:init --help/--enhance/--migrate/--dry-run etc.) to scan the codebase, classify business domains, generate Business Skill files in modus/knowledge/, update knowledge-catalog.md, and sync to multi-platform adapters. Trigger on /modus:init or any of its parameter variants. (Modus v3.3 — Router + Strategy)
 allowed-tools: Read, Write, Glob, Bash
 disable: false
+architecture: router-strategy        # v3.3 起：本文件为 Router；具体扫描 + Skill 生成委派给 strategies/{stack}-init.md
+strategy_files:
+  - strategies/java-init.md          # Spring Boot / MyBatis 后端
+  - strategies/frontend-init.md      # React / Vue / Next / Nuxt
+  - strategies/fallback-init.md      # 通用 Glob 兜底（go / python / rust / backend-node / 未识别）
+shared_files:
+  - shared/stack-detection.md        # Step 0.5 栈检测规则
+  - shared/frontmatter-spec.md       # 防腐字段规范（语言无关）
+  - shared/universal-skill-format.md # 17 节通用骨架（语言无关）
 supported_platforms:
   claude:
     status: full       # 全功能支持：SubAgent 并行扫描、多轮访谈、Bash 工具可用
@@ -10,6 +19,9 @@ supported_platforms:
   codebuddy:
     status: full       # 全功能支持
     notes: "推荐平台。与 Claude 能力对等，Skill 生成格式与 .codebuddy/ 目录结构完全兼容。"
+  continue:
+    status: full       # 全功能支持（与 CodeBuddy 同级，腾讯音乐内部 AI Coding 平台）
+    notes: "与 CodeBuddy 能力对等；目录结构 .continue/ 完全镜像 .codebuddy/，Skills/Agents/Hooks 全部支持。"
   cursor:
     status: partial    # 部分支持：无 SubAgent、无 Bash，Skill 以 .mdc 规则文件输出
     notes: "Cursor 不支持 SubAgent，init 流程退化为单 Agent 串行执行；Bash 工具不可用，目录扫描依赖 Glob/Read 工具。生成的 Skill 以 .cursor/rules/modus-biz-*.mdc 格式输出，不支持 v3/17节完整格式。"
@@ -111,13 +123,32 @@ Modus Init — 业务知识库初始化工具
 
 ## 本文件结构索引（Agent 必读）
 
-> 本文件共分三个区块，请根据当前任务按需加载，避免无效 token 消耗：
+> **v3.3 架构变更**：本文件已重构为 **Router + Strategy** 模式。原 Step 5（5 轮扫描）和 Step 8（业务 Skill 17 节模板）已抽到独立文件，实现"对外只暴露一个 `/modus:init` 命令、对内按主语言栈分流"。
 
-| 区块 | 内容 | Agent 读取时机 | 典型使用场景 |
-|------|------|----------------|------------|
-| **区块 A：执行流程**（Step 0-14） | Agent 执行 `/modus:init` 时的完整步骤指令 | **每次执行 `/modus:init` 必须完整读取** | 全新初始化、重新初始化（模式 1-4）、补全新节 |
-| **区块 B：防腐机制总览** | 防腐字段说明、双级 hash 规则、活跃度感知衰减、status 全链路图、同步副本管理规约 | 执行 Step 8 生成 Skill 前必读；执行 `/modus:verify`、`/modus:refresh` 前必读 | hash 不一致处理、status 升降级、副本同步问题排查 |
-| **区块 C：Business Skill 标准格式**（v3/17节模板） | 多语言适配说明 + 生成每个业务 Skill 时的完整格式参考 | 执行 Step 8 时按需读取对应节的格式要求；辅助命令 `/modus:verify`、`/modus:refresh` 执行时读取 | 格式参考、节内容门槛检查、信号词归属判断 |
+### 文件分工
+
+| 角色 | 文件 | 职责 |
+|------|------|------|
+| **Router**（本文件） | `templates/skills/modus-init/SKILL.md` | 参数解析、栈检测、迁移、平台同步、catalog 生成、完成回报——**栈无关的 14 步框架** |
+| **Java Strategy** | `strategies/java-init.md` | Spring Boot / MyBatis 后端的 5 轮扫描 + Java 17 节填充 |
+| **Frontend Strategy** | `strategies/frontend-init.md` | React / Vue / Next / Nuxt 的扫描 + 前端化 17 节填充（含 §3 React、§4 Vue、§5 通用前端） |
+| **Fallback Strategy** | `strategies/fallback-init.md` | Go / Python / Rust / Node 后端 / 未识别项目的简化 6 节生成 |
+| **Stack Detection** | `shared/stack-detection.md` | Step 0.5 栈检测的决策树和信号矩阵 |
+| **Frontmatter Spec** | `shared/frontmatter-spec.md` | 防腐字段规范（语言无关）+ status 生命周期 + 衰减规则 |
+| **Universal Skill Format** | `shared/universal-skill-format.md` | 17 节通用骨架（节号节名跨栈一致；节内填充按 stack 分流） |
+
+### 加载时机
+
+| 区块/文件 | Agent 何时读取 | 典型场景 |
+|-----------|----------------|---------|
+| **本文件区块 A：执行流程**（Step 0-14） | 每次执行 `/modus:init` 必读 | 全新初始化、增量更新、迁移 |
+| `shared/stack-detection.md` | Step 0.5 时读取 | 决定路由到哪个 strategy |
+| `strategies/{stack}-init.md` | Step 5、Step 8 按检测出的 `primaryStack` 加载 | 5 轮扫描、生成业务 Skill |
+| `shared/universal-skill-format.md` | Step 8 生成 Skill 时按需读取 | 17 节标准格式参考 |
+| `shared/frontmatter-spec.md` | Step 8 生成 Skill 前必读；`/modus:verify`/`/modus:refresh` 必读 | 防腐字段填写、status 升降级 |
+| **本文件区块 B：防腐机制总览** | hash 不一致排查、副本同步问题排查 | 与 `shared/frontmatter-spec.md` 互为补充（区块 B 含全链路图与同步副本规约） |
+
+> 通用知识库原则：**节号、节名、知识标签三者跨栈完全一致**；只有节内填充按 `primaryStack` 分流。这保证跨栈 monorepo 项目的 catalog 可以统一索引。
 
 ---
 <!-- ============================================================ -->
@@ -161,11 +192,66 @@ Modus Init — 业务知识库初始化工具
 检测到 --enhance <domain> 或 --enhance-all?
   是 → 跳转到 Step 2（增量更新模式）
   
-以上都无 → 执行标准全量初始化（Step 3 → Step 14）
+以上都无 → 执行标准全量初始化（Step 0.5 → Step 3 → Step 14）
 ```
 
 ---
 
+### Step 0.5：栈检测分流（v3.3 新增）★ Router 核心
+
+> **执行时机**：`Step 0` 完成后、`Step 1`/`Step 3` 之前。`--help` / `--migrate` / `--enhance` 模式下跳过本步骤（这些模式不重新扫描代码）。
+
+**目标**：探测项目主语言栈，将结果写入 `modus/config.yaml.primaryStack`，并决定 Step 5 / Step 8 加载哪个 strategy 文件。
+
+#### 执行步骤
+
+1. **读取栈检测规则文档**：使用 Read 工具读取 `templates/skills/modus-init/shared/stack-detection.md`（即「栈检测规则」单一真相来源）
+
+2. **按文档定义的决策树检测项目根**，按以下优先级（第一个命中即停）：
+   ```
+   pom.xml / build.gradle / build.gradle.kts → primaryStack=java
+   go.mod                                     → primaryStack=go
+   pyproject.toml / requirements.txt          → primaryStack=python
+   Cargo.toml                                 → primaryStack=rust
+   package.json：
+     deps 含 @nestjs/core/express/fastify/koa → primaryStack=backend-node
+     deps 含 vue/@vue/cli/nuxt/nuxt3          → primaryStack=frontend-vue
+     deps 含 react/next/@remix-run/react      → primaryStack=frontend-react
+     deps 都没                                 → primaryStack=frontend-other
+   全部都没                                    → primaryStack=fallback
+   ```
+
+3. **多栈共存（混合 monorepo）处理**：
+   - 若同时检测到多栈（如 `pom.xml` + `package.json`）：
+     - `--force` 模式：按优先级 `java > backend-node > frontend-* > go/python/rust > fallback` 自动选主栈
+     - 交互模式：按 `shared/stack-detection.md` §3.2 向用户展示选项，等待选择
+
+4. **写入 `modus/config.yaml.primaryStack`**：将检测结果持久化
+
+5. **路由声明（明确告知 Agent 后续 Step 加载哪个文件）**：
+   ```
+   primaryStack=java          → Step 5/Step 8 加载 strategies/java-init.md
+   primaryStack=frontend-react → Step 5/Step 8 加载 strategies/frontend-init.md（§3 React 子流程）
+   primaryStack=frontend-vue   → Step 5/Step 8 加载 strategies/frontend-init.md（§4 Vue 子流程）
+   primaryStack=frontend-other → Step 5/Step 8 加载 strategies/frontend-init.md（§5 通用前端）
+   其他（go/python/rust/backend-node/fallback）→ 加载 strategies/fallback-init.md
+   ```
+
+6. **向用户展示路由结果**（`--force` 时仍输出但不等待确认）：
+   ```
+   [Step 0.5 栈检测] ✓ 主栈：{primaryStack}
+     检测信号：{命中的文件/字段}
+     将使用：strategies/{stack}-init.md
+     业务 Skill 格式：v3-{stack}
+   ```
+
+#### 失败兜底
+
+- 检测过程异常（如 `package.json` 损坏）→ `primaryStack=fallback`，警告但不中断流程
+- 用户后续可通过编辑 `modus/config.yaml` 手动调整 `primaryStack` 后重跑 `/modus:init`
+
+---
+
 ### Step 1：迁移模式（--migrate）
 
 当用户运行 `/modus:init --migrate` 时执行此流程。
@@ -379,249 +465,96 @@ Step 2-7: 完成回报
 
 ---
 
-### Step 5：项目扫描与业务分类（5 轮全量扫描）
-
-启动一个「项目分析 SubAgent」，执行以下 **5 轮结构化扫描**（替代原有的简单目录读取）：
+### Step 5：项目扫描与业务分类 ★ 委派给 strategy
 
-#### 扫描前置：读取 scanRules 配置
+> **v3.3 路由模式**：本步骤的具体扫描逻辑已抽到独立 strategy 文件，根据 Step 0.5 检测到的 `primaryStack` 委派执行。Router 仅负责调度。
 
-在开始轮次 1 前，读取 `modus/config.yaml` 中的 `scanRules` 字段（若存在），构建本次扫描的规则集：
+#### 5.1 加载对应 strategy
 
-```
-scanRules.include_extensions（用户配置）
-  ||（合并）
-默认后缀：[.java, .kt, .py, .ts, .tsx, .js, .go, .rs, .php, .rb, .swift, .scala]
+根据 `modus/config.yaml.primaryStack` 加载文件：
 
-scanRules.exclude_patterns（用户配置）
-  ||（合并）
-默认排除：[target/**, build/**, dist/**, node_modules/**, .idea/**, .vscode/**,
-           generated/**, **/*Generated.java, *.lock, .git/**, .github/**]
-  ||（合并）
-项目根目录 .gitignore / .modus-ignore（若存在）
+| primaryStack | 加载文件 | 扫描方式 |
+|--------------|---------|---------|
+| `java` | `templates/skills/modus-init/strategies/java-init.md` | 5 轮 Java 全量扫描（Maven Module / 包级清单 / 方法签名 / 跨域 RPC / 表所有权） |
+| `frontend-react` | `templates/skills/modus-init/strategies/frontend-init.md`（§3 React 子流程） | 路由 + Page + Hook + API endpoint 5 轮扫描 |
+| `frontend-vue` | `templates/skills/modus-init/strategies/frontend-init.md`（§4 Vue 子流程） | SFC 解析 + Composable + Pinia + API 5 轮扫描 |
+| `frontend-other` | `templates/skills/modus-init/strategies/frontend-init.md`（§5 通用前端） | 简化 8 节生成 |
+| `go` / `python` / `rust` / `backend-node` / `fallback` | `templates/skills/modus-init/strategies/fallback-init.md` | 按目录前缀分组的简化扫描 |
 
-最终公式：扫描文件 = (include_extensions 匹配) - (exclude_patterns 排除)
-```
+#### 5.2 执行流程（统一框架）
 
-若 `scanRules` 不存在，使用全部默认值，不向用户提示。
-若存在用户自定义规则，输出一行说明：`[读取自定义扫描规则：排除 N 个额外路径，包含 M 个扩展名]`
+无论加载哪个 strategy，执行步骤一致：
 
-#### 轮次 1：模块发现
-
-**进度输出（轮次开始时）：**
-```
-[1/5 模块发现] 扫描中...
-```
+1. **使用 Read 工具读取**对应 strategy 文件
+2. **按 strategy 文档定义的"5 轮扫描"指令执行**（Java 是 Service/Mapper 语义，前端是 Hook/API 语义）
+3. **strategy 完成后，回到本 Router 继续执行**：5 轮扫描完成后的"域置信度评分矩阵"由 strategy 提供，Router 仅做汇总展示
 
-递归枚举项目中所有构建单元：
-- Java/Kotlin：递归发现所有 Maven Module（`pom.xml`）或 Gradle 子项目（`settings.gradle`）
-- Python：发现所有包目录（含 `__init__.py` 或 `pyproject.toml`）
-- 前端：发现所有独立 Node Package（`package.json`）
+#### 5.3 扫描前置：scanRules（栈无关，Router 处理）
 
-**进度输出（轮次完成时）：**
-```
-[1/5 模块发现] ✓ 发现 {N} 个构建模块 — {模块名1}, {模块名2}...
-```
+在调用 strategy 前，先合并 `modus/config.yaml.scanRules` 与栈对应的默认值（默认值由 strategy 文档提供），构建本次扫描的规则集：
 
-**失败回退：** 若无法识别任何构建单元，输出：
 ```
-[1/5 模块发现] ⚠️ 未发现标准构建文件（pom.xml/package.json），将以目录结构为单位扫描。
+最终扫描文件 = (include_extensions 匹配) - (exclude_patterns 排除) - .gitignore - .modus-ignore
 ```
 
-输出：模块列表（含模块名、路径、构建文件路径）
-
-#### 轮次 2：包级清单
-
-**进度输出（轮次开始时）：**
+若 `scanRules` 不存在，使用 strategy 默认值，不向用户提示；若存在自定义，输出：
 ```
-[2/5 包级清单] 扫描中...（{N} 个模块）
+[读取自定义扫描规则：排除 N 个额外路径，包含 M 个扩展名]
 ```
 
-对每个模块，逐包统计：
-- 文件数量
-- 类型分布（`Controller/Facade` / `Service/Manager` / `Mapper/DAO` / `Domain/Entity` / `Enum/Constant` / `DTO/VO` / `Exception/ErrorCode` / `MQ Consumer/Producer` / `XML Mapper` / `@Configuration`）
+#### 5.4 进度输出（栈无关，Router 统一规范）
 
-**输出格式：按文件数从多到少排序，完整展示不截断：**
+无论哪个 strategy，必须按以下统一格式输出进度：
 
 ```
-包级清单（共 {N} 个包）：
-
-  order（43个文件）   Controller✓ Facade✓  主要概念: 订单创建/支付/状态流转
-  payment（31个文件） Controller✓          主要概念: 支付发起/回调/退款
-  user（28个文件）    Controller✓ Facade✓  主要概念: 用户注册/登录/权限
-  inventory（12个文件）                    主要概念: 库存管理
-  diversion（3个文件）                     主要概念: 流量分发（⚠️ 小包候选）
-  singerfollower（2个文件）                主要概念: 关注关系（⚠️ 小包候选）
-  ...（全量展示，不截断）
-```
-
-**进度输出（轮次完成时）：**
-```
-[2/5 包级清单] ✓ 扫描 {N} 个文件，发现 {M} 个候选域（其中 {K} 个小包候选）
-```
-
-#### 轮次 3：域语义分析（方法签名级）
-
-按**三层递进**推断域归属，对非标准命名（如 `UserModuleV2Manager`、`BizOpportunityFacade`）也能准确识别：
-
-**层 A：包名语义词匹配**（快速初判）
-- 分析包名中的业务语义词（如 `order`、`pay`、`user`）
-- 若包名与已知业务词完全匹配，直接归入对应域（置信度 High）
-
-**层 B：公开方法签名分析**（语义细化）
-- 对 Service/Manager/Facade 类，提取所有 `public` 方法签名：
-  - 方法名（提取语义动词 + 名词，如 `confirmOrder` → 操作=confirm，对象=Order）
-  - 返回类型（List/PageResult/void → 推断是查询/写操作/事件）
-  - 参数中的 DTO/Entity 名称（如 `CreateOrderRequest` → 明确归入 order 域）
-- 从方法语义词聚类推断域：同包内方法名含有同一业务名词 ≥ 3 个 → 确认域归属
-
-**输出格式（增强版，包含代表性方法签名）：**
-
-```
-域识别结果（共 {N} 个域）：
-
-  order（订单域）  [置信度 High]
-    核心方法：createOrder(CreateOrderReq) → OrderVO
-             cancelOrder(Long orderId) → void
-             getOrderDetail(Long orderId) → OrderDetailVO
-             batchConfirmOrder(List<Long>) → BatchResultVO
-             queryOrderPage(OrderPageQuery) → PageResult<OrderVO>
-    → 关键文件：OrderService, OrderManager, OrderMapper
-
-  payment（支付域）  [置信度 Medium — 包名为 pay，方法含 payment/refund/callback]
-    核心方法：initPayment(PaymentInitReq) → PaymentVO
-             handleCallback(PayCallbackReq) → void
-    → 关键文件：PaymentService, PaymentMapper
-```
+[1/5 模块发现] 扫描中...
+[1/5 模块发现] ✓ 发现 {N} 个构建模块 — {模块名1}, {模块名2}...
 
-**层 C：回退策略**（当 A/B 均无法确定时）
-- 若类名含有多个语义域的词（如 `OrderPaymentService`），标记为"待人工确认"的跨域类
-- 若整个包只有 1-2 个文件，标记为"⚠️ 小包候选，建议合并到相近域"
-- 输出候选归属列表，等待轮次 5 跨域依赖分析后再最终确认
+[2/5 文件分类清单] 扫描中...（{N} 个模块）
+[2/5 文件分类清单] ✓ 扫描 {N} 个文件，发现 {M} 个候选域（其中 {K} 个小包候选）
 
-**进度输出（在轮次3开始处添加，在输出域清单后标注完成）：**
-```
-[3/5 域语义分析] 分析方法签名中...
-...（域识别结果）...
+[3/5 域语义分析] 分析中...
 [3/5 域语义分析] ✓ 确认 {N} 个域（{M} 个待人工确认）
-```
-
-#### 轮次 4：跨域依赖
-
-**进度输出：**
-```
-[4/5 跨域依赖] 扫描 RPC / MQ 调用链...
-```
-
-扫描 RPC 调用、MQ Topic 订阅/发布，绘制域间依赖关系：
-- `@DubboReference` / `@FeignClient` — 识别跨域 RPC 依赖
-- `eventPublisher.publish()` / `kafkaTemplate.send()` / `rocketMQTemplate.send()` — 识别 MQ 发布
-- `@KafkaListener` / `@RocketMQMessageListener` — 识别 MQ 订阅
-- `@Autowired` 或构造注入了来自其他业务包的 Service — 识别 Spring 跨域注入
-- `ApplicationEventPublisher.publishEvent()` + `@EventListener` — 识别事件驱动隐式依赖
-
-#### 轮次 5：数据库表所有权图谱（新增）
-
-**进度输出：**
-```
-[5/5 表所有权] 扫描 Mapper 文件...
-```
-
-扫描所有 XML Mapper 中的表名 + `@TableName` 注解，构建全局表归属地图：
 
-```
-扫描目标：
-  - resources/**/mapper/*.xml 中所有 <select>/<insert>/<update>/<delete> 的 FROM/INTO/UPDATE 子句
-  - @TableName("table_name") 注解（MyBatis-Plus）
-
-输出：表所有权矩阵
-  order_main        → [order]          ← 独占表（置信度+2）
-  order_item        → [order]          ← 独占表
-  payment_record    → [payment]        ← 独占表
-  user_account      → [user, payment]  ← ⚠️ 共享表，存在隐式跨域耦合
-  config_dict       → [order, user, payment] ← 公共配置表（排除出所有权统计）
-
-孤立表（无任何域 Mapper 访问）：
-  → 提示「发现 {N} 个无域归属的表，需人工决策归属：{表名列表}」
-```
-
-**进度输出（5轮全部完成后）：**
-```
+[4/5 跨域依赖] 扫描中...
 [4/5 跨域依赖] ✓ 绘制 {N} 条依赖关系
-[5/5 表所有权] ✓ 覆盖 {M} 张表，发现 {K} 个共享表
+
+[5/5 资源所有权] 扫描中...
+[5/5 资源所有权] ✓ 覆盖 {M} 个资源单元，发现 {K} 个共享资源
 
 扫描完成 ─────────────────────────────────────────────
-确认域：{N} 个 | 待确认：{M} 个 | 孤立表：{K} 张
+确认域：{N} 个 | 待确认：{M} 个 | 共享资源：{K} 个
 下一步：展示域汇总，等待用户确认（Step 6）
 ──────────────────────────────────────────────────────
 ```
 
-#### 5 轮扫描完成后：域置信度评分矩阵
-
-完成轮次 1-5 后，对每个候选域执行置信度评分（满分 10 分）：
+#### 5.5 失败兜底（Router 兜底，与 strategy 无关）
 
-> **执行时机说明**：置信度评分矩阵依赖全部 5 轮的扫描结果（尤其是轮次 4 的跨域依赖和轮次 5 的表所有权），必须在 5 轮全部完成后执行，而非轮次 3 结束后立即执行。
+- strategy 文件读取失败 → 自动降级到 `fallback-init.md`，警告但不中断
+- 扫描中途异常（如 OOM、token 超限）→ 按 strategy 中定义的"自动拆分"策略处理（详见 Step 8）
 
-| 评分维度 | 评分规则 | 说明 |
-|---------|---------|------|
-| ① 包名语义内聚度 | 高=2 / 中=1 / 低=0 | 包名与业务术语匹配度 |
-| ② 数据库表独占率 | >70%=2 / >40%=1 / <40%=0 | 独占表数 ÷ 总访问表数 |
-| ③ 对外入口完备性 | 有 Controller/Facade=2 / 仅内部=1 / 无入口=0 | 是否有对外暴露点 |
-| ④ 核心实体独立性 | 仅本域路径=2 / 跨域共享=1 / 无 Entity=0 | Domain/Entity 是否封装 |
-| ⑤ 事务边界清晰度 | 集中在本域 Service=2 / 跨域=1 / 无=0 | @Transactional 分布 |
+#### 5.6 域置信度分级（统一规范）
 
-**置信度分级处理：**
+各 strategy 输出的置信度评分（0-10）按以下统一规则分级：
 
 ```
-≥ 7 分 → [高置信度] 自动确认，在扫描结果中标 ✅
-4-6 分 → [中置信度] 标 ⚠️，在展示时突出显示，请用户确认
-< 4 分 → [低置信度] 标 ❌，强制暂停等待用户决策，不允许直接进入 Step 4
+≥ 7 分 → ✅ 自动确认
+4-6 分 → ⚠️ 用户确认（展示置信度偏低原因）
+< 4 分 → ❌ 强制暂停决策（必须人工选择处理方案：合并/拆分/重命名）
 ```
 
----
-
-**扫描结果展示（向用户展示）：**
+#### 5.7 扫描覆盖率报告（栈无关，Router 在 Step 5 末尾输出）
 
 ```
-我识别到以下业务域，请确认（将生成到 modus/knowledge/）：
-
-1. biz-order（订单域）— 订单创建、状态流转、查询        [置信度: 9/10 ✅]
-   关键文件: OrderController, OrderService, OrderMapper, OrderDomain, OrderStatus(Enum)
-   独占表: order_main, order_item（共2个）
-   
-2. biz-payment（支付域）— 支付发起、回调、退款          [置信度: 8/10 ✅]
-   关键文件: PayFacade, PayManager, PayRecordMapper, PayStatus(Enum)
-   独占表: payment_record（共1个）
-   
-3. biz-user（用户域）— 用户注册、登录、权限             [置信度: 5/10 ⚠️ 请确认]
-   关键文件: UserController, UserService, AuthManager
-   ⚠️ 该域未发现独立 Entity 类（得分偏低），请确认是否独立域？
-   
-4. biz-diversion（流量分发）— 流量路由                 [置信度: 2/10 ❌ 需要决策]
-   ❌ 低置信度：仅 2 个业务类，无 Controller/Facade，无独占表
-   建议选择：A) 合并至 user 域  B) 合并至 platform 域  C) 保持独立
-
-域间依赖：order → payment（RPC），order → user（RPC），payment → notify（MQ）
-共享表警告：user_account 被 user 和 payment 两个域访问，存在隐式耦合
-
-是否确认以上分类？（❌ 低置信度域必须先处理）
-```
-
----
-
-#### 扫描覆盖率报告（Step 2 末尾输出）
-
-```
-📊 扫描覆盖率报告
+📊 扫描覆盖率报告（基于 strategy: {primaryStack}）
   已识别域：{N} 个
-  项目总文件：{total} 个（已排除 *Test.java 和 generated/ 目录）
+  项目总文件：{total} 个（已排除 strategy 默认排除规则）
   已纳入域的文件：{covered} 个（{percent}%）
 
   未纳入文件（{uncovered} 个）：
-    排除原因 → 测试类（*Test.java）：{n} 个
-    排除原因 → 自动生成类（generated/、target/）：{n} 个
+    排除原因 → {strategy 定义的排除分类}
     排除原因 → 待确认归属：
-      - src/main/java/com/example/util/DateUtils.java
-      - src/main/java/com/example/common/PageHelper.java
+      - {文件路径列表，最多 5 个}
       （以上文件未归入任何域，需用户决策）
 
   如需将「待确认」文件归入某域，请回复：{文件路径} → {域名}
@@ -758,163 +691,143 @@ scanRules.exclude_patterns（用户配置）
 
 ---
 
-### Step 8：生成业务 Skill（Layer 2）—— 并行执行
+### Step 8：生成业务 Skill（Layer 2）★ 委派给 strategy
 
-用户确认后，**同时**为每个业务域启动独立的「Skills Builder SubAgent」（`modus-skill-creator` Skill，模式 A），并行生成所有业务 Skill 文件。各域之间完全独立，无需等待彼此完成。
+> **v3.3 路由模式**：Step 8 的具体扫描逻辑、文件分批策略、节内填充语义，已抽到独立 strategy 文件。Router 仅负责调度、并行编排、跨域回写。
 
-**目标路径（v3.1）：** `modus/knowledge/biz-{domain}/SKILL.md`
+#### 8.1 加载对应 strategy
 
-**并行调度规则：**
+按 Step 0.5 已写入的 `modus/config.yaml.primaryStack` 加载：
 
-```
-用户确认域列表后，立即并行启动 N 个 SubAgent：
+| primaryStack | 加载的 strategy 文件 |
+|--------------|---------------------|
+| `java` | `strategies/java-init.md`（含 10 类 Java 文件三批扫描） |
+| `frontend-react` / `frontend-vue` / `frontend-other` | `strategies/frontend-init.md`（前端 9 类文件 + Hook/API 协作骨架） |
+| 其他 | `strategies/fallback-init.md`（简化 6 节生成） |
+
+#### 8.2 并行调度规则（栈无关，Router 负责）
+
+用户在 Step 6 确认域列表后，立即并行启动 N 个 SubAgent：
 
-SubAgent-1 (biz-order域)   ──► 扫描订单全量文件（含Enum/MQ/Config等全10类）──► 生成 modus/knowledge/biz-order/SKILL.md
-SubAgent-2 (biz-payment域) ──► 扫描支付全量文件（含Enum/MQ/Config等全10类）──► 生成 modus/knowledge/biz-payment/SKILL.md
-SubAgent-3 (biz-user域)    ──► 扫描用户全量文件（含Enum/MQ/Config等全10类）──► 生成 modus/knowledge/biz-user/SKILL.md
+```
+SubAgent-1 (biz-{domain1}) ──► 加载 strategy ──► 全量扫描 ──► 生成 modus/knowledge/biz-{domain1}/SKILL.md
+SubAgent-2 (biz-{domain2}) ──► 加载 strategy ──► 全量扫描 ──► 生成 modus/knowledge/biz-{domain2}/SKILL.md
+SubAgent-3 (biz-{domain3}) ──► 加载 strategy ──► 全量扫描 ──► 生成 modus/knowledge/biz-{domain3}/SKILL.md
           │                                                                        │
           └──────────────────── 所有 SubAgent 完成 ─────────────────────────────┘
                                            ↓
                           主流程执行跨域依赖分析（Section 10 回写）
                                            ↓
-                                    进入 Step 6（串行）
+                                    进入 Step 9（多平台同步）
 ```
 
-**每个 SubAgent 的任务（模式 A 标准流程）：**
+无 SubAgent 能力的平台（如 Cursor）退化为单 Agent 串行执行。
 
-1. 接收域名称 + **全量文件路径列表**（来自 Step 5 轮次 2/3 的分析结果，含所有 10 类文件）
-2. 按优先级分三批扫描（**无文件数量上限，全量覆盖**）：
-   - **第一批（核心知识，必须完整扫描）**
-     - ① Controller/Facade → API 契约、权限注解
-     - ② Service/Manager → 业务规则、事务边界
-     - ③ Domain/Entity → 核心字段、业务方法
-     - ⑥ Enum/Constant → 完整枚举值和业务含义
-   - **第二批（细节知识，全量扫描）**
-     - ④ Mapper/DAO → 数据操作模式
-     - ⑤ XML Mapper → 关键 SQL（JOIN/子查询/复杂条件）
-     - ⑦ DTO/VO/Request/Response → 字段约束、校验规则
-   - **第三批（扩展知识，按 git 最近修改时间排序，优先扫描最新文件）**
-     - ⑧ Exception/ErrorCode → 错误码体系
-     - ⑨ MQ Consumer/Producer → 消息契约、幂等性保障
-     - ⑩ @Configuration → 开关配置、扩展点注册
-3. 提取：核心实体、业务规则、API 契约、状态机、错误码、关键 SQL 模式、扩展点、**业务不变量**（新增）
-4. 生成标准 17 节格式的 Skill 文件（含 `key_files`、`status: draft`、`format_version: v3`）
+#### 8.3 每个 SubAgent 的任务（统一规范）
 
-**Context 超限自动保护策略（替换原有硬限制）：**
+1. **接收**域名称 + 全量文件路径列表（来自 Step 5 strategy 的扫描结果）
+2. **使用 Read 工具读取**：
+   - `templates/skills/modus-init/strategies/{stack}-init.md`（栈特化扫描指南 + 17 节填充重点）
+   - `templates/skills/modus-init/shared/universal-skill-format.md`（17 节通用骨架，节号节名跨栈一致）
+   - `templates/skills/modus-init/shared/frontmatter-spec.md`（防腐字段规范）
+3. **按 strategy 文档的"文件分批扫描"指令执行**（各栈分批顺序不同，Java 是 Controller→Service→Mapper→Enum→...，前端是 Page→Hook→API→Type→...）
+4. **生成符合 17 节通用骨架的业务 Skill 文件**：
+   - 节号、节名、知识标签**严格遵循** `shared/universal-skill-format.md`（跨栈一致）
+   - 节内填充语义按 strategy 的"17 节填充指南"分流
+   - frontmatter 严格遵循 `shared/frontmatter-spec.md`
+5. **目标路径**：`modus/knowledge/biz-{domain}/SKILL.md`
+
+#### 8.4 Context 超限自动保护策略（栈无关）
 
-```
 当 token 预算不足（预计超出上下文窗口）时：
-  → 自动拆分：启动 SubAgent-A 扫描第一批 + 第二批文件
-              启动 SubAgent-B 扫描第三批文件（含剩余第二批）
-  → 合并：两个 SubAgent 完成后，由主流程执行知识合并：
-          - SubAgent-A 的结果作为 Skill 主体（Section 1-9）
-          - SubAgent-B 的补充结果追加合并（Section 10-17 + 知识条目去重）
-  → 在 Skill 末尾标注：「[两段合并扫描: 批次A={N}个 + 批次B={M}个，共 {N+M} 个文件]」
+
+```
+→ 自动拆分：SubAgent-A 扫描第一批 + 第二批文件
+            SubAgent-B 扫描第三批文件（含剩余第二批）
+→ 合并：两个 SubAgent 完成后，由主流程执行知识合并：
+        - SubAgent-A 的结果作为 Skill 主体（Section 1-9）
+        - SubAgent-B 的补充结果追加合并（Section 10-17 + 知识条目去重）
+→ 在 Skill 末尾标注：「[两段合并扫描: 批次A={N}个 + 批次B={M}个，共 {N+M} 个文件]」
 
 当两段都超限时（超大域 > 200 个文件）：
-  → 按域内子包进一步拆分（如 biz-order-core / biz-order-query / biz-order-settle）
-  → 提示用户是否手动拆分为多个子域，或接受分段扫描
+→ 按域内子包进一步拆分（如 biz-order-core / biz-order-query / biz-order-settle）
+→ 提示用户是否手动拆分为多个子域，或接受分段扫描
 ```
 
-**废除所有「⚠️ 未覆盖文件」提示块**，替换为：
+#### 8.5 Section 10 跨域依赖回写（所有 SubAgent 完成后，主流程执行）
+
+所有并行 SubAgent 完成后，主流程统一执行一轮跨域依赖回写：
+
+1. 汇总 Step 5 strategy 的"轮次 4 跨域依赖"扫描结果
+2. 对每个 Skill 的 Section 10（跨域依赖）填入 upstream / downstream
+3. 同步更新 frontmatter 的 `upstream_skills` 和 `downstream_skills` 字段
+4. 执行 upstream/downstream 双向同步（详见 `modus-skill-creator` Step 7 扩展算法）
+
+#### 8.6 聚合等待（输出格式栈无关）
 
 ```
-✓ {domain} 域已完成全量扫描（共 {N} 个文件，第一批 {A} 个 + 第二批 {B} 个 + 第三批 {C} 个）
+✓ modus/knowledge/biz-{domain1} 已生成（v3-{stack}/17节，{N1}个key_files，{M1}条规则，{K1}个API/endpoint）
+✓ modus/knowledge/biz-{domain2} 已生成（v3-{stack}/17节，{N2}个key_files，{M2}条规则，{K2}个API/endpoint）
+
+跨域依赖 Section 10 回写完成：
+  biz-{domain1}.upstream_skills   = [biz-{domainX}, biz-{domainY}]
+  biz-{domain2}.downstream_skills = [biz-{domainZ}]
 ```
 
-**Section 10 跨域依赖回写（所有 SubAgent 完成后，主流程执行）：**
+---
+
+### Step 8 补充：frontmatter 规范 ★ 委派给 shared
+
+> 所有栈通用的 frontmatter 防腐字段规范（基础元数据、防腐核心、key_files、质量评分、跨域依赖、外部依赖）已抽到 `shared/frontmatter-spec.md`。Step 8 SubAgent 必须在生成 Skill 前读取该文件。
+
+#### 8补.1 必读文件
 
-所有并行 SubAgent 完成后，主流程统一执行一轮跨域依赖分析：
-1. 汇总 Step 5 轮次 4 的跨域依赖关系图
-2. 对每个域 Skill 的 Section 10 进行回写，填入上游依赖域和下游被依赖域
-3. 同步更新各 Skill frontmatter 的 `upstream_skills` 和 `downstream_skills` 字段
-4. 执行 upstream/downstream 双向同步（详见 `modus-skill-creator`（SubAgent 00）Step 7 扩展算法）
+`templates/skills/modus-init/shared/frontmatter-spec.md` 定义：
+- 一、基础元数据字段（含跨栈通用的 `stack` 字段）
+- 二、防腐机制核心字段（`last_hash` / `file_hashes` / `usage_count` 等）
+- 三、key_files 填写通则（具体优先级清单见各 strategy）
+- 四、质量评分字段
+- 五、跨域依赖字段
+- 六、外部依赖感知字段（按栈而异：Java 从 pom.xml；前端从 package.json）
+- 七、frontmatter 模板（语言无关参考）
+- 八、Status 生命周期与衰减规则
+- 九、同步副本管理规约
 
-**聚合等待：**
+#### 8补.2 关键约束（Router 强制校验）
+
+主流程在汇总 SubAgent 输出前，必须校验每个 Skill 的 frontmatter 完整性：
 
 ```
-✓ modus/knowledge/biz-order   已生成（v3/17节，18个key_files，6条业务规则，5个API，状态机含4个状态）
-✓ modus/knowledge/biz-payment 已生成（v3/17节，12个key_files，5条业务规则，3个API，⚠️ 共87个文件，已覆盖50个）
-✓ modus/knowledge/biz-user    已生成（v3/17节，10个key_files，4条业务规则，6个API）
+对每个 SubAgent 产出的 modus/knowledge/biz-{domain}/SKILL.md：
 
-跨域依赖 Section 10 回写完成：
-  biz-order.upstream_skills   = [biz-payment, biz-user]
-  biz-payment.downstream_skills = [biz-order, biz-refund]
-```
-
-### Step 8 补充：生成 Business Skill 时必须填写完整 frontmatter（防腐机制核心）
-
-在生成每个业务 Skill（`.codebuddy/skills/modus-biz-{domain}/SKILL.md`）时，**必须**在 frontmatter 中填写以下**完整字段清单**。这些字段是知识防腐机制的核心，缺一不可：
-
-#### 一、基础元数据字段（必填）
-- `name`: Skill 唯一标识符（与目录名一致）
-- `description`: 一句话描述，必须包含 `[MODUS:BIZ]` 标记
-- `version`: 语义化版本号（初始 1.0.0）
-- `updated`: 最后更新日期（YYYY-MM-DD）
-- `status`: 成熟度状态（初始 draft）
-- `format_version`: 节结构版本（当前 v3）
-- `stale_after_days`: 过期天数阈值（默认 90）
-
-#### 二、防腐机制核心字段（必填，缺少则无法检测代码变更）
-- **`last_referenced`**: 最后引用时间（初始值 = `updated` 日期）
-  - 用途：计算知识衰减，超过 `stale_after_days` 自动降级
-- **`usage_count`**: 使用次数（初始值 = 0）
-  - 用途：成熟度升级判定（draft→verified→proven）
-- **`last_hash`**: 全局 SHA-1（按区块 B 标准算法：对每个文件单独 SHA-1，将「路径:SHA-1」对按文件路径字母序排序后拼接，再整体计算 SHA-1）
-  - 用途：**快速比对**入口——先比对全局 hash，一致则跳过；不一致时展开 `file_hashes` 逐文件比对，精准输出「变更文件清单」
-  - 计算时机：**init 生成 Skill 时即计算并写入**；后续命令引用时重新计算并比对
-  - ⚠️ **所有命令必须使用统一算法**，详见下方「标准 hash 计算算法」区块
-- **`file_hashes`**: 文件级 hash map（`{路径: SHA-1}` 格式，与 `key_files` 中每个文件一一对应）
-  - 用途：全局 hash 不一致时逐文件展开比对，精准定位哪个文件发生了变更，而非笼统标为 stale
-  - 计算时机：与 `last_hash` 同步计算写入；key_files 中每个文件单独计算 SHA-1
-- **`last_verified_by`**: 最后确认人（初始值 = ""，留空）
-  - 用途：记录人工验证信息，升为 verified 时填写
-- **`verified_at`**: 最后验证日期（初始值 = ""，留空）
-  - 用途：记录人工验证时间，由 `/modus:verify` 在升为 verified 时自动写入（YYYY-MM-DD 格式）
-
-#### 三、key_files 填写规则（最多 20 个，用于 hash 检测）
-- 上限 **20 个**文件（覆盖全部 10 类文件类型）
-- 按以下优先级选取（满 20 个时从后往前截断）：
-  - **优先级 1（必选）**：Service、Manager、Mapper/DAO、Domain/Entity
-  - **优先级 2（强烈建议）**：Enum/Constant（状态/类型枚举）、Exception/ErrorCode
-  - **优先级 3（有则加入）**：MQ Consumer/Producer、@Configuration
-- 对每个文件单独计算 SHA-1，按「路径:SHA-1」字母序排序后整体 SHA-1 得到 `last_hash`（禁止内容直接拼接，详见区块 B）
-- 确保 Enum/MQ/ErrorCode/Config 的变化能被 hash 检查感知
-
-#### 四、质量评分字段（必填，用于知识库质量报告）
-- **`domain_confidence`**: 本域的置信度评分（0-10），来自 Step 5 置信度评分矩阵
-- **`invariant_count`**: 生成的业务不变量条目数（Section 15）
-- **`glossary_size`**: 领域词汇表条目数（Section 16）
-- **`hidden_knowledge_rate`**: 隐性知识补全率（0-100，来自 Step 7 访谈问卷）
-- **`contract_version`**: 本域对外暴露接口的当前版本（初始 "1.0"）；接口升级时更新，下游调用域在自己的 Section 10 中记录此版本号
-
-#### 五、跨域依赖字段（由 Section 10 回写阶段自动填入）
-- **`upstream_skills`**: 本域依赖的其他域 Skill 列表
-- **`downstream_skills`**: 依赖本域的其他域 Skill 列表
-- **`stale_cascade`**: 联动失效标记（初始 false）；当任一 upstream_skills 的 hash 变更时自动置为 true
-
-#### 六、外部依赖感知字段（新增，init 自动从 pom.xml/package.json 提取）
-- **`external_deps`**: 本域规范依赖的外部库版本范围（map 格式）
-  - 计算时机：init 生成 Skill 时自动扫描 `pom.xml` 或 `package.json`，提取该域代码中 import 频率最高的第三方库
-  - 格式：`{lib-name}: "semver-range"` — 如 `spring-boot: "~2.7"`、`mybatis-plus: ">=3.5"`
-  - 衰减规则：当 `pom.xml` / `package.json` 中被记录的库发生 **major version 升级**（如 2.x → 3.x）时，自动将本 Skill 降级为 `stale`，并追加注释 `⚠️ 外部依赖 {lib} 升级（{old} → {new}），规范需验证`
-  - 检测时机：`/modus:init`（含 `--lint` 模式）及 `modus update` 执行时
-
-  **自动提取逻辑：** 对每个域，扫描其 `key_files` 中 import 语句，统计来自 `pom.xml` 中 `<dependencies>` 的第三方库（排除 java.*、springframework.*）引用频次，取前 5 个高频库记录版本范围。
-
-  **示例：**
-  ```yaml
-  external_deps:
-    spring-boot: "~2.7"         # 整个项目级别的关键框架
-    mybatis-plus: ">=3.5 <4.0"  # 该域 Mapper 依赖
-    dubbo: "~3.1"               # 该域跨域 RPC 依赖
-  ```
-
-**⛔ 重要提示：** 如果 frontmatter 缺少上述任一防腐字段（特别是 `last_referenced`、`usage_count`、`last_hash`、`file_hashes`、`key_files`），将导致：
-- 无法自动检测代码变更
-- 无法触发 Skill 更新
-- 无法计算知识衰减
-- 防腐机制完全失效
+强制项检查：
+  ✓ name / description / version / updated / status / format_version / stack
+  ✓ stale_after_days / last_referenced / usage_count
+  ✓ last_hash / file_hashes / key_files
+  ✓ last_verified_by / verified_at
+  ✓ domain_confidence / invariant_count / glossary_size / hidden_knowledge_rate / contract_version
+  ✓ upstream_skills / downstream_skills / stale_cascade
+  ✓ external_deps
+
+任一字段缺失：
+  → 自动补 "" 或 0 占位，不允许生成不完整 Skill
+  → 在汇总报告中标 ⚠️ "{domain}: frontmatter 字段 {field} 由 Router 自动补全为占位值，建议手动核对"
+```
+
+#### 8补.3 标准 hash 计算算法
+
+> 所有命令（init / verify / refresh / vibe / plan / spec / harness）**必须使用同一算法**：
+
+```bash
+# 第一步：对 key_files 中每个文件单独计算 SHA-1（写入 file_hashes）
+# 第二步：将「文件路径:SHA-1」对按文件路径字母序排序后拼接，再整体计算 SHA-1，得到 last_hash
+
+for f in $(echo "{key_files}" | tr ' ' '\n' | sort); do
+  echo "$(shasum -a 1 "$f" | awk '{print $1}'):$f"
+done | shasum -a 1 | awk '{print $1}'
+```
+
+> ⛔ **禁止使用「内容拼接后整体计算」的方式**——受文件顺序影响，且无法与 file_hashes 兼容。详见 `shared/frontmatter-spec.md` §标准 hash 计算算法。
 
 ---
 
@@ -1027,7 +940,6 @@ alwaysApply: false
 
 ---
 
-
 ### Step 11：生成技术知识 Skill（Layer 1）
 
 **目标路径（v3.1）：** `modus/knowledge/_tech-wiki/SKILL.md`
@@ -1194,6 +1106,7 @@ flowchart TD
         DRAFT -->|"/modus:verify\n满足对应门槛"| VERIFIED
         VERIFIED -->|"usage_count≥2\n不同工作流"| PROVEN
         PROVEN -.->|"超过衰减阈值"| VERIFIED
+        PROVEN -.->|"超过衰减阈值"| STALE_S
         VERIFIED -.->|"超过衰减阈值"| STALE_S
         STALE_S -->|"/modus:refresh"| DRAFT
         STALE_S -.->|"超过stale_after_days"| ARCHIVED
@@ -1353,454 +1266,47 @@ name: modus-biz-{domain}
 
 ---
 <!-- ============================================================ -->
-<!-- 区块 C：Business Skill 标准格式参考（执行 Step 5 时按需读取）-->
+<!-- 区块 C：Business Skill 标准格式（v3.3 起 → shared/universal-skill-format.md）-->
 <!-- ============================================================ -->
 
-## Business Skill 标准格式参考（v3.1 / 17节）
+## Business Skill 标准格式 ★ 委派给 shared
 
-### 多语言适配说明
+> **v3.3 路由模式**：业务 Skill 的 17 节标准格式已抽到独立的"通用 17 节骨架"文件，强调**节号、节名、知识标签三者跨栈完全一致**——这是通用知识库的核心契约。
 
-本模板以 **Java + Spring Boot + MyBatis** 为默认实现（最常见的企业 Java 技术栈）。对于其他语言/框架的项目，按以下规则调整：
+### C.1 必读文件
 
-| 调整点 | Java（默认） | Go + Gin/gRPC | Python + FastAPI |
-|--------|------------|--------------|-----------------|
-| **Section 3 字段表** | Java 类型（`Long`、`String`） | Go 类型（`int64`、`string`） | Pydantic 模型字段（含 `Field(...)` 校验） |
-| **Section 6 特有模式** | `AopContext.currentProxy()`、`@Transactional`、`BaseRpcResponse` | 中间件链（`middleware`）、`defer` 错误处理、gRPC status codes | `async/await` 模式、依赖注入（`Depends()`）、Pydantic 校验器 |
-| **Section 7 代码示例** | Java 类风格 | Go 函数风格（接收者方法） | Python async 函数风格 |
-| **Section 8 状态机** | 包含 `@Transactional` 注解 | 包含数据库事务块（`db.Begin()`/`tx.Commit()`） | 包含 SQLAlchemy 事务上下文 |
-| **Section 12 SQL 模式** | MyBatis XML Mapper | GORM / sqlx 查询 | SQLAlchemy ORM / 原生 SQL |
-| **key_files 文件类型** | `.java` | `.go` | `.py` |
+`templates/skills/modus-init/shared/universal-skill-format.md` 提供：
 
-> **操作指引**：当 Step 2 检测到项目为 Go/Python 项目时，生成 Business Skill 前须先调整以上差异项，其余节格式保持不变。
+- **17 节总览表**：节号 / 节名 / 知识标签（跨所有栈一致）
+- **跨栈语义对齐表**：节内填充按栈分流（Java=Service+MyBatis 语义；前端=Hook+API 语义；Go=Handler 语义；Python=Pydantic 语义）
+- **17 节标准 Markdown 模板**：所有 strategy 在 Step 8 复用本模板
+- **节级最低内容门槛**：用于 `/modus:verify` 的自检规则
 
----
-
-```markdown
----
-name: biz-{domain}
-description: "[MODUS:BIZ] {中文域名}业务知识 — {核心职责一句话}"
-version: 1.0.0
-updated: {YYYY-MM-DD}
-status: draft               # draft | verified | proven | stale | archived
-format_version: v3          # v1=7节 | v2=14节 | v3=17节（当前默认，含不变量/词汇表/新人指南）
-stale_after_days: 90        # 超过此天数自动降为 stale（默认 90 天）
-last_referenced: {YYYY-MM-DD}
-usage_count: 0
-last_hash: ""               # 全局 SHA-1（key_files 所有内容拼接后计算）；init 时写入，引用时快速比对
-file_hashes: {}             # 文件级 hash map：{路径: SHA-1}，与 key_files 一一对应；全局 hash 不一致时展开精准比对
-last_verified_by: ""        # 最后确认人（升为 verified 时填写）
-domain_confidence: 0        # 域置信度评分（0-10），来自 Step 2 评分矩阵
-invariant_count: 0          # Section 15 业务不变量条目数
-glossary_size: 0            # Section 16 领域词汇表条目数
-hidden_knowledge_rate: 0    # 隐性知识补全率（0-100），来自 Step 4 访谈问卷
-contract_version: "1.0"     # 本域对外暴露接口的当前版本；升级接口时同步更新，下游调用域在 Section 10 中记录此版本
-upstream_skills:            # 本 Skill 在 Section 10 中依赖的其他域 Skill
-  - biz-payment
-  - biz-user
-downstream_skills:          # 依赖本域的其他 Skill（被依赖方）
-  - biz-refund
-key_files:                  # 关键源文件列表，用于 hash 检查（最多 20 个，覆盖全 10 类文件）
-  # 优先级 1：核心业务逻辑（必选）
-  - src/.../service/{Domain}Service.java
-  - src/.../manager/{Domain}Manager.java
-  - src/.../dao/{Domain}CustomMapper.java
-  - src/.../domain/{Domain}.java
-  # 优先级 2：状态与规则（强烈建议）
-  - src/.../enums/{Domain}Status.java
-  - src/.../enums/{Domain}Type.java
-  - src/.../exception/{Domain}Exception.java
-  # 优先级 3：消息与配置（有则加入）
-  - src/.../mq/{Domain}Consumer.java
-  - src/.../mq/{Domain}Producer.java
-  - src/.../config/{Domain}Config.java
----
+### C.2 多语言节内填充按栈分流
 
-# {中文域名}业务知识
+各 strategy 文件（`strategies/{stack}-init.md`）提供本栈的"17 节填充指南"，定义节内具体填什么（按栈而异），但**不允许新增/删除/重命名节标题**。
 
-> 由 Modus Skills Builder 自动生成。[MODUS:BIZ]
+| 节 | Java 填充重点 | 前端填充重点 |
+|---|------------|-------------|
+| 2 核心实体 | Entity / Domain 类 + Java 类型 | TS interface / Zod schema + TS 类型 |
+| 5 API 契约 | 本域**对外暴露**的 REST/RPC | 本域**调用**的后端 endpoint |
+| 6 项目特有模式 | `@Transactional` + 同类调用陷阱 + 分布式锁 | Hook 命名 + 状态管理选型 + 错误边界 |
+| 12 关键数据访问模式 | XML Mapper SQL JOIN/索引 | API debounce/缓存/重试/取消/乐观更新 |
+| 13 开发陷阱 | 同类事务失效 + 枚举存 name() | Closure / 依赖数组 / SSR Hydration |
 
----
+> 完整对照见 `shared/universal-skill-format.md` § 跨栈语义对齐表。
 
-> **渐进加载模式（Agent 按任务类型选择，降低 token 消耗）：**
->
-> | 模式 | 读取范围 | 预估 token | 适用场景 |
-> |------|---------|-----------|---------|
-> | **极简模式** | Section 1、2、15 | ~500 tokens | 快速了解业务边界和不变量约束 |
-> | **开发模式** | Section 1-8、10 | ~1500 tokens | 新增功能、接口开发 |
-> | **审查模式** | Section 3、8、13、15 | ~1000 tokens | Code Review、架构评审 |
-> | **排查模式** | Section 9、13 + Section 8 | ~600 tokens | 线上 Bug 排查、异常分析 |
-> | **完整模式** | 全量（Section 1-17） | ~3500 tokens | 首次接触本域、生成设计文档 |
->
-> **员工速读导航：**
-> 初次接触本域 → 推荐阅读顺序：**Section 16（词汇表）→ Section 17.B（新人手册）→ Section 8（状态机）→ Section 3（业务规则）**
-> 排查线上问题 → 重点读：**Section 9（错误码）→ Section 13（开发陷阱）→ Section 15（业务不变量）**
->
-> **Skill 状态：** `[SKILL_STATUS]` | **最后更新：** `[UPDATED]` | **hash：** `[HASH_PREFIX]`
-> 若 status 为 `stale`，禁止直接引用，先运行 `/modus:refresh {domain}`
+### C.3 frontmatter 规范（防腐机制）
 
----
+frontmatter 字段规范不在本区块——见 **`shared/frontmatter-spec.md`**（语言无关）和 Step 8 补充。
 
-## 1. 域概述
+### C.4 Skill 文件末尾追加"更新摘要"（栈无关）
 
-{业务域的职责边界和核心价值，2-3 句话，人类可读}
+每次 SubAgent 生成或刷新 Skill 时，必须在文件末尾追加：
 
-**边界说明：**
-- 属于本域：{列举主要职责}
-- 不属于本域：{明确排除的职责}
-
-## 2. 核心实体 [model]
-
-| 实体名 | 中文名 | 说明 | 关键字段 |
-|--------|--------|------|----------|
-| Order  | 订单   | ...  | id, status, tenantId, amount |
-
-### 重要枚举 [model]
-
-\`\`\`java
-// OrderStatus — 订单状态
-CREATED(1, "已创建"),
-PAID(2, "已支付"),
-COMPLETED(3, "已完成"),
-CANCELLED(4, "已取消")
-\`\`\`
-
-## 3. 业务规则 [process] [guideline]
-
-**Section 3 子节划分规范（必须按此结构组织，禁止混写）：**
-
-### 核心字段说明
-
-Section 3 最低内容门槛：每个核心字段必含：Java 类型、是否非空、业务含义、关联枚举（如有）
-
-| 字段 | Java 类型 | 非空 | 业务含义 | 关联枚举 |
-|------|----------|------|----------|----------|
-| {fieldName} | {类型} | ✓/- | {业务含义} | {枚举类名，无则-} |
-
-### 业务流程规则 [process]
-
-- [process] {流程规则：如 订单状态只能按 CREATED→PAID→COMPLETED 单向流转}
-
-### 推荐做法 [guideline]
-
-- [guideline] {推荐做法：如 退款金额必须 ≤ 原始支付金额，在 Service 层校验}
-
-### 架构决策 [decision]
-
-- [decision] {架构决策：如 选择 MQ 异步通知而非同步 RPC，原因是解耦和削峰}
-
-> **⚠️ 内容边界约束（含信号词分流指引）：**
->
-> 当不确定某条内容该写在哪个 Section 时，根据以下**信号词**判断归属：
->
-> | 信号词模式 | 正确归属 | 典型例子 |
-> |----------|---------|---------|
-> | 「必须/禁止 + 违反=Bug/生产事故」 | Section 15 `[invariant]` | 「退款金额必须 ≤ 原始支付金额，否则为严重 Bug」 |
-> | 「推荐/建议/最佳实践」 | Section 3 `[guideline]` | 「建议在 Service 层做二次校验，而非只依赖前端」 |
-> | 「如果 A 发生则执行 B 流程」 | Section 3 `[process]` | 「支付超时后订单状态自动流转至 CANCELLED」 |
-> | 「选择方案 A 而非 B，因为...」 | Section 3 `[decision]` | 「选用 MQ 异步通知而非同步 RPC，原因是解耦削峰」 |
-> | 「曾经踩过/容易犯/易错点」 | Section 13 `[pitfall]` | 「曾因未加分布式锁导致重复订单，教训：必须加锁」 |
-> | 「新人首次开发前需了解/开发时注意」 | Section 17 | 「新人必读：状态枚举只存 code 值而非 name()」 |
->
-> - `[process]`/`[guideline]`/`[decision]` 写本节，`[pitfall]` 写 Section 13，`[invariant]` 写 Section 15
-> - 禁止在 Section 3 中混入「不变量」内容（如「金额必须 > 0」——这是约束而非规则，属 Section 15）
-> - 若某子节无内容，可省略该子节标题
-
-## 4. 关键文件索引 [model]
-
-| 层次 | 类名 | 路径 | 说明 |
-|------|------|------|------|
-| Controller | OrderController | src/.../controller/OrderController.java | 订单 REST 接口 |
-| Service | OrderService | src/.../service/OrderService.java | 订单核心逻辑 |
-| Mapper | OrderMapper | src/.../dao/OrderMapper.java | 订单 DB 操作（注意：在 dao 包下）|
-| Domain | Order | src/.../domain/Order.java | 订单领域对象 |
-
-## 5. API 契约 [model]
-
-Section 5 最低内容门槛：每个接口必含：入参校验规则、成功返回结构、错误码列表、是否需要幂等、权限注解值
-
-| 方法 | 路径 | 说明 | 关键参数 | 权限注解 | 幂等 |
-|------|------|------|----------|----------|------|
-| POST | /api/v1/orders | 创建订单 | amount(必填,>0), productId(必填) | @UserAuthorization | 是（防重token） |
-| GET | /api/v1/orders/{id} | 查询订单 | id(必填) | @UserAuthorization | - |
-
-## 6. 项目特有模式 [decision] [guideline]
-
-- [guideline] 事务使用 `AopContext.currentProxy()` 解决同类调用问题（avoid: @Transactional 直接同类调用）
-- [guideline] 分布式锁使用 `@DistributedLock` 注解，key 格式为 `{domain}:{id}`
-- [guideline] 响应统一用 `BaseRpcResponse.build(data)` 包装
-
-## 7. 典型代码示例
-
-**Section 7 最低内容门槛：**
-- 示例代码必须来自实际扫描的源码（不能是纯伪代码框架）
-- 每段示例必须附带关键步骤的内联说明注释
-- 至少包含 1 个「写入/变更」场景 + 1 个「查询/权限」场景（若存在）
-- 示例中必须体现 Section 6 中列出的项目特有模式（如 AopContext、BaseRpcResponse 等）
-
-\`\`\`java
-// 订单创建的标准模式（来自 OrderService.createOrder()）
-public OrderDTO createOrder(CreateOrderRequest request) {
-    // 1. 参数校验（Service 层，非 Controller 层）
-    validateCreateRequest(request);
-    // 2. 业务校验（余额、库存、限购等）
-    checkBusinessRules(request);
-    // 3. 创建 Domain 对象（领域逻辑封装在 Domain 中，不直接操作 Entity）
-    Order order = Order.create(request);
-    // 4. 持久化（通过 Mapper，注意：Mapper 必须在 dao 包下）
-    orderMapper.insert(order);
-    // 5. 发送 MQ 通知（异步，不影响主流程事务）
-    orderEventPublisher.publish(new OrderCreatedEvent(order));
-    // 6. 返回 DTO（使用 BaseRpcResponse 包装）
-    return BaseRpcResponse.build(OrderConverter.toDTO(order));
-}
-\`\`\`
-
-## 8. 状态机 [process]
-
-**前置检测条件：** 域中存在含 `status`/`state` 字段的 Entity 才生成本节；否则整节省略，禁止填占位符。
-
-Section 8 最低内容门槛：每条转换必含：起始状态、目标状态、触发条件、触发方法名、是否有事务保护
-
-\`\`\`mermaid
-stateDiagram-v2
-    [*] --> CREATED : createOrder() @Transactional
-    CREATED --> PAID : payOrder() 支付成功回调 @Transactional
-    PAID --> COMPLETED : completeOrder() 确认收货 @Transactional
-    PAID --> REFUNDING : applyRefund() 申请退款
-    REFUNDING --> REFUNDED : processRefund() @Transactional
-    CREATED --> CANCELLED : cancelOrder() 超时/主动取消 @Transactional
-    PAID --> CANCELLED : cancelOrder() 支付后取消（触发退款）
-    CREATED --> CREATE_FAILED : [异常流] 创建失败 (虚线)
-    PAID --> PAY_FAILED : [异常流] 支付失败回调 (虚线)
-\`\`\`
-
-> **图例说明：** 实线 = 正常流转；虚线 = 异常流/超时流（在实际 Mermaid 中用 `-->` 配合状态名区分，说明见下方子节）
-
-### 正常流转表
-
-| 起始状态 | 目标状态 | 触发条件 | 触发方法 | 事务保护 |
-|---------|---------|---------|---------|---------|
-| CREATED | PAID | 支付成功回调 | payOrder() | ✓ @Transactional |
-| PAID | COMPLETED | 用户确认收货 | completeOrder() | ✓ @Transactional |
-
-### 异常流（失败态处理）
-
-**前置检测条件：** 域中存在 `FAILED`/`ERROR`/`EXCEPTION` 类后缀状态，或 try-catch 中有状态变更操作，才生成本子节；否则省略。
-
-| 起始状态 | 失败目标状态 | 触发条件 | 触发方法 | 失败后处理 |
-|---------|-----------|---------|---------|----------|
-| CREATING | CREATE_FAILED | 数据库写入异常/库存不足 | createOrder() catch 块 | 记录失败原因，前端展示错误信息 |
-| PAYING | PAY_FAILED | 支付网关超时/余额不足 | payOrder() catch 块 | 订单回退可支付状态，允许重新支付 |
-
-> 若无失败态枚举值，写「暂无发现，随工作流积累」。
-
-### 超时自动流转
-
-**前置检测条件：** 域中存在定时任务（`@XxlJob`/`@Scheduled`/`XXXTimeoutJob`），或有 TTL 相关业务逻辑，才生成本子节；否则省略。
-
-| 当前状态 | 超时时长 | 流转目标 | 触发方式 | 补偿操作 |
-|---------|---------|---------|---------|---------|
-| CREATED | 30 分钟未支付 | CANCELLED | OrderTimeoutJob @XxlJob | 释放库存，发送取消通知 |
-| REFUNDING | 24 小时未处理 | 需人工介入 | RefundTimeoutJob @XxlJob | 创建人工工单，发送告警 |
-
-> 若无超时自动流转，写「暂无发现，随工作流积累」。
-
-### 补偿机制（MQ 失败重试与死信）
-
-**前置检测条件：** 域中存在 MQ 消费者（`@KafkaListener`/`@RocketMQMessageListener`），才生成本子节；否则省略。
-
-| 消息类型 | 正常消费 | 失败处理 | 重试策略 | 超限处理 |
-|---------|---------|---------|---------|---------|
-| payment.success | 订单状态流转至 PAID | 记录失败日志，状态不变 | 重试 3 次，间隔 1/2/5 分钟 | 进入死信队列，人工处理 |
-| order.timeout | 订单状态流转至 CANCELLED | 幂等检查通过则忽略 | 重试 1 次 | 记录告警日志 |
-
-> 若无 MQ 消费，写「暂无发现，随工作流积累」。
-
-## 9. 错误码与异常 [pitfall]
-
-（无条件生成。若为空则写「暂无发现，随工作流积累」，此为合法初始内容，质量自检通过。）
-
-| 错误码 | 异常类 | 触发场景 | HTTP状态 | 处理建议 |
-|--------|--------|---------|---------|---------|
-| ORDER_NOT_FOUND | OrderNotFoundException | 查询/操作不存在的订单 | 404 | 前端展示「订单不存在」 |
-| ORDER_STATUS_INVALID | OrderStatusException | 状态流转不合法 | 400 | 检查当前订单状态后重试 |
-
-## 10. 跨域依赖 [decision]
-
-（无条件生成。若为空则写「暂无发现，随工作流积累」，此为合法初始内容。由主流程 Section 10 回写阶段统一填入。）
-
-**上游依赖（本域调用的其他域）：**
-| 依赖域 | 交互方式 | 调用点 | 接口版本 | 降级预案 | 说明 |
-|--------|---------|-------|---------|---------|------|
-| payment | RPC @DubboReference | OrderService.createOrder() | v2.1 | 超时 3s 后返回支付处理中，异步重试 | 发起支付 |
-| user | RPC @DubboReference | OrderService.checkUser() | v1.0 | 超时降级：跳过用户状态校验，记录告警 | 校验用户状态 |
-
-**下游被依赖（调用本域的其他域）：**
-| 调用域 | 交互方式 | 接口版本（本域提供）| 场景 |
-|--------|---------|-----------------|------|
-| refund | RPC | v1.2 | 退款申请时查询原订单信息 |
-
-> **契约版本维护规则：**
-> - 本域对外暴露接口的当前版本记录在 frontmatter 的 `contract_version` 字段
-> - 调用方在本节上游依赖表中记录**调用时使用的版本号**
-> - 接口升级时：① 更新 `contract_version` ② 通知下游调用域更新其 Section 10 记录 ③ 触发 hash 更新
-
-## 11. 数据流向 [process]
-
-**前置检测条件：** 域中存在以下任意一项即生成本节；否则整节省略：
-- MQ 消息：`@KafkaListener` / `@RocketMQMessageListener` / `kafkaTemplate.send()` / `rocketMQTemplate.send()`
-- Spring 事件：`ApplicationEventPublisher.publishEvent()` / `@EventListener` / `implements *EventListener` 接口
-- 其他异步数据流：`@Async` + 跨域调用、`CompletableFuture` 跨域通信
-
-| 方向 | Topic/方法 | 触发时机 | 消费者/生产者 | 幂等保障 |
-|------|-----------|---------|------------|---------|
-| 发布 | order.created | 订单创建成功 | OrderService → NotifyConsumer | 业务唯一键去重 |
-| 订阅 | payment.success | 支付成功回调 | PaymentConsumer → OrderService | DB 唯一索引防重 |
-
-## 12. 关键 SQL 模式 [guideline]
-
-**前置检测条件：** 域中存在 XML Mapper 文件或含复杂 SQL 的注解（超过 2 表 JOIN 或有子查询）才生成本节；否则整节省略。
-
-Section 12 最低内容门槛：每条复杂 SQL 必含：查询语义说明、JOIN 表关系、索引命中路径、预期返回数据量级、是否存在慢查询风险
-
-| SQL 标识 | 查询语义 | JOIN 表 | 索引命中 | 数据量级 | 慢查询风险 |
-|---------|---------|--------|---------|---------|---------|
-| selectOrderWithItems | 查询订单及明细 | order + order_item | idx_order_id | ~20行 | 低（有索引） |
-| selectByStatusAndDate | 按状态+日期查订单 | order | idx_status_date | 可能万级 | ⚠️ 注意分页 |
-
-## 13. 常见开发陷阱 [pitfall]
-
-（无条件生成。若为空则写「暂无发现，随工作流积累」，此为合法初始内容。）
-
-- [pitfall] 并发创建订单时若不加 `@DistributedLock(key="order:create:{userId}")` 会出现重复订单
-- [pitfall] `OrderStatus` 枚举在数据库存 code 值（int），禁止直接存 name()，避免改名导致数据不一致
-- [pitfall] 跨 Service 调用 `@Transactional` 方法时必须通过 `AopContext.currentProxy()` 代理调用
-
-## 14. 扩展点 [decision]
-
-**前置检测条件：** 域中存在以下任意一项即生成本节；否则整节省略：
-- 标准扩展点：`interface + ≥2 个实现类`（策略模式、模板方法模式）
-- 配置条件化：`@ConditionalOn*` 注解（Spring Boot 条件化装配）
-- 项目级接口：`项目定义的 *EventListener` / `*Handler` / `*Strategy` / `*Processor` 接口 + ≥1 个实现类
-- 插件化机制：`@Plugin` / `@Extension` / SPI `ServiceLoader` 加载点
-
-| 扩展点 | 接口/注解 | 当前实现 | 扩展方式 |
-|--------|---------|---------|---------|
-| 支付渠道策略 | PayChannelStrategy | AlipayStrategy, WechatStrategy | Map<String, PayChannelStrategy> 注入 |
-| 订单事件监听 | @ConditionalOnProperty("order.notify") | DefaultNotifyHandler | 实现 OrderEventHandler 接口 |
-
-## 15. 业务不变量 [invariant]
-
-（无条件生成。记录系统必须始终为真的业务约束，违反即为 Bug。来源：if/else 推断 + 校验器分析 + 人工访谈。）
-
-| 不变量描述 | 验证位置 | 违反后果 | 来源 |
-|---------|---------|---------|------|
-| 订单金额必须 > 0 | OrderService:validateAmount() | 抛 InvalidAmountException | 代码推断 |
-| 同一用户同一商品当日限购 5 件 | OrderManager:checkDailyLimit() | 抛 PurchaseLimitException | 代码推断 |
-| 退款金额 ≤ 原始支付金额 | RefundService:84 | 抛 InvalidRefundException | [人工补充: {YYYY-MM-DD}] |
-
-> 若无任何不变量，写「暂无发现，随工作流积累」（此为合法初始内容）。
-
-## 16. 领域词汇表 [model]
-
-（无条件生成。帮助新人理解本域专属术语，消除歧义。来源：类名/枚举值语义分析 + 代码注释 + 人工访谈。）
-
-| 术语 | 定义 | 与通用概念的区别 |
-|------|------|----------------|
-| 订单 | 用户完成商品选购后生成的业务凭证，包含商品明细+支付信息 | 区别于「购物车」（临时）和「合同」（签约后） |
-| 结算 | 将已完成订单的金额从冻结余额转为可提现余额的操作 | 区别于「支付」（资金从用户到平台） |
-| 防重Token | 客户端生成的唯一标识符，服务端用于幂等检查，有效期5分钟 | 项目特有机制，非标准 JWT |
-
-> 若无特殊术语，写「暂无特定领域术语，使用通用定义」（此为合法初始内容）。
-
-## 17. 新人上手指南 [process]
-
-（无条件生成。本节分为两个独立子节，分别服务不同受众：Agent 快速定位 + 员工新人入门。）
-
----
-
-### 17.A — Agent 快速定位指南（机器优先）
-
-> 适用受众：AI Agent 执行任务时，根据任务类型找到最小必读路径。
-
-#### 按任务类型的最小读取路径
-
-| 任务类型 | 必读 Section | 关键文件 | 核心约束提示 |
-|---------|------------|---------|------------|
-| **新增 API 接口** | 5（API契约）→ 3（业务规则）→ 15（不变量） | `{Domain}Controller.java` / `{Domain}Facade.java` | 确认权限注解、幂等需求（见 Section 5）|
-| **修改业务规则** | 3（业务规则）→ 8（状态机）→ 15（不变量） | `{Domain}Service.java` / `{Domain}Manager.java` | 修改后同步维护 Section 15 不变量 |
-| **新增/修改状态流转** | 8（状态机）→ 3（流程规则）→ 9（错误码） | `{Domain}Status.java` / `{Domain}Service.java` | 同步更新 Section 8 状态图和转换表 |
-| **Code Review** | 15（不变量）→ 13（陷阱）→ 8（状态机）→ 3（规则） | — | 重点检查不变量是否有校验代码 |
-| **排查线上 Bug** | 9（错误码）→ 13（陷阱）→ 8（状态机） | — | 优先查错误码，再对照状态机异常流 |
-| **新增 MQ 消息** | 11（数据流向）→ 3（规则）→ 15（不变量） | `{Domain}Consumer.java` / `{Domain}Producer.java` | 确认幂等保障机制（见 Section 11）|
-| **修改数据库查询** | 12（SQL模式）→ 4（文件索引）→ 2（核心实体） | `{Domain}Mapper.java` / XML Mapper | 注意慢查询风险（见 Section 12）|
-
----
-
-### 17.B — 员工新人入门手册（人类优先）
-
-> 适用受众：初次接触本域的研发同学，目标是读完本节即可开始独立开发，无需找业务方反复答疑。
-
-#### 开发前必读清单
-
-> 建议逐项确认后再开始开发：
-
-1. 理解 `{Domain}Status` 枚举的 {N} 个状态及合法转换（见 Section 8 状态机）
-2. 了解 Section 15 的 {M} 条业务不变量，违反将导致生产事故
-3. 熟悉 Section 6 的项目特有编码模式（如 `AopContext.currentProxy()`、`BaseRpcResponse.build()`）
-4. 阅读「高频踩坑」中摘录的前 3 条 Section 13 陷阱
-
-#### 本域关键设计决策历史
-
-（自动从 Section 3 `[decision]` 条目中提取，补充设计背景；无内容时写「暂无记录，随工作流积累」）
-
-> **为什么这样设计？**（帮助新人理解现有架构，而不是仅知道怎么做）
-
-| 设计决策 | 选择方案 | 未选方案 | 设计理由 |
-|---------|---------|---------|---------|
-| {决策描述，如「通知方式」} | {选用方案，如「MQ 异步」} | {弃用方案，如「同步 RPC」} | {简要理由，如「解耦 + 削峰，支付服务故障不影响订单主流程」} |
-
-#### 本地环境搭建 Checklist
-
-（基于 Section 11 数据流向和 Section 10 跨域依赖自动生成；无相关配置时写「无特殊本地配置要求」）
-
-> **说明：** 以下为纯文字编号清单，本地启动前逐项确认：
-
-1. **MQ Topic 配置**：确认 `application-local.yml` 中 Topic 名称与联调环境一致
-   - 本域订阅 Topic：{来自 Section 11 的订阅 Topic 列表，无则写「-」}
-   - 本域发布 Topic：{来自 Section 11 的发布 Topic 列表，无则写「-」}
-2. **RPC 依赖服务**：确认以下服务在本地可访问（或已 Mock）
-   - {来自 Section 10 的上游依赖域列表，无则写「-」}
-3. **数据库**：确认本地 DB 已执行最新 migration，重点关注以下表
-   - {来自 Section 2 核心实体对应的主表，无则写「-」}
-4. **配置开关**：确认以下特性开关状态
-   - {来自 Section 14 扩展点的条件化配置，无则写「-」}
-
-#### 首次开发任务推荐
-
-（推荐从最简单的查询接口入手，逐步熟悉域内结构）
-
-推荐路径：**查询接口** → **写入接口** → **状态流转** → **跨域集成**
-
-#### 常见问题 FAQ
-
-（来自 Step 4 访谈问卷的回答摘要；无内容时写「暂无记录，随工作流积累」）
-
-| 问题 | 答案 | 来源 |
-|------|------|------|
-| {高频问题，如「为什么枚举存 code 不存 name？」} | {答案} | {代码推断 / [人工补充: {日期}]} |
-
-#### 高频踩坑（精选自 Section 13 前 3 条）
-
-（自动提取 Section 13 前 3 条 `[pitfall]`，无内容时写「暂无记录，随工作流积累」）
-
-1. ...
-2. ...
-3. ...
-
----
+```markdown
 <!-- 更新摘要（由 Skills Builder 自动追加）
-[{YYYY-MM-DD}] 模式A生成：17节完整格式（v3），扫描 {M} 个文件，不变量{I}条，词汇{G}个，隐性知识率{H}%
+[{YYYY-MM-DD}] {stack} strategy 生成：17节完整格式（v3-{stack}），扫描 {M} 个文件，不变量{I}条，词汇{G}个，隐性知识率{H}%
 -->
 ```