@zhanlucode/zl-darwin-arm64 1.5.87028

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

@@ -0,0 +1,350 @@
+---
+name: beta_requirement_review
+description: |
+  beta 环境需求审核技能，用于审核 beta 环境（演示/测试环境）中的需求质量并生成审核报告。当用户提到"审核需求""需求审核""帮我审核需求""审核xx项目需求""beta环境审核""演示项目审核""检查需求质量"等表述时触发。即使用户没有明确说"beta"，但明确指定演示项目、beta 环境功能验证测试等测试类项目时，也应使用此 skill。与 `requirement-review` 的差异：固定使用 lingji-beta MCP、默认拉取"分析+规划"状态、输出单份汇总报告到 prd/review/ 目录、文件名带 Beta_ 前缀、增加 description 三小节（【需求背景】/【需求价值】/【需求详情】）专项检查、字段基于实际 beta 数据结构调整。
+---
+
+# beta 环境需求审核
+
+> 对 beta 环境中的需求进行质量审核：默认审核"分析+规划"状态的需求，按五维度（完整性/清晰性/可测试性/一致性/可行性）+ description 三小节专项检查逐条审核，生成单份汇总审核报告到 `prd/review/` 目录。
+
+## 流程
+
+**重要：本流程的 7 个步骤是连续执行的，从第 1 步到第 7 步必须依次完成，不要在任意步骤之间停下等待用户输入（第 4 步和第 5 步使用 question 工具与用户交互除外）。特别地，第 1 步身份解析完成后，必须立即继续执行第 2 步及后续步骤，不要停在身份解析结果处。**
+
+### 第 1 步：身份解析
+
+从本地认证文件读取当前用户身份信息。
+
+- **Windows 路径**：`C:\Users\Admin\.local\share\zhanlu\auth_zhanlu.json`
+- **macOS / Linux 路径**：`~/.local/share/zhanlu/auth_zhanlu.json`
+
+从 `metadata` 中提取 `email` 与 `userName`，将邮箱后缀统一转换为 `@cmss.cmcc`：
+
+```
+zhangsan@cmss.chinamobile.com → zhangsan@cmss.cmcc
+```
+
+输出身份检测结果：
+
+```
+用户身份：
+- 中文名：任博婕妤
+- 邮箱（需求系统）：renbojieyu@cmss.cmcc
+```
+
+### 第 2 步：提取查询条件
+
+从用户请求中提取审核范围条件：
+
+| 用户说法                    | 含义                                                          |
+| --------------------------- | ------------------------------------------------------------- |
+| "帮我审核 beta 需求"        | 审核我作为负责人的所有"分析+规划"状态需求                     |
+| "审核演示项目需求"          | 审核"演示项目"空间内我作为负责人的"分析+规划"状态需求         |
+| "审核 RR20260119400340"     | 审核指定需求 Key（按 number 精确匹配）                        |
+| "审核一致性相关的需求"      | 按标题关键词模糊匹配我作为负责人的"分析+规划"状态需求         |
+
+**模糊匹配规则：**
+- 项目名：支持 `getProjectList` 返回值中的部分匹配
+- 需求 Key：精确匹配 `number` 字段
+- 标题关键词：在 `listWorkItems` 返回结果中按 `title` 字段做客户端 `contains` 匹配
+
+**默认审核状态：** 分析（Analyse）、规划（Plan）。
+
+**负责人匹配：** 客户端按 `assignee.user_name` 字段过滤为当前用户邮箱（`listWorkItems` 不直接支持按 assignee 过滤）。
+
+### 第 3 步：调用 lingji-beta MCP 拉取需求
+
+固定使用 lingji-beta MCP 工具链：
+
+- `lingji-beta__getProjectList` — 解析项目名 → projectId
+- `lingji-beta__listWorkItems` — 按 projectId + issueType 拉取工作项列表（**不含 description**）
+- `lingji-beta__getWorkItemDetail` — **单条详情，包含 description、子工作项**（**审核前必须对每条候选需求调用一次以获取 description 用于三小节检查**）
+
+**查询参数（listWorkItems）：**
+- `projectId`: 项目 ID
+- `issueType`: `RR`
+
+> ⚠️ description 字段只存在于 `getWorkItemDetail` 返回结果中。审核"完整性"维度时，必须对每条候选需求调用 `getWorkItemDetail` 解析【需求背景】/【需求价值】/【需求详情】三段内容。
+
+### 第 4 步：IDE 交互 — 确认审核范围
+
+将查询到的需求按项目分组，展示给用户确认：
+
+```
+📋 beta 环境需求审核范围确认
+
+项目：演示项目（e13a682906ef49518812e2b95318d87b）
+待审核需求：2 条
+  1. RR20260616628399 | 需求代码一致性分析 | 状态：分析 | 优先级：高
+  2. RR20260119400340 | 私有云单产品创建版本需强制关联解决方案版本 | 状态：分析 | 优先级：中
+
+以上是否为您要审核的需求？如需调整范围，请告知。
+```
+
+使用 `question` 工具让用户确认，选项包括：
+- 确认，继续审核
+- 调整范围（用户可说明增减哪些需求）
+
+### 第 5 步：确认文档保存路径
+
+用户确认审核范围后，询问文档保存路径：
+
+```
+请确认 beta 环境需求审核报告保存路径：
+- 默认路径：当前项目 prd/review/ 目录下
+- 文件名格式：需求审核_Beta_YYYYMMDD.md
+  例：需求审核_Beta_20260618.md
+```
+
+使用 `question` 工具让用户选择：
+- 使用默认路径（prd/review/）
+- 自定义路径（用户输入）
+
+### 第 6 步：逐条审核需求
+
+对每条需求按 **五维度 + description 三小节专项检查** 进行审核。
+
+#### 维度一：完整性
+
+| 检查点 | 说明 | 判定标准 |
+|--------|------|----------|
+| 业务背景 | description 中【需求背景】小节是否说明了需求来源、痛点和预期价值 | 【需求背景】小节存在且有实质内容（非占位符） |
+| 需求描述 | description 中【需求详情】小节是否完整描述了功能范围 | 【需求详情】小节存在，包含功能范围和核心交互 |
+| 验收标准 | 是否可从【需求详情】推导可验证的验收条目 | 【需求详情】信息足够推导 ≥3 条验收条目 |
+| 关联信息 | 是否关联了项目、迭代、计划时间 | `domain_id` / `plan_iteration` / `plan_end_date` 非空（按需） |
+| 价值说明 | description 中【需求价值】小节是否说明了预期收益 | 【需求价值】小节存在且有实质内容 |
+
+#### 维度二：清晰性
+
+| 检查点 | 说明 | 判定标准 |
+|--------|------|----------|
+| 语义明确 | 需求描述是否无歧义，概念是否定义清晰 | 无模糊表述（如"等""相关"无具体指向），关键术语有定义 |
+| 边界清晰 | 功能边界是否明确，输入输出是否清晰 | 明确了做什么和不做什么，输入输出格式有说明 |
+| 量化标准 | 验收标准/价值是否可量化 | 包含具体的指标或判定条件，而非仅定性描述 |
+| 颗粒度 | 需求拆分颗粒度是否合理 | 单条需求描述的功能范围适中，不过大（跨多个独立功能）也不过小 |
+
+#### 维度三：可测试性
+
+| 检查点 | 说明 | 判定标准 |
+|--------|------|----------|
+| 验收可验证 | 验收标准是否可直接转化为测试用例 | 每条验收标准可映射到具体的测试操作和预期结果 |
+| 异常场景 | 是否覆盖了异常和边界场景 | 包含输入异常、权限异常、超时/失败等场景的处理说明 |
+| 性能指标 | 对性能/准确性有要求的场景是否定义了指标 | AI类需求需定义准确率、响应时间等；非AI类视情况而定 |
+
+#### 维度四：一致性
+
+| 检查点 | 说明 | 判定标准 |
+|--------|------|----------|
+| 内部一致 | description 三小节之间是否一致 | 【需求背景】/【需求价值】/【需求详情】三段内容相互呼应，无矛盾 |
+| 优先级匹配 | 优先级与业务价值/紧急程度是否匹配 | 高/中/低优先级需求应有相应的【需求价值】支撑 |
+| 外部一致 | 与同项目其他需求是否存在冲突或重叠 | 同项目需求间功能边界不重叠，无矛盾定义 |
+
+#### 维度五：可行性
+
+| 检查点 | 说明 | 判定标准 |
+|--------|------|----------|
+| 技术可行性 | 是否可基于需求详情识别技术路径 | 【需求详情】信息可推导技术实现路径 |
+| 时间可行性 | 计划时间是否充足 | `plan_end_date` 合理，未出现已过期但仍未推进 |
+| 依赖明确 | 外部依赖是否已识别和说明 | 如依赖其他系统/接口/数据，需明确说明 |
+
+#### description 三小节专项检查
+
+> **此专项检查是 beta 环境特有，因 description 字段包含【需求背景】/【需求价值】/【需求详情】三个小节，需对小节完整性、实质内容、占位符等进行专项审核。**
+
+| 检查点 | 说明 | 判定标准 |
+|--------|------|----------|
+| 小节齐全 | 三个小节标签是否都存在 | description 同时包含 `【需求背景】`、`【需求价值】`、`【需求详情】` 三个标签 |
+| 顺序正确 | 小节排列顺序是否符合规范 | 顺序为：需求背景 → 需求价值 → 需求详情 |
+| 非占位符 | 各小节内容是否为实质内容 | 三段文字均不是占位符（如"未提供"、"待补充"、"xxx"、标题原文重复）|
+| 长度合理 | 各小节内容长度是否足够 | 每段至少 1 句实质内容（建议【需求背景】≥30字、【需求价值】≥20字、【需求详情】≥50字）|
+| 背景价值对齐 | 业务背景与价值说明是否逻辑对应 | 痛点 → 价值 一一对应，未出现背景说A价值说B |
+| 详情可推导验收 | 【需求详情】是否足够推导验收标准 | 【需求详情】能拆解出 ≥3 个独立功能点 |
+
+**三小节专项检查结果：**
+- ✅ 通过：所有 6 个检查点均满足
+- ⚠️ 有条件通过：1-2 个检查点不满足，但不影响核心功能理解
+- ❌ 不通过：≥3 个检查点不满足，或出现"三段均为占位符"等严重情况
+
+#### 审核意见判定规则
+
+每条需求根据 **五维度 + 三小节专项** 的审核结果，给出整体审核意见：
+
+| 审核意见 | 判定条件 |
+|----------|----------|
+| ✅ 通过 | 五维度均无问题，三小节专项通过 |
+| ⚠️ 有条件通过 | 存在中严重度问题或三小节专项有条件通过，但不影响核心功能理解和测试 |
+| ❌ 不通过 | 存在高严重度问题（关键信息缺失、需求三段矛盾、占位符文本等），或三小节专项不通过 |
+
+**严重度分级：**
+- **高**：关键信息缺失（【需求背景】空、占位符）、三小节内容矛盾、核心功能定义不清
+- **中**：边界条件缺失、量化标准不足、异常场景未覆盖、小节长度不足
+- **低**：关联迭代未填写、计划时间已过期但仍在推进、非核心字段缺失
+
+### 第 7 步：生成审核报告文档
+
+按照以下模板生成单份汇总审核报告，并**必须使用 `write` 工具将文档写入第 5 步确认的文件路径**。不要仅在对话中展示文档内容，必须将完整内容写入文件。如果目录不存在，需先创建目录。
+
+**文件名格式：** `需求审核_Beta_YYYYMMDD.md`
+
+```markdown
+# beta 环境需求审核报告
+
+## beta 环境元信息
+
+| 字段 | 值 |
+|---|---|
+| 环境标识 | beta |
+| 审核人 | 任博婕妤 (renbojieyu@cmss.cmcc) |
+| 审核日期 | 2026-06-18 |
+| 审核范围 | 演示项目（e13a682906ef49518812e2b95318d87b），分析+规划状态 |
+| 审核需求总数 | 2 |
+| MCP 来源 | lingji-beta |
+
+---
+
+## 审核概览
+
+| 指标 | 数量 |
+|------|------|
+| 审核需求总数 | 2 |
+| ✅ 通过 | 0 |
+| ⚠️ 有条件通过 | 1 |
+| ❌ 不通过 | 1 |
+| 三小节专项通过 | 0 |
+| 三小节专项不通过 | 2 |
+
+---
+
+## 需求 1：RR20260616628399 — 需求代码一致性分析
+
+**审核意见：** ❌ 不通过
+
+**基本信息：**
+
+| 字段 | 值 |
+|------|-----|
+| 需求Key | RR20260616628399 |
+| 标题 | 需求代码一致性分析 |
+| 类型 | RR-初始需求 |
+| 状态 | 分析 |
+| 优先级 | 高 |
+| 负责人 | 任博婕妤 (renbojieyu@cmss.cmcc) |
+| 提出人 | 程龙 (chenglong2@cmss.cmcc) |
+| 关联项目 | 演示项目 |
+| 关联迭代 | 未提供 |
+| 计划结束时间 | 未提供 |
+| 创建时间 | 2026-06-16 16:21 |
+
+**description 三小节专项检查：**
+
+| 检查点 | 审核结果 | 问题描述 |
+|--------|----------|----------|
+| 小节齐全 | ✅ | 三个小节标签均存在 |
+| 顺序正确 | ✅ | 顺序符合规范 |
+| 非占位符 | ❌ | 三段内容均为占位符"需求代码一致性分析"，无实质内容 |
+| 长度合理 | ❌ | 每段仅 7 字，远低于建议长度 |
+| 背景价值对齐 | ⚠️ | 背景与价值内容相同，无法判断逻辑对应 |
+| 详情可推导验收 | ❌ | 【需求详情】无实质功能点，无法推导验收标准 |
+
+**五维度审核明细：**
+
+| 维度 | 审核结果 | 问题描述 |
+|------|----------|----------|
+| 完整性 | ❌ | 【需求背景】/【需求价值】/【需求详情】均为占位符，验收标准无法推导 |
+| 清晰性 | ❌ | 无实质功能描述，语义不明确 |
+| 可测试性 | ❌ | 无法从【需求详情】推导任何验收条目 |
+| 一致性 | ⚠️ | 标题与三段内容相关，但内容无实质信息 |
+| 可行性 | ⚠️ | 计划时间未设置，无法评估时间可行性 |
+
+**问题清单：**
+
+| 序号 | 严重程度 | 问题描述 | 改进建议 |
+|------|----------|----------|----------|
+| 1 | 高 | 【需求背景】为占位符"需求代码一致性分析"，未说明需求来源、痛点、预期价值 | 补充业务背景：需求由谁提出、解决什么场景下的什么问题、预期带来什么收益 |
+| 2 | 高 | 【需求价值】为占位符，未说明预期收益 | 补充价值说明：落地后能带来哪些可衡量的业务价值 |
+| 3 | 高 | 【需求详情】为占位符，未描述功能范围、核心流程、输入输出 | 补充功能详情：核心功能点、关键交互、输入输出格式、关键约束 |
+| 4 | 中 | 三段长度均不足（仅 7 字） | 建议【需求背景】≥30字、【需求价值】≥20字、【需求详情】≥50字 |
+| 5 | 中 | 计划开始/结束时间未设置 | 在需求分析完成后明确计划工时与目标迭代 |
+| 6 | 低 | 关联迭代未设置 | 进入规划阶段时关联迭代 |
+
+---
+
+## 需求 2：RR20260119400340 — 私有云单产品创建版本需强制关联解决方案版本
+
+（... 同上结构 ...）
+
+---
+
+## 共性问题汇总
+
+| 共性问题 | 涉及需求 | 建议 |
+|----------|----------|------|
+| description 三小节内容为占位符 | RR20260616628399 | 由需求提出人补充实质性内容；建议在需求创建模板中增加"小节最小长度校验" |
+| 计划时间未设置 | RR20260616628399、RR20260119400340 | 在需求分析阶段同步设置计划开始/结束时间 |
+| 关联迭代缺失 | RR20260616628399 | 进入规划阶段时关联迭代 |
+```
+
+### 第 8 步：展示执行结果
+
+审核报告生成后，向用户展示：
+
+```
+✅ beta 环境需求审核完成
+
+📄 审核报告已生成：prd/review/需求审核_Beta_20260618.md
+📋 审核概览：
+   - 审核需求总数：2
+   - ✅ 通过：0
+   - ⚠️ 有条件通过：1
+   - ❌ 不通过：1
+   - 三小节专项通过：0
+   - 三小节专项不通过：2
+```
+
+## 字段映射参考（基于 lingji-beta 实际数据）
+
+| 审核报告字段         | MCP 数据字段                          | 说明 |
+| -------------------- | ------------------------------------- | ---- |
+| 需求Key              | `number`                              |      |
+| 标题                 | `title`                               |      |
+| 类型                 | `category` + `type`                   | 例：`RR` + `raw requirement` → "RR-初始需求" |
+| 状态                 | `status.display_value`                | 初始/分析/规划/实现/交付/验收/完成 |
+| 优先级               | `priority.display_value`              | 高/中/低 |
+| 负责人               | `assignee.nick_name` + `user_name`    | 姓名 + 邮箱 |
+| 提出人               | `submitted_by[0].nick_name` + `user_name` |      |
+| 关联项目             | `project.title`                       |      |
+| 关联迭代             | `plan_iteration.title`                |      |
+| 计划开始时间         | `plan_start_date`                     | 时间戳转 YYYY-MM-DD |
+| 计划结束时间         | `plan_end_date`                       | 时间戳转 YYYY-MM-DD |
+| 创建时间             | `created_date`                        | 时间戳转 YYYY-MM-DD HH:mm |
+| description 三小节   | `description`（**仅 getWorkItemDetail 返回**）| 解析为【需求背景】/【需求价值】/【需求详情】 |
+
+## description 三小节解析规则
+
+> 三小节专项检查依赖此解析结果。解析时按以下规则处理：
+
+1. **HTML 标签清理**：`<p>`、`<br>`、`<span>` 等替换为换行符或删除
+2. **小节定位**：通过 `【需求背景】`、`【需求价值】`、`【需求详情】` 三个标签定位段落边界
+3. **小节顺序校验**：期望顺序为 需求背景 → 需求价值 → 需求详情；顺序错误在专项检查中标 ❌
+4. **占位符识别**：以下模式视为占位符：
+   - 文字内容与需求标题完全相同
+   - 包含"未提供""待补充""TBD""TODO""xxx"等关键词
+   - 内容长度 < 5 个中文字符
+5. **小节缺失**：未匹配到任一标签时，该小节视为"缺失"，对应检查点标 ❌
+
+## 注意事项
+
+- 所有字段值为空时标注"未提供"，不做臆测
+- 审核意见基于需求文档的现有内容判定，不依赖外部知识
+- 时间字段保持原始格式，不做转换
+- 人员名字后跟随邮箱不要省略
+- **description 必填检查**：审核前必须对每条需求调用 `getWorkItemDetail` 获取 description；若 description 缺失或为空，则完整性维度直接判 ❌
+- **占位符严格识别**：description 中任一小节被识别为占位符，对应"非占位符"检查点判 ❌，并升级为高严重度问题
+- 如果查询结果为空（无待审核需求），告知用户"当前没有找到您作为负责人的待审核需求"，并建议检查项目范围或状态条件
+- 项目名、需求 Key、标题关键词支持模糊匹配，匹配后需与用户确认
+- 如果需求量较大（>10条），建议分批审核，每批不超过10条
+- **类型码映射**：`RR` → 初始需求，`US` → 用户故事，`Task` → 任务
+- **状态码映射**：`Start` → 初始，`Analyse` → 分析，`Plan` → 规划，`Doing` → 实现，`Delivered` → 交付，`Checking` → 验收，`Finish` → 完成
+- **默认审核状态**：分析（Analyse）+ 规划（Plan）
+- **回写说明**：本 skill 仅生成审核报告，不直接回传平台（审核意见由需求提出人/负责人根据报告自行优化需求）

