ai-project-manage-cli 7.1.39 → 8.0.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ai-project-manage-cli",
-  "version": "7.1.39",
+  "version": "8.0.2",
   "description": "命令行工具：后续用于调用平台后端 API 完成运维与自动化操作",
   "type": "module",
   "private": false,
@@ -38,7 +38,6 @@
     "ws": "~8.18.0",
     "listpage-http": "~0.0.318",
     "commander": "~14.0.3",
-    "yaml": "~2.8.4",
     "minio": "~8.0.7",
     "dockerode": "~5.0.0",
     "ssh2": "~1.16.0",

package/template/AGENTS.md

@@ -1,56 +0,0 @@
-## APM 指南
-
-### 工作流程
-
-按任务轻重选择路径：
-
-#### 轻量回复（被 @ 询问、确认、同步进展）
-
-1. 读取 `.apm/sessions/<会话ID>/session.yaml`
-2. 读取 `.apm/rules/reply.md`
-3. **立即**用 `AppendMessage` 工具回复（可先简短确认，再补充）
-4. 按需阅读 `docs/` 下的文档，有进展继续调用 `AppendMessage`
-
-#### 重任务（开发、写方案、评审）
-
-1. 读取 `.apm/sessions/<会话ID>/session.yaml`，必要时读取 `messages.xml` 了解历史
-2. 根据你的名字从 `session.yaml` 的 `members` 中找到你对应的 **description**（智能体描述，非人设提示词）
-3. 根据角色描述完成用户指定的任务
-4. 任务有阶段性进展或者任务完成后必须回复消息（具体见规则 `reply.md`）
-5. 写工作日志（具体见规则 `write_doc.md`）
-
-**禁止**在未回复前先读完所有 docs。有进展就先调用 `AppendMessage`。
-
-### 目录指引
-
-- 全局文档指引（.apm/\*）
-
-  - 技能: `.apm/skills/<技能名称>/SKILL.md`，一些常用的工作方法，根据你当前的角色按需阅读
-  - 规则: `.apm/rules/*`
-    - reply.md：当需要回复消息时需要读取这个文档，记住回复规则
-    - write_doc.md：当需要写文档时需要读取这个文档，记住写文档的规则
-    - webide_reply.md：WebIDE 任务必守；用户可见只走 AppendMessage，最终自然语言收尾最多 1 句、禁止复述
-    - webide_git_commit.md：WebIDE 开发/修码时读取，按规范分轮 commit，结束前 push
-    - webide_sql_change.md：WebIDE 开发/修码时读取；若有数据表或 SQL 变更，须在 AppendMessage 中醒目提示
-    - webide_testcase.md：WebIDE 生成测试用例时读取，按规范编写并提交用例
-    - webide_merge.md：WebIDE 验收通过后读取；直接调用 MergeWebIdePullRequests 合并代码
-
-- 项目文档（`.apm/project/<项目ID>/`）:
-
-  - 索引: `.apm/project/<项目ID>/manifest.json` — 该项目在平台登记的文档列表
-  - 文档文件: `.apm/project/<项目ID>/{path}` — 与 manifest 中 path 对应；`apm pull` / Session `connect` 会同步；WebIDE 处理 `webide-message` 时按**任务所属项目**拉取到对应目录，结束后推回平台
-  - 部署/本地 dev：Read `.apm/project/<项目ID>/deploy.md`（完整路径以 prompt 为准）
-  - 任务涉及菜单名、路由、业务术语等时，**先 Read manifest 与相关文档**，禁止猜测路径
-
-- 本轮任务需要关注的文档指引（.apm/sessions/<会话 ID>/\*）:
-
-  - 本轮会话状态: `session.yaml`，从这里可以看到每个成员的信息，找到可以协助你一起解决问题的人，可以结合 `RULE.md`一起看
-  - 群文档: `docs/xxxx.md`，当需要相关上下文可以在这里查找，按需阅读
-  - 附件列表: `attachments/*`，当有文档中提及附件时，从这里查找
-  - 协作规则: `RULE.md`，在这里可以看到不同成员的协作规则，从而找其他成员协助你一起解决问题，按需阅读
-  - 协作 TODO: `TODO.md`，跨轮次任务清单（待办与已完成项），按需阅读
-  - 历史消息记录: `messages.xml`，历史消息列表，数据量很大，按需阅读
-  - 初始目标: `TASK.md`，最初的目标，不一定具体，团队成员会有人负责让这个任务变得具体，仅供参考。如果你是相关的角色，则你需要先读取这个目标，然后规划接下来的动作。
-
-- WebIDE 任务附件（`.apm/webide/<taskId>/attachments/`）:
-  - `apm connect` 处理 webide-message 时会自动同步；prompt 中若出现「任务附件」指引，请按路径查看相关文件

