ai-project-manage-cli 2.0.26 → 3.0.2

package/templates/skills/apm-release/SKILL.md

@@ -1,87 +0,0 @@
----
-name: apm-release
-description: 需求上线：取分支 → 切分支并拉最新 → code-deploy 正式环境 → apm release 同步状态。用户 @ 本技能时使用。
----
-
-# 需求上线（apm-release）
-
-## 输入
-
-- **`requirementId`（必须）**：需求主键 ID。
-- **`-f` / `--force`（可选，默认不加）**：仅当用户在对话中**明确表态**「不用走代码审核 / 不审代码直接上线 / 合并 PR 即可」等同类含义时，第 4 步的 `apm release` 才增加 **`-f`**（与 CLI 一致：创建 PR 后对其实施 squash 合并）。**用户未明确说时一律不带 `-f`**，不得自行替用户决定。
-
-## 执行顺序（严格 1 → 2 → 3 → 4）
-
-### 第 1 步 — 获取分支名
-
-执行：
-
-```bash
-apm get branchName <requirementId>
-```
-
-从标准输出读取**一行分支名**，记为 `BRANCH`。若命令失败，**不要继续第 2、3 步**，直接进入第 4 步（见下：若拿不到 `BRANCH`，`-b` 无法填写时须在对话中说明，并按失败场景处理）。
-
-**对话输出**：本步结束后，在回复中写明**执行状态**（成功/失败）与**结果**（分支名或报错摘要）。
-
-### 第 2 步 — 切分支并拉取最新
-
-1. 若工作区有未提交变更（含未跟踪文件按项目习惯）：先 `git stash`（或等价方式）保存，再切分支。
-2. `git checkout <BRANCH>`（已在该分支可跳过 checkout）。
-3. `git pull`（或 `git fetch` + 与项目一致的合并方式），确保当前分支与远程一致、代码最新。
-4. **合并冲突时**（pull/merge 产生冲突）：
-   - 可先**自行解决**，但**只处理**与本次需求意图**明显无冲突**的情形（例如无关文件、能明确判定为可安全合并的变更）。
-   - 一旦出现**无法分辨**的冲突（说不清是否影响本需求、怀疑与需求意图相悖、或不能确信合并结果正确）：**立即判定本步骤失败**，**不要**猜测性选边或强行合并；进入第 4 步，`-r` 用简短说明（如 `pull 冲突无法安全解决`）。
-
-任一步失败则**停止第 3 步**，进入第 4 步。
-
-**对话输出**：本步结束后，在回复中写明**执行状态**与**结果**（当前分支、pull 是否成功、stash 是否使用、若有冲突则是否已解决或已判失败等）。
-
-### 第 3 步 — 部署正式环境
-
-调用 **`code-deploy` 技能**：按项目 `.apm/deploy/README.md`（或技能约定）部署**线上/正式环境**。
-
-失败则**停止**，进入第 4 步。
-
-**对话输出**：本步结束后，在回复中写明**执行状态**与**结果**（部署是否完成、关键输出摘要）。
-
-### 第 4 步 — 同步状态（`apm release`）
-
-**始终在本流程末尾执行本步**（前面任一步失败也要执行，用于同步服务端状态）。
-
-```bash
-apm release <requirementId> -b <BRANCH>
-# 用户已明确「不审代码直接上线」时（见上文「输入」）：
-apm release <requirementId> -b <BRANCH> -f
-```
-
-- **第 1～3 步全部成功**：带 `-b`；**仅**在用户已明确要求时再加 `-f`。不带 `-r`。
-- **任一步失败**：带 `-b` 与 **`-r`**，`reason` 为**简短**失败说明（十来字～一两行），不要把整段日志塞进 `-r`。**失败路径不要加 `-f`**（`-f` 只用于成功同步且用户明确要跳审合并的场景）。
-
-示例：
-
-```bash
-apm release <requirementId> -b <BRANCH> -r "获取分支失败"
-apm release <requirementId> -b <BRANCH> -r "git pull 冲突"
-apm release <requirementId> -b <BRANCH> -r "code-deploy 失败"
-```
-
-若第 1 步未得到 `BRANCH`，无法在命令行合法填写 `-b` 时：在对话中说明阻塞原因；若能从用户或环境确认分支名再补 `-b`，否则不要编造分支名。
-
-## 对话输出（必选）
-
-**第 1～3 步**在面向用户的回复中用下面表格呈现（每步一行；未执行的步骤填「未执行」及原因）：
-
-| 步骤 | 状态 | 结果/说明 |
-|------|------|-----------|
-| 1 获取分支名 | 成功 / 失败 / 未执行 | 分支名或报错摘要 |
-| 2 切分支并拉取 | 成功 / 失败 / 未执行 | 当前分支、pull/stash/冲突处理摘要 |
-| 3 code-deploy | 成功 / 失败 / 未执行 | 部署是否完成、关键输出摘要 |
-
-**第 4 步**：在表格后另起一段说明是否执行 `apm release`、是否带 **`-r`**、是否因用户明确要求而带 **`-f`**、命令是否成功。
-
-## 约束
-
-- `-r` 仅用于概括失败类型，详细日志放在对话说明里。
-- **`-f`**：仅在用户**明确口头表达**「不审代码直接上线」等含义时使用；不得因图省事或默认假设而加 `-f`。
-- 不要为「碰运气」重复执行同一意图的 `apm release`；成功路径 `-b`（无 `-r`）与失败路径 `-b -r` 各以一次为常例。

