ai-project-manage-cli 2.0.26 → 3.0.1

package/templates/skills/apm-propose/specs-instruction.md

@@ -1,114 +0,0 @@
-# specs 工件：写作说明（供 apm-propose 读取）
-
-在工作项目录下生成 **`specs/`** 内的规格文件，定义系统 **应做什么**，与 **`design.md`**（如何实现）区分。内容须可验证：**每条「需求」下须有至少一个「场景」**。
-
-**工件 DAG、单会话减少重复 Read**：见 **`.apm/skills/apm-propose/SKILL.md`**（「工件依赖」「单会话读取策略」）。
-
----
-
-## 依赖（写入前须全文阅读）
-
-| 文件 | 说明 |
-| --- | --- |
-| **`.apm/workitems/<requirementId>/prd.md`** | 业务事实、约束、验收；**唯一权威需求来源**。 |
-| **`.apm/workitems/<requirementId>/proposal.md`** | **能力范围**（新增能力 / 变更能力）；每项能力须在 `specs/` 中有对应文档；文件名用**短横线小写**（如 `user-auth`、`data-export`）。 |
-
-若无 **`proposal.md`**，不得编写 specs。若无 **`prd.md`**，按 apm-propose **SKILL** 先执行 **`apm get requirement <requirementId>`** 再读。
-
-**不依赖** **`design.md`**：specs 可与设计文档并行撰写，但须与 **proposal 中的能力约定**、**prd** 一致。
-
----
-
-## 输出位置
-
-- 根目录：**`.apm/workitems/<requirementId>/specs/`**
-- 文件组织（须与 **`propose-instruction.md`** 及 proposal 中的能力列表一致）：
-  - **常用**：一能力一文件 **`specs/<短横线名称>.md`**
-  - **也可**：**`specs/<短横线名称>/规格.md`**（同一工作项内择一风格，勿混用）
-
----
-
-## 写作说明
-
-### 与 proposal 对齐
-
-按 **`proposal.md`「能力范围」**逐条落地：
-
-- **新增能力**：每个名称对应一个上述路径下的文件，以 **「新增需求」** 类内容为主。
-- **变更能力**：在对应文件中用 **变更需求 / 移除需求 / 重命名需求** 等章节描述相对旧行为的变化。若仓库有既有能力说明，可先阅读 **`.apm/product-capability-inventory/`** 或相关能力文档以核对名称，**不得**虚构 prd、proposal 未出现的能力。
-
-### 变更分块（均使用二级标题 `##`）
-
-可按需组合多个分块：
-
-| 二级标题 | 用途 |
-| --- | --- |
-| **新增需求** | 全新能力或新需求条款。 |
-| **变更需求** | 行为有变：须写入**修改后的完整段落**（从「### 需求：」到其下全部场景），禁止只贴片段，以免后续对账丢失上下文。 |
-| **移除需求** | 下线或废弃：每条须写 **原因**、必要时写 **迁移说明**。 |
-| **重命名需求** | 仅名称变化：写清 **原名称**、**新名称**。 |
-
-若整份文件均为新能力，可只保留 **新增需求** 分块。纯新增内容放在 **新增需求**，不要用 **变更需求** 代替。
-
-### 单条需求结构
-
-- 需求标题：`**### 需求：<名称>**`，其下为正文。
-- **措辞**：对行为约束用 **须、必须** 等明确用语，避免「尽量、可以」之类除非 prd 明确要求弱化。
-- 场景标题：`**#### 场景：<名称>**`（场景标题固定用 **四个井号**，勿用三个，以免与需求层级混淆）。
-- 场景正文建议采用：
-  - `- **当** …`
-  - `- **则** …`
-- **每条需求至少包含一个场景。**
-
-### 变更类特别注意
-
-若产品清单或仓库中已有该能力的旧规格，应先找到旧全文，再整体放入 **变更需求** 下改写，**保持标题与结构便于对照**。
-
-若只是补充新条款、不改变已有行为，在 **新增需求** 中增加条目，勿用 **变更需求**。
-
-### 可验证性
-
-每个 **场景** 都能对应测试或验收步骤；后续 **`tasks.md`** 中的 **需求编号** 可与 **需求 / 场景** 标题互相对照。
-
----
-
-## 单文件模板示例
-
-```markdown
-## 新增需求
-
-### 需求：<需求名称>
-系统须 <规范性行为，一条或多句表述清楚>。
-
-#### 场景：<场景名称>
-- **当** <前置或触发条件>
-- **则** <预期结果>
-
-## 变更需求
-
-### 需求：<与既有需求同一标题>
-<!-- 此处放完整替换后的需求正文及全部场景 -->
-
-#### 场景：<场景名称>
-- **当** …
-- **则** …
-
-## 移除需求
-
-### 需求：<需求名称>
-**原因**：……  
-**迁移说明**：……
-
-## 重命名需求
-
-- **原名称：** …
-- **新名称：** …
-```
-
-按实际只保留需要的 `##` 分块；不需要的整块省略。
-
----
-
-## 与后续工件的关系
-
-本目录与 **`design.md`** 均完成后，方可编写 **`.apm/workitems/<requirementId>/tasks.md`**。

