ai-project-manage-cli 7.0.2 → 7.0.3

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

@@ -1,93 +0,0 @@
-# apm-dev：按计划开发并发布测试环境
-
-## 工作流程
-
-### 步骤 1: 获取实现计划与协作内容
-
-1. 用 **Read** 工具阅读本端计划：前端读 `.apm/project/docs/FRONTEND-PLAN.md`，后端读 `.apm/project/docs/BACKEND-PLAN.md`；计划不存在则退出流程并回复说明（兼容旧流程：若存在 `PRD.md` + `FRONTEND.md` / `BACKEND.md` + `API.md`，按旧文档执行）。
-2. 前端涉及接口对接时，以 `.apm/project/docs/API.md` 为唯一契约来源，**不等后端部署完成**；`API.md` 不存在或字段没写清时 `@后端` 补充，禁止自行猜测或在计划中重复编写接口定义。
-3. **假设门禁（开发前必须检查）**：查看计划「依据与假设」章节——
-   - 「假设」仍有未确认项：`@项目经理` 列出待确认假设，**停止本次开发**；
-   - 项目经理已回复：先按 `.apm/skills/apm-write-plan/SKILL.md` 步骤 5 把确认结果**回填进计划文档并同步**（确认的假设移入「依据」，否定的修订实现步骤与白名单），然后再开发。
-     严禁带着未回填的澄清直接开发——项目经理在聊天里给过的口径若没落进计划，开发与 diff 评审都不会认。
-
-### 步骤 2: 明确开发模式
-
-**Quick 开发**（满足越多越适用）:
-
-- 影响范围局部：少量文件或单一层次（例如仅前端组件、或仅一个后端模块小改）。
-- 无新表结构/大规模迁移/权限模型变更。
-- 计划实现步骤清晰且数量少（经验上 **≤3** 条独立步骤）。
-- 不需要跨多服务的架构裁定即可开工。
-
-**Spec 开发**：（命中任一条即可）：
-
-- 前后端联动、多包改造或新公共抽象。
-- 新数据模型、迁移、或安全/审计/权限相关。
-- 计划范围大、条款多，或存在明显「待确认/多方案」需先规划。
-- 评估认为不先产出 **proposal / design / specs / tasks** 不宜直接编码。
-
-### 步骤 3: 如果前一步判定为 **Quick 开发** 才（在子 Agent 中）执行本步骤，否则执行下一步：
-
-- 父 Agent 已通过 **Read** 掌握本端计划；若启动新子 Agent，在委派提示中写明工作项路径（`.apm/project/`）、以及「实现须严格对照计划，**只允许改动计划『改动文件白名单』中列出的文件**；完成后若有代码改动须单独 `git commit`」。
-- 使用 **Task** 工具，`subagent_type: generalPurpose`，**readonly: false**，委派子 Agent：
-  - 按需 **Read** 本端计划文档。
-  - 按计划直接改代码；遵守本仓库构建与依赖约定（AGENTS.md）。
-  - **白名单约束**：只改计划白名单内的文件。开发中确需新增文件或改动白名单外文件，先更新计划文档的白名单（写明原因），再动手；**禁止悄悄越界**。
-  - **Git**：实现与自洽验收通过后，若有代码改动，**立即 `git add` + `git commit` 一次**（Quick 通常为单次交付，**一次实现 = 一个 commit**；勿拆成无意义碎 commit）。提交信息建议包含需求摘要。
-  - **后端 SQL 文档**（仅后端）：改动涉及 SQL 时，须 **Write** `.apm/project/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` 并完整遵循：在 `.apm/project/plans/` 下生成 **proposal、design、specs、tasks** 等工件。
-3. **子 Agent B（实现）**：待 A 成功落盘后，再 Task `generalPurpose`，提示其自行 **Read** `.apm/skills/apm-apply-change/SKILL.md` 并完整遵循：按 **`.apm/project/plans/tasks.md`** 驱动实现与勾选；遵守该技能中的停止条件与 commit 约定；同样遵守计划「改动文件白名单」；**后端**改动涉及 SQL 时须产出 `.apm/project/docs/SQL.md`（见下文「后端 SQL 变更文档」）。
-4. 若 **apm-propose** 未产出可用 **`plans/tasks.md`**，不得强行进入 **apm-apply-change**；表格中标记阻塞原因。
-
-### 后端 SQL 变更文档（仅后端工程师）
-
-若本次改动涉及 SQL（DDL/DML、表结构、索引、数据修复、Mapper/XML 中新增或修改 SQL 语句等），开发阶段必须 **Write** `.apm/project/docs/SQL.md`，内容包括：
-
-- **目标数据库**（库名/实例名、类型如 MySQL；同一变更涉及多库时分别标注）
-- 变更摘要（改了什么表/数据、为什么）
-- 完整 SQL 语句（按执行顺序排列；**每条须放在 ` ```sql ` 代码块中**，便于复制执行；**禁止**用 `...` 或「省略」占位代替任何片段）
-- 执行环境说明（测试/生产是否一致、是否需人工执行）
-- 回滚方案（如适用；回滚 SQL 同样用 ` ```sql ` 代码块，须完整可执行，禁止省略）
-
-示例：
-
-````markdown
-## 目标数据库
-
-`oxc_platform`（MySQL 8.x）
-
-## 变更摘要
-
-为 inspection_class 表新增 is_project_add 字段。
-
-## 执行 SQL
-
-```sql
-ALTER TABLE inspection_class ADD COLUMN is_project_add VARCHAR(1) DEFAULT '0';
-```
-````
-
-`BACKEND-PLAN.md` 中不写大段 SQL，只可在实现步骤中注明「须产出 SQL.md」。若 `.apm/project/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. **发布测试环境**：**Read** `.apm/skills/apm-deploy/SKILL.md` 并按其流程部署；**后端**涉及 SQL 变更时，须在回复中引用 `.apm/project/docs/SQL.md`，并写明待执行的 SQL 文件名或执行顺序。
-3. **白名单对账**：在回复中逐文件列出本次改动与计划白名单的对应关系。
-
-**注意：不做联调。** 前后端各自按 `API.md` 交付，接口对不上属于契约或实现问题，由 diff 评审与人工验收暴露后打回修复；禁止自行发起「联调」「接口实测」类的开放式动作。
-
-完成后用 `append_message` 回复：改动概述 + 白名单对账 + 构建结果 + 测试环境地址，并 `@` 评审角色进行 diff 评审。

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

@@ -1,52 +0,0 @@
-## 文档说明
-
-从 **PRD** 为事实来源，在 `plans/` 下产出四份规划工件（`docs/PRD.md` 除外），供 **apm-apply-change** 按 `plans/tasks.md` 勾选推进实现。
-
-**工作项根目录**：`.apm/project/`（下文路径均相对该目录）
-
-| 工件        | 落盘路径                | 作用                                                                               | 依赖                                            | 撰写规范                 |
-| ----------- | ----------------------- | ---------------------------------------------------------------------------------- | ----------------------------------------------- | ------------------------ |
-| 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`
-  - **完成标准**：迁移可执行；已有合同默认状态正确
-```

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

@@ -1,70 +0,0 @@
-## 工作流程
-
-### 步骤 1：确认身份
-
-1. 根据 AGENTS.md 与当前对话上下文，确认自己的**角色**（agent）与**名字**（member）。
-2. 若无法确定，停止流程并在回复中说明。
-
-### 步骤 2：收集本人贡献材料
-
-1. **Read** `.apm/project/docs/` 下本人撰写的工作日志与相关文档（文件名含本人名字或本轮产出）。
-2. 结合当前对话中本人的回复与决策，提取可复用的口径与做法。
-3. 若有效材料少于 1 条，停止流程并在回复中说明「材料不足，无法复盘」及缺什么。
-
-### 步骤 3：补充任务背景（按需）
-
-1. **Read** `.apm/project/docs/PRD.md`（若存在），锚定「这次在解决什么业务问题」。
-2. 按需 **Read** `.apm/project/manifest.json` 及其他相关项目文档，**不要**把全文复制进复盘。
-
-### 步骤 4：生成经验 Skill 草稿
-
-1. 用 **Read** 工具阅读 `.apm/skills/apm-recap/recap-template.md`
-2. 严格按模板结构撰写，**Write** 到 `.apm/project/docs/<name>-复盘技能.md`
-3. 文件名中的 `<name>` 与当前 member 名字完全一致（含中文）
-
-**内容原则**：
-
-- 只基于步骤 2 ～ 3 的实际材料归纳，**禁止编造**未出现过的决策或产出
-- 写**可复用的经验**（口径、做法、踩坑），**禁止**按轮次记流水账（不要写「第 N 轮我…」）
-- **产品语言优先**；必要时后端可写表名 / 主表字段名，但避免大段代码、文件路径、组件名
-- 只复盘**本人**贡献；他人工作仅可在「协作依赖」中简要提及，不得代写
-
-### 步骤 5：拟定平台 Skill 元数据
-
-在草稿文件**最顶部**写入元数据块（格式见 recap-template.md），包含：
-
-- `skill_name`：建议 `recap-<agent-key>-<topic-slug>`（英文小写、连字符；topic 取自任务主题）
-- `skill_description`：第三人称，说明适用场景与触发词，便于下次任务时被发现
-- `merge_strategy`：同业务域已有 Skill 时填 `upsert`，全新领域填 `create`
-
-**agent-key 参考**（按当前角色映射）：
-
-| agent      | agent-key |
-| ---------- | --------- |
-| 产品经理   | pm        |
-| 前端工程师 | frontend  |
-| 后端工程师 | backend   |
-| 全栈工程师 | fullstack |
-| 项目经理   | pm-lead   |
-
-### 步骤 6：回复消息
-
-回复中须包含：
-
-1. 草稿路径：`.apm/project/docs/<name>-复盘技能.md`
-2. 建议的 `skill_name` 与 `skill_description`（与元数据块一致）
-3. 本次复盘摘要（3 ～ 5 条 bullet，概括解决了哪些口径/问题）
-4. 发布提醒：草稿需由管理员发布到平台 **Skills** 后，执行 `apm update-skills`，其他成员方可 Read 该经验技能
-
----
-
-## 约束
-
-- 本技能只生成**草稿**；Agent 无法直接写入平台 Skill 库或 `.apm/skills/`
-- 不得修改他人已写的 `docs/*-复盘技能.md`
-- 若 PRD 与项目文档矛盾，以**本人实际产出与发言**为准，并在「已知踩坑」中注明口径尚未统一
-
-## 何时使用本技能
-
-- 用户或项目经理要求复盘、总结、沉淀经验
-- 任务阶段性完成，角色主动沉淀领域知识

package/template/skills/apm-recap/recap-template.md

@@ -1,121 +0,0 @@
-## 复盘技能模板
-
-生成 `.apm/project/docs/<name>-复盘技能.md` 时，**完整文件**须包含下方「元数据块 + 正文」两部分。
-
----
-
-### 元数据块（写在文件最顶部）
-
-```markdown
----
-skill_name: recap-<agent-key>-<topic-slug>
-skill_description: <第三人称描述：谁在什么业务域的经验；什么需求场景下应阅读本技能。含 2～4 个触发关键词。>
-agent: <当前角色，如「后端工程师」>
-member: <当前名字，如「医务小朱」>
-source_project: <仓库或任务主题简述>
-merge_strategy: upsert
-generated_at: <YYYY-MM-DD>
----
-```
-
-**skill_name 示例**：
-
-- `recap-backend-death-patient-list`
-- `recap-frontend-death-patient-list`
-- `recap-pm-medical-record-check`
-
-**skill_description 示例**：
-
-> 医务小朱在死亡患者列表选择界面项目中的后端经验。处理死亡患者筛选、病历检查、HIS 列表接口相关需求时使用。
-
----
-
-### 正文骨架（元数据块之后）
-
-```markdown
-## 适用场景
-
-- <什么业务、什么页面、什么类型的需求应读本技能>
-- <2 ～ 3 条，每条一句，可验收>
-
-## 任务背景
-
-<1 ～ 3 句：本次任务要解决什么；不写轮次过程>
-
-## 已解决的口径与决策
-
-<!-- 产品/技术结论，可直接当下次任务的规范 -->
-
-### <决策点 1 简短名称>
-
-- **结论**：…
-- **依据**：…（可引用 PRD 行号或本人发言中的要点，不要贴大段原文）
-
-### <决策点 2>
-
-- **结论**：…
-- **依据**：…
-
-## 可复用做法
-
-<!-- 步骤、检查清单、评审要点——下次同类任务可直接照做 -->
-
-1. …
-2. …
-
-## 已知踩坑与协作依赖
-
-### 踩坑
-
-- …
-
-### 协作依赖
-
-- **<其他角色名>**：…（仅写与本人工作相关的交接点）
-
-## 关联产出
-
-<!-- 只列文件名，不贴全文 -->
-
-- `PRD.md` / `<角色>-技术方案.md` / …
-
-## 来源
-
-- 项目：<source_project>
-- 角色：<member>（<agent>）
-- 生成：<generated_at>
-```
-
----
-
-### 编写规范
-
-| 类型       | 写法要点                                                    |
-| ---------- | ----------------------------------------------------------- |
-| 口径/决策  | 写清「是什么 + 为什么」，避免「讨论过」「沟通过」等空泛表述 |
-| 可复用做法 | 用动词开头（确认、校验、先…再…），可当作 checklist          |
-| 踩坑       | 写「不要…」「注意…」，说明后果或触发条件                    |
-| 协作依赖   | 只写阻塞或交接点，不写他人完整方案                          |
-| 禁止       | 轮次叙事、聊天记录摘要、大段代码、组件/文件路径堆砌         |
-
-### 质量自检（写入前逐项确认）
-
-- [ ] 元数据块完整，`skill_name` 为英文 slug
-- [ ] 「适用场景」陌生人能判断要不要读
-- [ ] 「已解决的口径与决策」至少 1 条，且来自本人产出或 docs
-- [ ] 全文无「第 N 轮」字样
-- [ ] 无编造：材料中没有的内容未写入
-
-### 合并已有 Skill 时（merge_strategy: upsert）
-
-若平台已存在同名 `skill_name` 的 Skill，生成草稿时在正文最末追加：
-
-```markdown
-## 合并说明
-
-- 本次新增：<bullet 列表>
-- 本次修正：<bullet 列表，旧口径 → 新口径>
-- 建议保留不变：<bullet 列表>
-```
-
-管理员发布时对照合并说明更新平台 Skill 正文。

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

@@ -1,26 +0,0 @@
-## 工作流程
-
-### 步骤 1: 获取当前版本 PRD 的内容
-
-先用 **Read** 工具阅读 `.apm/project/docs/PRD.md`，如果存在则这个目录下的内容为需求文档，否则 **Read** `.apm/project/manifest.json` 与相关项目文档，或 `@项目经理` 确认需求来源。
-
-### 步骤 2: 理解代码，给出评审意见，具体要求如下：
-
-#### 评审目标如下：
-
-1. 梳理需求边界：发现文档中未写清的口径
-2. 调研实现难度：在实现难度较高时给出提示
-3. 禁止为了凑问题而提问，当 PRD 已足够清晰且无高难度改造时，可直接说此任务没问题
-4. 你只需要站在自己的角度去评审，禁止站在全局思考问题。结合代码进行评审即可：
-   - 前端关注 UI 交互还原，交互逻辑的各种边界，不考虑一些与后端接口之类的问题
-   - 后端则关注数据表设计，需求对应的数据接口是否合理，能否获取
-   - 全栈则关注前面两者，可以把这些问题合并起来提出来
-
-**难度高的定义**：预估改动的文件可能比较多，超过 10 个；或者改动逻辑比较复杂；
-
-#### 表达规范如下
-
-1. **产品语言优先**：页面定位用「医德考评弹窗」「行风办审批页」等说法；**禁止**用文件路径、组件名、函数名作为论据主体。
-2. **后端可略宽**：必要时可写**表名 / 主表字段名**帮助产品理解数据口径，但仍避免贴大段代码或接口路径。
-3. **锚定 PRD**：当需要引用到任务文档中的某一条时可以直接说行号，比如：需求原文[1-3]说 xxx；
-4. **问题 = 文档缺口**：只写 PRD **未写清**且**影响本端理解边界**的点。已写清楚的规则不要重复质疑。

package/template/skills/apm-write-frontend-plan/SKILL.md

@@ -1,27 +0,0 @@
-## 适用范围
-
-前端工程师在 `API.md` 就绪后，编写 `.apm/project/docs/FRONTEND.md`。
-
-这是一份 **Plan**（实现计划），不是技术方案：说清楚改什么、分几步做、动哪些文件；接口细节读 `API.md`，代码细节留给 `apm-dev`。
-
----
-
-## 工作流程
-
-1. **Read** `.apm/project/docs/PRD.md`、`.apm/project/docs/API.md`；`API.md` 不存在则退出并 @ 后端。
-2. 按需调研代码库，确认改动入口。
-3. **Read** `.apm/skills/apm-write-frontend-plan/plan-template.md`，按模板 **Write** `.apm/project/docs/FRONTEND.md`。
-4. 回复消息通知可进入开发。
-
----
-
-## 写作要求
-
-- 篇幅宜短（通常 **30 ～ 80 行**），宁可少写，不要铺表、不要伪代码。
-- 接口只写「何时调、关键点」，不复制 `API.md`。
-- 产品语言描述交互；文件路径只出现在「涉及文件」。
-- 禁止流水账。
-
-## 何时使用
-
-协作流程阶段 3；或用户要求写 `FRONTEND.md`。

package/template/skills/apm-write-frontend-plan/plan-template.md

@@ -1,40 +0,0 @@
-# Plan 模板
-
-对齐 Cursor Plan：背景 → 实现步骤 → 涉及文件 → 接口要点 → 验收。全文尽量一页以内。
-
-```markdown
-# <功能名称>
-
-## 背景
-
-<2 ～ 3 句：要做什么、限定在哪个页面/场景、现网什么保持不变>
-
-## 实现步骤
-
-1. <第一步：例如新增某弹窗组件，负责什么交互>
-2. <第二步：例如改某页面条件分支，触发条件是什么>
-3. <第三步：对接 API.md 中的某某接口，调用时机>
-4. <第四步：回填/校验/联调>
-
-## 涉及文件
-
-- `<路径>` — <改什么>
-- `<路径>` — <改什么>
-
-## 接口
-
-（不复制 API.md；几条 bullet 即可）
-
-- 列表：<何时请求、首屏传什么>
-- 详情：<选中后怎么走>
-- 注意：<禁止用列表数据代替详情等，引用 API.md 章节>
-
-## 验收
-
-- [ ] <对照 PRD 的可检查项>
-- [ ] <…>
-```
-
-## 不要写
-
-伪代码、参数表、JSON 示例、mermaid（除非步骤说不清）、风险大表、模块拆分专章。

package/template/skills/apm-write-plan/SKILL.md

@@ -1,79 +0,0 @@
-# apm-write-plan：直接基于需求写实现计划
-
-## 适用范围
-
-前端 / 后端工程师在任务启动后**直接读原始需求写实现计划**，不经过 PRD。
-
-本技能合并了原 `apm-write-prd`、`apm-review`、`apm-write-frontend-plan`、`apm-write-backend-api` 四个技能的职能：评审（判断是否参与、发现口径缺口）和方案（怎么改、改哪些文件）一步完成。
-
-| 角色 | 产出文档                                                      | 路径                                                                 |
-| ---- | ------------------------------------------------------------- | -------------------------------------------------------------------- |
-| 后端 | `BACKEND-PLAN.md`（实现计划）+ `API.md`（联调契约，单独产出） | `.apm/project/docs/BACKEND-PLAN.md`、`.apm/project/docs/API.md`      |
-| 前端 | `FRONTEND-PLAN.md`                                            | `.apm/project/docs/FRONTEND-PLAN.md`                                 |
-
-**两份后端文档禁止合并**：`BACKEND-PLAN.md` 不写完整参数表 / JSON 示例；`API.md` 不写 Service / SQL 等实现细节。
-
----
-
-## 工作流程
-
-### 步骤 1：判断本端是否需要参与
-
-**Read** `.apm/project/manifest.json` 与 `.apm/project/docs/` 下的需求文档（如 `PRD.md`）；必要时 `@项目经理` 确认需求范围。
-
-- **不涉及本端改动**：立即用 `append_message` 回复「本需求与前端/后端无关，理由：xxx」（一句话说明理由），**流程到此结束，禁止写任何文档、禁止改任何代码**。
-- **涉及本端改动**：进入步骤 2。
-
-### 步骤 2：有限调研（必须遵守预算）
-
-1. **优先读现成结论**：先读 `.apm/project/docs/` 下已有的模块档案、历史工作日志、其他成员已同步的文档，能复用就不要重新调研。
-2. **再调研代码**：只看与需求直接相关的页面 / 接口 / 表。**调研预算：最多读 15 个代码文件**，禁止全库考古、禁止顺藤摸瓜阅读无关模块。
-3. **口径不清不要自己拍板**：调研中发现需求没写清的业务口径（例如字段含义、互斥规则、历史数据兼容），一律记入计划的「依据与假设」章节，禁止编造业务规则。
-
-**前端额外要求**：若本次涉及接口对接，**Read** `.apm/project/docs/API.md`；不存在则先 `@后端` 产出 `API.md`，**禁止在计划中自行编写或抄写接口定义**。
-
-### 步骤 3：按模板写计划
-
-**Read** `.apm/skills/apm-write-plan/plan-template.md`，按模板 **Write** 对应的计划文档。硬性要求，缺一不可：
-
-1. **依据与假设**：每条关键口径标注来源（需求原文第几条 / 现有代码行为 / 已有文档）；标不出来源的就是「假设」，单独列出。
-2. **改动文件白名单**：本次允许改动的文件完整列表。后续开发与 diff 评审都以此为准，**开发时改了白名单之外的文件会被打回**。
-3. **后端专属——同步产出 API.md**（涉及接口变更时）：**Read** `.apm/skills/apm-write-plan/api-template.md`，按模板 **Write** `.apm/project/docs/API.md`。这是前端联调的唯一契约来源，前端直接阅读本文档，禁止各写一份。
-4. **后端专属——SQL 变更声明**（仅当涉及表结构/数据变更时）：在「实现步骤」中注明开发须产出 `.apm/project/docs/SQL.md`；计划本身不写大段 SQL，完整语句由后端开发阶段写入该文档。
-5. **前端专属——接口对接要点**：只写「何时调、关键点」，引用 `API.md` 章节，**禁止复制参数表 / JSON 示例**。
-
-### 步骤 4：回复
-
-回复消息（遵守 `reply.md`）：
-
-- **「假设」章节非空**：把假设逐条列进回复内容，`@项目经理` 请其确认；明确说「以上假设确认前不开始开发」。
-- **无假设**：回复计划已就绪，可进入测试要点编写。
-- **后端**：涉及接口变更时，回复中 `@前端` 阅读 `API.md` 并编写 `FRONTEND-PLAN.md`。
-- **前端**：`API.md` 尚未就绪时，回复 `@后端` 先产出 `API.md`，**禁止自行编写接口契约**。
-
-### 步骤 5：假设回填（项目经理确认后必须执行）
-
-当你被安排「根据项目经理的确认更新计划」，或发现项目经理已回复假设确认时：
-
-1. 根据项目经理在对话中的确认回复，**逐条对照你列出的假设**。
-2. 更新计划文档：
-   - 被确认的假设 → **移入「依据」表格**，来源写「项目经理确认」；
-   - 被否定或修正的假设 → 按项目经理给出的口径**修订「实现步骤」与「改动文件白名单」**；
-   - 项目经理没有回应的假设 → 保留在「假设」中，再次 `@项目经理` 追问。
-3. **后端**：假设修订涉及接口口径时，同步更新 `.apm/project/docs/API.md`。
-4. 重新执行 `apm sync-document` 同步计划与 API 文档。
-5. 回复消息：逐条说明每个假设的处理结果（确认采纳 / 按口径修订了什么），全部解决则声明「假设已清零，可进入测试要点编写」。
-
-**禁止**跳过回填直接开发：澄清结论必须落进计划文档（接口口径落进 `API.md`），后续开发与 diff 评审都只认文档，不认聊天记录。
-
----
-
-## 写作要求
-
-- 篇幅 **40 ～ 100 行**，宁可少写；不要伪代码、不要大段 SQL（完整语句写入 `.apm/project/docs/SQL.md`，由后端开发阶段产出）。
-- 用产品语言描述行为，文件路径只出现在「改动文件白名单」。
-- 前后端可同轮并行编写计划；前端接口部分依赖 `API.md`，后端须先或同步产出。
-
-## 何时使用
-
-协作流程阶段 1（实现计划）；或用户要求写 `BACKEND-PLAN.md` / `FRONTEND-PLAN.md` / `API.md`。