package/templates/skills/code-change-summary/SKILL.md

@@ -1,84 +0,0 @@
----
-name: code-change-summary
-description: 在功能分支上相对基线分支（可指定，未指定则用 main/master）生成代码变更摘要；须提供需求 id，结果落盘至 `.apm/workitems/<需求id>/change.md`；对话中只汇报步骤结果、不输出文件正文。用户主动触发，例如在对话中提及本技能时调用。
----
-
-# 代码变更摘要
-
-**目的**：把相对基准分支的改动整理成可读的摘要，便于评审或交接。输出**只包含**下列四类（与 `summary-template.md` 四节一一对应；顺序可调整；无内容按模板留空或写「无」）：
-
-1. **修改原因**：需求/问题背景（仅来自已提供的需求、Issue、说明；**无则留空或「无」，禁止猜测**）。
-2. **改了什么**：涉及哪些路径、整体做了什么（归纳为主，可附文件列表）。
-3. **为什么这么改**：按文件或文件组，说明技术层面的修改动机；**可用 Markdown 表格**（例如列为「路径/文件（组）」「修改原因」）呈现，便于扫读。
-4. **复杂逻辑与编写思路**：有复杂处再展开；否则一句话带过。
-
-## 输入
-
-- **需求 id**（**必填**）：工作项 / 需求唯一标识；用于落盘路径与正文元数据。对话中未给出时，**须先向用户索要**，不得用占位符或猜测值继续生成。
-- **基线分支**（对比起点）：用户可在对话中**明确指定**（例如「相对 `develop` 的变更」）。**未指定**时，在仓库中选用 **`main` 或 `master`**：优先使用存在的 `refs/heads/main`，否则使用 `refs/heads/master`（可用 `git show-ref`、`git rev-parse --verify` 等只读命令确认）。
-- 后续所有 `git log` / `git diff` 均相对该基线分支与当前 `HEAD` 进行比较。
-
-## 触发前提
-
-- **仅在新分支执行**：当前分支必须不是 `main` 或 `master`
-- **用户主动触发**：当用于在对话中提及本技能时触发
-- **已提供需求 id**：无则仅提示补充，不生成、不落盘
-
-## 核心原则
-
-- **依据**：第 1 点只能写「有据可查」的背景；第 2、3 点须与 `git diff`（及对话中用户补充的事实）对齐，不臆测改动意图。
-- **写法**：以归纳与说明为主，**禁止**大段粘贴源码；复杂逻辑用自然语言 / 小标题写清思路即可。
-
-## 执行流程
-
-1. **确定基线并获取变更**（只读 git）：先按上文「输入」解析出 `{BASE_BRANCH}`，记为 `BASE`（用户指定名，或 `main` / `master` 中实际存在的那一个）。
-
-```bash
-git branch --show-current
-git log BASE..HEAD --oneline
-git diff BASE..HEAD --name-status
-git diff BASE..HEAD            # 必要时查看具体 diff
-```
-
-2. **整理「改了什么」**：从 `--name-status` 与 diff 归纳模块、变更类型（新增/修改/删除）与一句话范围。
-
-3. **整理「为什么这么改」**：按文件或文件组，对照 diff 说明动机（修 bug、接新需求、重构、命名约定等）；**推荐用表格**输出，见模板中 `{WHY_PER_FILE}` 填法。
-
-4. **判断是否需要「复杂逻辑与编写思路」**：多文件联动、新抽象、状态机、非直观算法等则展开；否则第四节用一句话带过。
-
-5. **修改原因**：若用户本次对话或链接中**没有**需求描述，该节为空或「无」；若用户粘贴了需求，再提炼为简短背景。
-
-6. **填充模板**：`summary-template.md`，替换全部占位符（含 `{WORKITEM_ID}`）。
-
-7. **交付（落盘）**：
-
-   - **路径**（相对仓库根）：`.apm/workitems/<需求id>/change.md`（`<需求id>` 为输入中的需求 id，与目录名一致）。
-   - **内容**：填充后的完整 Markdown；**勿包含**模板末尾的 `<!-- 填法... -->` 注释块。
-   - **目录**：若 `.apm/workitems/<需求id>/` 不存在则创建后再写入。
-
-## 对话中的汇报
-
-- **只汇报各步骤的执行结果**（例如：基线已解析为 `main`、已读取 diff、已填充模板、已写入某路径）。**不要**在对话中输出、复述或摘要 **`change.md` 的文件内容**（全文与片段均不要），除非用户**另行明确要求**查看。
-
-## 模板占位符
-
-模板路径：`summary-template.md`。
-
-| 占位符 | 含义 |
-|--------|------|
-| `{WORKITEM_ID}` | 需求 id（与输入一致，写入正文元数据） |
-| `{BRANCH_NAME}` | 当前分支名 |
-| `{DATE}` | 生成日期 |
-| `{BASE_BRANCH}` | 本次对比使用的基线分支名（用户指定，或未指定时解析得到的 `main` 或 `master`） |
-| `{CHANGE_REASON}` | 修改原因（无则空或「无」） |
-| `{WHAT_CHANGED}` | 改了什么（文件与归纳） |
-| `{WHY_PER_FILE}` | 为什么这么改（按文件/文件组；**可用表格**，见模板填法） |
-| `{COMPLEX_LOGIC_RATIONALE}` | 复杂逻辑与编写思路（无则简短声明） |
-
-**各占位符的正文结构与填法**：见模板**文件末尾** `<!-- ... -->` 注释。生成最终 Markdown 时**不要输出该 HTML 注释块**。
-
-## 实现注意
-
-- 只读命令：`git branch`、`git diff`、`git log`、`git show-ref`、`git rev-parse`
-- 未指定基线时：优先选用本地存在的 `main`，否则 `master`；若用户指定了其他分支名，则必须以该分支为 `BASE`（需存在且可解析）
-- 落盘：写入 `.apm/workitems/<需求id>/change.md`；`<需求id>` 中含路径不安全字符时，按操作系统与团队约定处理（一般需求 id 为字母数字与 `-`/`_`）

