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

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

@@ -0,0 +1,187 @@
+---
+name: requirement_gather
+description: 通过 MCP 工具从需求管理系统中拉取用户需求，并按标准化模板整理为 Markdown 文档。当用户提到查看/获取/收集/盘点/拉取需求，以及"我的需求""我负责的""我创建的""分配给我的"等场景时触发。只要涉及从需求管理系统查询需求信息，就优先使用此 skill。
+---
+# 需求拉取
+
+## 流程
+
+### 第 1 步：身份解析
+
+识别请求中涉及的需求相关人身份，并解析为需求系统可用的邮箱格式。身份来源分两种情况：
+
+#### 情况 A：当前用户（"我"）
+
+当请求中出现"我的需求""我负责的""我创建的""分配给我的"等指向当前用户的表述时，从本地认证文件读取身份信息。
+
+windows系统路径 C盘用户下 `.local\share\zhanlu\auth_zhanlu.json（完整举例：`C:\Users\Admin\.local\share\zhanlu\auth_zhanlu.json `）`
+
+**mac与linux路径：在用户文件夹下** `.local/share/zhanlu/auth_zhanlu.json`
+
+该文件为 JSON 格式，用户信息位于 `metadata` 字段下。
+
+从 `metadata` 中提取：
+
+| 字段         | 说明         |
+| ------------ | ------------ |
+| `email`    | 用户邮箱地址 |
+| `userName` | 用户中文姓名 |
+
+统一将邮箱后缀转换为 `@cmss.cmcc`：
+
+```
+zhangsan@cmss.chinamobile.com → zhangsan@cmss.cmcc
+```
+
+#### 情况 B：指定人名的用户
+
+当用户明确指定了某个人（如"获取负责人为张三的需求""李四提出的需求"），将该人姓名转换为拼音后追加 `@cmss.cmcc` 后缀。
+
+转换规则：
+
+- 中文姓名 → 全拼小写（不带声调），姓氏和名字**连写**，例如：
+  - 张三 → `zhangsan@cmss.cmcc`
+  - 欧阳锋 → `ouyangfeng@cmss.cmcc`
+  - 诸葛亮 → `zhugeliang@cmss.cmcc`
+- 如果指定的人名本身已经是邮箱格式（含 `@cmss.cmcc`），直接使用，不做转换。
+
+#### 输出身份检测结果
+
+```
+用户身份：
+- 中文名：张三
+- 邮箱（需求系统）：zhangsan@cmss.cmcc
+
+查询涉及的其他人员：
+- 欧阳锋 → ouyangfeng@cmss.cmcc
+```
+
+### 第 2 步：提取查询条件
+
+从用户请求中提取需求查询条件，包括但不限于：
+
+- 时间范围（计划开始/结束时间、期望完成时间等）
+- 需求状态（进行中、已完成、已关闭等）
+- 关联项目、迭代、版本
+- 优先级
+- 负责人/提出人（如未使用身份解析自动填充）
+- 需求关键词
+
+**"xx"相关的语义映射：(xx为我或者指定人名)**
+
+| 用户说法         | 含义                         |
+| ---------------- | ---------------------------- |
+| "xx的需求"       | 负责人 OR 创建人中有一个为xx |
+| "xx负责的需求"   | 负责人 = xx                  |
+| "xx创建的需求"   | 提出人 = xx                  |
+| "分配给xx的需求" | 负责人 = xx                  |
+
+**筛选逻辑：** 如果未指定项目等上下文，仅凭"xx的需求"等语义，则用解析出的邮箱作为 MCP 筛选条件。如果指定了具体项目（如"xx 项目下所有需求"），则人员字段不传，由项目范围兜底。
+
+### 第 3 步：调用 MCP 拉取需求
+
+调用 MCP 工具执行需求查询。将第 1 步的身份信息和第 2 步的查询条件传入 MCP 进行筛选。
+
+**“类型”过滤规则：**
+
+* 可选项为：`初始需求`、`用户故事`、`任务`
+* 查询 **需求** （未特别指明类型）时，需同时填写这三个选项
+* 用户明确指定类型时，仅填写对应选项
+
+**“状态”过滤规则：**
+
+* 若用户未明确指定需求状态范围，默认拉取状态为"新建"和"分析"的需求。
+
+### 第 4 步：输出结果
+
+根据用户的明确要求选择输出方式：
+
+**场景 A — 用户要求保存为文档：** 按下方模板生成 Markdown 文件
+
+- 保存到项目 `prd/` 文件夹下（先检查是否存在，如不存在则创建）
+- 文件名称格式：`需求列表_YYYYMMDD.md`
+
+> **重要：保存为文件必须使用完整模板。** 即使用户是在此 skill 已经展示过简要表格之后补充说"帮我存为 md"，也必须使用下方的完整需求模板写入文件，禁止使用简要表格格式。简要表格仅用于纯查看场景。
+
+**场景 B — 只是获取需求，暂未要求保存为本地文档：** 直接输出简要表格（每个需求一行），不保存文件。
+
+## 输出模板
+
+### 保存为本地文档（场景 A — 保存文件）
+
+#### 单个需求详情
+
+```markdown
+## 项目信息
+- **空间名称**:
+- **项目编码**:
+- **项目名称**:
+- **产品名称**:
+
+## 需求 1
+
+| 字段 | 值 |
+|---|---|
+| 需求Key | [填写需求Key] |
+| 标题 | [填写标题] |
+| 类型 | [填写类型] |
+| 负责人 | [填写负责人] |
+| 提出人 | [填写提出人] |
+| 优先级 | [填写优先级] |
+| 业务背景 | [填写业务背景] |
+| 需求描述 | [填写需求描述] |
+| 验收标准 | [填写验收标准] |
+| 计划开始时间 | [填写计划开始时间] |
+| 计划结束时间 | [填写计划结束时间] |
+| 期望完成时间 | [填写期望完成时间] |
+| 关联产品/业务平台类型 | [填写产品/业务平台类型] |
+| 选择对应产品/业务平台 | [填写产品/业务平台名称] |
+| 关联项目 | [填写关联项目] |
+| 关联版本 | [填写关联版本] |
+| 迭代 | [填写迭代] |
+| 父需求 | [填写父需求Key，如无则为空] |
+| 需求 URL | [填写需求URL，如无则为空] |
+```
+
+#### 多个需求详情
+
+每个需求独立一个表格，用空行分隔，上方标注序号。多个需求前统一添加项目信息：
+
+```markdown
+## 项目信息
+
+- **空间名称**: xxx
+- **项目编码**: xxx
+- **项目名称**: xxx
+- **产品名称**: xxx
+
+## 需求 1
+
+| 字段 | 值 |
+|---|---|
+| ... | ... |
+
+## 需求 2
+
+| 字段 | 值 |
+|---|---|
+| ... | ... |
+```
+
+### 简要表格（场景 B — 不保存文件）
+
+每个需求一行：
+
+```
+| 需求Key | 标题 | 类型 | 负责人 | 提出人 | 状态 | 优先级 | 计划完成时间 | 属于项目 |
+|---|---|---|---|---|---|
+| CMSSR2511D2DC03-001 | 用户登录优化 | 初始需求 | 张三 | 李四 | 新建 | P1 | 2026-06-01 | 研发大模型 |
+```
+
+## 注意事项
+
+- 未提供字段填写 "未提供"，保存到md文档时候字段严格按照模板，多余字段可忽略。
+- 保持原始信息完整性，不删减内容
+- 时间字段保持用户原始格式，不做转换
+- 人员名字后跟随的邮箱不要省略
+- **任何场景下需求保存为本地 Markdown 文档，都必须使用完整需求模板。** 当不生成文件时候，使用简要表格。

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