package/templates/skills/apm-propose/tasks-instruction.md

@@ -1,90 +0,0 @@
-# tasks 工件：写作说明（供 apm-propose 读取）
-
-生成 **`tasks.md`**：把实现工作拆成**可勾选、可追踪**的条款。后续 **apm-apply-change** 依赖 **`- [ ]` / `- [x]`** 勾选推进，格式须严格遵守。
-
-**工件 DAG、单会话减少重复 Read**：见 **`.apm/skills/apm-propose/SKILL.md`**（「工件依赖」「单会话读取策略」）。
-
----
-
-## 依赖（写入前须 Read 完）
-
-| 文件 | 说明 |
-| --- | --- |
-| **`.apm/workitems/<requirementId>/prd.md`** | 范围与验收 |
-| **`.apm/workitems/<requirementId>/proposal.md`** | 动机与能力边界 |
-| **`.apm/workitems/<requirementId>/design.md`** | 如何做、模块与路径 |
-| **`.apm/workitems/<requirementId>/specs/`** | 须做什么、需求与场景 |
-
-若 **`design.md` 或 `specs/`**（至少一个规格文件）尚未就绪，**不得**编写 **tasks.md**。
-
----
-
-## 输出路径
-
-**`.apm/workitems/<requirementId>/tasks.md`**
-
----
-
-## 写作说明
-
-### 格式（须严格遵守）
-
-- **每一条待办必须是复选框**：行首 **`- [ ]`**（半角方括号、半角空格）。**不用** `- [ ]` 的行在实现阶段**无法被可靠追踪**。
-- **按主题分组**：使用带序号的二级标题，例如 **`## 1. 环境准备`**、**`## 2. 核心实现`**。
-- **任务编号**：组内序号 **`组号.序号`**，与描述同一行，例如 **`- [ ] 1.1 初始化数据模型`**、**`- [ ] 2.1 实现导出接口`**。
-- **粒度**：每项宜在一次会话内能做完；过粗则拆，过细可按模块合并。
-- **顺序**：按**技术依赖**排列（例如契约/数据先于接口/UI）。
-
-### 每条任务须带的元数据（缩进子列表）
-
-紧接在 **`- [ ]` 行下方**，用无序列表写出（便于人工与 Agent 对照）：
-
-| 字段 | 说明 |
-| --- | --- |
-| **需求编号** | 对应 **specs** 中 **### 需求：** 或 **#### 场景：** 的可识别标题/编号 |
-| **预期改动路径** | 计划修改或新增的文件/目录（可多条） |
-| **验证用例编号** | 可选；与测试或验收条目对应 |
-| **完成标准** | 可观察的完成判据（与 specs 场景可对照） |
-
-示例：
-
-```markdown
-## 1. 数据层
-
-- [ ] 1.1 新增合同状态字段
-  - **需求编号**：需求：合同状态同步（见 specs/contract.md）
-  - **预期改动路径**：`servers/be/prisma/schema.prisma` …
-  - **完成标准**：迁移可执行；已有合同默认状态正确
-```
-
-### 内容来源
-
-- **做什么、验收什么**：以 **specs** 为主，**prd** 补业务约束。
-- **改哪里、怎么迁**：以 **design** 为主，**预期改动路径**须与 design 中的模块划分**一致**；必要时 **SemanticSearch** 仓库以填路径。
-
-### 可验证性
-
-每条任务应有明确「做完」的样子；**完成标准** 应能让评审者或自己判断无需再猜。
-
----
-
-## 模板示例
-
-```markdown
-## 1. <!-- 分组名称，如：准备 -->
-
-- [ ] 1.1 <!-- 简短任务说明 -->
-  - **需求编号**：…
-  - **预期改动路径**：…
-  - **验证用例编号**：（可选）…
-  - **完成标准**：…
-
-## 2. <!-- 分组名称，如：核心实现 -->
-
-- [ ] 2.1 …
-  - **需求编号**：…
-  - **预期改动路径**：…
-  - **完成标准**：…
-```
-
----

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)