package/templates/skills/code-change-summary/summary-template.md

@@ -1,55 +0,0 @@
-# 代码变更摘要 - {BRANCH_NAME}
-
-**需求 ID**：{WORKITEM_ID}  
-**生成时间**：{DATE}  
-**对比基准**：{BASE_BRANCH}
-
----
-
-## 修改原因
-
-{CHANGE_REASON}
-
----
-
-## 改了什么
-
-{WHAT_CHANGED}
-
----
-
-## 为什么这么改
-
-{WHY_PER_FILE}
-
----
-
-## 复杂逻辑与编写思路
-
-{COMPLEX_LOGIC_RATIONALE}
-
-<!--
-填法（勿粘贴到最终输出）：输出时去掉本注释块。
-
-{WORKITEM_ID}
-- 与技能输入中的**需求 id**一致；同时用于落盘路径 `.apm/workitems/<需求id>/change.md`。
-
-{CHANGE_REASON}
-- 从用户给出的需求、Issue、PR 描述、产品说明等**已提供信息**中提炼背景与动机；若对话或仓库中**没有**可依据的叙述，本小节只保留标题下空行或写「无」（**禁止臆测、补全故事**）。
-
-{WHAT_CHANGED}
-- 基于相对**基线分支**（`{BASE_BRANCH}`）的 `git diff BASE..HEAD` / `--name-status` 归纳：涉及哪些路径、增删改概况；可按「模块 / 职责」分组一句话概括，避免把 diff 全文当正文。
-
-{WHY_PER_FILE}
-- **按文件**（或关系密切的一组文件合并成一条）说明本次修改的直接原因：解决什么问题、与相邻改动的关系；与「改了什么」对应，避免重复贴代码。
-- **呈现**：优先使用 Markdown **表格**，列建议包含「路径 / 文件（组）」与「修改原因」；文件很多时可按目录或模块合并行。示例：
-
-| 路径 / 文件（组） | 修改原因 |
-| --- | --- |
-| `path/to/a.ts` | … |
-| `path/to/`（多文件） | … |
-
-{COMPLEX_LOGIC_RATIONALE}
-- **仅当**存在非显而易见的控制流、状态机、并发、算法、跨层协议时再写；简单字段增删、重命名、配置替换可写「本次无复杂逻辑需单独说明。」或等价一句。
-- 内容侧重：**为何这样拆分**、数据流/调用链、关键取舍；禁止大段粘贴源码。
--->

package/templates/skills/code-deploy/SKILL.md