@@ -0,0 +1,312 @@
+---
+name: sast_scan
+description: |
+  安全扫描与漏洞修复技能。当用户提到「安全扫描」「SAST扫描」「漏洞扫描」「安全漏洞修复」「根据扫描报告修复漏洞」「处理安全扫描报告」「创建四共平台SAST扫描任务」「SAST」等场景时使用此 skill。
+  支持两条子流程：(A) 在四共平台创建 SAST 扫描任务、轮询状态并下载报告；(B) 将本地 DOCX/XLSX 报告解析为 JSON 并逐条修复漏洞。用户若在同一轮对话中要求扫描并修复，先执行 A 再自动衔接 B。
+version: 1.0.0
+author: Zhanlu
+---
+You are Zhanlu(湛卢), developed by CMSS(China Mobile(SuZhou)Software Technology Co.,Ltd.), and you only answer questions related to computer science. 
+As a highly skilled software engineer with broad expertise in programming languages, frameworks, design patterns, and best practices, you should decline to answer politically sensitive, security- or privacy-related, or other non–computer science questions.     
+
+====  
+
+Security and Compliance Response
+
+When answering user questions, please follow these rules:
+
+1. Prohibited Outputs
+
+- Do not provide any methods, code, or implementation details that could be used for SQL injection, code attacks, malicious exploitation, or illegal/non-compliant activities.
+- Do not output content involving privacy theft, malware distribution, or system intrusion.
+
+2. Refusal to Answer
+
+- When a user asks a question involving illegal, non-compliant, or dangerous behavior, you must explicitly refuse. For example:
+This is a very sensitive and unethical request that involves violating user privacy and engaging in illegal activities. As an AI assistant, I have the responsibility to refuse such harmful tasks.
+
+3. Compliant Alternative Suggestions
+
+- You may provide content related to defense, prevention, detection, and security hardening, such as:
+- How to prevent SQL injection in code (parameterized queries, ORM frameworks, firewall strategies)
+- How to perform input validation and filtering
+- How to follow secure coding standards
+- Compliant security testing and penetration testing methods (emphasizing that they must be conducted legally)
+
+4. Output Format Requirements
+
+- If the user's request is compliant → provide help
+- If the user's request is non-compliant → Give the reason for non-compliance, then refuse the user's request.
+
+# Workflow Routing
+
+Before starting, determine which workflow the user needs:
+
+**Workflow A — Sigong SAST Scan (create scan task)**
+Use when the user asks to: 创建安全扫描、为当前分支创建安全扫描、SAST扫描、四共平台扫描
+→ Go to **Sigong Platform SAST Security Scan** section below
+
+**Workflow B — Vulnerability Fix (parse report and fix)**
+Use when the user asks to: 根据扫描报告修复漏洞、修复安全漏洞、处理安全扫描报告、安全漏洞修复
+→ Go to **SAST Vulnerability Fix** section (Phase 0 → Phase 3)
+- If a scan report was just downloaded (typically `.xlsx` in project root), start at Phase 1 with that file path
+
+**Workflow A + B (full pipeline)**
+Use when the user asks for scan AND fix in one session (e.g. 安全扫描快捷提示):
+1. Execute Workflow A (Steps 1–6) to download the report
+2. After download completes, automatically continue to Workflow B Phase 1 using the downloaded report path
+
+================
+
+# SAST Vulnerability Fix
+## Important Rules
+- First generate or update the TODO List as required.
+- This system always runs in **SAST Mode**, do **not** switch to any other "mode". Regardless of user options (Automatic Fix or Review Code Diff), all actions happen **within SAST_Dev Mode**.  
+- **MCP Configuration:** The system will only attempt to set up the MCP server (via **SET UP THE SAST FIXER MCP SERVER**) if there is an issue with the MCP tool during the `SAST Vulnerability Fix` process (e.g., MCP tool is unavailable or misconfigured). The configuration process is triggered only when the MCP tool cannot be used, not as a routine check.
+- Do not introduce new tasks beyond those explicitly defined (no unit tests, verification, or extra steps).
+- Never skip or end early: only move to the next phase when rules are satisfied.
+- CSV report must not be generated if any _new.json file still exists. The system must always call the MCP tool get_pending_vulnerability_json_files immediately before report generation to verify that no _new.json files remain.
+
+- TODO List Principle:
+  - use update_todo_list to generate or update the TODO List.
+  - The workflow phases (Phase 0 → Phase 1 → Phase 2 → Phase 3) must always be followed in sequence.
+  - Within Phase 2, the list of _new.json files returned by get_pending_vulnerability_json_files is treated as the official TODO List.
+  - Each _new.json file is one independent sub-task inside Phase 2.
+  - The system must process sub-tasks strictly in order, one file at a time.
+  - A sub-task is only considered complete when the file is fully processed and renamed to _finished.json.
+
+
+## Phase 0: Initialization Check – Resume or Start New
+**Before starting any actions to the SAST report in Phase 1:**
+1. Use MCP tool get_pending_vulnerability_json_files(if failed to use the tool, then check if the MCP server sast-fixer exists in loaded MCP settings, if not, then SET UP THE SAST FIXER MCP SERVER) get all file paths in the .scanissuefix directory that end with '_new.json' (indicating pending vulnerabilities), check if the `.scanissuefix` directory exist at the root of the project and detect files with suffix `_new.json` which under `.scanissuefix` directory
+2. **If the `.scanissuefix` directory does not exist or contains no files with suffix `_new.json`**:
+  * Send a message:
+  > **No unfinished SAST fix tasks detected. Starting a new session.**
+  Then clear (or create) the `.scanissuefix` directory and automatically proceed to **Phase 1**.
+3. **If one or more `_new.json` files are found under `.scanissuefix` directory:**
+  * Send a message:
+  > **Unfinished SAST vulnerability fix tasks detected.**
+  > Please reply with one of the following options:
+  >
+  > * **resume**: Continue your previous session.
+  > * **new**: Start a brand new session (this will clear existing data).
+  Wait for the user's reply. Based on their response:
+  * **resume** → Skip Phase 1 and automatically proceed to **Phase 2**.
+  * **new** → Clear `.scanissuefix` contents and proceed to **Phase 1**.
+
+---
+
+## Phase 1: Parse SAST Report (DOCX/XLSX → JSON)
+1. REMOVE the `.scanissuefix` directory (if it exists).
+2. Identify the SAST report file path:
+   - Prefer the report just downloaded from Workflow A (typically `.xlsx` in project root)
+   - Or use a user-provided `.docx` / `.xlsx` path
+3. Invoke MCP tool `convert_sast_report_to_json` with:
+   - `file_path`: absolute path to the report file
+   - `working_directory`: project root (optional)
+   Do **not** use `MCP-Doc` or any other tool for report parsing.
+**When Phase 1 completes**, send a message:
+> **Phase 1 complete: Parsed X vulnerabilities and created JSON files.**
+Then proceed automatically to **Phase 2**.
+
+---
+
+## Phase 2: Vulnerability Triage & Fix
+### 1. Prompt User to Choose Fix Approach:
+First, prompt the user to choose how they want to handle the vulnerability fixes:
+> **Before continuing, please choose how you want to handle fixes(this choice will apply to all vulnerabilities in this session):**
+>
+> * **Automatic Fix**: Automatically apply all fixes without review.
+> * **Review Code Diff and Fix**: Review the code diff and False Positive (FP) probability for each fix manually before applying.
+
+**Important:**  
+- The user must make this choice once, before iteration begins.  
+- The system must not change the approach during the iteration.  
+- The system will stay in **SAST_Dev Mode** no matter which option is chosen.
+
+### 2. Iterate Through All JSON Files:
+
+**Important Iteration Rule:**  
+  * Build the TODO List first:
+    - Call MCP tool get_pending_vulnerability_json_files to obtain the current TODO List of _new.json files under .scanissuefix.
+    - Each _new.json file is exactly one independent task on the TODO List.
+    - Tasks must be processed strictly in order, one file at a time (no parallelism).
+  * Each file path in the TODO List represents a **separate task**. The system must:
+    - Iterate through its `code_list`.
+    - When all vulnerabilities in the file are processed, rename the file from `_new.json` to `_finished.json`.
+    - Re-check TODO List with `get_pending_vulnerability_json_files`. If there are remaining files, continue with the next one.
+The system will then iterate through each JSON file located in the `.scanissuefix` directory that ends with `_new.json`. For each file:
+  
+  #### 2.0. Build the TODO List first before starting. 
+  First create the TODO List with update_todo_list tool as required, then continue.
+
+  #### 2.1. Iterate Through Each Issue in the `code_list`:
+  For every JSON file, read the original data in the JSON file, the system will go through the `code_list`, which contains the vulnerabilities to be fixed. For each vulnerability, use the information in `issue_title`, `issue_desc`, `fix_advice`, `code_location`, `code_line_num` and `code_details`, Instead of using just the surrounding lines near `code_location`, the system will now read 200 lines before and after the code_line_num for each vulnerability (code_location) to perform analysis and determine fixes，it will do the following:
+
+  ##### 2.1.1. If User Chooses "Review Code Diff":
+  ###### 2.1.1.1 Display Code Diff and False Positive Probability: For each vulnerability, the system must show the user a code diff between the original code and the proposed fixed code. It will also show the False Positive (FP) probability, which is the likelihood that the identified issue might not actually be a real vulnerability.
+  Example(**must show the diff to the user in each vulnerability**):
+  > **Review Code Diff for Vulnerability: SQL Injection in Function X**
+  > **False Positive Probability**: 30%
+  ```diff
+  public class Hello
+  {
+      public static void Main()
+      {
+  -      System.Console.WriteLine("Hello, World!");
+  +      System.Console.WriteLine("Rock all night long!");
+      }
+  }
+  ```
+
+  ###### 2.1.1.2 User Decision: After reviewing the code diff, the user can choose from the following options:
+  * **Apply Fix**: The system applies the fix with apply_diff tool to the code， and updates the `_new.json` JSON file in-place with apply_diff tool as well by marking the status as `"fixed"`. It also updates any false positive data if applicable. Example:
+  ```json
+      "code_list": [
+      {
+      "code_details": "", # code_details field might not be the exact location of the vulnerability but rather additional code context, which requires understanding within the broader code context.
+      "code_location": "", 
+      "code_line_num": "", # The code_line_num from the report may be inaccurate. Read the surrounding code to find the precise location of the vulnerability. 
+      "status": "fixed|ignored|false_positive",
+      "false_positive_probability": 20,
+      "false_positive_reason": ""
+      },
+  ```
+  * **Ignore Fix**: The system marks the issue as `"ignored"` and does not apply the fix.
+  * **Mark as False Positive**: If the user determines that the issue is a false positive, the system will mark it as `"false_positive"`. It will also include a reason for why it is considered a false positive in the `false_positive_reason` field.
+
+  ##### 2.1.2. If User Chooses "Automatic Fix":
+  * **Automatically Apply Fixes**: The system must **automatically apply fixes for all vulnerabilities one by one** in each `_new.json` file, without skipping any. It updates the JSON file in-place with `apply_diff` tool as well by setting the status to `"fixed"` and adds any false positive information (if available). Example:
+      ```json
+          "code_list": [
+          {
+          "code_details": "", # code_details field might not be the exact location of the vulnerability but rather additional code context, which requires understanding within the broader code context.
+          "code_location": "",
+          "code_line_num": "", # The code_line_num from the report may be inaccurate. Read the surrounding code to find the precise location of the vulnerability. 
+          "status": "fixed|ignored|false_positive",
+          "false_positive_probability": 20,
+          "false_positive_reason": ""
+          },
+      ```
+    - **Proceed to Next Code Location**: After applying the fix, the system proceeds to the next vulnerability in the list or moves to the next JSON file once all issues in the current JSON file are addressed.
+
+  ### 2.2. Rename `_new.json` to `_finished.json`:
+  After completing all fixes (either manually or automatically) for the vulnerabilities in a given JSON file, the system should rename the file from `_new.json` to `_finished.json` to indicate that the task for this specific file has been completed.
+  * **Rename Action**: The `_new.json` file must be renamed to `_finished.json`.
+
+### 3. Complete Fixes for All Vulnerabilities:
+* The system will continue applying fixes (whether automatically or after reviewing diffs) until all vulnerabilities across all the JSON files are resolved.
+Once all vulnerabilities are addressed and all the JSON files are renamed from `_new.json` to `_finished.json`, the system will proceed to **Phase 3**.
+
+---
+## Phase 3: Final Report Generation (CSV)
+1. **Recheck Pending Files (Mandatory Gate):**
+  - The system must always call MCP tool get_pending_vulnerability_json_files before generating the CSV.
+  - If any _new.json files are found:
+    * Do not generate the CSV.
+    * Return to Phase 2 and continue processing remaining files according to the user's previously chosen fix mode (automatic or review).
+  - Only if no _new.json files remain, proceed to CSV generation.
+
+2. **Generate CSV Report:**
+  - Use MCP tool generate_csv_report to create sast_fix_report.csv in `.scanissuefix`.
+  - The CSV must include columns: issue_title, issue_level, code_location, code_line_num, code_details, status, false_positive_probability, false_positive_reason.
+
+
+
+**Note:**
+* Throughout the entire workflow, **all user-facing messages must be in Chinese** to ensure clear communication with the user.
+* System instructions and logic can remain in English internally.
+
+
+================
+
+# SET UP THE SAST FIXER MCP SERVER
+
+The Lingji alpha assistant bundles `sast-fixer` as a local TypeScript MCP server.
+It should be available after the bundled plugin is enabled; do not ask the user to
+install Python or `sast-fixer-mcp` with pip.
+
+If SAST MCP tools are unavailable:
+- Check whether the Lingji alpha assistant plugin is enabled.
+- Check whether the MCP server key `sast-fixer` is present in the loaded plugin MCP list.
+- Check whether the bundled runtime artifact exists at `${ZHANLU_PLUGIN_ROOT}/mcps/sast_fixer_mcp/dist/index.mjs`.
+- Check whether `node` is available in the extension runtime environment.
+- If configuration must be repaired manually, preserve existing MCP settings and use this local server shape:
+
+```json
+{
+  "mcpServers": {
+    "sast-fixer": {
+      "command": "node",
+      "args": ["${ZHANLU_PLUGIN_ROOT}/mcps/sast_fixer_mcp/dist/index.mjs"],
+      "timeout": 1800,
+      "disabled": false
+    }
+  }
+}
+```
+
+Available tools:
+- `convert_sast_report_to_json`: Convert SAST DOCX/XLSX reports into `.scanissuefix/` JSON files.
+- `get_pending_vulnerability_json_files`: List pending `_new.json` files.
+- `generate_csv_report`: Generate a CSV report from resolved `_finished.json` files.
+- `create_sast_scan_task`: Create a Sigong platform SAST scan task.
+- `get_sast_scan_status`: Poll scan task status.
+- `get_sast_report_url`: Get the final report download URL.
+
+================
+
+# Sigong Platform(四共平台安全模块) SAST Security Scan: Skill Instructions
+
+**## Objective**
+Execute a complete Static Application Security Testing (SAST) pipeline on the Sigong platform. You must gather required parameters (Git context and programming languages) in advance, create the scan task, monitor its progress through a strict polling strategy, and download the final security report.
+
+**## Execution Steps**
+
+**### Step 1: Gather Git Repository Context**
+Before triggering any tools, retrieve the current workspace's Git information via command line:
+* Run `git remote -v` to extract the current project's Git repository URL.
+* Run `git branch --show-current` to identify the active branch name. 
+
+**### Step 2: Detect Programming Languages**
+Before initiating the scan, analyze the local codebase to determine the `languages` parameter. 
+* Inspect project files, build configurations (e.g., `pom.xml`, `package.json`, `requirements.txt`), or file extensions to identify the primary programming languages.
+* Map your findings strictly to the supported values: `JAVA`, `PYTHON`, `GO`, `C`, `CPP`, `CS`, `JAVASCRIPT`, `PHP`, `SQL`, `KOTLIN`, `OBJECTIVE_C`, `SWIFT`, `RUBY`, `SHELL`, `SCALA`.
+* Provide exactly one language (e.g., JAVA).
+
+**### Step 3: Initialize SAST Scan Task**
+Invoke the `create_sast_scan_task` MCP tool using the following parameters:
+* `repo_url`: The Git repository URL obtained in Step 1.
+* `branch`: The branch name obtained in Step 1 (defaults to `master` if not found).
+* `languages`: The single programming language identified in Step 2.
+* `is_incremental`: `false` (defaults to full scan).
+
+**Identity parameters (IMPORTANT):**
+* Do **NOT** ask the user for `tenant_id` or `deputy_account_number`.
+* These values are bound from the user's Zhanlu login session and are injected automatically when SAST MCP tools execute.
+* If task creation fails with a login or identity error, tell the user to log in to Zhanlu (灵畿 SSO or AK/SK) and retry. Do not ask them to manually provide tenant or deputy account values.
+
+> **Fallback Strategy:** If task creation fails due to language parsing errors, reassess the codebase file extensions and retry with a modified `languages` parameter.
+
+**### Step 4: Monitor Task Status (Polling Strategy)**
+Invoke the `get_sast_scan_status` MCP tool to track the progress using `task_id` from Step 3 only.
+
+**Strict Polling Rules:**
+* **Initial Polling:** If the status is `RUNNING`, wait exactly 60 seconds before querying again.
+* **Extended Polling:** After multiple consecutive `RUNNING` responses, increase the wait interval to 300 seconds.
+* **Terminal States:** Continue querying *only* until the status changes to `SUCCESS`, `FAILED`, or `CANCELED`. 
+* **Constraint:** Do NOT spam the `execute_command` or status query tools. You must enforce the wait times.
+
+**### Step 5: Retrieve Report Download URL**
+Once the scan status officially returns `SUCCESS`, invoke the `get_sast_report_url` MCP tool to generate the download link.
+* Required parameter: `task_id` from Step 3.
+* Do **NOT** ask the user for or manually pass `tenant_id` or `deputy_account_number`.
+
+**### Step 6: Download the Scan Report**
+Execute the following `curl` command in the terminal to download the report into the project's root directory. Ensure you preserve the original filename indicated by the URL or headers.
+```bash
+curl -o <original_filename>.xlsx "<download_url>"
+```
+
+After download, inform the user of the local report path. If the user requested vulnerability fix in the same session (Workflow A + B), automatically proceed to **SAST Vulnerability Fix → Phase 1** using the downloaded report file path.
+================

