@zhanlucode/zl-darwin-arm64 1.5.87028

package/bin/zhanlu-plugins/lingji-beta-assistant/README.md

@@ -0,0 +1,21 @@
+# 灵畿β助手（内置 Plugin）
+
+随 Zhanlu CLI 分发的内置插件，提供灵畿β远程 MCP。
+## 品牌用字（强制）
+
+完整规范见 [`packages/opencode/src/zhanlu/brand-naming.md`](../../../brand-naming.md)。Skill 与对用户回复只写正确形式，勿罗列近音错写。
+
+正确用字：
+- zhanlu → 湛卢、湛卢 IDE
+- lingji → 灵畿、灵畿平台、灵畿β助手
+- kylin → 麒麟、银河麒麟
+- uos → 统信、统信 UOS
+- 账号登录语义使用「登录」
+## 包含内容
+
+| 类型 | 内容 |
+|---|---|
+| **Skills** | 暂无 |
+| **MCP** | `lingji-beta` → `http://rdcloud.4c.hq.cmcc/cmdevops-aiplus-agent-gateway/zhanlu-cloud/mcp/sse` |
+
+用户目录中的同名插件会覆盖内置版本。

package/bin/zhanlu-plugins/lingji-beta-assistant/skills/.gitkeep

@@ -0,0 +1 @@
+

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