@@ -1,39 +0,0 @@
----
-name: code-deploy
-description: 按项目内 `.apm/deploy/README.md` 执行部署；仅在用户主动提及该技能或明确要求按部署文档操作时触发。
----
-
-# 按文档部署
-
-## 工作流程（必须按顺序）
-
-1. **读取部署文档**  
-   在**目标项目根目录**下，用 Read 工具阅读：
-
-   `.apm/deploy/README.md`
-
-2. **文档不存在则结束**  
-   若该路径不存在、无法读取或内容为空且无可用步骤：**立即终止**，简要说明缺少 `.apm/deploy/README.md`；**不要**用其它文件（如根 README、package.json、CI 配置）推断部署方式。
-
-3. **文档存在则部署到目标环境**  
-   - **确定目标环境**（可与文档、用户描述对照，作合理推断；与下文「步骤失败」的禁止猜测不是同一回事）：  
-     - 用户若明确说了环境（如预发、生产），以用户为准。  
-     - **若未说明，默认部署到测试环境。**  
-     - 若文档**只提供一种部署方式**、未区分多环境，**按该文档直接执行即可**。  
-     - 若文档区分多环境而用户未点名，**结合文档章节/标题与用户描述**推断；仍无法确定时，**采用默认测试环境**。  
-   - **只执行与本次目标环境相关的部分**（以文档中的章节、命令、变量为准）。  
-   - **严格按文档给出的命令、顺序、目录与环境变量执行**；文档未写明的操作一律不做。  
-   - **若任一步报错**（非 0 退出、明确失败输出、或文档步骤无法继续）：**立即结束**，如实汇报错误与失败步骤；**不要**猜测原因、不要擅自换命令、不要静默重试或「尝试修复」——除非文档本身写了失败时的处理分支。
-
-## 结果汇报与成败判定
-
-`.apm/deploy/README.md` **通常不会**提供「如何确认部署已成功」的校验方式；**不要**自行做健康检查、访问地址验证等以证明服务真实可用。**如实汇报**按文档执行的步骤、命令与终端输出即可，**不宣称**已验证目标环境一定部署成功。
-
-- **失败**：部署过程中出现**明显报错**（例如命令非 0 退出、明确的错误输出、无法按文档继续执行），与上文第 3 步「任一步报错」一致，立即结束并说明失败点。  
-- **非失败**：未出现上述明显报错时，按流程执行完毕后**如实汇总结果**即可，**不**额外判定「是否真的部署成功」。
-
-## 禁止事项
-
-- 绕过或未读 `.apm/deploy/README.md` 就执行部署。  
-- 文档缺失时从别处「推断」部署流程。  
-- 步骤失败后用通用经验替代文档或继续试错。

package/templates/skills/prd-review/SKILL.md

