@zhanlucode/zl-darwin-arm64 1.6.4-moma.0

package/bin/zhanlu-plugins/lingji-alpha-assistant/skills/requirement-analysis/SKILL.md

@@ -0,0 +1,346 @@
+---
+name: requirement_analysis
+description: |
+  需求分析技能，用于对研发空间中的新建/分析状态需求进行深度分析优化，生成需求分析文档并回传灵畿平台。当用户提到"帮我分析需求""帮我分析xx空间需求""帮我分析xx版本需求""帮我分析xx、xx需求""需求分析""分析需求"等表述时触发此技能。即使用户没有明确说"分析"，但表达了需要对需求进行深化、完善、补充、评估的场景，也应使用此技能。该技能会查询用户作为负责人的新建/分析状态需求，对每条需求进行优化扩写（补充业务背景、完善需求描述、细化验收标准、评估可行性），生成结构化的需求分析 Markdown 文档，并支持将分析结果回传灵畿平台更新需求字段。
+---
+
+# 需求分析
+
+对研发空间中的新建/分析状态初始需求进行深度分析优化，生成结构化需求分析文档，并支持回传灵畿平台。
+
+
+## 品牌用字（强制）
+
+完整正确/禁止对照见 `packages/opencode/src/kilocode/brand-naming.md`（运行时每轮也会注入，请勿在本 Skill 正文复述禁止用字以免污染模型上下文）。
+
+- 平台名写「灵畿平台」；助手名写「灵畿α助手」
+- 产品名写「湛卢」「湛卢 IDE」
+- 账号登录语义写「登录」
+
+登录失效、回传平台、引导用户重新认证时，一律使用上述正确写法，不得近音替换。
+
+
+## 流程
+
+**重要：本流程的 10 个步骤是连续执行的，从第 1 步到第 10 步必须依次完成，不要在任意步骤之间停下等待用户输入（第 4 步、第 5 步、第 9 步使用 question 工具与用户交互除外）。特别地，第 1 步身份解析完成后，必须立即继续执行第 2 步及后续步骤，不要停在身份解析结果处。**
+
+### 第 1 步：身份解析
+
+从本地认证文件读取当前用户身份信息。
+
+**路径：** C:\Users\Admin\.local\share\zhanlu\auth_zhanlu.json
+
+从 metadata 中提取：
+
+| 字段         | 说明         |
+| ------------ | ------------ |
+| `email`    | 用户邮箱地址 |
+| `userName` | 用户中文姓名 |
+
+将邮箱后缀统一转换为 `@cmss.cmcc`：
+```
+zhangsan@cmss.chinamobile.com → zhangsan@cmss.cmcc
+```
+
+输出身份检测结果：
+```
+用户身份：
+- 中文名：张三
+- 邮箱（需求系统）：zhangsan@cmss.cmcc
+```
+
+### 第 2 步：提取查询条件
+
+从用户请求中提取分析范围条件：
+
+| 用户说法                   | 含义                                   |
+| -------------------------- | -------------------------------------- |
+| "帮我分析需求"             | 分析我作为负责人的所有新建/分析状态需求 |
+| "帮我分析xx空间需求"       | 分析指定空间内我作为负责人的新建/分析状态需求 |
+| "帮我分析xx版本需求"       | 分析指定版本下我作为负责人的新建/分析状态需求 |
+| "帮我分析xx、xx需求"       | 分析指定需求Key或标题的需求             |
+
+**模糊匹配规则：**
+- 空间名称：支持部分匹配，如"研发大模型"可匹配"研发大模型关键技术研发"
+- 版本名称：支持部分匹配，如"V2.7"可匹配"V2.7.2版本-V2.7.2"
+- 需求Key/标题：支持部分匹配，如"873"可匹配"CMSSR2511D2DC03-873"，"一致性"可匹配"需求代码一致性检查"
+
+如果用户指定了多个条件（如"xx空间+xx版本"），取交集。
+
+**默认查询状态：** 新建、分析。查询时 `statusName` 传入 `["新建", "分析"]`。
+
+**负责人匹配：** 查询条件中需过滤 assignee（负责人）包含当前用户的需求。在调用 MCP 查询时，使用 `values__assignee` 参数传入当前用户邮箱进行过滤。如果通过 MCP 无法直接按 assignee 过滤，则查询后在返回结果中筛选 assignee 包含当前用户邮箱的记录。
+
+### 第 3 步：调用 MCP 拉取需求
+
+调用 `cmdevops-req_list_req_item` 执行需求查询。
+
+**查询参数：**
+- `itemTypeName`: ["初始需求"]
+- `statusName`: ["新建", "分析"]
+- `values__assignee`: [当前用户邮箱]
+- `workspaceName`: 如果指定了空间，传入空间名称（支持模糊，可多传几个可能的空间名让 MCP 返回后二次筛选）
+- `key`: 如果指定了需求Key，传入
+- `name`: 如果指定了需求标题关键词，传入
+
+如果一次查询结果不足，可多次分页查询（调整 `from` 参数）直到拉取全部。
+
+### 第 4 步：IDE 交互 — 确认分析范围
+
+将查询到的需求按空间分组，展示给用户确认：
+
+```
+📋 需求分析范围确认
+
+空间：研发大模型关键技术研发（CMSSR2511D2DC03）
+待分析需求：3 条
+  1. CMSSR2511D2DC03-873 | 需求代码一致性检查 | 状态：新建
+  2. CMSSR2511D2DC03-889 | AI辅助创建用户故事 | 状态：分析
+  3. CMSSR2511D2DC03-874 | 需求合规性检查 | 状态：新建
+
+以上是否为您要分析的需求？如需调整范围，请告知。
+```
+
+使用 `question` 工具让用户确认，选项包括：
+- 确认，继续分析
+- 调整范围（用户可说明增减哪些需求）
+
+### 第 5 步：确认文档保存路径
+
+用户确认分析范围后，询问文档保存路径：
+
+```
+请确认需求分析文档保存路径：
+- 默认路径：当前项目 doc/ 目录下
+- 文件名格式：需求编号+需求标题.md（如 CMSSR2511D2DC03-873_需求代码一致性检查.md）
+```
+
+使用 `question` 工具让用户选择：
+- 使用默认路径（doc/）
+- 自定义路径（用户输入）
+
+### 第 6 步：逐条分析需求
+
+对每条需求进行深度分析优化，包括以下工作：
+
+#### 6.1 业务背景补充
+
+检查需求的 `businessBackground`（业务背景）字段：
+- 如果为空或内容过于简略，基于需求标题和描述推导补充业务背景
+- 补充内容应包含：需求来源、当前痛点、预期价值
+- 如果已有完整业务背景，保留原文不做修改
+
+#### 6.2 需求描述完善
+
+检查需求的 `requirement`（需求描述）字段：
+- 如果描述模糊或过于简略，进行扩写和完善
+- 完善方向：明确功能范围、核心交互流程、输入输出、关键约束条件
+- 使用清晰的技术语言，消除模糊表述（如"等""相关"需具体化）
+- 如果已有完整需求描述，在原基础上补充可能遗漏的细节
+
+#### 6.3 验收标准细化
+
+检查需求的 `acceptanceCriteria`（验收标准）字段：
+- 如果为空或过于定性，细化为可量化、可验证的验收条目
+- 每条验收标准应包含：具体的操作场景 + 预期结果
+- 覆盖正常路径和主要异常场景
+- 如果已有详细验收标准，检查是否有遗漏的关键场景并补充
+
+#### 6.4 可行性分析评估
+
+对需求进行可行性分析：
+- **技术可行性**：评估技术实现路径，识别技术风险和难点
+- **时间可行性**：评估计划时间是否充足
+- **依赖识别**：识别外部系统/接口/数据依赖
+- 给出可行性结论：可行 / 需求不可行（需说明原因）
+
+### 第 7 步：生成需求分析文档
+
+按照以下模板为每条需求生成独立的 Markdown 文档，并**必须使用 `write` 工具将文档写入第 5 步确认的文件路径**。不要仅在对话中展示文档内容，必须将完整内容写入文件。如果目录不存在，需先创建目录。
+
+**文件名格式：** `{需求Key}_{需求标题}.md`（文件名中的特殊字符用下划线替代）
+
+**文档模板：**
+
+参考 `requirements-gather` 的完整需求字段模板，在文档顶部展示需求的完整字段信息，下方附加分析内容。
+
+#### 单个需求文档模板
+
+```markdown
+# {需求标题}
+
+## 项目信息
+
+- **空间名称**: [workspace.name]
+- **项目编码**: [projectNo]
+- **项目名称**: [projectName]
+- **产品名称**: [productName]
+
+## 需求字段
+
+| 字段 | 值 |
+|------|-----|
+| 需求Key | [需求Key] |
+| 标题 | [需求标题] |
+| 类型 | [itemType.name，如"初始需求"] |
+| 负责人 | [assignee，格式：姓名(邮箱)] |
+| 提出人 | [proposer，格式：姓名(邮箱)] |
+| 优先级 | [priorityName] |
+| 业务背景 | [原始 businessBackground 字段值，如为空填"未提供"] |
+| 需求描述 | [原始 requirement 字段值，如为空填"未提供"] |
+| 验收标准 | [原始 acceptanceCriteria 字段值，如为空填"未提供"] |
+| 计划开始时间 | [plannedStartTime，如为空填"未提供"] |
+| 计划结束时间 | [plannedEndTime，如为空填"未提供"] |
+| 期望完成时间 | [expectedCompletionTime，如为空填"未提供"] |
+| 关联产品/业务平台类型 | [selectProduct，如为空填"未提供"] |
+| 选择对应产品/业务平台 | [productName，如为空填"未提供"] |
+| 关联项目 | [projectName，如为空填"未提供"] |
+| 关联版本 | [associatedVersion，如为空填"未提供"] |
+| 迭代 | [sprint，如为空填"未提供"] |
+| 父需求 | [parentItemKey，如无则填空] |
+| 需求 URL | [detailUrl，如无则填空] |
+
+## 需求内容
+
+### 业务背景
+
+（原始字段：[原始 businessBackground 值，如为空则写"空"]）
+
+（分析补充）
+
+[完善后的业务背景内容。如果原始字段为空，标注"（原始字段为空，以下为分析补充）"后写入补充内容；如果原始字段有内容但需要补充，标注"（原始内容）"和"（补充内容）"区分。]
+
+### 需求描述
+
+（原始字段：[原始 requirement 值，如为空则写"空"]）
+
+（分析补充）
+
+[完善后的需求描述内容。格式同业务背景的处理方式。]
+
+### 验收标准
+
+（原始字段：[原始 acceptanceCriteria 值，如为空则写"空"]）
+
+（分析补充）
+
+[细化后的验收标准内容。格式同业务背景的处理方式。]
+
+## 可行性分析
+
+| 字段 | 值 |
+|------|-----|
+| 可行性结论 | 可行 / 需求不可行 |
+| 不可行原因 | [如果结论为"需求不可行"，说明原因；如果"可行"，填"无"] |
+| 技术可行性分析 | [技术实现路径评估] |
+| 时间可行性分析 | [计划时间评估] |
+| 外部依赖 | [识别的外部依赖，无则填"无"] |
+```
+
+#### 多个需求文档模板
+
+如果一次分析多条需求，**每个需求生成独立文件**，每个文件都使用上述完整模板。不要将多个需求合并在同一文件中。
+
+### 第 8 步：展示执行结果
+
+文档生成后，向用户展示：
+
+```
+✅ 需求分析完成
+
+📁 文档生成路径：[路径]
+📄 生成文件：
+   - CMSSR2511D2DC03-873_需求代码一致性检查.md
+   - CMSSR2511D2DC03-889_AI辅助创建用户故事.md
+   - CMSSR2511D2DC03-874_需求合规性检查.md
+```
+
+### 第 9 步：询问是否回传灵畿平台
+
+使用 `question` 工具询问用户是否将分析结果回传灵畿平台：
+
+```
+是否将需求分析结果回传灵畿平台？
+回传操作将更新每条需求的业务背景、需求描述、验收标准等字段。
+```
+
+选项：
+- 确认回传
+- 暂不回传（仅保留本地文档）
+
+如果用户选择"暂不回传"，流程结束。
+
+### 第 10 步：执行需求回传
+
+如果用户确认回传，对每条需求更新需求字段：
+
+调用 `cmdevops-req_update_req_initial_requirement` 更新需求字段：
+
+- `objectId`: 需求的 objectId
+- `values` 中需更新的字段：
+  - `businessBackground`: 第 7 步文档中的完善后业务背景
+  - `requirement`: 第 7 步文档中的完善后需求描述
+  - `acceptanceCriteria`: 第 7 步文档中的细化后验收标准
+  - `feasibilityAssessment`: 第 7 步文档中的可行性分析结论（如无可行性评估字段，可将此信息写入 notes 字段）
+  - `notes`: 追加可行性分析摘要（如"技术可行，无外部依赖"等简要结论）
+
+**注意：** 只回传非空的分析内容。如果某个字段在原始需求和本次分析中均无内容，不传入该字段。
+
+**回传文本格式规范（重要）：**
+
+灵畿平台内部使用富文本格式存储字段内容，直接传入 Markdown 格式文本会导致排版错乱。回传时必须遵循以下格式规范：
+
+**禁止使用的格式字符：**
+- 多级标题符号：#、##、###
+- 表格语法：|、:、---
+- 复杂列表符号：-、*、+（用数字点 . 替代）
+- Markdown 链接语法：[text](url)
+- 强制换行符：\n（段落间用句号或分号分隔即可）
+
+**推荐使用的格式：**
+1. 使用简洁段落文本，以句子和逗号、句号为分隔，避免强制换行
+2. 使用数字编号 1. 2. 3. 作为列表标记，避免使用 - 或 *
+3. 用中文标点替代：列表分隔使用 、或 ；，避免使用 |
+4. 段落间用句号 . 或分号 ；分隔
+
+**正确格式示例：**
+- businessBackground: "需求来源：用户在使用云硬盘服务时，需要了解历史使用情况以便进行成本分析。当前痛点：云硬盘服务缺少历史使用记录查询功能。预期价值：提供完整的云硬盘使用历史记录查询能力，支持多维度筛选。"
+- requirement: "在云硬盘服务中新增查询历史使用记录功能。核心功能：1.提供统一的API接口，支持分页查询；2.支持按时间范围、云硬盘ID、操作类型筛选；3.返回完整的操作信息；4.记录按操作时间倒序排列。"
+- acceptanceCriteria: "1.基础功能验证：输入有效的云硬盘ID列表，返回对应的历史使用记录。2.时间范围查询：支持按时间范围筛选。3.操作类型筛选：支持按操作类型筛选。4.分页功能：默认20条，最大100条。5.数据准确性：记录按操作时间倒序排列。6.异常处理：输入无效参数时返回错误提示。"
+
+**错误格式示例（禁止使用）：**
+- "## 需求来源\n用户需要...\n\n## 当前痛点"
+- "- 功能1\n- 功能2\n* 功能3"
+- "| 测试项 | 预期结果 |\n|------|----------|"
+
+**文本长度控制：**
+- 单个字段文本建议控制在 2000 字符以内
+- 如分析内容过长，可适当精简后回传
+- 本地文档保留完整分析内容，仅回传精简版本
+
+#### 10.1 展示回传结果
+
+所有需求回传完成后，展示结果：
+
+```
+✅ 需求回传完成
+
+| 需求 | 字段更新 |
+|------|----------|
+| CMSSR2511D2DC03-873 需求代码一致性检查 | ✅ 已更新 |
+| CMSSR2511D2DC03-889 AI辅助创建用户故事 | ✅ 已更新 |
+| CMSSR2511D2DC03-874 需求合规性检查 | ✅ 已更新 |
+```
+
+如果某条需求回传失败，标注失败原因并建议用户手动处理。
+
+## 注意事项
+
+- 所有字段值为空时标注"未提供"或"未指定"，不做臆测
+- 需求描述的扩写基于原始内容的语义延伸，不引入原始需求未涉及的功能范围
+- 业务背景补充必须基于需求标题和描述推导，不凭空编造业务场景
+- 验收标准的细化需与需求描述保持一致，不超出需求描述的功能边界
+- 时间字段保持原始格式，不做转换
+- 人员名字后跟随邮箱不要省略
+- 如果需求量大（>10条），建议分批分析，每批不超过10条
+- 文件名中的特殊字符（/\\:*?"<>|）用下划线替代

