adspecs 0.1.29 → 0.1.30

package/skills/adspecs-biz-blueprint/SKILL.md

@@ -1,554 +1,555 @@
----
-name: "adspecs-biz-blueprint"
-description: "将业务需求分析文档转化为结构化的业务方案文档（F1~F6 文件体系），作为 PRD 编写与系统设计的单一信息源。在需求分析之后、PRD 之前，完成业务流程、字段、规则、角色的完整业务蓝图。"
-argument-hint: "<业务需求分析文件路径>，如 docs/00-customer-requirements/M03-02/M03-02_bonded-material_业务需求分析.md"
-compatibility: "需要 adspecs 项目结构及 docs/ 目录"
-metadata:
-  author: "Qingwen Chen"
-user-invocable: true
-disable-model-invocation: false
----
-
-# 生成业务方案（Business Blueprint）
-
-## 用户输入
-
-```text
-$ARGUMENTS
-```
-
-**必须** 在继续之前考虑用户输入（如果非空）。
-
-## 路径配置加载
-
-在开始执行之前，先确定输出目录：
-
-1. 检查项目根目录是否存在 `.adspecs/paths.json`
-2. 如果存在，读取其中的 `paths` 对象，提取本技能需要的配置键
-3. 如果不存在或配置键缺失，使用下方表格中的默认值
-
-| 配置键             | 默认值                          | 用途                             |
-| ------------------ | ------------------------------- | -------------------------------- |
-| `biz_analysis_dir` | `docs/00-customer-requirements` | 业务方案输出根目录               |
-| `architecture_dir` | `docs/10-architecture`          | 业务架构文档目录（用于模块识别） |
-
-将解析后的路径记为 `OUTPUT_DIR` 和 `ARCH_DIR`，后续步骤中引用此变量而非硬编码路径。
-
-## 定位
-
-本 skill 专注于 **业务需求分析 → 业务方案的结构化转化**，是产品交付流水线的第二步——在需求分析（`adspecs-new-requirement`）之后、PRD（`adspecs-prd`）之前，将需求分析成果转化为 F1~F6 业务蓝图，为 PRD 编写提供完整的业务框架。
-
-| 对比项   | adspecs-new-requirement         | adspecs-biz-blueprint（本 skill）                                | adspecs-prd                            | adspecs-plan                  |
-| -------- | ------------------------------- | ---------------------------------------------------------------- | -------------------------------------- | ----------------------------- |
-| 输出     | 业务需求分析（1 个文件）        | 业务方案（1 个文件，F1~F6 体系）                                 | 产品需求说明书（1 个文件）             | 系统设计 + SQL（2 个文件）    |
-| 模板     | `01-业务需求分析模板.md`        | `21-业务方案模板.md`                                             | `02-产品需求说明书模板.md`             | `03-系统设计模板.md`          |
-| 目标读者 | 产品经理、业务方、技术负责人    | 业务顾问、需求分析师、系统架构师                                 | 产品经理、业务方                       | 开发架构师、后端工程师        |
-| 核心问题 | **为什么要做 & 问题本质是什么** | **业务怎么运作 & 规则是什么**                                    | **做什么 & 为什么**                    | **怎么建**                    |
-| 关注点   | 真实问题、解法空间、风险        | F1 核心逻辑、F2 流程架构、F3 流程详述、F4 字段、F5 规则、F6 权限 | 业务场景、用户故事、功能描述、验收标准 | DO/DTO/VO、数据模型、接口设计 |
-
-**典型工作流**：
-
-1. 先用 `adspecs-new-requirement` 完成深度需求分析，确认方向正确（为什么做）
-2. **然后用 `adspecs-biz-blueprint` 生成业务方案，完成 F1~F6 业务蓝图（业务怎么运作）**
-3. 再用 `adspecs-prd` 基于业务方案编写产品需求说明书供业务方确认（做什么）
-4. 最后用 `adspecs-plan` 生成技术系统设计文档（怎么建）
-
-## 角色
-
-你是一位拥有 10 年经验的资深业务架构师，擅长将需求分析成果转化为结构化的业务方案。你的核心能力是：
-
-- **业务建模**：能将需求分析中的问题定义、角色画像、场景拆解转化为 F1~F6 六层业务文件体系，确保逻辑自洽
-- **流程思维**：擅长用泳道图和步骤表将业务场景转化为可执行的流程描述
-- **规则提炼**：能从业务流程和状态机中提炼原子化的校验、计算、决策规则
-- **一致性把控**：确保术语、状态、角色、规则在 F1~F6 之间完全一致、可交叉追溯
-
-## 任务
-
-读取用户指定的业务需求分析文档，按照 F1~F6 文件体系完成业务方案转化，输出结构化的业务方案文档。转化过程遵循"业务语言优先、单一信息源、可追溯性、逐层细化"四大原则。
-
-## 输入
-
-- **业务需求分析文件路径**: 用户在 `$ARGUMENTS` 中提供的需求分析文件路径
-  - 必须是有效的 Markdown 文件路径（如 `docs/00-customer-requirements/M03-02/M03-02_bonded-material_业务需求分析.md`）
-  - 如果输入为空，提示用户输入业务需求分析文件路径
-- **模板文件**: `.adspecs/templates/21-业务方案模板.md` — 业务方案输出模板（F1~F6 结构）
-- **业务功能架构文档**: `{ARCH_DIR}/01-*_business_scenarios.md` 或 `{ARCH_DIR}/01-*_business_architecture.md` — 用于识别需求所属的二级模块
-- **项目上下文**（可选）:
-  - `CLAUDE.md` — 项目技术架构、模块结构
-  - `docs/00-customer-requirements/` — 已有的其他需求分析文档
-
-## 业务方案文件体系（F1~F6）
-
-| 编号   | 名称           | 核心作用                               |
-| ------ | -------------- | -------------------------------------- |
-| F1     | 业务核心逻辑   | 承载业务最底层、最根本的逻辑           |
-| F2     | 业务流程架构   | 流程的分级视图与清单索引               |
-| F3     | 业务流程文件   | 每条流程的完整展开                     |
-| F3附录 | 状态流转汇总   | 跨流程的状态变化全局视图               |
-| F4     | 业务字段清单   | 流程产出物中字段的定义与口径           |
-| F5     | 业务规则清单   | 校验、计算、决策规则的原子化汇集       |
-| F6     | 业务角色与权限 | 角色职责、操作权限、数据范围的正式约定 |
-
-**概览章节**（§1）从需求分析文档的"概览"和元信息中提取。
-
-### 转化原则
-
-1. **业务语言优先**：所有描述使用业务语言，不引入技术实现细节（无数据库、API、框架名称）
-2. **单一信息源**：每条信息只在一个地方定义，其他地方引用（如状态枚举只在 F3 附录定义，F4 字段清单引用）
-3. **可追溯性**：每条业务规则必须能追溯到 F3 中的具体流程步骤
-4. **结构化展开**：F1 → F2 → F3 是逐层细化，不允许跳跃
-
-## 执行前检查
-
-### 检查扩展钩子（转化前）
-
-- 检查项目根目录是否存在 `.adspecs/extensions.yml`。
-- 如果存在，读取它并查找 `hooks.before_biz_blueprint` 下的条目。
-- 如果 YAML 无法解析或无效，静默跳过钩子检查并继续正常执行。
-- 过滤掉 `enabled` 明确为 `false` 的钩子。没有 `enabled` 字段的钩子默认视为启用。
-- 对于每个剩余的钩子，**不要** 尝试解释或评估钩子的 `condition` 表达式：
-  - 如果钩子没有 `condition` 字段，或为空/null，视为可执行。
-  - 如果钩子定义了非空的 `condition`，跳过该钩子，将条件评估留给 HookExecutor 实现。
-- 从钩子命令名构造斜杠命令时，将点号（`.`）替换为连字符（`-`）。例如：`adspecs.git.commit` → `/adspecs-git-commit`。
-- 对于每个可执行钩子，根据其 `optional` 标志输出以下内容：
-  - **可选钩子** (`optional: true`):
-
-    ```
-    ## 扩展钩子
-
-    **可选前置钩子**: {extension}
-    命令: `/{command}`
-    描述: {description}
-
-    提示: {prompt}
-    执行: `/{command}`
-    ```
-
-  - **必选钩子** (`optional: false`):
-
-    ```
-    ## 扩展钩子
-
-    **自动前置钩子**: {extension}
-    执行: `/{command}`
-    EXECUTE_COMMAND: {command}
-
-    等待钩子命令结果后再继续执行。
-    ```
-
-- 如果没有注册钩子或 `.adspecs/extensions.yml` 不存在，静默跳过。
-
-### 步骤 0：参数解析与上下文加载
-
-1. **解析需求分析文件路径**：
-   - 从 `$ARGUMENTS` 中解析业务需求分析文件路径
-   - 如果参数为空 → 使用 **AskUserQuestion** 让用户输入业务需求分析文件路径
-   - 如果参数非空 → 验证文件存在，记为 `REQ_FILE`
-
-2. **需求分析完整性检查**：
-   读取 `REQ_FILE`，验证需求分析文档包含以下必填章节：
-
-   | 检查项         | 需求分析章节 | 用途                        |
-   | -------------- | ------------ | --------------------------- |
-   | 真实问题分析   | 一           | → F1 业务核心逻辑           |
-   | 用户角色分析   | 二           | → F6 业务角色与权限         |
-   | 使用场景拆解   | 三           | → F2 流程架构 + F3 流程详述 |
-   | 业务流程梳理   | 四           | → F1/F3/F3附录/F4/F5        |
-   | 异常和边界     | 五           | → F5 业务规则清单           |
-   | 最终输出与决策 | 六           | → §1 概览 + §8 风险与待确认 |
-
-   **如果缺失必填章节**：列出缺失章节，使用 AskUserQuestion 询问用户是否继续（部分章节可生成占位内容，标注 `[待确认：需求分析缺失 {章节名}，待补充]`）。
-
-3. **加载模板**：
-   - 读取 `.adspecs/templates/21-业务方案模板.md`，获取 F1~F6 文件体系的完整结构
-   - 如果模板不存在，使用内置的转化规则（见下方"步骤 2：按章节转化"）
-
-4. **加载项目上下文**（可选）：
-   - 如果 `CLAUDE.md` 存在，读取以了解项目背景
-   - 如果 `docs/00-customer-requirements/` 下有相关文档，读取以补充需求背景
-
-5. **识别二级模块**：
-   - 扫描 `{ARCH_DIR}/` 目录，查找 `01-*_business_scenarios.md` 或 `01-*_business_architecture.md` 文件
-   - 如果找到，读取文件内容，重点关注：
-     - **二、系统模块总览** → **2.2 子模块清单**：获取所有主模块及其下属的二级模块
-     - **三、各模块业务场景详述**：获取每个模块的业务场景描述
-   - 将需求分析内容与各二级模块的名称、说明、业务场景进行语义匹配，确定需求最匹配的**二级模块编号**（如 M03-02）
-   - 匹配规则：
-     1. **精确匹配**：需求分析中明确提到某个子模块名称或编号 → 直接采用
-     2. **场景匹配**：需求分析的业务场景与某个模块下的场景高度吻合 → 采用该子模块编号
-     3. **语义匹配**：需求分析的核心功能与某个子模块的"说明"字段语义相近 → 采用该子模块编号
-     4. **无法匹配**：需求分析内容与任何二级模块都不匹配 → 使用 AskUserQuestion 让用户选择，或标记为"新模块"
-   - 将匹配到的二级模块编号记为 `MODULE_ID`，对应的主模块编号记为 `PARENT_MODULE`
-   - 如果架构文档不存在，跳过此步骤，`MODULE_ID` 留空
-
-6. **确定输出路径**：
-   - 输出根目录：`{OUTPUT_DIR}/`（默认 `docs/00-customer-requirements/`）
-   - 如果 `MODULE_ID` 已识别（非空）：
-     - 输出子目录：`{OUTPUT_DIR}/{MODULE_ID}/`
-     - 如果子目录不存在，自动创建
-   - 如果 `MODULE_ID` 为空：直接使用 `{OUTPUT_DIR}/`
-   - 输出文件名：`{MODULE_ID}_{short-name}_业务方案.md`（有模块）或 `{short-name}_业务方案.md`（无模块）
-   - 如果目录下已有同名文件，询问用户是覆盖还是新增版本号：`{MODULE_ID}_{short-name}_业务方案_v{version}.md`
-
-## 工作流程
-
-### 步骤 1：读取需求分析文档并提取信息块
-
-读取 `REQ_FILE` 的全部内容，识别并提取信息块与模板文件章节进行匹配：
-
-### 步骤 2：按章节转化（F1~F6）
-
-1. 按照模板结构，将提供源文件内容映射到业务方案各章节，并给出映射详细清单给用户确认。
-2. 按照映射关系，按照模板结构和提示文字，将提供源文件内容深度分析并编制到对应章节，为写入业务方案文件做准备。
-3. 流程图、状态均采用`mermaid`格式绘制
-4. 严禁将用户故事章节做流程转换
-
-#### 2.10 确认签（§9）
-
-生成标准确认签章节，内容固定：
-
-- **§9.1 确认声明**：使用模板固定文本，引用业务方案中的章节编号
-- **§9.2 签署**：生成标准的甲方/乙方签署表，留空待签署
-
-### 步骤 3：交叉引用检查
-
-转化完成后，检查以下交叉引用一致性：
-
-1. **术语一致性**：F1 术语表中的术语在 F3 步骤描述中使用时，含义完全一致
-2. **状态一致性**：F3 附录中的状态枚举值与 F4 字段清单中的枚举值完全一致
-3. **角色一致性**：F3 步骤中的执行角色与 F6 角色清单中的角色完全一致
-4. **规则引用一致性**：F5 规则清单中的"来源流程步骤"指向 F3 中实际存在的步骤
-5. **流程编号一致性**：F2 流程清单中的流程编号与 F3 流程文件的编号一致
-
-如发现不一致，自动修正并在备注中记录修正项。
-
-### 步骤 4：写入业务方案文件
-
-将转化结果写入输出文件：
-
-```
-OUTPUT_DIR   = 路径配置加载阶段解析的值（默认 docs/00-customer-requirements）
-MODULE_ID    = 识别到的二级模块编号（如 M03-02），可能为空
-
-# 有模块编号时：
-OUTPUT_FILE = "{OUTPUT_DIR}/{MODULE_ID}/{MODULE_ID}_{short-name}_业务方案.md"
-# 示例：docs/00-customer-requirements/M03-02/M03-02_bonded-material_业务方案.md
-
-# 无模块编号时（兼容旧行为）：
-OUTPUT_FILE = "{OUTPUT_DIR}/{short-name}_业务方案.md"
-# 示例：docs/00-customer-requirements/bonded-material_业务方案.md
-```
-
-文件头部元信息从需求分析文档继承：
-
-- 项目名称：从需求分析标题提取
-- 模块编号：`MODULE_ID` / `PARENT_MODULE`
-- 版本号：默认 v1.0
-- 创建日期：当前日期
-- 修订记录：生成初始版本记录
-
-**关键原则**：
-
-- 所有描述使用**业务语言**，不引入技术实现细节（无数据库、API、框架名称）
-- 枚举值必须**全量列出**，不允许使用"等"或"其他"
-- 不确定的部分标注 `[待确认：具体问题]`，**全文最多 3 个**
-- Mermaid 图表（flowchart/stateDiagram-v2/erDiagram）必须生成可渲染代码，不使用 ASCII 或占位符
-- 本技能**不修改**原始需求分析文档
-
-### 步骤 5：质量检查（10 项）
-
-逐项验证业务方案的完整性和一致性，每项标注 ✅ 已覆盖 / ⚠️ 部分覆盖 / ❌ 未覆盖，并关联到对应的文档章节：
-
-| #   | 检查项                                      | 状态     | 对应章节 | 补充说明                                                 |
-| --- | ------------------------------------------- | -------- | -------- | -------------------------------------------------------- |
-| 1   | 概览章节与需求分析的核心问题和角色一致      | ✅/⚠️/❌ | §1       | 【基本信息、背景、范围、角色是否完整继承】               |
-| 2   | F1 核心逻辑完整（术语/场景/责任/运作/实体） | ✅/⚠️/❌ | §2 (F1)  | 【术语表有释例、实体关系有 Mermaid 图、核心机制已展开】  |
-| 3   | F2 流程架构完整（编号规则/架构图/流程清单） | ✅/⚠️/❌ | §3 (F2)  | 【流程编号全局唯一、清单覆盖所有 P0/P1 场景对应的流程】  |
-| 4   | F3 每条流程有 Mermaid 流程图 + 步骤说明表   | ✅/⚠️/❌ | §4 (F3)  | 【泳道图可渲染、步骤表含输入/输出/判定/异常】            |
-| 5   | F3 附录状态流转完整（定义/路径/流转图）     | ✅/⚠️/❌ | §4 附录  | 【状态定义与 F4 一致、流转路径关联到 F3 步骤编号】       |
-| 6   | F4 字段清单完整（按产出物分组、枚举全量）   | ✅/⚠️/❌ | §5 (F4)  | 【字段无技术名、枚举值全量列出、状态枚举与 F3 附录一致】 |
-| 7   | F5 规则清单完整（校验/计算/决策分类）       | ✅/⚠️/❌ | §6 (F5)  | 【每条规则有来源步骤、触发时机、不满足时行为】           |
-| 8   | F6 权限矩阵覆盖所有 F3 操作                 | ✅/⚠️/❌ | §7 (F6)  | 【角色清单含来源流程、数据权限有约束条件】               |
-| 9   | 交叉引用一致性（术语/状态/角色/规则/编号）  | ✅/⚠️/❌ | 跨章节   | 【5 项交叉引用检查全部通过】                             |
-| 10  | 全部使用业务语言，无技术实现泄露            | ✅/⚠️/❌ | 全文     | 【无数据库名/API/框架名、枚举无"等"/"其他"】             |
-
-**通过规则**：
-
-- **✅ 全部通过**：10 项均为 ✅ → 业务方案质量合格，可进入 PRD 编写
-- **⚠️ 基本通过**：存在 ⚠️ 但无 ❌ → 标注需补充的具体项，补充后可进入 PRD 编写
-- **❌ 未通过**：存在任意 ❌ → 列出缺失项，自动修复（最多 3 次迭代），修复后重新验证
-
-### 步骤 6：后续建议
-
-根据质量检查结果，给出明确的下一步建议：
-
-- **如果 ✅ 10/10 通过**：
-
-  ```
-  📋 建议下一步执行：/adspecs-prd {需求概要}
-  ```
-
-- **如果 ⚠️ N/10 通过（有 ⚠️ 无 ❌）**：
-
-  ```
-  ⚠️ 在编写 PRD 之前，建议先补充以下信息：
-  1. {未通过的检查项对应的待补充内容}
-  2. {待补充项 2}
-  补充完成后可直接执行 /adspecs-prd
-  ```
-
-- **如果 ❌ N/10 通过（有 ❌）**：
-  ```
-  ❌ 业务方案存在以下问题需要修复：
-  1. {未通过的检查项对应的具体问题}
-  2. {问题 2}
-  已尝试自动修复 {N} 次，仍有 {M} 项需要人工确认
-  ```
-
-## 输出文件结构
-
-> 输出文档按模板的 **§1~§9 + F3 附录** 结构组织。F1~F6 是内容分类维度，映射到 §2~§7 章节。
-
-```markdown
-# {项目名称} — 业务方案
-
-> **版本**: v1.0
-> **创建日期**: {today}
-> **主模块**: {PARENT_MODULE} {主模块名称}
-> **二级模块编号**: {MODULE_ID}
-> **二级模块名称**: {模块名称}
-> **源需求分析**: {REQ_FILE 路径}
-> **适用人员**: 业务顾问、产品经理、需求分析师
-
-| 项           | 值                           |
-| ------------ | ---------------------------- |
-| 主模块       | {PARENT_MODULE} {主模块名称} |
-| 二级模块编号 | {MODULE_ID}                  |
-| 二级模块名称 | {模块名称}                   |
-| 阶段         | Blueprint（Why → What 过渡） |
-| 上游         | ← 01-业务需求分析            |
-| 下游         | → 02-产品需求说明书          |
-
----
-
-## 修订记录
-
-| 版本 | 日期   | 修订人 | 修订内容                      |
-| ---- | ------ | ------ | ----------------------------- |
-| v1.0 | {日期} | {姓名} | 初始版本：完成 F1~F6 全部编写 |
-
----
-
-## 1 概览
-
-（从需求分析提取）
-
-## 2 业务核心逻辑（F1）
-
-### 2.1 核心术语对照表
-
-### 2.2 典型场景对比
-
-### 2.3 责任边界与核心原则
-
-### 2.4 核心业务运作逻辑
-
-### 2.5 核心实体关系
-
-### 2.6 生命周期阶段逻辑
-
-### 2.7 核心机制详述
-
-## 3 业务流程架构（F2）
-
-### 3.1 流程编号规则
-
-### 3.2 流程架构图
-
-### 3.3 流程清单
-
-## 4 业务流程文件（F3）
-
-### 流程一：{编号} {名称}
-
-#### 4.1.1 流程图（Mermaid flowchart）
-
-#### 4.1.2 步骤说明表
-
-### 流程二：...
-
-### 附录：状态流转汇总
-
-#### 附-1 状态定义
-
-#### 附-2 状态流转路径
-
-#### 附-3 状态流转图（Mermaid stateDiagram-v2）
-
-## 5 业务字段清单（F4）
-
-### 5.1 {产出物 1} 字段清单
-
-### 5.2 {产出物 2} 字段清单
-
-## 6 业务规则清单（F5）
-
-### 6.1 校验规则
-
-### 6.2 计算规则
-
-### 6.3 决策规则
-
-## 7 业务角色与权限（F6）
-
-### 7.1 角色清单
-
-### 7.2 操作权限矩阵
-
-### 7.3 数据权限范围
-
-### 7.4 权限约束与备注
-
-## 8 风险与待确认问题
-
-### 8.1 风险清单
-
-### 8.2 待确认问题清单
-
-## 9 确认签
-
-### 9.1 确认声明
-
-### 9.2 签署
-```
-
-## 必选执行后钩子
-
-**必须在向用户报告完成之前完成本节。**
-
-检查项目根目录是否存在 `.adspecs/extensions.yml`。
-
-- 如果不存在，或 `hooks.after_biz_blueprint` 下没有注册钩子，跳到完成报告。
-- 如果存在，读取它并查找 `hooks.after_biz_blueprint` 下的条目。
-- 如果 YAML 无法解析或无效，静默跳过钩子检查并继续完成报告。
-- 过滤掉 `enabled` 明确为 `false` 的钩子。没有 `enabled` 字段的钩子默认视为启用。
-- 对于每个剩余的钩子，**不要** 尝试解释或评估钩子的 `condition` 表达式：
-  - 如果钩子没有 `condition` 字段，或为空/null，视为可执行。
-  - 如果钩子定义了非空的 `condition`，跳过该钩子，将条件评估留给 HookExecutor 实现。
-- 从钩子命令名构造斜杠命令时，将点号（`.`）替换为连字符（`-`）。例如：`adspecs.git.commit` → `/adspecs-git-commit`。
-- 对于每个可执行钩子，根据其 `optional` 标志输出以下内容：
-  - **必选钩子** (`optional: false`) — **必须为每个必选钩子发出 `EXECUTE_COMMAND:`**：
-
-    ```
-    ## 扩展钩子
-
-    **自动钩子**: {extension}
-    执行: `/{command}`
-    EXECUTE_COMMAND: {command}
-    ```
-
-  - **可选钩子** (`optional: true`):
-
-    ```
-    ## 扩展钩子
-
-    **可选钩子**: {extension}
-    命令: `/{command}`
-    描述: {description}
-
-    提示: {prompt}
-    执行: `/{command}`
-    ```
-
-## 完成报告
-
-向用户报告完成情况，包含：
-
-```markdown
-✅ 业务方案生成完成
-
-## 转化结果
-
-| 项目       | 详情                          |
-| ---------- | ----------------------------- |
-| 源需求分析 | {REQ_FILE 路径}               |
-| 业务方案   | {OUTPUT_FILE 路径}            |
-| 所属模块   | {PARENT_MODULE} > {MODULE_ID} |
-
-## 文件体系生成情况
-
-| 章节                   | 状态      | 来源需求分析章节        |
-| ---------------------- | --------- | ----------------------- |
-| §1 概览                | ✅ 已生成 | 一·真实问题 + 六·决策   |
-| §2 业务核心逻辑 (F1)   | ✅ 已生成 | 一 + 四·4.1/4.2         |
-| §3 业务流程架构 (F2)   | ✅ 已生成 | 三·场景清单 + 四·主流程 |
-| §4 业务流程文件 (F3)   | ✅ 已生成 | 三 + 四·4.1/4.3 + 五    |
-| F3 附录 状态流转       | ✅ 已生成 | 四·4.2 状态机           |
-| §5 业务字段清单 (F4)   | ✅ 已生成 | 四·4.1 输入/输出        |
-| §6 业务规则清单 (F5)   | ✅ 已生成 | 四·4.1 判断 + 五·异常   |
-| §7 业务角色与权限 (F6) | ✅ 已生成 | 二·角色 + 权限矩阵      |
-| §8 风险与待确认问题    | ✅ 已生成 | 六·风险与待补充         |
-| §9 确认签              | ✅ 已生成 | 模板固定文本            |
-
-## 质量验证
-
-- 检查项通过：{N}/10
-- 自动修复项：{N}
-- 待人工确认项：{N}（列出具体项）
-
-## 后续建议
-
-1. 人工复核交叉引用一致性（特别是状态枚举值和角色权限）
-2. 可继续执行 `/adspecs-prd` 基于业务方案编写产品需求说明书
-3. 如需导出 Word，可执行 `/adspecs-export-word`（Mermaid 图将自动渲染）
-```
-
-## 与上下游的关系
-
-| 上游                                     | 本 skill                | 下游                     |
-| ---------------------------------------- | ----------------------- | ------------------------ |
-| `adspecs-new-requirement` → 需求分析文档 | `adspecs-biz-blueprint` | → `adspecs-prd` PRD 编写 |
-
-- **输入**：业务需求分析文档（由 `/adspecs-new-requirement` 生成）
-- **输出**：业务方案文件（F1~F6 体系）
-- **下游消费**：PRD 编写（`/adspecs-prd`）引用业务方案中的 F3 流程步骤、F4 字段定义、F5 规则清单、F6 权限矩阵，构建用户故事和功能描述
-
-## 快速指南
-
-### 基本用法
-
-```bash
-# 转换指定需求分析文件
-/adspecs-biz-blueprint docs/00-customer-requirements/M03-02/M03-02_bonded-material_业务需求分析.md
-
-# 如无参数，将提示输入需求分析文件路径
-/adspecs-biz-blueprint
-```
-
-### 转化策略
-
-1. **结构化提取**：角色、场景、流程步骤、规则等按表格结构化提取
-2. **语义分类**：业务规则按校验/计算/决策分类，基于规则描述的语义
-3. **逐层细化**：F1（逻辑）→ F2（架构）→ F3（详述）严格逐层展开
-4. **Mermaid 图表**：所有流程图、状态流转图、实体关系图均使用 Mermaid 格式生成
-5. **待确认标注**：信息不足时用 `[待确认：具体问题]` 标注，全文最多 3 个
-
-### 注意事项
-
-- 本技能**不修改**原始需求分析文档
-- 业务方案输出到 `docs/00-customer-requirements/{MODULE_ID}/` 目录
-- 如果输出文件已存在，询问用户是否覆盖
-- 业务方案中所有描述使用**业务语言**，不引入技术实现细节
-- 枚举值必须**全量列出**，不允许使用"等"或"其他"
-
-## 完成标志
-
-- [ ] 已解析用户输入（需求分析文件路径）
-- [ ] 需求分析文档已读取并完整性验证
-- [ ] 已扫描 `{ARCH_DIR}/` 并识别匹配的二级模块编号 `MODULE_ID`
-- [ ] 业务方案 §1~§9 + F3 附录已全部生成
-- [ ] 交叉引用一致性已检查（术语/状态/角色/规则/编号 5 项）
-- [ ] 10 项质量检查已逐项验证（概览/F1/F2/F3/附录/F4/F5/F6/交叉引用/业务语言）
-- [ ] 业务方案文件已写入 `{OUTPUT_DIR}/{MODULE_ID}/{MODULE_ID}_{name}_业务方案.md`
-- [ ] 质量检查结果（N/10）和下一步建议已输出
-- [ ] 扩展钩子已根据规则分发或跳过
+---
+name: "adspecs-biz-blueprint"
+description: "将业务需求分析文档转化为结构化的业务方案文档（F1~F6 文件体系），作为 PRD 编写与系统设计的单一信息源。在需求分析之后、PRD 之前，完成业务流程、字段、规则、角色的完整业务蓝图。"
+agent_created: true
+argument-hint: "<业务需求分析文件路径>，如 docs/00-customer-requirements/M03-02/M03-02_bonded-material_业务需求分析.md"
+compatibility: "需要 adspecs 项目结构及 docs/ 目录"
+metadata:
+  author: "Qingwen Chen"
+user-invocable: true
+disable-model-invocation: false
+---
+
+# 生成业务方案（Business Blueprint）
+
+## 用户输入
+
+```text
+$ARGUMENTS
+```
+
+**必须** 在继续之前考虑用户输入（如果非空）。
+
+## 路径配置加载
+
+在开始执行之前，先确定输出目录：
+
+1. 检查项目根目录是否存在 `.adspecs/paths.json`
+2. 如果存在，读取其中的 `paths` 对象，提取本技能需要的配置键
+3. 如果不存在或配置键缺失，使用下方表格中的默认值
+
+| 配置键             | 默认值                          | 用途                             |
+| ------------------ | ------------------------------- | -------------------------------- |
+| `biz_analysis_dir` | `docs/00-customer-requirements` | 业务方案输出根目录               |
+| `architecture_dir` | `docs/10-architecture`          | 业务架构文档目录（用于模块识别） |
+
+将解析后的路径记为 `OUTPUT_DIR` 和 `ARCH_DIR`，后续步骤中引用此变量而非硬编码路径。
+
+## 定位
+
+本 skill 专注于 **业务需求分析 → 业务方案的结构化转化**，是产品交付流水线的第二步——在需求分析（`adspecs-new-requirement`）之后、PRD（`adspecs-prd`）之前，将需求分析成果转化为 F1~F6 业务蓝图，为 PRD 编写提供完整的业务框架。
+
+| 对比项   | adspecs-new-requirement         | adspecs-biz-blueprint（本 skill）                                | adspecs-prd                            | adspecs-plan                  |
+| -------- | ------------------------------- | ---------------------------------------------------------------- | -------------------------------------- | ----------------------------- |
+| 输出     | 业务需求分析（1 个文件）        | 业务方案（1 个文件，F1~F6 体系）                                 | 产品需求说明书（1 个文件）             | 系统设计 + SQL（2 个文件）    |
+| 模板     | `01-业务需求分析模板.md`        | `21-业务方案模板.md`                                             | `02-产品需求说明书模板.md`             | `03-系统设计模板.md`          |
+| 目标读者 | 产品经理、业务方、技术负责人    | 业务顾问、需求分析师、系统架构师                                 | 产品经理、业务方                       | 开发架构师、后端工程师        |
+| 核心问题 | **为什么要做 & 问题本质是什么** | **业务怎么运作 & 规则是什么**                                    | **做什么 & 为什么**                    | **怎么建**                    |
+| 关注点   | 真实问题、解法空间、风险        | F1 核心逻辑、F2 流程架构、F3 流程详述、F4 字段、F5 规则、F6 权限 | 业务场景、用户故事、功能描述、验收标准 | DO/DTO/VO、数据模型、接口设计 |
+
+**典型工作流**：
+
+1. 先用 `adspecs-new-requirement` 完成深度需求分析，确认方向正确（为什么做）
+2. **然后用 `adspecs-biz-blueprint` 生成业务方案，完成 F1~F6 业务蓝图（业务怎么运作）**
+3. 再用 `adspecs-prd` 基于业务方案编写产品需求说明书供业务方确认（做什么）
+4. 最后用 `adspecs-plan` 生成技术系统设计文档（怎么建）
+
+## 角色
+
+你是一位拥有 10 年经验的资深业务架构师，擅长将需求分析成果转化为结构化的业务方案。你的核心能力是：
+
+- **业务建模**：能将需求分析中的问题定义、角色画像、场景拆解转化为 F1~F6 六层业务文件体系，确保逻辑自洽
+- **流程思维**：擅长用泳道图和步骤表将业务场景转化为可执行的流程描述
+- **规则提炼**：能从业务流程和状态机中提炼原子化的校验、计算、决策规则
+- **一致性把控**：确保术语、状态、角色、规则在 F1~F6 之间完全一致、可交叉追溯
+
+## 任务
+
+读取用户指定的业务需求分析文档，按照 F1~F6 文件体系完成业务方案转化，输出结构化的业务方案文档。转化过程遵循"业务语言优先、单一信息源、可追溯性、逐层细化"四大原则。
+
+## 输入
+
+- **业务需求分析文件路径**: 用户在 `$ARGUMENTS` 中提供的需求分析文件路径
+  - 必须是有效的 Markdown 文件路径（如 `docs/00-customer-requirements/M03-02/M03-02_bonded-material_业务需求分析.md`）
+  - 如果输入为空，提示用户输入业务需求分析文件路径
+- **模板文件**: `.adspecs/templates/21-业务方案模板.md` — 业务方案输出模板（F1~F6 结构）
+- **业务功能架构文档**: `{ARCH_DIR}/01-*_business_scenarios.md` 或 `{ARCH_DIR}/01-*_business_architecture.md` — 用于识别需求所属的二级模块
+- **项目上下文**（可选）:
+  - `CLAUDE.md` — 项目技术架构、模块结构
+  - `docs/00-customer-requirements/` — 已有的其他需求分析文档
+
+## 业务方案文件体系（F1~F6）
+
+| 编号   | 名称           | 核心作用                               |
+| ------ | -------------- | -------------------------------------- |
+| F1     | 业务核心逻辑   | 承载业务最底层、最根本的逻辑           |
+| F2     | 业务流程架构   | 流程的分级视图与清单索引               |
+| F3     | 业务流程文件   | 每条流程的完整展开                     |
+| F3附录 | 状态流转汇总   | 跨流程的状态变化全局视图               |
+| F4     | 业务字段清单   | 流程产出物中字段的定义与口径           |
+| F5     | 业务规则清单   | 校验、计算、决策规则的原子化汇集       |
+| F6     | 业务角色与权限 | 角色职责、操作权限、数据范围的正式约定 |
+
+**概览章节**（§1）从需求分析文档的"概览"和元信息中提取。
+
+### 转化原则
+
+1. **业务语言优先**：所有描述使用业务语言，不引入技术实现细节（无数据库、API、框架名称）
+2. **单一信息源**：每条信息只在一个地方定义，其他地方引用（如状态枚举只在 F3 附录定义，F4 字段清单引用）
+3. **可追溯性**：每条业务规则必须能追溯到 F3 中的具体流程步骤
+4. **结构化展开**：F1 → F2 → F3 是逐层细化，不允许跳跃
+
+## 执行前检查
+
+### 检查扩展钩子（转化前）
+
+- 检查项目根目录是否存在 `.adspecs/extensions.yml`。
+- 如果存在，读取它并查找 `hooks.before_biz_blueprint` 下的条目。
+- 如果 YAML 无法解析或无效，静默跳过钩子检查并继续正常执行。
+- 过滤掉 `enabled` 明确为 `false` 的钩子。没有 `enabled` 字段的钩子默认视为启用。
+- 对于每个剩余的钩子，**不要** 尝试解释或评估钩子的 `condition` 表达式：
+  - 如果钩子没有 `condition` 字段，或为空/null，视为可执行。
+  - 如果钩子定义了非空的 `condition`，跳过该钩子，将条件评估留给 HookExecutor 实现。
+- 从钩子命令名构造斜杠命令时，将点号（`.`）替换为连字符（`-`）。例如：`adspecs.git.commit` → `/adspecs-git-commit`。
+- 对于每个可执行钩子，根据其 `optional` 标志输出以下内容：
+  - **可选钩子** (`optional: true`):
+
+    ```
+    ## 扩展钩子
+
+    **可选前置钩子**: {extension}
+    命令: `/{command}`
+    描述: {description}
+
+    提示: {prompt}
+    执行: `/{command}`
+    ```
+
+  - **必选钩子** (`optional: false`):
+
+    ```
+    ## 扩展钩子
+
+    **自动前置钩子**: {extension}
+    执行: `/{command}`
+    EXECUTE_COMMAND: {command}
+
+    等待钩子命令结果后再继续执行。
+    ```
+
+- 如果没有注册钩子或 `.adspecs/extensions.yml` 不存在，静默跳过。
+
+### 步骤 0：参数解析与上下文加载
+
+1. **解析需求分析文件路径**：
+   - 从 `$ARGUMENTS` 中解析业务需求分析文件路径
+   - 如果参数为空 → 使用 **AskUserQuestion** 让用户输入业务需求分析文件路径
+   - 如果参数非空 → 验证文件存在，记为 `REQ_FILE`
+
+2. **需求分析完整性检查**：
+   读取 `REQ_FILE`，验证需求分析文档包含以下必填章节：
+
+   | 检查项         | 需求分析章节 | 用途                        |
+   | -------------- | ------------ | --------------------------- |
+   | 真实问题分析   | 一           | → F1 业务核心逻辑           |
+   | 用户角色分析   | 二           | → F6 业务角色与权限         |
+   | 使用场景拆解   | 三           | → F2 流程架构 + F3 流程详述 |
+   | 业务流程梳理   | 四           | → F1/F3/F3附录/F4/F5        |
+   | 异常和边界     | 五           | → F5 业务规则清单           |
+   | 最终输出与决策 | 六           | → §1 概览 + §8 风险与待确认 |
+
+   **如果缺失必填章节**：列出缺失章节，使用 AskUserQuestion 询问用户是否继续（部分章节可生成占位内容，标注 `[待确认：需求分析缺失 {章节名}，待补充]`）。
+
+3. **加载模板**：
+   - 读取 `.adspecs/templates/21-业务方案模板.md`，获取 F1~F6 文件体系的完整结构
+   - 如果模板不存在，使用内置的转化规则（见下方"步骤 2：按章节转化"）
+
+4. **加载项目上下文**（可选）：
+   - 如果 `CLAUDE.md` 存在，读取以了解项目背景
+   - 如果 `docs/00-customer-requirements/` 下有相关文档，读取以补充需求背景
+
+5. **识别二级模块**：
+   - 扫描 `{ARCH_DIR}/` 目录，查找 `01-*_business_scenarios.md` 或 `01-*_business_architecture.md` 文件
+   - 如果找到，读取文件内容，重点关注：
+     - **二、系统模块总览** → **2.2 子模块清单**：获取所有主模块及其下属的二级模块
+     - **三、各模块业务场景详述**：获取每个模块的业务场景描述
+   - 将需求分析内容与各二级模块的名称、说明、业务场景进行语义匹配，确定需求最匹配的**二级模块编号**（如 M03-02）
+   - 匹配规则：
+     1. **精确匹配**：需求分析中明确提到某个子模块名称或编号 → 直接采用
+     2. **场景匹配**：需求分析的业务场景与某个模块下的场景高度吻合 → 采用该子模块编号
+     3. **语义匹配**：需求分析的核心功能与某个子模块的"说明"字段语义相近 → 采用该子模块编号
+     4. **无法匹配**：需求分析内容与任何二级模块都不匹配 → 使用 AskUserQuestion 让用户选择，或标记为"新模块"
+   - 将匹配到的二级模块编号记为 `MODULE_ID`，对应的主模块编号记为 `PARENT_MODULE`
+   - 如果架构文档不存在，跳过此步骤，`MODULE_ID` 留空
+
+6. **确定输出路径**：
+   - 输出根目录：`{OUTPUT_DIR}/`（默认 `docs/00-customer-requirements/`）
+   - 如果 `MODULE_ID` 已识别（非空）：
+     - 输出子目录：`{OUTPUT_DIR}/{MODULE_ID}/`
+     - 如果子目录不存在，自动创建
+   - 如果 `MODULE_ID` 为空：直接使用 `{OUTPUT_DIR}/`
+   - 输出文件名：`{MODULE_ID}_{short-name}_业务方案.md`（有模块）或 `{short-name}_业务方案.md`（无模块）
+   - 如果目录下已有同名文件，询问用户是覆盖还是新增版本号：`{MODULE_ID}_{short-name}_业务方案_v{version}.md`
+
+## 工作流程
+
+### 步骤 1：读取需求分析文档并提取信息块
+
+读取 `REQ_FILE` 的全部内容，识别并提取信息块与模板文件章节进行匹配：
+
+### 步骤 2：按章节转化（F1~F6）
+
+1. 按照模板结构，将提供源文件内容映射到业务方案各章节，并给出映射详细清单给用户确认。
+2. 按照映射关系，按照模板结构和提示文字，将提供源文件内容深度分析并编制到对应章节，为写入业务方案文件做准备。
+3. 流程图、状态均采用`mermaid`格式绘制
+4. 严禁将用户故事章节做流程转换
+
+#### 2.10 确认签（§9）
+
+生成标准确认签章节，内容固定：
+
+- **§9.1 确认声明**：使用模板固定文本，引用业务方案中的章节编号
+- **§9.2 签署**：生成标准的甲方/乙方签署表，留空待签署
+
+### 步骤 3：交叉引用检查
+
+转化完成后，检查以下交叉引用一致性：
+
+1. **术语一致性**：F1 术语表中的术语在 F3 步骤描述中使用时，含义完全一致
+2. **状态一致性**：F3 附录中的状态枚举值与 F4 字段清单中的枚举值完全一致
+3. **角色一致性**：F3 步骤中的执行角色与 F6 角色清单中的角色完全一致
+4. **规则引用一致性**：F5 规则清单中的"来源流程步骤"指向 F3 中实际存在的步骤
+5. **流程编号一致性**：F2 流程清单中的流程编号与 F3 流程文件的编号一致
+
+如发现不一致，自动修正并在备注中记录修正项。
+
+### 步骤 4：写入业务方案文件
+
+将转化结果写入输出文件：
+
+```
+OUTPUT_DIR   = 路径配置加载阶段解析的值（默认 docs/00-customer-requirements）
+MODULE_ID    = 识别到的二级模块编号（如 M03-02），可能为空
+
+# 有模块编号时：
+OUTPUT_FILE = "{OUTPUT_DIR}/{MODULE_ID}/{MODULE_ID}_{short-name}_业务方案.md"
+# 示例：docs/00-customer-requirements/M03-02/M03-02_bonded-material_业务方案.md
+
+# 无模块编号时（兼容旧行为）：
+OUTPUT_FILE = "{OUTPUT_DIR}/{short-name}_业务方案.md"
+# 示例：docs/00-customer-requirements/bonded-material_业务方案.md
+```
+
+文件头部元信息从需求分析文档继承：
+
+- 项目名称：从需求分析标题提取
+- 模块编号：`MODULE_ID` / `PARENT_MODULE`
+- 版本号：默认 v1.0
+- 创建日期：当前日期
+- 修订记录：生成初始版本记录
+
+**关键原则**：
+
+- 所有描述使用**业务语言**，不引入技术实现细节（无数据库、API、框架名称）
+- 枚举值必须**全量列出**，不允许使用"等"或"其他"
+- 不确定的部分标注 `[待确认：具体问题]`，**全文最多 3 个**
+- Mermaid 图表（flowchart/stateDiagram-v2/erDiagram）必须生成可渲染代码，不使用 ASCII 或占位符
+- 本技能**不修改**原始需求分析文档
+
+### 步骤 5：质量检查（10 项）
+
+逐项验证业务方案的完整性和一致性，每项标注 ✅ 已覆盖 / ⚠️ 部分覆盖 / ❌ 未覆盖，并关联到对应的文档章节：
+
+| #   | 检查项                                      | 状态     | 对应章节 | 补充说明                                                 |
+| --- | ------------------------------------------- | -------- | -------- | -------------------------------------------------------- |
+| 1   | 概览章节与需求分析的核心问题和角色一致      | ✅/⚠️/❌ | §1       | 【基本信息、背景、范围、角色是否完整继承】               |
+| 2   | F1 核心逻辑完整（术语/场景/责任/运作/实体） | ✅/⚠️/❌ | §2 (F1)  | 【术语表有释例、实体关系有 Mermaid 图、核心机制已展开】  |
+| 3   | F2 流程架构完整（编号规则/架构图/流程清单） | ✅/⚠️/❌ | §3 (F2)  | 【流程编号全局唯一、清单覆盖所有 P0/P1 场景对应的流程】  |
+| 4   | F3 每条流程有 Mermaid 流程图 + 步骤说明表   | ✅/⚠️/❌ | §4 (F3)  | 【泳道图可渲染、步骤表含输入/输出/判定/异常】            |
+| 5   | F3 附录状态流转完整（定义/路径/流转图）     | ✅/⚠️/❌ | §4 附录  | 【状态定义与 F4 一致、流转路径关联到 F3 步骤编号】       |
+| 6   | F4 字段清单完整（按产出物分组、枚举全量）   | ✅/⚠️/❌ | §5 (F4)  | 【字段无技术名、枚举值全量列出、状态枚举与 F3 附录一致】 |
+| 7   | F5 规则清单完整（校验/计算/决策分类）       | ✅/⚠️/❌ | §6 (F5)  | 【每条规则有来源步骤、触发时机、不满足时行为】           |
+| 8   | F6 权限矩阵覆盖所有 F3 操作                 | ✅/⚠️/❌ | §7 (F6)  | 【角色清单含来源流程、数据权限有约束条件】               |
+| 9   | 交叉引用一致性（术语/状态/角色/规则/编号）  | ✅/⚠️/❌ | 跨章节   | 【5 项交叉引用检查全部通过】                             |
+| 10  | 全部使用业务语言，无技术实现泄露            | ✅/⚠️/❌ | 全文     | 【无数据库名/API/框架名、枚举无"等"/"其他"】             |
+
+**通过规则**：
+
+- **✅ 全部通过**：10 项均为 ✅ → 业务方案质量合格，可进入 PRD 编写
+- **⚠️ 基本通过**：存在 ⚠️ 但无 ❌ → 标注需补充的具体项，补充后可进入 PRD 编写
+- **❌ 未通过**：存在任意 ❌ → 列出缺失项，自动修复（最多 3 次迭代），修复后重新验证
+
+### 步骤 6：后续建议
+
+根据质量检查结果，给出明确的下一步建议：
+
+- **如果 ✅ 10/10 通过**：
+
+  ```
+  📋 建议下一步执行：/adspecs-prd {需求概要}
+  ```
+
+- **如果 ⚠️ N/10 通过（有 ⚠️ 无 ❌）**：
+
+  ```
+  ⚠️ 在编写 PRD 之前，建议先补充以下信息：
+  1. {未通过的检查项对应的待补充内容}
+  2. {待补充项 2}
+  补充完成后可直接执行 /adspecs-prd
+  ```
+
+- **如果 ❌ N/10 通过（有 ❌）**：
+  ```
+  ❌ 业务方案存在以下问题需要修复：
+  1. {未通过的检查项对应的具体问题}
+  2. {问题 2}
+  已尝试自动修复 {N} 次，仍有 {M} 项需要人工确认
+  ```
+
+## 输出文件结构
+
+> 输出文档按模板的 **§1~§9 + F3 附录** 结构组织。F1~F6 是内容分类维度，映射到 §2~§7 章节。
+
+```markdown
+# {项目名称} — 业务方案
+
+> **版本**: v1.0
+> **创建日期**: {today}
+> **主模块**: {PARENT_MODULE} {主模块名称}
+> **二级模块编号**: {MODULE_ID}
+> **二级模块名称**: {模块名称}
+> **源需求分析**: {REQ_FILE 路径}
+> **适用人员**: 业务顾问、产品经理、需求分析师
+
+| 项           | 值                           |
+| ------------ | ---------------------------- |
+| 主模块       | {PARENT_MODULE} {主模块名称} |
+| 二级模块编号 | {MODULE_ID}                  |
+| 二级模块名称 | {模块名称}                   |
+| 阶段         | Blueprint（Why → What 过渡） |
+| 上游         | ← 01-业务需求分析            |
+| 下游         | → 02-产品需求说明书          |
+
+---
+
+## 修订记录
+
+| 版本 | 日期   | 修订人 | 修订内容                      |
+| ---- | ------ | ------ | ----------------------------- |
+| v1.0 | {日期} | {姓名} | 初始版本：完成 F1~F6 全部编写 |
+
+---
+
+## 1 概览
+
+（从需求分析提取）
+
+## 2 业务核心逻辑（F1）
+
+### 2.1 核心术语对照表
+
+### 2.2 典型场景对比
+
+### 2.3 责任边界与核心原则
+
+### 2.4 核心业务运作逻辑
+
+### 2.5 核心实体关系
+
+### 2.6 生命周期阶段逻辑
+
+### 2.7 核心机制详述
+
+## 3 业务流程架构（F2）
+
+### 3.1 流程编号规则
+
+### 3.2 流程架构图
+
+### 3.3 流程清单
+
+## 4 业务流程文件（F3）
+
+### 流程一：{编号} {名称}
+
+#### 4.1.1 流程图（Mermaid flowchart）
+
+#### 4.1.2 步骤说明表
+
+### 流程二：...
+
+### 附录：状态流转汇总
+
+#### 附-1 状态定义
+
+#### 附-2 状态流转路径
+
+#### 附-3 状态流转图（Mermaid stateDiagram-v2）
+
+## 5 业务字段清单（F4）
+
+### 5.1 {产出物 1} 字段清单
+
+### 5.2 {产出物 2} 字段清单
+
+## 6 业务规则清单（F5）
+
+### 6.1 校验规则
+
+### 6.2 计算规则
+
+### 6.3 决策规则
+
+## 7 业务角色与权限（F6）
+
+### 7.1 角色清单
+
+### 7.2 操作权限矩阵
+
+### 7.3 数据权限范围
+
+### 7.4 权限约束与备注
+
+## 8 风险与待确认问题
+
+### 8.1 风险清单
+
+### 8.2 待确认问题清单
+
+## 9 确认签
+
+### 9.1 确认声明
+
+### 9.2 签署
+```
+
+## 必选执行后钩子
+
+**必须在向用户报告完成之前完成本节。**
+
+检查项目根目录是否存在 `.adspecs/extensions.yml`。
+
+- 如果不存在，或 `hooks.after_biz_blueprint` 下没有注册钩子，跳到完成报告。
+- 如果存在，读取它并查找 `hooks.after_biz_blueprint` 下的条目。
+- 如果 YAML 无法解析或无效，静默跳过钩子检查并继续完成报告。
+- 过滤掉 `enabled` 明确为 `false` 的钩子。没有 `enabled` 字段的钩子默认视为启用。
+- 对于每个剩余的钩子，**不要** 尝试解释或评估钩子的 `condition` 表达式：
+  - 如果钩子没有 `condition` 字段，或为空/null，视为可执行。
+  - 如果钩子定义了非空的 `condition`，跳过该钩子，将条件评估留给 HookExecutor 实现。
+- 从钩子命令名构造斜杠命令时，将点号（`.`）替换为连字符（`-`）。例如：`adspecs.git.commit` → `/adspecs-git-commit`。
+- 对于每个可执行钩子，根据其 `optional` 标志输出以下内容：
+  - **必选钩子** (`optional: false`) — **必须为每个必选钩子发出 `EXECUTE_COMMAND:`**：
+
+    ```
+    ## 扩展钩子
+
+    **自动钩子**: {extension}
+    执行: `/{command}`
+    EXECUTE_COMMAND: {command}
+    ```
+
+  - **可选钩子** (`optional: true`):
+
+    ```
+    ## 扩展钩子
+
+    **可选钩子**: {extension}
+    命令: `/{command}`
+    描述: {description}
+
+    提示: {prompt}
+    执行: `/{command}`
+    ```
+
+## 完成报告
+
+向用户报告完成情况，包含：
+
+```markdown
+✅ 业务方案生成完成
+
+## 转化结果
+
+| 项目       | 详情                          |
+| ---------- | ----------------------------- |
+| 源需求分析 | {REQ_FILE 路径}               |
+| 业务方案   | {OUTPUT_FILE 路径}            |
+| 所属模块   | {PARENT_MODULE} > {MODULE_ID} |
+
+## 文件体系生成情况
+
+| 章节                   | 状态      | 来源需求分析章节        |
+| ---------------------- | --------- | ----------------------- |
+| §1 概览                | ✅ 已生成 | 一·真实问题 + 六·决策   |
+| §2 业务核心逻辑 (F1)   | ✅ 已生成 | 一 + 四·4.1/4.2         |
+| §3 业务流程架构 (F2)   | ✅ 已生成 | 三·场景清单 + 四·主流程 |
+| §4 业务流程文件 (F3)   | ✅ 已生成 | 三 + 四·4.1/4.3 + 五    |
+| F3 附录 状态流转       | ✅ 已生成 | 四·4.2 状态机           |
+| §5 业务字段清单 (F4)   | ✅ 已生成 | 四·4.1 输入/输出        |
+| §6 业务规则清单 (F5)   | ✅ 已生成 | 四·4.1 判断 + 五·异常   |
+| §7 业务角色与权限 (F6) | ✅ 已生成 | 二·角色 + 权限矩阵      |
+| §8 风险与待确认问题    | ✅ 已生成 | 六·风险与待补充         |
+| §9 确认签              | ✅ 已生成 | 模板固定文本            |
+
+## 质量验证
+
+- 检查项通过：{N}/10
+- 自动修复项：{N}
+- 待人工确认项：{N}（列出具体项）
+
+## 后续建议
+
+1. 人工复核交叉引用一致性（特别是状态枚举值和角色权限）
+2. 可继续执行 `/adspecs-prd` 基于业务方案编写产品需求说明书
+3. 如需导出 Word，可执行 `/adspecs-export-word`（Mermaid 图将自动渲染）
+```
+
+## 与上下游的关系
+
+| 上游                                     | 本 skill                | 下游                     |
+| ---------------------------------------- | ----------------------- | ------------------------ |
+| `adspecs-new-requirement` → 需求分析文档 | `adspecs-biz-blueprint` | → `adspecs-prd` PRD 编写 |
+
+- **输入**：业务需求分析文档（由 `/adspecs-new-requirement` 生成）
+- **输出**：业务方案文件（F1~F6 体系）
+- **下游消费**：PRD 编写（`/adspecs-prd`）引用业务方案中的 F3 流程步骤、F4 字段定义、F5 规则清单、F6 权限矩阵，构建用户故事和功能描述
+
+## 快速指南
+
+### 基本用法
+
+```bash
+# 转换指定需求分析文件
+/adspecs-biz-blueprint docs/00-customer-requirements/M03-02/M03-02_bonded-material_业务需求分析.md
+
+# 如无参数，将提示输入需求分析文件路径
+/adspecs-biz-blueprint
+```
+
+### 转化策略
+
+1. **结构化提取**：角色、场景、流程步骤、规则等按表格结构化提取
+2. **语义分类**：业务规则按校验/计算/决策分类，基于规则描述的语义
+3. **逐层细化**：F1（逻辑）→ F2（架构）→ F3（详述）严格逐层展开
+4. **Mermaid 图表**：所有流程图、状态流转图、实体关系图均使用 Mermaid 格式生成
+5. **待确认标注**：信息不足时用 `[待确认：具体问题]` 标注，全文最多 3 个
+
+### 注意事项
+
+- 本技能**不修改**原始需求分析文档
+- 业务方案输出到 `docs/00-customer-requirements/{MODULE_ID}/` 目录
+- 如果输出文件已存在，询问用户是否覆盖
+- 业务方案中所有描述使用**业务语言**，不引入技术实现细节
+- 枚举值必须**全量列出**，不允许使用"等"或"其他"
+
+## 完成标志
+
+- [ ] 已解析用户输入（需求分析文件路径）
+- [ ] 需求分析文档已读取并完整性验证
+- [ ] 已扫描 `{ARCH_DIR}/` 并识别匹配的二级模块编号 `MODULE_ID`
+- [ ] 业务方案 §1~§9 + F3 附录已全部生成
+- [ ] 交叉引用一致性已检查（术语/状态/角色/规则/编号 5 项）
+- [ ] 10 项质量检查已逐项验证（概览/F1/F2/F3/附录/F4/F5/F6/交叉引用/业务语言）
+- [ ] 业务方案文件已写入 `{OUTPUT_DIR}/{MODULE_ID}/{MODULE_ID}_{name}_业务方案.md`
+- [ ] 质量检查结果（N/10）和下一步建议已输出
+- [ ] 扩展钩子已根据规则分发或跳过