@@ -1,48 +0,0 @@
----
-name: prd-review
-description: 结合本仓库上下文对需求做结构化评审，只有当用户主动提及该技能时才可被使用，该技能调用依赖需求ID。
----
-
-# 需求评审
-
-## 触发条件
-
-用户**明确声明**使用本技能（例如在对话中 @ 本 SKILL）
-
-## 输入
-
-- **`requirementId`(必须)**：需求 ID。
-
-## 输出
-
-- **评审正文（须写入 comment）**：须先按模板在**逻辑上**成文（完整 Markdown 字符串），不得仅给零散要点。**对话中不要粘贴完整评审正文**；全文仅写入 **`.apm/workitems/<requirementId>/comment.md`** 并通过 **`apm set comment`** 提交，供用户在需求侧或系统中查看。
-- 将需求拆成若干条「需求点」（若本就一条则一条），对每条按 [output-template.md](output-template.md) 的**字段规则与并存关系**输出结论。
-- **项目隐性知识沉淀建议（必选，唯一在对话中展示的长文）**：在完成评审正文并**提交 comment 之后**，在对话里**只**输出这一段（可用 Markdown 小标题）；**不要**在对话中重复贴评审模板全文。目的**不是**把需求写得更细，而是让**仓库侧**的文档、约定、可复用模式更清晰（必要时含代码组织/命名层面的改进方向），使日后**简短需求**也能被 AI 定位「改哪里、怎么改」，减少与「通用/行业默认」不一致时的重复追问（例如本项目的交互惯例、删除是否确认、与已有类似流程应对齐的隐性规则等）。须紧扣**本次需求内容**与**本次评审中暴露的、源于项目与常识差异的盲区**，给出可执行的沉淀项；**禁止**泛泛而谈。**不得**写入 **`.apm/workitems/<requirementId>/comment.md`**，**不得**作为 `apm set comment` 的正文内容。
-- 语言面向产品可读：少堆砌实现细节，**不**用具体文件路径、函数名当「证据」；仓库仅用于理解**能力边界、术语与业务上下文**。
-
-结构要点（写入 comment 的部分以 `output-template.md` 为准）：`### 评审人`、`### 需求点 n`、`- **需求描述：**:` 及可选的 `业务合理性` / `问题` / `可行性` / `风险点`。**不包含**「隐性知识沉淀」类段落。
-
-## 评审原则
-
-1. **产品视角优先**：用户侧影响、业务闭环、风险与待确认点；避免晦涩技术术语堆砌。
-2. **与仓库对齐（能力边界）**：阅读 `AGENTS.md`、子项目说明、`.apm/product-capability-inventory` 等与需求相关的部分，判断需求是否与既有能力/术语冲突、是否超出现有边界。**禁止**用「某文件某行」证明 PRD 对错；**禁止**根据代码**猜测** PRD 未写清的口径——口径不清应归入「问题」待产品澄清。
-3. **业务合理性（按需）**：结合仓库可读的业务/产品上下文，判断需求是否想清楚、方案是否当下较优、是否与业务目标或流程冲突。**仅当**不合理、需再商榷或非当下较优时，才写 `- **业务合理性：**:`；合理则**不写**该字段。
-4. **信息完备与落地（互斥规则）**：
-   - 仅当 PRD/需求信息**不足以**形成开发可执行描述（关键落点、口径、范围、汇总规则等无法确定）时，写 `- **问题：**`，此时**不写**可行性与风险点。
-   - 若已足以判断「可以实现」（非关键细节不阻塞落地），写 `- **可行性：**`（成本低/中/高 + 精简说明）；影响面大时再追加 `- **风险点：**`。
-5. **澄清优先但不泛问**：不阻塞落地则不提问；不问可推断的琐碎问题。
-6. **隐性知识沉淀可执行**：对用户单独输出的每条沉淀建议应能回答「在仓库里补什么、能消除哪类隐性歧义」；若本次未发现值得沉淀的差异点，仍须给出一句结论（例如「未发现与通用假设显著偏离、需单独成文的隐性规则」）。
-
-## 执行步骤
-
-1. **获取需求正文**：`apm get requirement <requirementId>`，如果报错则停止后面的步骤
-2. **读代码**：阅读仓库源码以及 `.apm/product-capability-inventory` 中与需求相关的条目；不展开无关模块代码。
-3. **拆条**：多条诉求时拆成 `### 需求点 1..N`，每条独立走完「业务合理性（可选）→ 问题 或 可行性（+风险）」逻辑。
-4. **成文（仅评审模板）**：按 `output-template.md` 拼出写入 comment 的 Markdown（顶格可加 `### 评审人` + 当前模型名）；**不含**「隐性知识沉淀」段落；**随即**将**该字符串**写入 **`.apm/workitems/<requirementId>/comment.md`**（如果存在则直接覆盖更新）。
-5. **自检**：每条是否都有「需求描述」；「问题」与「可行性/风险」是否互斥符合 `output-template.md`；是否误引代码路径作论据；comment 全文是否**未混入**隐性知识段落。
-6. **提交评审记录**：`apm set comment <requirementId>`（正文与 comment.md 一致，仅为评审模板内容）。
-7. **对用户的单独陈述**：在对话中**仅**输出「项目隐性知识沉淀建议」（见上文「输出」）；开头可用一句告知「完整评审已写入 comment / 已提交，以下仅为隐性知识沉淀」；**不要**在对话中粘贴评审正文，也**不要**把隐性知识段写入 comment 或重复提交。
-
-## 附加资源
-
-- 输出结构与字段规则：[output-template.md](output-template.md)

package/templates/skills/prd-review/output-template.md

@@ -1,47 +0,0 @@
-### 评审人
-
-模型名称
-
-### 需求点 1
-
-- **需求描述：**: （一句话概括要做什么，产品视角）
-  - （关键点 1）
-  - （关键点 2）
-
-### 需求点 2
-
-- **需求描述：**: （一句话概括要做什么，产品视角）
-
-- **问题：**
-  - （问题 1：必须澄清“页面/表/口径/范围/汇总规则”等）
-  - （问题 2）
-  - （问题 3）
-
-### 需求点 3
-
-- **需求描述：**: （一句话概括要做什么，产品视角）
-
-- **可行性：**
-  - 成本：低/中/高
-  - （在不引入猜测的前提下，说明成本对应的业务/口径/环节调整）
-
-### 需求点 4
-
-- **需求描述：**: （一句话概括要做什么，产品视角）
-- **可行性：**
-  - 成本：中/高
-  - （在不引入猜测的前提下，说明成本对应的业务/口径/环节调整）
-- **风险点：**
-  - （风险 1：可能影响的不止是展示文案，例如统计口径/汇总逻辑/跨模块联动等）
-  - （风险 2）
-
-### 需求点 5（业务合理性：仅不合理时出现）
-
-- **需求描述：**: （一句话概括要做什么，产品视角）
-- **业务合理性：**
-  - （为何不合理/与用户目标或现有业务冲突/用户方案非当下较优；可写更可取的替代思路或需产品先拍板的点）
-- **可行性：**
-  - 成本：低/中/高
-  - （仍可在指出业务问题的同时评估落地成本；若信息仍不足以落地，则改用「需求点 2」结构：业务合理性 + **问题**，不出现可行性/风险点）
-
-字段顺序与并存：`需求描述` 始终第一；`业务合理性` 仅在不合理时出现在 `需求描述` 之后。其后仍遵循「有问题则只写问题，无问题则写可行性（可加风险点）」。