@@ -0,0 +1,383 @@
+---
+name: beta_requirement_analysis
+description: |
+  beta 环境需求分析技能，用于对 beta 环境（演示/测试环境）中负责人为当前用户的"新建/分析"状态初始需求（RR）进行深度分析优化，生成结构化 Markdown 文档并支持回传 lingji-beta 平台。当用户提到"beta环境分析需求""分析beta需求""帮我分析演示项目需求""分析测试环境需求"等表述时触发。即使用户没有明确说"beta"，但明确指定演示项目、beta 环境功能验证测试等测试类项目时，也应使用此 skill。与 `requirement-analysis` 的差异：固定使用 lingji-beta MCP、输出到 prd/analysis/ 目录、文件名带 Beta_ 前缀、将 description 中【需求背景】/【需求价值】/【需求详情】视为三个独立字段分别 AI 扩写、文档头部增加 beta 环境元信息、字段基于实际 beta 数据结构调整、回传时直接用分析补充后的三段内容覆盖原 description。
+---
+
+# beta 环境需求分析
+
+> 对 beta 环境中"新建/分析"状态的初始需求（RR）进行深度分析优化：基于 description 中的【需求背景】/【需求价值】/【需求详情】三段分别进行 AI 扩写，生成结构化分析文档，并支持将扩写结果直接回传 lingji-beta 平台。
+
+## 流程
+
+**重要：本流程的 10 个步骤是连续执行的，从第 1 步到第 10 步必须依次完成，不要在任意步骤之间停下等待用户输入（第 4 步、第 5 步、第 9 步使用 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 需求"            | 分析我作为负责人的所有 beta 环境"新建/分析"状态初始需求       |
+| "分析演示项目需求"              | 分析"演示项目"空间内我作为负责人的"新建/分析"状态初始需求     |
+| "分析 RR20260119400340"         | 分析指定需求 Key（按 number 精确匹配）                        |
+| "分析一致性相关的需求"          | 按标题关键词模糊匹配我作为负责人的"新建/分析"状态需求         |
+
+**模糊匹配规则：**
+- 项目名：支持 `getProjectList` 返回值中的部分匹配
+- 需求 Key：精确匹配 `number` 字段
+- 标题关键词：在 `listWorkItems` 返回结果中按 `title` 字段做客户端 `contains` 匹配
+
+**默认查询状态：** 新建（Start / Committed）、分析（Analyse）。
+
+### 第 3 步：调用 lingji-beta MCP 拉取需求
+
+固定使用 lingji-beta MCP 工具链：
+
+- `lingji-beta__getProjectList` — 解析项目名 → projectId
+- `lingji-beta__listWorkItems` — 按 projectId + issueType=RR 拉取初始需求列表
+- `lingji-beta__getWorkItemDetail` — **单条详情，包含 description、子工作项、关联关系**（生成文档前必须调用）
+
+**查询参数（listWorkItems）：**
+- `projectId`: 项目 ID（必填）
+- `issueType`: `RR`
+
+**默认过滤：**
+- `status.code` ∈ {`Start`, `Analyse`}（客户端过滤）
+- `assignee.user_name` 等于当前用户邮箱（客户端过滤）
+
+> ⚠️ 列表接口不返回 `description`，分析文档生成前必须对每条候选需求调用 `getWorkItemDetail` 获取完整 `description`（含 `【需求背景】`、`【需求价值】`、`【需求详情】` 三个小节）。
+
+### 第 4 步：IDE 交互 — 确认分析范围
+
+将查询到的需求按项目分组，展示给用户确认：
+
+```
+📋 beta 环境需求分析范围确认
+
+项目：演示项目（e13a682906ef49518812e2b95318d87b）
+待分析需求：1 条
+  1. RR20260616628399 | 需求代码一致性分析 | 状态：分析 | 优先级：高
+
+以上是否为您要分析的需求？如需调整范围，请告知。
+```
+
+使用 `question` 工具让用户确认，选项包括：
+- 确认，继续分析
+- 调整范围（用户可说明增减哪些需求）
+
+### 第 5 步：确认文档保存路径
+
+用户确认分析范围后，询问文档保存路径：
+
+```
+请确认 beta 环境需求分析文档保存路径：
+- 默认路径：当前项目 prd/analysis/ 目录下
+- 文件名格式：Beta_{需求Key}_{需求标题}.md
+  例：Beta_RR20260616628399_需求代码一致性分析.md
+```
+
+使用 `question` 工具让用户选择：
+- 使用默认路径（prd/analysis/）
+- 自定义路径（用户输入）
+
+### 第 6 步：逐条分析需求
+
+对每条需求进行深度分析优化。**核心原则：description 中的 `【需求背景】`、`【需求价值】`、`【需求详情】` 三个小节视为三个独立分析字段，分别进行 AI 扩写/补充，扩写后的内容直接回传平台。**
+
+#### 6.1 业务背景（对应【需求背景】）
+
+1. 提取 `description` 中 `【需求背景】` 小节内容作为"原始字段"
+2. 基于"需求标题 + 【需求价值】 + 【需求详情】"进行 AI 扩写，输出"分析补充"内容
+3. 扩写方向：
+   - **需求来源**：需求由谁提出、解决什么业务场景下的什么问题
+   - **当前痛点**：当前流程/系统中存在的具体痛点（至少 2-3 个）
+   - **预期价值**：需求落地后能带来的具体收益（量化或可衡量的指标）
+4. 若原始【需求背景】已有完整内容，分析补充部分应在原文基础上延伸，不重复原文表述
+
+#### 6.2 需求描述（对应【需求详情】）
+
+1. 提取 `description` 中 `【需求详情】` 小节内容作为"原始字段"
+2. 基于"需求标题 + 【需求背景】 + 【需求价值】"进行 AI 扩写，输出"分析补充"内容
+3. 扩写方向：
+   - **核心功能范围**：明确包含哪些功能点，边界是什么
+   - **关键交互流程**：用户/系统的主要操作流程
+   - **输入输出**：明确数据来源、格式、输出形式
+   - **关键约束**：性能/并发/兼容性/安全等非功能性约束
+4. 扩写时按"1. 2. 3."编号组织，每条功能点一行，便于后续回传
+
+#### 6.3 验收标准（新生成字段）
+
+由于 beta 环境 `description` 中**没有独立的验收标准字段**，需基于【需求详情】内容推导完整的验收条目：
+
+- 每条验收标准格式：**操作场景 + 预期结果**（参考引用文档的 9 条标准格式）
+- 覆盖维度：
+  1. 核心功能验证（每个核心功能点对应 1-2 条）
+  2. 异常/边界场景验证
+  3. 数据准确性验证（量化指标，如准确率 ≥ X%）
+  4. 性能验证（如响应时间 ≤ X 秒）
+  5. 安全/权限验证
+  6. 集成/依赖验证
+- 若【需求详情】信息不足无法推导具体指标，标注"待确认"
+
+#### 6.4 可行性分析评估
+
+| 维度         | 评估内容                                                     |
+| ------------ | ------------------------------------------------------------ |
+| 技术可行性   | 评估技术实现路径，识别技术风险和难点                         |
+| 时间可行性   | 评估计划时间是否充足（参考 `plan_end_date` / `plan_iteration`）|
+| 依赖识别     | 识别外部系统/接口/数据依赖（参考 `rr2ir` / `rr2us` / `link`） |
+| 结论         | 可行 / 需求不可行（需说明原因）                              |
+
+### 第 7 步：生成需求分析文档
+
+按照以下模板为每条需求生成独立的 Markdown 文档，并**必须使用 `write` 工具将文档写入第 5 步确认的文件路径**。不要仅在对话中展示文档内容，必须将完整内容写入文件。如果目录不存在，需先创建目录。
+
+**文件名格式：** `Beta_{需求Key}_{需求标题}.md`（文件名中的特殊字符 `/\\:*?"<>|` 用下划线替代）
+
+#### 单个需求文档模板
+
+```markdown
+# {需求标题}
+
+## beta 环境元信息
+
+| 字段 | 值 |
+|---|---|
+| 环境标识 | beta |
+| 拉取时间 | 2026-06-16 17:30 |
+| 拉取人 | 任博婕妤 (renbojieyu@cmss.cmcc) |
+| MCP 来源 | lingji-beta |
+
+## 项目信息
+
+- **空间名称**: [domain_id.name]
+- **项目编码**: [projectId]
+- **项目名称**: [project.title]
+- **产品名称**: [project.title]
+
+## 需求字段
+
+| 字段 | 值 |
+|------|-----|
+| 需求Key | [number] |
+| 标题 | [title] |
+| 类型 | [category + type，如"RR-初始需求"] |
+| 状态 | [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] |
+| 期望完成时间 | [expect_delivery_time] |
+| 关联迭代 | [plan_iteration.title] |
+| 父需求 | [parent_id 对应的 number] |
+| 关联需求 | [rr2ir / rr2us / link] |
+| 子需求 | [child_issues 中各 number + title] |
+| 创建时间 | [created_date] |
+| 最近修改时间 | [modified_date] |
+| 需求描述 | [description 去除 HTML 标签后保留换行] |
+| 需求 URL | [如无则填"未提供"] |
+
+## 需求内容
+
+### 业务背景
+
+（原始字段：[从 description 中提取的【需求背景】原始内容]）
+
+（分析补充）
+
+[AI 扩写后的业务背景。包含"需求来源 / 当前痛点 / 预期价值"三段。]
+
+### 需求描述
+
+（原始字段：[从 description 中提取的【需求详情】原始内容]）
+
+（分析补充）
+
+[AI 扩写后的需求描述。包含"核心功能 / 关键流程 / 输入输出 / 关键约束"四段，按"1. 2. 3."编号。]
+
+### 验收标准
+
+（原始字段：beta 环境无独立验收标准字段，以下为基于【需求详情】推导的新增内容）
+
+（分析补充）
+
+[1. 核心功能 1 验证：操作场景 + 预期结果]
+
+[2. 核心功能 2 验证：操作场景 + 预期结果]
+
+[3. 异常场景验证：操作场景 + 预期结果]
+
+[4. 数据准确性验证：操作场景 + 量化指标（如准确率≥X%）]
+
+[N. 性能/安全/集成验证：操作场景 + 预期结果]
+
+## 可行性分析
+
+| 字段 | 值 |
+|------|-----|
+| 可行性结论 | 可行 / 需求不可行 |
+| 不可行原因 | [如果结论为"需求不可行"，说明原因；否则填"无"] |
+| 技术可行性分析 | [技术实现路径评估] |
+| 时间可行性分析 | [计划时间评估，参考 plan_end_date / plan_iteration] |
+| 外部依赖 | [识别的外部依赖，参考 rr2ir / rr2us / link；无则填"无"] |
+```
+
+#### 多个需求文档
+
+如果一次分析多条需求，**每个需求生成独立文件**（`Beta_{Key1}_{标题1}.md`、`Beta_{Key2}_{标题2}.md`…），不要将多个需求合并在同一文件中。
+
+### 第 8 步：展示执行结果
+
+文档生成后，向用户展示：
+
+```
+✅ beta 环境需求分析完成
+
+📁 文档生成路径：prd/analysis/
+📄 生成文件：
+   - Beta_RR20260616628399_需求代码一致性分析.md
+```
+
+### 第 9 步：询问是否回传 lingji-beta 平台
+
+使用 `question` 工具询问用户是否将分析结果回传 lingji-beta 平台：
+
+```
+是否将分析补充结果回传 lingji-beta 平台？
+回传操作将使用 batchUpdateWorkItems 更新每条需求的 description 字段，
+将【需求背景】、【需求价值】、【需求详情】三个小节替换为分析补充后的内容；
+若分析建议调整优先级，同步更新 priority 字段。
+```
+
+选项：
+- 确认回传
+- 暂不回传（仅保留本地文档）
+
+如果用户选择"暂不回传"，流程结束。
+
+### 第 10 步：执行需求回传
+
+如果用户确认回传，对每条需求调用 `lingji-beta__batchUpdateWorkItems` 更新需求字段。
+
+**回传字段策略：**
+
+| 字段          | 是否回传 | 回传内容                                                       |
+| ------------- | -------- | -------------------------------------------------------------- |
+| `description` | 是       | 替换为"分析补充后"的【需求背景】+【需求价值】+【需求详情】三段 HTML |
+| `priority`    | 按需     | 仅当分析建议调整优先级时回传新值（如"高"→"中"）                |
+| `title`       | 否       | 不修改                                                         |
+| `status`      | 否       | 不通过此 skill 修改状态                                        |
+
+**回传 description 拼装规则：**
+
+回传内容 = AI 补充后的 `【需求背景】` + AI 补充后的 `【需求价值】` + AI 补充后的 `【需求详情】`，按以下 HTML 格式拼装：
+
+```html
+<p><strong>【需求背景】</strong></p>
+<p>{AI 补充后的业务背景内容，多段落用多个 <p> 包裹}</p>
+
+<p><strong>【需求价值】</strong></p>
+<p>{AI 补充后的价值内容}</p>
+
+<p><strong>【需求详情】</strong></p>
+<p>1. {功能点 1}</p>
+<p>2. {功能点 2}</p>
+<p>3. {功能点 3}</p>
+...
+```
+
+**调用参数（batchUpdateWorkItems）：**
+- `projectId`: 项目 ID
+- `id`: [需求 ID 数组]
+- `attribute.description`: 上述拼装后的 HTML 字符串
+- `attribute.priority`: 可选，仅当建议调整时传入
+
+**注意：**
+- **直接覆盖**原 `description` 的三个小节内容为分析补充后的版本
+- 不在末尾追加【分析备注】段（避免污染原始结构）
+- 仅回传非空字段，若分析建议无变更则跳过该条回传
+- 回传前展示本次回传的字段变化对照（原始 vs 补充）供用户复核
+
+#### 10.1 展示回传结果
+
+所有需求回传完成后，展示结果：
+
+```
+✅ 需求回传完成
+
+| 需求 | description 字段更新 | priority 字段更新 |
+|------|---------------------|------------------|
+| RR20260616628399 需求代码一致性分析 | ✅ 已替换三小节 | 未调整 |
+
+如果某条需求回传失败，标注失败原因并建议用户手动处理。
+
+## 字段映射参考（基于 lingji-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`       | 例：软件 |
+| 计划工时(人天)       | `workload_man_day`                    |      |
+| 计划开始时间         | `plan_start_date`                     | 时间戳转 YYYY-MM-DD |
+| 计划结束时间         | `plan_end_date`                       | 时间戳转 YYYY-MM-DD |
+| 关联迭代             | `plan_iteration.title`                |      |
+| 父需求               | `parent_id` → 反查 `number`           |      |
+| 关联需求             | `rr2ir` / `rr2us` / `link`            |      |
+| 子需求               | `child_issues[*].number` + `.title`   |      |
+| 创建时间             | `created_date`                        | 时间戳转 YYYY-MM-DD HH:mm |
+| 最近修改时间         | `modified_date`                       | 时间戳转 YYYY-MM-DD HH:mm |
+| 需求描述             | `description`（**仅 getWorkItemDetail 返回**）| 去除 HTML 标签后保留换行 |
+
+## 注意事项
+
+- 所有字段值为空时标注"未提供"或"未指定"，不做臆测
+- **description 字段处理**：生成文档前必须对每条需求调用 `getWorkItemDetail` 获取 `description`；HTML 标签（如 `<p>`、`<span>`、`<br>`）需替换为换行符
+- **三小节分析原则**：将 `【需求背景】`、`【需求价值】`、`【需求详情】` 视为三个独立字段分别进行 AI 扩写/补充
+  - 业务背景：扩写"需求来源/当前痛点/预期价值"三段
+  - 需求描述：扩写"核心功能/关键流程/输入输出/关键约束"四段（按"1. 2. 3."编号）
+  - 验收标准：从【需求详情】推导新条目（9 条标准格式，含量化指标）
+- 扩写需基于原始内容延伸，不引入原始需求未涉及的功能范围
+- 验收标准的推导需与【需求详情】保持一致，不超出需求描述的功能边界
+- 人员名字后跟随的邮箱不要省略
+- 文件名中的特殊字符（`/\\:*?"<>|`）用下划线替代
+- 如果需求量大（>10条），建议分批分析，每批不超过10条
+- **回传策略**：直接覆盖原 `description` 的三个小节为分析补充后的内容（HTML 格式），**不追加**【分析备注】段
+- **类型码映射**：`RR` → 初始需求，`US` → 用户故事，`Task` → 任务
+- **状态码映射**：`Start` → 初始，`Analyse` → 分析，`Plan` → 规划，`Doing` → 实现，`Delivered` → 交付，`Checking` → 验收，`Finish` → 完成