package/template/apm.config.json

@@ -1,3 +0,0 @@
-{
-  "name": ""
-}

package/template/rules/reply.md

@@ -1,16 +0,0 @@
-## 群内回复规则
-
-1. 如果回复的内容包含文档地址，不要把前缀也写出来，直接用文档名称即可。例如: 我已经把待处理的内容更新到了 `PRD.md` 中，请查阅。
-2. 回复的内容并非对你工作的总结，要尽可能简洁，不要长篇大论，如果同步的内容确实较多，你可以先写文档，然后指引用户去阅读你写的文档。
-3. 只要你有任何进展都可以调用下面的命令进行回复，你可以一直补充内容。**被 @ 提及时，收到后必须先回复一句简短确认（不超过 50 字），再开始读文档或执行任务。**
-4. 如果有需要指定相关人，必须在消息内容中@指定出来
-
-## 执行回复的方法
-
-调用 `AppendMessage` 工具，`content` 传入你要回复的消息内容。可多次调用补充进展。
-
-示例: `AppendMessage(content="收到，正在分析后端改动范围。")`
-
-## 写文档的方法
-
-如果知道写文档的方法，可以阅读 `./write_doc.md`

package/template/rules/write_doc.md

@@ -1,39 +0,0 @@
-## 写工作日志
-
-命名方式： <你的名字>-工作日志.md
-保存位置: .apm/sessions/<会话 ID>/docs/<文件名>
-日志格式：见如下 markdown 中间的内容
-
-```markdown
-## <简要总结本轮干了什么>
-
-<内容>
-```
-
-## 写其他文件
-
-命名方式: <你的名字>-<主题>.md
-保存位置: .apm/sessions/<会话 ID>/docs/<文件名>
-文档内容格式: 根据你的主题来，不限制，禁止记流水账。
-
-## SQL 变更文档（仅后端）
-
-固定文件名: `SQL.md`
-保存位置: `.apm/sessions/<会话 ID>/docs/SQL.md`
-适用场景: 后端开发涉及 SQL 改动（DDL/DML、表结构、Mapper/XML 中 SQL 等）时必须产出或追加更新，详见 `.apm/skills/apm-dev/SKILL.md` 中「后端 SQL 变更文档」章节。
-格式要求:
-
-- 须标注**目标数据库**（库名/实例名、类型如 MySQL；同一变更涉及多库时分别标注）
-- 待执行的 SQL 语句须放在 ` ```sql ` 代码块中，按执行顺序逐条列出
-- SQL 须写完整、可直接复制执行，**禁止**用 `...` 或「省略」占位代替表名、字段名、条件等任何片段
-
-## 文档同步
-
-保存到 `docs/` 后，`apm connect` 会在每轮 Agent 结束时自动推送到平台，无需额外操作。
-
-## 注意事项
-
-1. 文档内容可以被其他团队成员看到，要有价值，禁止记流水账
-2. 你可以根据你的名字查到自己写的文档，并且禁止更改其他人写的文档
-3. 不要随便创建新文档，可以在已有文档的基础上添加内容（`SQL.md` 为后端 SQL 变更的固定交付文档，除外）
-4. 文档不可删除，不可更新文档名称，在写入时要谨慎

package/template/skills/apm-apply-change/SKILL.md

@@ -1,116 +0,0 @@
-## 文档说明
-
-按工作项中的 **`plans/tasks.md`** 驱动实现：**读规划 → 写代码 → 对账元数据 → 勾选 → 单独 commit**，直至全部完成、**停止执行**或硬阻塞。
-
-**工作项根目录**：`.apm/sessions/<sessionId>/`（下文路径均相对该目录）
-
-| 文件              | 路径                | 用途                                                                                      |
-| ----------------- | ------------------- | ----------------------------------------------------------------------------------------- |
-| tasks（**驱动**） | `plans/tasks.md`    | 唯一进度来源（`- [ ]` / `- [x]`）；缺文件、无待办 → 阻塞，须先 **apm-propose** 或手工补齐 |
-| PRD               | `docs/PRD.md`       | 范围与验收                                                                                |
-| proposal          | `plans/proposal.md` | 变更背景（按需）                                                                          |
-| design            | `plans/design.md`   | **改哪里**、技术决策（按任务引用）                                                        |
-| specs             | `plans/specs/*.md`  | **做什么**（按任务 **需求编号** 引用）                                                    |
-
-**前置**：`plans/tasks.md` 须由 **apm-propose** 生成，格式见 `.apm/skills/apm-propose/tasks.md`（`- [ ]`、元数据子列表等）。
-
-**sessionId**：若本轮未提供——对话中能**唯一**确定 `.apm/sessions/` 下目录名则用之，否则**停止**（不 AskUserQuestion）。确定后于**首次回复**写明 **使用工作项：`<sessionId>`** 即可，不必单独成步。
-
-**单任务循环**：说明当前项 → 最小实现 → 对账（需求编号 / 预期与实际路径 / 完成标准）→ `- [x]` → **一项待办 = 一个 commit**。
-
----
-
-## 停止执行（优先于继续推进）
-
-发现规划与代码**严重不一致**、需用户做产品/架构**决策**、或环境/权限等**硬阻塞**时：**不再**处理下一项、**不**勾选完成，仅输出：
-
-1. **客观事实**：已读路径、与任务/代码的**具体矛盾**（可摘引）。
-2. **当前进度**：`plans/tasks.md` 处理到哪一条；未提交改动范围（若有）。
-3. **需要用户提供什么**：清单，一句一项。
-
-**禁止**：替用户决策、给「建议先改 A/B」、可选方案、排障命令（除非任务/文档已写明须执行的命令）。
-
-**允许**：说明「缺某信息则无法继续」的逻辑关系（不展开成方案）。
-
-**仍可继续**：任务略含糊，但在 PRD / design / specs / tasks 已有文字内可**自洽**完成；若有**假设**须写清。一旦假设触及「以谁为准」→ 转 **停止执行**。
-
----
-
-## 工作流程
-
-### 步骤 1：读取 `plans/tasks.md` 并判断状态
-
-1. **Read** `plans/tasks.md`。
-2. 缺失、为空或无 `- [ ]` → **停止**，提示先具备可执行 tasks。
-3. 若全部为 `- [x]` → 仅陈述「已全部完成」（不建议是否提交/MR）。
-
-### 步骤 2：读取实现上下文
-
-开始**第一个**未勾选任务前，至少 **Read** `docs/PRD.md` 及当前项所需的 `plans/design.md` / `plans/specs/` 片段（见任务 **需求编号**）。不要求每项任务重读全部规划；以**当前任务行** + 缺口再 Read 为准。
-
-#### 单会话读取策略
-
-| 文件                               | 建议                                                                             |
-| ---------------------------------- | -------------------------------------------------------------------------------- |
-| `docs/PRD.md`                      | 本会话首次实现前至少读一次                                                       |
-| `plans/design.md` / `plans/specs/` | 连续多项时，已读过且无疑虑可不重复全文；按任务元数据 **Read（偏移）** 或再读全文 |
-
-### 步骤 3：展示进度并开始循环
-
-展示 **工作项**、**N/M 已完成**（由勾选统计）、**当前将处理**的下一条 `- [ ]`（含编号如 `2.1`）。
-
-对每条未勾选任务（建议自上而下）：
-
-1. 说明正在处理的编号与简述。
-2. **最小**改动实现；与该项描述一致。
-3. **勾选前**对账（与 `plans/tasks.md` 子列表字段一致）：
-   - **需求编号**、**预期改动路径** vs **实际改动文件**（偏差须简述）
-   - **验证用例编号**（若有）、**完成标准** / 验证结果
-4. 依据齐且自洽后，将对应行改为 `- [x]`，**立即**单独 `git commit`（信息含任务编号或简述）。
-
-### 步骤 4：收尾
-
-- **全部完成**：进度 N/M、本会话已完成项摘要；**不**建议 MR/发布等后续流程。
-- **暂停**：按 **停止执行** 三节输出；无「可选后续」。
-
----
-
-## 会话输出（示例）
-
-**进行中**
-
-```
-## 正在实施：<sessionId>
-
-处理任务 3/7：2.1 实现导出接口
-✓ 任务完成 · commit <short-sha> <subject>
-```
-
-**全部完成**
-
-```
-## 实现完成
-**工作项：** <sessionId> · **进度：** 7/7 ✓
-（每项待办均已对应独立 commit。）
-```
-
-**暂停**
-
-```
-## 实现已暂停
-**进度：** 4/7
-### 事实与原因
-…
-### 需要用户提供（或决策）
-- …
-```
-
----
-
-## Guardrails
-
-- 持续执行待办，直至完成、**停止执行**或硬阻塞。
-- 未读清当前任务依赖前**不要**盲改；未对账前**不要**勾选完成。
-- 验证失败或依据不足时保持 `- [ ]` 并写明缺口；元数据缺失时在实现前尽量补全或按 tasks 模板推断并注明。
-- **不要**因发现规划与代码不符而主动改 `plans/` 下规划文件或建议改哪份；**停止**并交还用户。
-- **可分段调用**：部分完成后结束会话，下次同一工作项继续；规划修订由用户在流程外完成后再运行本技能。

package/template/skills/apm-confirm-assumptions/SKILL.md

@@ -1,3 +0,0 @@
-# apm-confirm-assumptions（已废弃）
-
-本技能已更名为 **`apm-update-plan`**。请 **Read** `.apm/skills/apm-update-plan/SKILL.md`。

package/template/skills/apm-dev/SKILL.md

@@ -1,80 +0,0 @@
-# apm-dev：按计划开发
-
-## 工作流程
-
-### 步骤 1: 获取实现计划与协作内容
-
-1. 用 **Read** 工具阅读本端计划：前端读 `.apm/sessions/<会话ID>/docs/FRONTEND-PLAN.md`，后端读 `docs/BACKEND-PLAN.md`；计划不存在则退出流程并回复说明（兼容旧流程：若存在 `PRD.md` + `FRONTEND.md` / `BACKEND.md` + `API.md`，按旧文档执行）。
-2. 前端涉及接口对接时，以 `docs/API.md` 为唯一契约来源，**不等后端部署完成**；`API.md` 不存在或字段没写清时 `@后端` 补充，禁止自行猜测或在计划中重复编写接口定义。
-3. **开发门禁（开发前必须检查）**：
-   - 执行 **`apm dev-gate <会话ID> --source FRONTEND_PLAN`**（后端用 `BACKEND_PLAN`）；
-   - `pendingAssumptions > 0` → `@项目经理` 请其在 Web「待您确认」Panel 提交，**停止开发**；
-   - `!assumptionsCleared` 且有假设 → **停止开发**；
-   - `!understandingConfirmed` → `@项目经理` 请其在聊天回复「理解正确，可进入开发」，**停止开发**；
-   - `readyForDev === true` → 可继续。
-     **禁止**从 `messages.xml` 解析 PM 假设回复。
-
-### 步骤 2: 明确开发模式
-
-**Quick 开发**（满足越多越适用）:
-
-- 影响范围局部：少量文件或单一层次（例如仅前端组件、或仅一个后端模块小改）。
-- 无新表结构/大规模迁移/权限模型变更。
-- 计划实现步骤清晰且数量少（经验上 **≤3** 条独立步骤）。
-- 不需要跨多服务的架构裁定即可开工。
-
-**Spec 开发**：（命中任一条即可）：
-
-- 前后端联动、多包改造或新公共抽象。
-- 新数据模型、迁移、或安全/审计/权限相关。
-- 计划范围大、条款多，或存在明显「待确认/多方案」需先规划。
-- 评估认为不先产出 **proposal / design / specs / tasks** 不宜直接编码。
-
-### 步骤 3: 如果前一步判定为 **Quick 开发** 才（在子 Agent 中）执行本步骤，否则执行下一步：
-
-- 父 Agent 已通过 **Read** 掌握本端计划；若启动新子 Agent，在委派提示中写明会话 ID、消息 ID、工作项路径、以及「实现须严格对照计划，**只允许改动计划『改动文件白名单』中列出的文件**；完成后若有代码改动须单独 `git commit`」。
-- 使用 **Task** 工具，`subagent_type: generalPurpose`，**readonly: false**，委派子 Agent：
-  - 按需 **Read** 本端计划文档。
-  - 按计划直接改代码；遵守本仓库构建与依赖约定（AGENTS.md）。
-  - **白名单约束**：只改计划白名单内的文件。开发中确需新增文件或改动白名单外文件，先更新计划文档的白名单（写明原因），再动手；**禁止悄悄越界**。
-  - **Git**：实现与自洽验收通过后，若有代码改动，**立即 `git add` + `git commit` 一次**（Quick 通常为单次交付，**一次实现 = 一个 commit**；勿拆成无意义碎 commit）。提交信息建议包含 `sessionId`（可从 `session.yaml` 获取）与需求摘要。
-  - **后端 SQL 文档**（仅后端）：改动涉及 SQL 时，须 **Write** `docs/SQL.md`（见下文「后端 SQL 变更文档」）。
-  - 完成后在返回中说明：改了哪些路径、与白名单的对账结果（逐文件列出）、是否产出/更新 `SQL.md`、是否通过本地可执行的检查（若子 Agent 跑了构建/测试则写明结果）；若有 commit，写明 **short-sha** 与 **subject**，无代码改动则注明跳过 commit。
-
-### 步骤 4: 如果前一步判定为 **Spec 开发** 才（在子 Agent 中）执行本步骤，否则执行下一步：
-
-1. 父 Agent **Read** `.apm/skills/apm-propose/SKILL.md` 和 `.apm/skills/apm-apply-change/SKILL.md`
-2. **子 Agent A（规划）**：Task `generalPurpose`，提示其自行 **Read** `.apm/skills/apm-propose/SKILL.md` 并完整遵循：在 `plans/` 下生成 **proposal、design、specs、tasks** 等工件。
-3. **子 Agent B（实现）**：待 A 成功落盘后，再 Task `generalPurpose`，提示其自行 **Read** `.apm/skills/apm-apply-change/SKILL.md` 并完整遵循：按 **`plans/tasks.md`** 驱动实现与勾选；遵守该技能中的停止条件与 commit 约定；同样遵守计划「改动文件白名单」；**后端**改动涉及 SQL 时须产出 `docs/SQL.md`（见下文「后端 SQL 变更文档」）。
-4. 若 **apm-propose** 未产出可用 **`plans/tasks.md`**，不得强行进入 **apm-apply-change**；表格中标记阻塞原因。
-
-### 后端 SQL 变更文档（仅后端工程师）
-
-若本次改动涉及 SQL（DDL/DML、表结构、索引、数据修复、Mapper/XML 中新增或修改 SQL 语句等），开发阶段必须 **Write** `.apm/sessions/<会话ID>/docs/SQL.md`，内容包括：
-
-- **目标数据库**（库名/实例名、类型如 MySQL；同一变更涉及多库时分别标注）
-- 变更摘要（改了什么表/数据、为什么）
-- 完整 SQL 语句（按执行顺序排列；**每条须放在 ` ```sql ` 代码块中**，便于复制执行；**禁止**用 `...` 或「省略」占位代替任何片段）
-- 执行环境说明（测试/生产是否一致、是否需人工执行）
-- 回滚方案（如适用；回滚 SQL 同样用 ` ```sql ` 代码块，须完整可执行，禁止省略）
-
-`BACKEND-PLAN.md` 中不写大段 SQL，只可在实现步骤中注明「须产出 SQL.md」。若会话 `docs/` 下已有 `SQL.md`，在其上追加本次变更，勿另建其他 SQL 文档。
-
-### 步骤 5: 提交并 push 代码，保证工作区干净
-
-- Quick / Spec 子 Agent 完成且本地已有 commit 时，父 Agent **立即 `git push`**（当前分支首次 push 用 `git push -u origin HEAD`）。
-- 无本地 commit、无远程或未配置 upstream 时说明原因，勿强行 push。
-
-### 步骤 6: 构建验证（完成定义）
-
-开发完成的定义是以下各项**全部满足**，缺一不可：
-
-1. **构建通过**：执行本仓库的构建/检查命令（见 AGENTS.md），失败必须修复后重试。
-2. **SQL 文档**（**仅后端**）：涉及 SQL 变更时，须在回复中引用 `docs/SQL.md`，并写明待执行的 SQL 文件名或执行顺序。
-3. **白名单对账**：在回复中逐文件列出本次改动与计划白名单的对应关系。
-
-**禁止自行部署。** 不要执行 `apm deploy`、`apm deploy-frontend`、`apm deploy-backend`、`apm deploy-sftp` 等任何部署命令；发布测试/正式环境由人工或平台触发。
-
-**注意：不做联调。** 前后端各自按 `API.md` 交付，接口对不上属于契约或实现问题，由 diff 评审与人工验收暴露后打回修复；禁止自行发起「联调」「接口实测」类的开放式动作。
-
-完成后用 `AppendMessage` 回复：改动概述 + 白名单对账 + 构建结果，并 `@` 评审角色进行 diff 评审。

package/template/skills/apm-diff-review/SKILL.md

@@ -1,63 +0,0 @@
-# apm-diff-review：开发完成后的代码改动评审
-
-## 适用范围
-
-开发完成之后，由评审角色（可以是另一端工程师或专职评审智能体）检查 git 改动是否「只做了该做的事」。这是防止 AI 乱改代码的机器门禁：**通过才交人验收，不通过打回开发**。
-
-评审对象是 **diff**，不是整个代码库；禁止借评审之机重构或顺手改代码。**本技能全程只读，不允许写任何代码。**
-
----
-
-## 工作流程
-
-### 步骤 1：定位本次任务的改动
-
-1. **Read** `.apm/sessions/<会话ID>/docs/` 下的 `BACKEND-PLAN.md` / `FRONTEND-PLAN.md`，拿到「改动文件白名单」。
-2. 在工作目录执行 `git log --oneline -20`，找到本任务相关的 commit（提交信息中含会话 ID 或需求关键词）。
-3. `git diff <基线>..HEAD --stat` 与 `git diff <基线>..HEAD` 查看完整改动。
-
-### 步骤 2：四项检查
-
-| 检查项         | 判定                                                                                                                                                                            |
-| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **白名单对账** | diff 中出现白名单之外的文件，且计划未更新说明 → **不通过**                                                                                                                      |
-| **需求相关性** | 存在与本需求无关的改动（顺手重构、改格式、动了无关逻辑）→ **不通过**                                                                                                            |
-| **计划落实**   | 计划「实现步骤」中的关键点在 diff 中找不到对应实现 → **不通过**                                                                                                                 |
-| **SQL 文档**   | **仅后端**：diff 涉及 SQL 改动（DDL/DML、表结构、Mapper/XML 中 SQL 等），但 `docs/SQL.md` 缺失、未标注目标数据库、与改动不一致、或 SQL 代码块含 `...`/「省略」占位 → **不通过** |
-
-注意事项：
-
-- 锚定计划和需求原文做判断，不要凭个人偏好挑剔代码风格。
-- 改动是否「无关」拿不准时，倾向放过，但在回复中提示验收人留意。
-
-### 步骤 3：评审通过后创建 PR
-
-评审**通过**后，先在工作目录执行（创建/更新本会话特性分支对应的 PR）：
-
-```bash
-apm create-pr --session <会话ID> --title "<需求摘要>" --content "<计划摘要 + 白名单对账 + 评审结论>"
-```
-
-- 标题会自动加上 `[AI]` 标识，表明该 PR 由 AI 创建；同一分支已有开启的 PR 时会改为更新，不会重复创建。
-- 命令输出的 PR 链接用于下一步回复中引用。
-- 若创建失败（如客户机未配置 GitHub/Gitee API Key），**不要阻断交付**：记录失败原因，在回复中 `@项目经理` 说明需人工处理。
-
-### 步骤 4：输出结论
-
-**通过**：用 `AppendMessage` 回复评审结论，并 `@项目经理` 交人验收，回复中必须包含：
-
-1. 「diff 评审通过」+ 一句话改动概述；
-2. **PR 链接**（上一步 `apm create-pr` 输出；创建失败则注明原因）；
-3. 提示按 `CHECKLIST.md` 逐条验收（部署与回归验收由人工或平台完成）。
-
-**不通过**：用 `AppendMessage` 输出问题清单（每条注明文件 + 问题 + 依据哪条计划/需求），`@` 对应工程师打回修改。**禁止自己动手改。**
-
----
-
-## 迭代上限
-
-同一任务的 diff 评审**最多打回 3 次**。第 3 次仍不通过时，不再打回，改为 `@项目经理` 说明僵持原因，由人决策（人工修复 / 调整计划 / 放弃本次改动）。
-
-## 何时使用
-
-协作流程阶段 4（diff 评审）；或用户要求评审代码改动。

package/template/skills/apm-propose/SKILL.md

@@ -1,52 +0,0 @@
-## 文档说明
-
-从 **PRD** 为事实来源，在 `plans/` 下产出四份规划工件（`docs/PRD.md` 除外），供 **apm-apply-change** 按 `plans/tasks.md` 勾选推进实现。
-
-**工作项根目录**：`.apm/sessions/<sessionId>/`（下文路径均相对该目录）
-
-| 工件        | 落盘路径                | 作用                                                                               | 依赖                                            | 撰写规范                 |
-| ----------- | ----------------------- | ---------------------------------------------------------------------------------- | ----------------------------------------------- | ------------------------ |
-| PRD（输入） | `docs/PRD.md`           | 需求与验收的事实来源                                                               | —                                               | —                        |
-| proposal    | `plans/proposal.md`     | **Why / What**；**Capabilities** 与 `plans/specs/` 的契约；不写实现细节            | PRD                                             | **Read** `./proposal.md` |
-| design      | `plans/design.md`       | **How**：架构与决策；不写逐行代码，不替代 `plans/tasks.md`                         | PRD、proposal                                   | **Read** `./design.md`   |
-| specs       | `plans/specs/<name>.md` | 系统**应做什么**；与 **Capabilities** 逐条对齐，不得虚构 PRD/proposal 未出现的能力 | PRD、proposal（**不**依赖 design）              | **Read** `./specs.md`    |
-| tasks       | `plans/tasks.md`        | 将 specs + design 拆为 `- [ ]` 可勾选任务                                          | PRD、proposal、design、specs（至少 1 个 `.md`） | **Read** `./tasks.md`    |
-
-**撰写顺序**：`proposal` → `design` 与 `specs`（可并行）→ `tasks`（须等 design 与 specs 均已落盘）。
-
----
-
-## 工作流程
-
-### 步骤 1：读取 PRD 与协作上下文
-
-1. **Read** `docs/PRD.md`；不存在则失败并退出。
-2. 按需 **Read** `docs/` 下其他文档（如联调说明）。
-
-### 步骤 2：按顺序落盘四工件
-
-遵循上表**撰写顺序**与**依赖**；每完成一工件即写入对应**落盘路径**。
-
-### 步骤 3：跟踪与收尾
-
-1. 用 **TodoWrite** 跟踪四工件（`ready` / `blocked` / `done`）；依赖未满足时**不得**写下一工件。
-2. 撰写前 **Read** 依赖项及该工件**撰写规范**列中的 `./*.md`；写 `tasks` 前必要时 **SemanticSearch** / **Read** 仓库代码，使**预期改动路径**可落地。
-3. 全部完成后汇总：工作项路径、已创建文件、PRD 与各工件对应关系（一两句）；回复含各工件一句话用途。
-
-#### 单会话读取策略
-
-同一会话连续跑完时可省略重复 Read，但**不得**省略依赖关系；断点续写或新会话须按上表**依赖**列重新 Read 磁盘文件。
-
-| 文件                               | 建议                                                  |
-| ---------------------------------- | ----------------------------------------------------- |
-| `docs/PRD.md`                      | 进入流程时至少读一次全文                              |
-| `plans/proposal.md`                | 写 design/specs 时，若本会话刚写入全文可不重复 Read   |
-| `plans/design.md` / `plans/specs/` | 写 `plans/tasks.md` 时若无可靠记忆须 Read；以落盘为准 |
-
----
-
-## Guardrails
-
-- 后写须与 PRD 及已落盘前序文件一致。
-- 四工件缺一不可（`plans/specs/` 至少一个 `.md`）；落盘非空后再进下一工件。
-- **默认不覆盖**已有规划文件；用户明确要求「整目录覆盖重生成」时除外。

package/template/skills/apm-propose/design.md

@@ -1,37 +0,0 @@
-## 撰写说明
-
-跨模块、新依赖、安全/性能/迁移复杂或方案待拍板时写完整版；否则可精简，但保留 **Context** 与 **Decisions**。
-
-## 模板
-
-```markdown
-## Context
-
-<!-- 背景、约束、与 PRD / proposal 的衔接 -->
-
-## Goals / Non-Goals
-
-**Goals:**
-
-<!-- 本设计要达成的目标 -->
-
-**Non-Goals:**
-
-<!-- 明确不在本设计范围内的事项 -->
-
-## Decisions
-
-<!-- 每项：备选 + 取舍理由 -->
-
-## Risks / Trade-offs
-
-<!-- [风险] → 缓解 -->
-
-## Migration Plan
-
-<!-- 无则写 无 / 不适用 -->
-
-## Open Questions
-
-<!-- 无则写 无 -->
-```

package/template/skills/apm-propose/proposal.md

@@ -1,31 +0,0 @@
-## 模板
-
-```markdown
-## Why
-
-<!-- 1～2 句：解决什么、为何是现在 -->
-
-## What Changes
-
-<!-- 变更要点；破坏性变更标注 BREAKING -->
-
-## Capabilities
-
-<!-- proposal 与 specs 的契约：每一项须在后续 `plans/specs/` 可追溯 -->
-
-### New Capabilities
-
-<!-- 每条对应 `plans/specs/<kebab-name>.md`（如 `user-auth`）。 -->
-
-- `<name>`: <brief description>
-
-### Modified Capabilities
-
-<!-- 规格层行为变更；无则写「无」 -->
-
-- `<existing-name>`: <what requirement behavior changes>
-
-## Impact
-
-<!-- 受影响代码、API、依赖、系统 -->
-```

package/template/skills/apm-propose/specs.md

@@ -1,39 +0,0 @@
-## 文件组织
-
-一能力一文件 `plans/specs/<短横线名称>.md`（或 `plans/specs/<名称>/规格.md`，同一工作项内择一，勿混用）。
-
-## 结构约定
-
-- 分块（`##`）：**新增需求** / **变更需求** / **移除需求** / **重命名需求**（按需组合；纯新增只用「新增需求」）。
-- 需求：`**### 需求：<名称>**`；行为用 **须、必须**。
-- 场景：`**#### 场景：<名称>**`（固定四个 `#`）；正文 `- **当** …` / `- **则** …`。
-- **每条需求至少一个场景**；变更需求须写**完整替换段落**（从需求到全部场景），禁止只贴片段。
-
-## 模板
-
-```markdown
-## 新增需求
-
-### 需求：<名称>
-
-系统须 …
-
-#### 场景：<名称>
-
-- **当** …
-- **则** …
-
-## 变更需求
-
-<!-- 完整替换后的需求 + 全部场景 -->
-
-## 移除需求
-
-### 需求：<名称>
-
-**原因**：… **迁移说明**：…
-
-## 重命名需求
-
-- **原名称：** … **新名称：** …
-```

package/template/skills/apm-propose/tasks.md

@@ -1,16 +0,0 @@
-## 格式约定
-
-- 行首 **`- [ ]`**；分组 **`## 1. 名称`**；编号 **`- [ ] 1.1 说明`**（组号.序号）。
-- 每项下方缩进子列表：**需求编号**（对应 specs 中需求/场景）、**预期改动路径**、**验证用例编号**（可选）、**完成标准**。
-- **做什么**以 specs 为准，**改哪里**以 design 为准；按技术依赖排序。
-
-## 示例
-
-```markdown
-## 1. 数据层
-
-- [ ] 1.1 新增合同状态字段
-  - **需求编号**：需求：合同状态同步（见 plans/specs/contract.md）
-  - **预期改动路径**：`servers/be/prisma/schema.prisma`
-  - **完成标准**：迁移可执行；已有合同默认状态正确
-```