package/templates/skills/prd-sync/SKILL.md

@@ -1,74 +0,0 @@
----
-name: prd-sync
-description: 根据评论与用户回复合并修订需求 PRD，仅当用户主动提及该技能时使用，依赖需求 ID。
----
-
-# 需求 PRD 修订与同步
-
-本技能用于在**需求原文**之上，结合用户给出的**补充信息**，把零散说明整理成**结构清晰、可执行**的一版需求正文：先将定稿**覆盖**本地 `prd.md`，再通过 **`apm set requirement`** 将正文同步到服务端。补充信息**常见**为针对评审的逐条回应，亦可包含用户明确提供的其他修订说明；**仅**将用户明确要写入的口径并入正文，不替用户发挥。
-
-## 触发条件
-
-用户**明确声明**使用本技能（例如在对话中 @ 本 SKILL）
-
-## 输入
-
-- **`requirementId`(必须)**：需求 ID。
-
-可选：**修订范围**（全文重写 / 只改某几节）、**术语表**、**必须保留的编号**。
-
-## 合并原则
-
-1. **正文依据 = 需求原文 + 补充信息**：只把用户在补充信息中**明确**要体现的内容（补充、修改、删除、拍板口径）合并进修订稿；用户没说到的，**保持原文或不写**，**不自作主张**补需求、不替用户「落实」评审建议。
-2. **未回应的评审**：不列入「待确认」、不改成待办、不推断「仍有问题」；视为用户未要求在本次修订中处理（可能无此问题、暂不改、或评审误解）。
-3. **评审的定位**：仅辅助理解补充信息在回应什么；补充信息与评审不一致时，**以补充信息为准**。
-4. **消除重复**：同一议题在原文与补充信息中多处出现时，合并为**一处**表述。
-5. **可追溯（轻量）**：可选「修订说明」概括相对原文的变化，且**只写补充信息实际带来的变化**，不罗列未采纳的评审。
-6. **与仓库一致**：对照 `AGENTS.md`、`.apm/product-capability-inventory` 等，避免修订稿与用户已确认表述冲突；**禁止**用代码路径当需求论据。
-7. **图片引用保持原样**：若原文含图片（如 `<img ...>`），在修订稿中直接保留对应 `img` 标签原文；不要改写成“图片见原始文档”等占位说明。
-
-## 输出
-
-- **落盘（必须）**：将定稿的**完整修订稿**按合并原则写入 **`.apm/workitems/<requirementId>/prd.md`**，结构可参考 [updated-requirement-template.md](updated-requirement-template.md)；**语言**与需求原文一致（中文为主时全文中文）。「用户只要补丁」时仍须先合并为**完整一版**再写入文件。
-- **对话收尾（必须）**：技能执行结束后，在对话中的**最后一条总结**须用 **Markdown 表格**呈现**执行步骤**每一小步的**状态/结果**（例如：已完成 / 已跳过及原因 / 失败及错误信息 / CLI 关键输出摘要）。表格行须覆盖：**1～5** 与 **6.1、6.2**（与下节「执行步骤」对应）。**不要**在对话里复述、概括或摘录**更新后的需求正文**；修订内容以仓库内 `prd.md` 与同步结果为准。
-
-  列名可自拟，示例如下（内容填真实状态即可）：
-
-  | 步骤 | 状态/结果 |
-  |------|-----------|
-  | 1. 拉取需求与评论 | |
-  | 2. 按补充信息合并修订 | |
-  | 3. 评审辅助定位（跳过未回应项） | |
-  | 4. 「待确认」处理 | |
-  | 5. 通读检查 | |
-  | 6.1 覆盖本地 `prd.md` | |
-  | 6.2 `apm set requirement` | |
-
-## 执行步骤
-
-1. **拉取需求与评论（使用 CLI）**：执行 `apm get requirement <requirementId> --all`，获取需求文档及**全部评论**；该命令会将需求信息（含正文、版本与评论等）打印到终端，作为后续修订的**原文与评审依据**。
-2. 以**原文**为底稿，对照**评审内容**，逐条落实**补充信息**中明确要求写进需求的修改。
-3. 仅当某条补充信息明显对应某条评审时，再辅助定位修改位置；**跳过**用户完全未提的评审条目（仍须已提供评审全文/摘录以便对照，但不据此发挥）。
-4. **「待确认」**：仅当**用户自己在补充信息里**留下未决口径、或明确说「待定」「再议」时写入；**不因**评审提了而用户未提供对应补充就填「待确认」。
-5. 通读检查：无内部矛盾；正文无不来自补充信息的「新需求」。
-6. **存档并同步到服务端（两步）**：
-
-   **6.1 覆盖本地需求文档**：将第 5 步定稿的**完整修订稿**写入 **`.apm/workitems/<requirementId>/prd.md`**（**覆盖**原文件，与 `apm get requirement` 拉取下来的路径一致）。
-
-   **6.2 同步到服务器**：在仓库根目录执行 **`apm set requirement <requirementId>`**
-
-   ```bash
-   apm set requirement 1
-   ```
-
-## 自检清单
-
-- [ ] 修订稿中的新增/变更均可追溯到补充信息（或用户要求保留的原文），无「替用户采纳评审」的发挥
-- [ ] 未把未回应的评审当成待解决问题写进文档
-- [ ] 未把评审人猜测当事实写进需求
-- [ ] 修订稿单读可理解，不依赖聊天记录才能懂
-- [ ] `.apm/workitems/<requirementId>/prd.md`与定稿修订稿一致，且已成功执行 `apm set requirement`
-
-## 附加资源
-
-- 推荐输出结构：[updated-requirement-template.md](updated-requirement-template.md)