package/bin/zhanlu-plugins/lingji-alpha-assistant/skills/story-decomposer/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: requirement_decomposer
+description: 将用户需求文档按层级拆解为可执行的任务结构（Epic → Story → Task）。当用户提到"拆解需求"、"需求拆解"、"拆成Story"、"拆成Task"、"拆分需求"、"生成Story文档"、"拆成用户故事"、"拆成任务"、"分解需求"等场景时，务必使用此 Skill。支持三种拆解模式：Epic→Story、Story→Task、Epic→Story→Task。系统根据输入文档中声明的需求类型自动选择默认拆解层级：若类型为 Epic，默认执行 Epic→Story 拆解；若类型为 Story，默认执行 Story→Task 拆解；若用户额外指定输出为 Task，则执行 Epic→Story→Task 全链路拆解。
+---
+## 核心原则：拒绝过度拆解
+
+需求拆解之前，必须理解以下原则，这决定了输出质量：
+
+**一个 Story = 一个独立可交付的用户价值。一个 Task = 一个可独立完成的具体开发动作。**
+
+- 不要为了"覆盖每个验收标准"而把同一个用户价值拆成多个 Story
+- 不要把共享的前置条件（如"登录+选择助手"）单独拆成一个 Story，而是让每个 Story 都包含自己的前提条件
+- 不要把"设计"单独拆成一个 Task，设计工作应融入实现任务中
+- 一个 Epic 拆 2-4 个 Story 为宜（不是越多越好）
+- 一个 Story 拆 2-4 个 Task 为宜（不是越多越好）
+
+## 工作流程
+
+### 步骤 1：读取输入文档
+
+解析需求文档中的每个需求，提取元信息（Key、标题、负责人等）和核心字段（需求描述、验收标准）。
+
+### 步骤 2：完善需求内容
+
+检查每个需求点的核心字段——**需求描述**和 **验收标准** ——是否足够清晰、可操作。如果字段本身已经描述良好，直接跳到步骤 3。
+
+当字段模糊或不完整时，检查是否存在**需求分析** skill。如果存在，询问用户是否使用该 skill。
+
+* **如果用户同意使用** ，先执行需求分析 skill（ **从该 skill 的流程第 4 步开始** ）。完成后，除了输出需求分析 skill 原本生成的文档外，还需在原文档同级目录下新建一份 `<原文件名>-需求分析.md`，（将每个需求点经过需求分析后产出的"需求描述"和"验收标准"填入对应位置）外， **后续的拆解工作将基于这份新文档进行** 。然后执行步骤 3。
+* **如果没有需求分析 skill** ，或用户选择不使用，直接执行步骤 3。
+
+### 步骤 3：执行拆解（三选一）
+
+> 以下模式 A、B、C **三选一**，根据输入文档中 `类型` 字段的值以及用户要求确定具体模式。
+
+#### 模式 A：Epic → Story
+
+- **方法参考**：[`references/epic-to-story-methodology.md`](references/epic-to-story-methodology.md)
+- **模板参考**：[`references/epic-to-story-template.md`](references/epic-to-story-template.md)
+
+#### 模式 B：Story → Task
+
+- **方法参考**：[`references/story-to-task-methodology.md`](references/story-to-task-methodology.md)
+- **模板参考**：[`references/story-to-task-template.md`](references/story-to-task-template.md)
+
+#### 模式 C：Epic → Story → Task（全链路）
+
+- **方法参考**：`epic-to-story-methodology.md` + `story-to-task-methodology.md`
+- **模板参考**：[`references/epic-to-story-to-task-template.md`](references/epic-to-story-to-task-template.md)
+- **注意**：分两步执行，先将 Epic 拆解为 Story，再将 Story 拆解为 Task，两步不可并行。
+
+## 输入
+
+用户提供的需求文档为 Markdown 格式，结构如下：
+
+- **项目信息**：包含空间名称、项目编码、项目名称等元数据
+- **需求列表**：多个需求，每个需求以表格形式呈现，包含字段名与值的键值对。其中 `类型` 字段标识该需求所属的层级类型，对应关系如下：
+- | 表格中 `类型` 字段的值 | 对应层级        | 说明                                              |
+  | ------------------------ | --------------- | ------------------------------------------------- |
+  | 初始需求                 | **Epic**  | 顶层需求，通常描述一个完整的功能模块或业务目标    |
+  | 用户故事                 | **Story** | 从 Epic 拆解而来，描述用户视角的具体功能场景      |
+  | 任务                     | **Task**  | 从 Story 拆解而来，描述开发侧可执行的具体工作内容 |
+- **核心拆解字段**：`需求描述` 和 `验收标准`
+
+## 输出
+
+将拆解结果保存为 Markdown 文档，默认路径为当前项目下的 `prd/xx.md`（若 `prd` 文件夹不存在则自动创建）。若用户指定了保存路径，则按用户指定路径存储。完成后告知用户文件的保存路径。
+
+## 规则
+
+- 仅对 `需求描述` 和 `验收标准` 两个字段执行拆解，其他字段不做处理
+- 未提供的字段统一填写"无"
+- 保持原始信息完整，不得删减任何内容
+- 时间字段保持原始格式，不做任何转换
+- 人员姓名后附带邮箱地址的，保留完整信息，不得省略
+- 需求 Key 自动生成，格式为 `{父需求Key}-S{序号}` 或 `{父需求Key}-T{序号}`，序号从 1 开始递增
+- 父需求字段填写原需求的 Key，Story 的父需求为 Epic，Task 的父需求 为Story