package/bin/zhanlu-plugins/lingji-alpha-assistant/skills/requirement-review/SKILL.md

@@ -0,0 +1,267 @@
+---
+name: requirement_review
+description: |
+  需求审核技能，用于审核研发空间中的需求质量并生成审核意见文档。当用户提到"审核需求""需求审核""帮我审核需求""审核xx空间需求""审核xx版本需求""审核xx需求""检查需求质量""需求评审"等表述时触发此技能。即使用户没有明确说"审核"，但表达了检查需求完整性、规范性、质量的意图，也应使用此技能。该技能会查询用户作为负责人的待审核需求，按完整性、清晰性、可测试性、一致性、可行性五个维度逐条审核，生成包含审核意见（通过/不通过）及问题描述的 Markdown 文档，并将文档写入文件。
+---
+
+# 需求审核
+
+对研发空间中的需求进行质量审核，生成包含审核意见的 Markdown 文档。
+
+## 流程
+
+**重要：本流程的 8 个步骤是连续执行的，从第 1 步到第 8 步必须依次完成，不要在任意步骤之间停下等待用户输入（第 4 步和第 5 步使用 question 工具与用户交互除外）。特别地，第 1 步身份解析完成后，必须立即继续执行第 2 步及后续步骤，不要停在身份解析结果处。**
+
+### 第 1 步：身份解析
+
+从本地认证文件读取当前用户身份信息。
+
+**路径：** `C:\Users\Admin\.local\share\zhanlu\auth_zhanlu.json`
+
+从 `metadata` 中提取：
+
+| 字段         | 说明         |
+| ------------ | ------------ |
+| `email`    | 用户邮箱地址 |
+| `userName` | 用户中文姓名 |
+
+将邮箱后缀统一转换为 `@cmss.cmcc`：
+```
+zhangsan@cmss.chinamobile.com → zhangsan@cmss.cmcc
+```
+
+输出身份检测结果：
+```
+用户身份：
+- 中文名：张三
+- 邮箱（需求系统）：zhangsan@cmss.cmcc
+```
+
+### 第 2 步：提取查询条件
+
+从用户请求中提取审核范围条件：
+
+| 用户说法                   | 含义                         |
+| -------------------------- | ---------------------------- |
+| "帮我审核需求"             | 审核我作为负责人的所有待审核需求 |
+| "帮我审核xx空间需求"       | 审核指定空间内我作为负责人的待审核需求 |
+| "帮我审核xx版本需求"       | 审核指定版本下我作为负责人的待审核需求 |
+| "帮我审核xx、xx需求"       | 审核指定需求Key或标题的需求   |
+
+**模糊匹配规则：**
+- 空间名称：支持部分匹配，如"研发大模型"可匹配"研发大模型关键技术研发"
+- 版本名称：支持部分匹配，如"V2.7"可匹配"V2.7.2版本-V2.7.2"
+- 需求Key/标题：支持部分匹配，如"873"可匹配"CMSSR2511D2DC03-873"，"一致性"可匹配"需求代码一致性检查"
+
+如果用户指定了多个条件（如"xx空间+xx版本"），取交集。
+
+**默认审核状态：** 如果用户未指定状态，默认查询"评审完成"状态的需求（即待审核状态）。如果用户明确指定了状态，按用户指定的状态查询。
+
+**负责人匹配：** 查询条件中需过滤 assignee（负责人）包含当前用户的需求。在调用 MCP 查询时，使用 `values__assignee` 参数传入当前用户邮箱进行过滤。如果通过 MCP 无法直接按 assignee 过滤，则查询后在返回结果中筛选 assignee 包含当前用户邮箱的记录。
+
+### 第 3 步：调用 MCP 拉取需求
+
+调用 `cmdevops-req_list_req_item` 执行需求查询。
+
+**查询参数：**
+- `itemTypeName`: ["初始需求", "用户故事"]
+- `statusName`: 根据第 2 步确定的状态（默认为 ["评审完成"]）
+- `values__assignee`: [当前用户邮箱]（按负责人筛选）
+- `workspaceName`: 如果指定了空间，传入空间名称（支持模糊，可多传几个可能的空间名让 MCP 返回后二次筛选）
+- `key`: 如果指定了需求Key，传入
+- `name`: 如果指定了需求标题关键词，传入
+
+如果一次查询结果不足，可多次分页查询（调整 `from` 参数）直到拉取全部。
+
+### 第 4 步：IDE 交互 — 确认审核范围
+
+将查询到的需求按空间分组，展示给用户确认：
+
+```
+📋 审核需求范围确认
+
+空间：研发大模型关键技术研发（CMSSR2511D2DC03）
+待审核需求：3 条
+  1. CMSSR2511D2DC03-873 | 需求代码一致性检查
+  2. CMSSR2511D2DC03-889 | ＡＩ辅助创建用户故事
+  3. CMSSR2511D2DC03-874 | 需求合规性检查
+
+以上是否为您要审核的需求？如需调整范围，请告知。
+```
+
+使用 `question` 工具让用户确认，选项包括：
+- 确认，继续审核
+- 调整范围（用户可说明增减哪些需求）
+
+### 第 5 步：确认文档保存路径
+
+用户确认审核范围后，询问文档保存路径：
+
+```
+请确认审核文档保存路径：
+- 默认路径：当前项目 prd/ 目录下
+- 文件名格式：需求审核_YYYYMMDD.md
+```
+
+使用 `question` 工具让用户选择：
+- 使用默认路径
+- 自定义路径（用户输入）
+
+### 第 6 步：逐条审核需求
+
+对每条需求按以下五个维度进行审核，每个维度包含具体的检查点：
+
+#### 维度一：完整性
+
+| 检查点 | 说明 | 判定标准 |
+|--------|------|----------|
+| 业务背景 | 是否说明了需求的来源、痛点和预期价值 | 业务背景字段非空且有实质内容 |
+| 需求描述 | 是否完整描述了功能范围 | 需求描述字段非空，包含功能范围和核心交互 |
+| 验收标准 | 是否覆盖主要功能路径和预期结果 | 验收标准字段非空，包含可验证的结果描述 |
+| 关联信息 | 是否关联了项目、系统、版本 | 项目、系统字段非空；版本字段视情况而定（非强制） |
+| 计划时间 | 是否有合理的计划开始/结束时间 | 计划时间字段非空且结束时间晚于开始时间 |
+
+#### 维度二：清晰性
+
+| 检查点 | 说明 | 判定标准 |
+|--------|------|----------|
+| 语义明确 | 需求描述是否无歧义，概念是否定义清晰 | 无模糊表述（如"等""相关"无具体指向），关键术语有定义 |
+| 边界清晰 | 功能边界是否明确，输入输出是否清晰 | 明确了做什么和不做什么，输入输出格式有说明 |
+| 量化标准 | 验收标准是否可量化 | 验收标准包含具体的指标或判定条件，而非仅定性描述 |
+| 颗粒度 | 需求拆分颗粒度是否合理 | 单条需求描述的功能范围适中，不过大（跨多个独立功能）也不过小 |
+
+#### 维度三：可测试性
+
+| 检查点 | 说明 | 判定标准 |
+|--------|------|----------|
+| 验收可验证 | 验收标准是否可直接转化为测试用例 | 每条验收标准可映射到具体的测试操作和预期结果 |
+| 异常场景 | 是否覆盖了异常和边界场景 | 包含输入异常、权限异常、超时/失败等场景的处理说明 |
+| 性能指标 | 对性能/准确性有要求的场景是否定义了指标 | AI类需求需定义准确率、响应时间等；非AI类视情况而定 |
+
+#### 维度四：一致性
+
+| 检查点 | 说明 | 判定标准 |
+|--------|------|----------|
+| 内部一致 | 需求描述与验收标准是否一致 | 验收标准完整覆盖需求描述中的功能点，无矛盾 |
+| 优先级匹配 | 优先级与业务价值/紧急程度是否匹配 | P0/P1 需求应有充分的业务价值说明 |
+| 外部一致 | 与同空间其他需求是否存在冲突或重叠 | 同空间需求间功能边界不重叠，无矛盾定义 |
+
+#### 维度五：可行性
+
+| 检查点 | 说明 | 判定标准 |
+|--------|------|----------|
+| 技术可行性 | 是否已做可行性评估 | 可行性评估字段非空且结论为"可行" |
+| 时间可行性 | 计划时间是否充足 | 结束时间与开始时间之间的间隔合理，未出现已过期但仍未推进 |
+| 依赖明确 | 外部依赖是否已识别和说明 | 如依赖其他系统/接口/数据，需明确说明 |
+
+#### 审核意见判定规则
+
+每条需求根据五个维度的审核结果，给出整体审核意见：
+
+| 审核意见 | 判定条件 |
+|----------|----------|
+| ✅ 通过 | 五个维度均无问题，或仅有低严重度问题 |
+| ⚠️ 有条件通过 | 存在中严重度问题但不影响核心功能理解和测试 |
+| ❌ 不通过 | 存在高严重度问题，影响需求的核心功能定义、可测试性或一致性 |
+
+**严重度分级：**
+- **高**：关键信息缺失（业务背景空、验收标准空）、需求描述与验收标准矛盾、核心功能定义不清
+- **中**：边界条件缺失、量化标准不足、异常场景未覆盖
+- **低**：关联版本未填写、计划时间已过期但仍在推进、非核心字段缺失
+
+### 第 7 步：生成审核文档
+
+按照以下模板生成 Markdown 审核文档，并**必须使用 `write` 工具将文档写入第 5 步确认的文件路径**。不要仅在对话中展示文档内容，必须将完整内容写入文件。如果目录不存在，需先创建目录。
+
+```markdown
+# 需求审核报告
+
+**审核人**：[用户中文名]（[用户邮箱]）
+**审核日期**：[YYYY-MM-DD]
+**审核范围**：[空间名称]（[空间Key]）
+
+---
+
+## 审核概览
+
+| 指标 | 数量 |
+|------|------|
+| 审核需求总数 | [N] |
+| ✅ 通过 | [N] |
+| ⚠️ 有条件通过 | [N] |
+| ❌ 不通过 | [N] |
+
+---
+
+## 需求 1：[需求Key] — [需求标题]
+
+**审核意见：** ✅ 通过 / ⚠️ 有条件通过 / ❌ 不通过
+
+**基本信息：**
+
+| 字段 | 值 |
+|------|-----|
+| 需求Key | [填写] |
+| 标题 | [填写] |
+| 类型 | [初始需求/用户故事] |
+| 负责人 | [填写] |
+| 提出人 | [填写] |
+| 优先级 | [填写] |
+| 计划开始时间 | [填写] |
+| 计划结束时间 | [填写] |
+
+**审核明细：**
+
+| 维度 | 审核结果 | 问题描述 |
+|------|----------|----------|
+| 完整性 | ✅/⚠️/❌ | [问题描述，无问题则填"无"] |
+| 清晰性 | ✅/⚠️/❌ | [问题描述] |
+| 可测试性 | ✅/⚠️/❌ | [问题描述] |
+| 一致性 | ✅/⚠️/❌ | [问题描述] |
+| 可行性 | ✅/⚠️/❌ | [问题描述] |
+
+**问题清单：**
+
+| 序号 | 严重程度 | 问题描述 | 改进建议 |
+|------|----------|----------|----------|
+| 1 | 高/中/低 | [具体问题描述] | [改进建议] |
+
+---
+
+## 需求 2：[需求Key] — [需求标题]
+
+（同上格式）
+
+---
+
+## 共性问题汇总
+
+| 共性问题 | 涉及需求 | 建议 |
+|----------|----------|------|
+| [问题描述] | [需求Key列表] | [改进建议] |
+```
+
+### 第 8 步：展示执行结果
+
+审核文档生成后，向用户展示：
+
+```
+✅ 需求审核完成
+
+📄 审核文档已生成：[文件路径]
+📋 审核概览：
+   - 审核需求总数：3
+   - ✅ 通过：1
+   - ⚠️ 有条件通过：1
+   - ❌ 不通过：1
+```
+
+## 注意事项
+
+- 所有字段值为空时标注"未提供"，不做臆测
+- 审核意见基于需求文档的现有内容判定，不依赖外部知识
+- 时间字段保持原始格式，不做转换
+- 人员名字后跟随邮箱不要省略
+- 如果查询结果为空（无待审核需求），告知用户"当前没有找到您作为负责人的待审核需求"，并建议检查空间范围或状态条件
+- 空间、版本、需求名称支持模糊匹配，匹配后需与用户确认
+- 如果需求量较大（>10条），建议分批审核，每批不超过10条