package/templates/skills/prd-sync/updated-requirement-template.md

@@ -1,39 +0,0 @@
-# [需求标题]（修订稿）
-
-**修订说明**（可选）
-
-- 基于评审日期 / 评审记录：简要一句
-- 本次合并的要点：1～3 条 bullet
-
----
-
-## 背景与目标
-
-（合并原文与用户补充信息中明确补充/修正的表述）
-
-## 范围
-
-- **包含**：
-- **不包含**：（若**补充信息**或原文中明确收窄/排除）
-
-## 需求说明
-
-### 需求点 1：[名称]
-
-（将原文与补充信息合并后的**可执行描述**写清：角色、场景、规则、口径、边界）
-
-### 需求点 2：…
-
-## 非功能与约束（若有）
-
-（性能、权限、兼容、埋点等——仅当原文或补充信息涉及）
-
-## 待确认
-
-仅当**用户自己在补充信息里**留下未拍板事项、或写明「待定」「再议」等时列出（可选章节，可整节省略）：
-
-- [ ] （用户未决口径摘要）— 用户原话或简要归纳
-
----
-
-若用户只需要「替换某几段」而非全文，可仅在回复中给出**修改后的完整段落** + 简短「相对原文的变更摘要」，不必机械填满所有章节。

package/templates/skills/prd-testcase/SKILL.md