package/bin/zhanlu-plugins/lingji-beta-assistant/skills/beta-requirements-gather/SKILL.md

@@ -0,0 +1,244 @@
+---
+name: beta_requirements_gather
+description: 通过 lingji-beta MCP 工具从 beta 环境（演示/测试环境）的需求管理系统中拉取需求，并按标准化模板整理为带环境标识的 Markdown 文档。当用户提到"beta环境需求""演示环境需求""测试环境需求""拉取beta需求""beta环境盘点"等场景时触发。即使用户没有明确说"beta"，但明确指定演示项目、beta 环境功能验证测试等测试类项目时，也应使用此 skill。
+---
+
+# beta 环境需求拉取
+
+> 与 `requirements-gather` 的差异：固定使用 lingji-beta MCP、输出文件名带 `Beta_` 前缀、文档头部增加 beta 环境元信息、模板字段基于实际 beta 环境数据结构调整（移除"业务背景/验收标准"等 beta 环境未采集字段，新增"业务域/计划工时/状态停留/子需求"等真实存在字段）。
+
+## 流程
+
+### 第 1 步：身份解析
+
+识别请求中涉及的需求相关人身份，并解析为需求系统可用的邮箱格式。
+
+#### 情况 A：当前用户（"我"）
+
+当请求中出现"我的需求""我负责的""我创建的""分配给我的"等指向当前用户的表述时，从本地认证文件读取身份信息。
+
+- **Windows 路径**：`C:\Users\Admin\.local\share\zhanlu\auth_zhanlu.json`
+- **macOS / Linux 路径**：`~/.local/share/zhanlu/auth_zhanlu.json`
+
+从 `metadata` 字段中提取 `email` 与 `userName`，将邮箱后缀统一转换为 `@cmss.cmcc`：
+
+```
+zhangsan@cmss.chinamobile.com → zhangsan@cmss.cmcc
+```
+
+#### 情况 B：指定人名的用户
+
+将中文姓名转为全拼小写（不带声调，姓氏名字连写）后追加 `@cmss.cmcc`：
+
+- 张三 → `zhangsan@cmss.cmcc`
+- 欧阳锋 → `ouyangfeng@cmss.cmcc`
+- 诸葛亮 → `zhugeliang@cmss.cmcc`
+
+#### 输出身份检测结果
+
+```
+用户身份：
+- 中文名：张三
+- 邮箱（需求系统）：zhangsan@cmss.cmcc
+
+查询涉及的其他人员：
+- 欧阳锋 → ouyangfeng@cmss.cmcc
+```
+
+### 第 2 步：提取查询条件
+
+从用户请求中提取需求查询条件，包括但不限于：
+
+- 时间范围（计划开始/结束时间、期望完成时间等）
+- 需求状态
+- 关联项目、迭代、版本
+- 优先级
+- 负责人 / 提出人
+- 需求关键词
+
+**"xx"相关的语义映射：**
+
+| 用户说法         | 含义                         |
+| ---------------- | ---------------------------- |
+| "xx的需求"       | 负责人 OR 创建人中有一个为xx |
+| "xx负责的需求"   | 负责人 = xx                  |
+| "xx创建的需求"   | 提出人 = xx                  |
+| "分配给xx的需求" | 负责人 = xx                  |
+
+**筛选逻辑：** 未指定项目时，用解析出的邮箱作为 MCP 筛选条件；指定了具体项目（如"演示项目下所有需求"），则人员字段不传，由项目范围兜底。
+
+### 第 3 步：调用 lingji-beta MCP 拉取需求
+
+固定使用 lingji-beta MCP 工具链执行查询。典型工具：
+
+- `lingji-beta__getProjectList` — 解析项目名 → projectId
+- `lingji-beta__listWorkItems` — 按 projectId + issueType 拉取工作项列表（**仅返回列表字段，不含 description**）
+- `lingji-beta__queryWorkItemTree` — 拉取树状结构（自动展开父子层级）
+- `lingji-beta__getWorkItemDetail` — **单条详情，包含 description、子工作项、关联关系等**（**生成文档时必须对每条需求都调用一次**）
+
+> ⚠️ **关键：description 字段只存在于 `getWorkItemDetail` 返回结果中。** `listWorkItems` 和 `queryWorkItemTree` 都不会返回 description。生成 Markdown 文档前，必须对每条需求（无论 RR / US / Task）逐一调用 `getWorkItemDetail` 获取完整描述。**绝不允许**因为 description 字段在列表接口中缺失就直接填"未提供"。
+
+**"类型"过滤规则：**
+
+- 可选项：`RR`（初始需求 / 原始需求）、`US`（用户故事）、`Task`（任务）
+- 查询 **需求**（未特别指明类型）时，需同时按 RR / US / Task 三次调用 `listWorkItems` 后合并去重
+- 用户明确指定类型时，仅调用对应类型
+
+**"状态"过滤规则：**
+
+- 未明确指定时，默认拉取状态为 **"新建"（Start / Committed）** 和 **"分析"（Analyse）** 的需求
+- `listWorkItems` 接口不直接支持状态过滤，需在结果返回后按 `status.code` 字段做客户端过滤
+
+### 第 4 步：输出结果
+
+根据用户明确要求选择输出方式：
+
+**场景 A — 用户要求保存为文档：** 按下方模板生成 Markdown 文件
+
+- 保存到项目 `prd/` 文件夹下（先检查是否存在，如不存在则创建）
+- 文件名称格式：**`需求列表_Beta_YYYYMMDD.md`**（`YYYYMMDD` 为当天日期，例如 `20260616`）
+- **必须**在文档头部输出 beta 环境元信息块（见下方模板）
+
+> **重要：保存为文件必须使用完整模板 + beta 环境元信息。** 即使用户在此 skill 已经展示过简要表格后补充说"帮我存为 md"，也必须使用下方的完整需求模板写入文件，禁止使用简要表格格式。简要表格仅用于纯查看场景。
+
+**场景 B — 只是获取需求，暂未要求保存为本地文档：** 直接输出简要表格（每个需求一行），不保存文件。
+
+## 输出模板
+
+### 保存为本地文档（场景 A — 保存文件）
+
+#### 文档头部 beta 环境元信息（必填）
+
+```markdown
+# beta 环境需求列表
+
+| 字段 | 值 |
+|---|---|
+| 环境标识 | beta |
+| 拉取时间 | 2026-06-16 16:55 |
+| 拉取人 | 任博婕妤 (renbojieyu@cmss.cmcc) |
+| 查询条件 | 项目=演示项目, 类型=RR/US/Task, 状态=新建/分析 |
+| 需求总数 | 8 |
+| MCP 来源 | lingji-beta |
+```
+
+#### 单个需求详情
+
+```markdown
+## 项目信息
+- **空间名称**:
+- **项目编码**:
+- **项目名称**:
+- **产品名称**:
+
+## 需求 1
+
+| 字段 | 值 |
+|---|---|
+| 需求Key | [number] |
+| 标题 | [title] |
+| 类型 | [category 类型码 + 名称] |
+| 状态 | [status.display_value] |
+| 状态停留天数 | [stay_days] |
+| 优先级 | [priority.display_value] |
+| 负责人 | [assignee.nick_name + 邮箱] |
+| 提出人 | [submitted_by[0].nick_name + 邮箱] |
+| 承接人 | [recipient[0].nick_name + 邮箱] |
+| 创建人 | [created_by.nick_name + 邮箱] |
+| 业务域 | [business_domain.display_value] |
+| 故事点 | [story_point.display_value] |
+| 计划工时(人天) | [workload_man_day] |
+| 计划开始时间 | [plan_start_date] |
+| 计划结束时间 | [plan_end_date] |
+| 计划开发结束时间 | [plan_dev_end_date] |
+| 计划测试结束时间 | [plan_test_end_date] |
+| 期望完成时间 | [expect_delivery_time] |
+| 关联迭代 | [plan_iteration.title] |
+| 关联项目 | [project.title] |
+| 父需求 | [parent_id 对应的 number] |
+| 关联需求 | [rr2ir / rr2us / us2rr / ir2feature] |
+| 子需求 | [child_issues 中各 number + title] |
+| 创建时间 | [created_date] |
+| 最近修改时间 | [modified_date] |
+| 需求描述 | [description 去除 HTML 标签] |
+| 需求 URL | [如无则填"未提供"] |
+```
+
+#### 多个需求详情
+
+每个需求独立一个表格，用空行分隔，上方标注序号。多个需求前统一添加 beta 环境元信息块 + 项目信息：
+
+```markdown
+# beta 环境需求列表
+（... beta 环境元信息块 ...）
+
+## 项目信息
+
+- **空间名称**: xxx
+- **项目编码**: xxx
+- **项目名称**: xxx
+- **产品名称**: xxx
+
+## 需求 1
+
+| 字段 | 值 |
+|---|---|
+| ... | ... |
+
+## 需求 2
+
+| 字段 | 值 |
+|---|---|
+| ... | ... |
+```
+
+### 简要表格（场景 B — 不保存文件）
+
+每个需求一行：
+
+```
+| 需求Key | 标题 | 类型 | 负责人 | 提出人 | 状态 | 优先级 | 业务域 | 计划工时 | 关联迭代 | 状态停留天数 | 属于项目 |
+|---|---|---|---|---|---|---|---|---|---|---|---|
+| RR20260119400340 | 私有云单产品创建版本需强制关联解决方案版本 | RR-初始需求 | 朱范琴(zhufanqin@cmss.cmcc) | 朱范琴 | 分析 | 中 | 未提供 | 0.5 | 4.12.0 | 106 | 演示项目 |
+```
+
+## 字段映射参考（基于实际 MCP 数据）
+
+> 以下为 lingji-beta MCP 返回字段与输出模板的对应关系，仅列在 beta 环境数据中实际出现过的字段。
+
+| 输出模板字段           | MCP 数据字段                                       | 说明 |
+| ---------------------- | -------------------------------------------------- | ---- |
+| 需求Key                | `number`                                           |      |
+| 标题                   | `title`                                            |      |
+| 类型                   | `category` + `type`                                | 例：`RR` + `raw requirement` → "RR-初始需求" |
+| 状态                   | `status.display_value`                             | 值为：初始/分析/规划/实现/交付/验收/完成 |
+| 状态停留天数           | `stay_days`                                        | 当前状态停留天数 |
+| 优先级                 | `priority.display_value`                           | 高/中/低 |
+| 负责人                 | `assignee.nick_name` + `user_name`                 | 姓名 + 邮箱 |
+| 提出人                 | `submitted_by[0].nick_name` + `user_name`          |  |
+| 承接人                 | `recipient[0].nick_name` + `user_name`             | 仅 RR 有 |
+| 业务域                 | `business_domain.display_value`                    | 例：软件 |
+| 故事点                 | `story_point.display_value`                        | 仅 US 有 |
+| 计划工时(人天)         | `workload_man_day`                                 |      |
+| 计划开始时间           | `plan_start_date`                                  | 时间戳转 YYYY-MM-DD |
+| 计划结束时间           | `plan_end_date`                                    | 时间戳转 YYYY-MM-DD |
+| 计划开发结束时间       | `plan_dev_end_date`                                | 仅 US/Task |
+| 计划测试结束时间       | `plan_test_end_date`                               |      |
+| 期望完成时间           | `expect_delivery_time`                             | 时间戳转 YYYY-MM-DD |
+| 关联迭代               | `plan_iteration.title`                             |      |
+| 父需求                 | `parent_id` → 反查 `number`                        |      |
+| 关联需求               | `rr2ir` / `rr2us` / `us2rr` / `ir2feature`         | 拼接 + 反查 number |
+| 子需求                 | `child_issues[*].number` + `.title`                | 多个用换行分隔 |
+| 创建时间               | `created_date`                                     | 时间戳转 YYYY-MM-DD HH:mm |
+| 最近修改时间           | `modified_date`                                    | 时间戳转 YYYY-MM-DD HH:mm |
+| 需求描述               | `description`（**仅 `getWorkItemDetail` 接口返回**）| 去除 HTML 标签后保留换行；`listWorkItems` 无此字段 |
+
+## 注意事项
+
+- **未提供字段**填写 "未提供"，保存到 md 文档时字段严格按照模板，多余字段可忽略
+- **时间字段**保持原始格式不做转换（时间戳需在生成时手动转 YYYY-MM-DD）
+- **人员名字后跟随的邮箱不要省略**，例如 `朱范琴 (zhufanqin@cmss.cmcc)`
+- **任何场景下需求保存为本地 Markdown 文档，都必须使用完整需求模板 + beta 环境元信息块。** 当不生成文件时，使用简要表格
+- **类型码映射**：`RR` → 初始需求，`US` → 用户故事，`Task` → 任务
+- **状态码映射**：`Start` → 初始，`Analyse` → 分析，`Plan` → 规划，`Doing` → 实现，`Delivered` → 交付，`Checking` → 验收，`Finish` → 完成
+- **description 字段处理**：生成文档前必须对每条需求调用 `getWorkItemDetail` 获取 `description`；HTML 标签（如 `<p>`、`<span>`、`<br>`）需替换为换行符；含 `【需求背景】`、`【需求价值】`、`【需求详情】` 等小节标签的描述必须原样保留

package/bin/zl

@@ -0,0 +1,4 @@
+[diffend] Oversized file quarantined before diffing.
+name: package/bin/zl
+size: 117308258 bytes
+sha256: d717a795a3148af7a3d014fe28c81c2700f9d066c1dab0770cfb84c5d8c8dfc1

package/package.json

@@ -0,0 +1,22 @@
+{
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/village-way/vscodium"
+  },
+  "name": "@zhanlucode/zl-darwin-arm64",
+  "version": "1.5.87028",
+  "preferUnplugged": true,
+  "os": [
+    "darwin"
+  ],
+  "cpu": [
+    "arm64"
+  ],
+  "keywords": [
+    "zhanlu",
+    "zl",
+    "cli",
+    "ai",
+    "coding"
+  ]
+}