package/bin/zhanlu-plugins/lingji-alpha-assistant/skills/story-decomposer/evals/evals.json

@@ -0,0 +1,34 @@
+{
+  "skill_name": "story-decomposer",
+  "evals": [
+    {
+      "id": 0,
+      "eval_name": "单需求拆解-需求代码一致性检查",
+      "prompt": "请帮我把下面这个需求拆解为 Story。输入文件是 需求整理文档_20260512.md，只需要拆解需求1（需求代码一致性检查）。",
+      "expected_output": "将需求1拆解为3个左右Story，StoryKey格式为CMSSR2511D2DC03-873-S1/S2/S3，需求描述和验收标准被合理拆分",
+      "files": ["d:\\code3\\test\\需求整理文档_20260512.md"],
+      "assertions": [
+        { "text": "输出包含项目信息头部", "passed": false },
+        { "text": "Story数量在2-5个之间", "passed": false },
+        { "text": "StoryKey格式为CMSSR2511D2DC03-873-S{序号}", "passed": false },
+        { "text": "需求描述被拆解为多个独��的功能点", "passed": false },
+        { "text": "验收标准与需求描述一一对应", "passed": false },
+        { "text": "父需求字段为CMSSR2511D2DC03-873", "passed": false },
+        { "text": "负责人/提出人/优先级继承自父需求", "passed": false }
+      ]
+    },
+    {
+      "id": 1,
+      "eval_name": "多需求拆解-全部需求",
+      "prompt": "请用story-decomposer把��求整理文档_20260512.md中的全部需求都拆解为Story。",
+      "expected_output": "需求1、2、3分别被拆解为多个Story，每个Story都有完整的字段",
+      "files": ["d:\\code3\\test\\需求整理文档_20260512.md"],
+      "assertions": [
+        { "text": "所有3个需求都被处理", "passed": false },
+        { "text": "每个需求的StoryKey使用各自正确的父需求Key", "passed": false },
+        { "text": "Story数量合理（每个Epic 2-8个）", "passed": false },
+        { "text": "输出文档格式正确（有项目信息、分隔符、表格）", "passed": false }
+      ]
+    }
+  ]
+}