@@ -1,82 +0,0 @@
----
-name: prd-testcase
-description: 基于需求文档为其生成测试用例，当用户在明确要求调用本技能时使用，输入参数是 requirementId。
----
-
-# 从需求文档生成手工测试用例
-
-## 触发条件
-
-用户在对话中明确要求使用本技能。
-
-## 输入
-
-- **requirementId**：需求 ID
-
-## 输出
-
-1. 手工测试用例文档：`.apm/workitems/<requirementId>/testcase.md`
-
----
-
-## 执行流程
-
-1. **拉取需求与评论（使用 CLI）**：执行 `apm get requirement <requirementId>`，获取需求文档。
-
-### 2. 提取需求点
-- 需求点是唯一真理：所有测试点、口径、阈值、边界与禁止项必须从需求清单提炼。
-- 将需求拆分为可追踪条目并编号：`REQ-001`、`REQ-002`、`REQ-003`...
-
-### 3. 先做覆盖设计（严格模式）
-
-- **需求正向覆盖（强制）**：每个 `REQ` 至少映射 1 条测试用例（`REQ -> TC`）。
-- **用例逆向追踪（强制）**：每条 `TC` 必须回指至少 1 个 `REQ`（`TC -> REQ`）。
-- **场景维度覆盖（强制）**：每个 `REQ` 至少覆盖以下三类场景：
-  - 正向场景（主流程成功）
-  - 边界场景（阈值/长度/上下限/临界值）
-  - 异常场景（非法输入/失败分支/缺失前置条件）
-- 按上述规则先形成覆盖矩阵，再进入写作：
-  - 需求覆盖矩阵：`REQ -> TC[]`
-  - 用例追踪矩阵：`TC -> REQ[]`
-
-### 4. 生成手工测试用例（正文平铺）
-
-- 依据需求清单归纳可测场景，生成 `test_case.md`。
-- **靶心优先级（强制，避免“先射箭再画靶”）**：
-  - **最高优先级：需求清单（requirements/PRD）**。用例的“口径/阈值/不得改变的规则/显示范围/不做什么”等验收结论，必须优先从需求清单可读出的表述提炼。
-  - **第二优先级：产品能力清单 CAP**。用例的“目标入口/目标组件区域”必须以 CAP 的 `入口锚点（强制）` 与 `UI 识别锚点（强制）` 为准；若用例目标落在其它相似页面/表格组件上，应视为冲突，必须改写用例以落到 CAP 指定区域。
-- **入口锚点补全（强制，引用产品能力清单）**：
-  - 若仓库存在 `.apm/product-capability-inventory/`，则对每条用例的“目标 UI 区域”执行 CAP 对齐：
-    1. 从 `.apm/product-capability-inventory/<系统名>/index.md` 的「能力条目目录表」中，基于需求点标题/关键术语选择最匹配的 `CAP-xxx`（仅选一个最匹配的）。
-    2. 打开对应 `.apm/product-capability-inventory/<系统名>/CAP-xxx.md`，读取字段 `入口锚点（强制）` 与 `UI 识别锚点（强制）`。
-    3. 将 `入口锚点（强制）` 作为“导航来源”，把它转译为用例中的 **操作步骤**（至少覆盖：菜单/抽屉标题/Tab/子页签/目标区域的进入）。
-    4. 将 `UI 识别锚点（强制）` 作为“断言来源”，在 **预期结果**中至少包含 1 条与 `UI 识别锚点（强制）` 对应的可断言检查（例如：表头列名/关键按钮文案/区域标题等），并确保步骤中确实进入了该区域。
-  - 若找不到合适 CAP 或 CAP 缺失上述必填字段，则回退到“保守定位”：
-    - 用例操作步骤必须显式包含：菜单路径/页面标题 或 抽屉标题 或 Tab 文案 + 目标区域至少两列表头/关键按钮文案（从需求清单提炼），并用预期结果体现可断言点。
-- **testcase.md 格式与结构（强制）**：正文平铺用例、`case_id` 以及缩进/编号规则等全部约束，严格遵循同目录 [`reference.md`](./reference.md)。
-- 将整份 Markdown 写入固定路径：`.apm/workitems/<requirementId>/testcase.md`
-- 在文末追加覆盖校验小节（强制）：
-  - `## 覆盖校验`
-  - `### 需求覆盖矩阵（REQ -> TC）`
-  - `### 用例追踪矩阵（TC -> REQ）`
-  - `### 场景维度检查`（逐条 REQ 标记正向/边界/异常是否覆盖）
-
-### 5. 导入测试用例到系统
-
-- **命令**（在仓库根目录执行）：`apm set testcase <requirementId>`
----
-
-## 依赖与约定
-
-- **输出结构**：仅遵循 `reference.md` 的用例文档格式规范
-- **完整示例**：见 [reference.md](reference.md)
----
-
-## 成功标准
-
-- 手工测试用例文档已生成到约定路径（`.apm/workitems/<requirementId>/testcase.md`）
-- 文档格式与结构完全符合同目录 `reference.md`（正文平铺用例、`case_id` 与缩进/编号规则）。
-- 每条用例均为 **操作步骤 + 预期结果** 的精简形态，便于生成 **前端 E2E** 用例脚本
-- 需求覆盖率为 100%（无未覆盖 REQ）
-- 无孤儿用例（每条 TC 均可追溯到至少 1 条 REQ）
-- 每条 REQ 至少覆盖正向、边界、异常三类场景

package/templates/skills/prd-testcase/reference.md

@@ -1,44 +0,0 @@
-# 手工测试用例格式参考（正文平铺）
-
-## 文档层级约定
-
-- **文首**：使用 **`# 测试用例`** 作为标题，后续直接进入正文用例
-- **正文**：仅用 **`### <优先级>:<具体标题>(<case_id>)`** 平铺用例
-- **正文用例字段**：在每个 `### <优先级>:<标题>(<case_id>)` 标题后，**紧跟**两类字段：
-  - `- 测试类型：端到端测试|单元测试|集成测试`（必填）
-  - `- 数据依赖：...`（可选；仅当需要在测试脚本运行前额外准备数据/状态时填写，否则可省略）
-- **正文预期结果**：格式与 **操作步骤** 一致，使用 **编号列表**（`- 预期结果:` 下一行写 `  1.` `  2.` …，**两个空格**缩进），**不要**用制表符 Tab 单独顶格一段
-- **case_id**：全文递增 **`TC-001`、`TC-002`、…**；
-
-## 完整结构示例
-
-````markdown
-# 测试用例
-
-### P0: 列表顶部展示新增入口(TC-001)
-- 测试类型：端到端测试
-- 操作步骤：
-  1. 使用具备回款列表访问权限的账号登录
-  2. 进入「回款列表」页面
-- 预期结果:
-  1. 页面顶部展示「新增回款」按钮
-
-### P0: 点击新增打开表单(TC-002)
-- 测试类型：端到端测试
-- 操作步骤：
-  1. 在回款列表页点击「新增回款」
-- 预期结果:
-  1. 出现含金额与日期的表单
-
-### P1: 默认按约定字段降序(TC-003)
-- 操作步骤：
-  1. 进入月度回款任务明细列表页
-- 预期结果:
-  1. 列表按约定字段降序，首行符合规则
-````
-
-## 从需求到用例的映射
-
-- 从需求条目或需求句提炼可测试点；**不必**为每个需求条目单独建章节
-- **操作步骤** 写成可翻译为 E2E 动作序列的编号列表
-- **预期结果** 写成 **可自动化断言** 的编号列表