ai-project-manage-cli 7.1.39 → 8.0.2

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

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

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

@@ -1,121 +0,0 @@
-## 复盘技能模板
-
-生成 `.apm/sessions/<会话ID>/docs/<name>-复盘技能.md` 时，**完整文件**须包含下方「元数据块 + 正文」两部分。
-
----
-
-### 元数据块（写在文件最顶部）
-
-```markdown
----
-skill_name: recap-<agent-key>-<topic-slug>
-skill_description: <第三人称描述：谁在什么业务域的经验；什么需求场景下应阅读本技能。含 2～4 个触发关键词。>
-agent: <session.yaml 中的 agent，如「后端工程师」>
-member: <session.yaml 中的 name，如「医务小朱」>
-source_session: <会话 ID>
-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` / `TASK.md` / `<角色>-技术方案.md` / …
-
-## 来源
-
-- 会话：<source_session>
-- 角色：<member>（<agent>）
-- 生成：<generated_at>
-```
-
----
-
-### 编写规范
-
-| 类型       | 写法要点                                                    |
-| ---------- | ----------------------------------------------------------- |
-| 口径/决策  | 写清「是什么 + 为什么」，避免「讨论过」「沟通过」等空泛表述 |
-| 可复用做法 | 用动词开头（确认、校验、先…再…），可当作 checklist          |
-| 踩坑       | 写「不要…」「注意…」，说明后果或触发条件                    |
-| 协作依赖   | 只写阻塞或交接点，不写他人完整方案                          |
-| 禁止       | 轮次叙事、聊天记录摘要、大段代码、组件/文件路径堆砌         |
-
-### 质量自检（写入前逐项确认）
-
-- [ ] 元数据块完整，`skill_name` 为英文 slug
-- [ ] 「适用场景」陌生人能判断要不要读
-- [ ] 「已解决的口径与决策」至少 1 条，且来自本人 messages 或 docs
-- [ ] 全文无「第 N 轮」字样
-- [ ] 无编造：材料中没有的内容未写入
-
-### 合并已有 Skill 时（merge_strategy: upsert）
-
-若平台已存在同名 `skill_name` 的 Skill，生成草稿时在正文最末追加：
-
-```markdown
-## 合并说明
-
-- 本次新增：<bullet 列表>
-- 本次修正：<bullet 列表，旧口径 → 新口径>
-- 建议保留不变：<bullet 列表>
-```
-
-管理员发布时对照合并说明更新平台 Skill 正文。

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

@@ -1,26 +0,0 @@
-# apm-update-plan：按 PM 确认结果更新计划
-
-## 何时使用
-
-收到沟通群消息「假设已全部确认。请相关工程师：」后。
-
-## 工作流程
-
-1. **`apm pull`** 拉取最新文档（含 ASSUMPTIONS 确认结果）。
-2. **Read** 本端 `docs/FRONTEND-ASSUMPTIONS.md` 或 `docs/BACKEND-ASSUMPTIONS.md`（**禁止**读 assumptions.json）。
-3. **Read** 本端 PLAN：`docs/FRONTEND-PLAN.md` 或 `docs/BACKEND-PLAN.md`。
-4. 逐条按 ASSUMPTIONS 中「确认结果」更新 PLAN：
-   - 移入「依据」表，来源写「项目经理确认」；
-   - 影响实现范围时 → 修订「实现步骤 / 改动文件白名单」；后端涉及接口则同步 `docs/API.md`。
-5. 重写 PLAN §1「需求理解」（融合 PM 确认口径）。
-6. **`apm sync-document`** 同步 PLAN（及 API 文档）。
-7. **`AppendMessage`**：本端需求理解摘要 + @项目经理，请其回复「理解正确，可进入开发」。
-8. **Read/Update** `TODO.md`：勾选相关待办。
-
-**禁止** `apm assumptions --mark-backfilled`（已废弃）。
-
-**禁止**从 `messages.xml` 解析 PM 对假设的回复——只认 ASSUMPTIONS 文档中的确认结果。
-
-## 何时使用
-
-协作流程阶段 1.5（假设确认后更新计划）。

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

@@ -1,78 +0,0 @@
-# apm-write-assumptions：编写并同步待确认口径
-
-## 何时使用
-
-`apm-write-plan` 步骤 3 编写 `*-ASSUMPTIONS.md` 时；或需重写/补写假设文档时。
-
-| 角色 | 产出                           |
-| ---- | ------------------------------ |
-| 前端 | `docs/FRONTEND-ASSUMPTIONS.md` |
-| 后端 | `docs/BACKEND-ASSUMPTIONS.md`  |
-
----
-
-## 工作流程
-
-### 1. 按模板编写
-
-1. **Read** `.apm/skills/apm-write-assumptions/assumptions-template.md`
-2. **Write** 本端 `docs/*-ASSUMPTIONS.md`（写作时对照下方 **PM 校验规则**）
-3. 无假设时正文仅一行：`无，口径均有依据。`
-
-### 2. 直接 sync
-
-```bash
-apm sync-document <sessionId> --file FRONTEND-ASSUMPTIONS.md
-# 或 BACKEND-ASSUMPTIONS.md
-```
-
-**成功**须看到：
-
-```text
-[apm] 假设解析: 标记 N 条，入库 N 条（PM 可确认 N 条）
-```
-
-无假设时无 `假设解析` 行，属正常。
-
-### 3. 报错则改完重 sync
-
-`sync-document` 失败时会打印具体假设编号与原因（如 `假设 A2 未通过 PM 校验: …`）。
-
-1. 按报错修正对应 `A*` 的 **问 / 场景 / 选项**（规则见下）
-2. 再次执行步骤 2
-3. **禁止**在未成功 sync 前 @ 项目经理、sync PLAN、或声称「请在 Web 待确认」
-
----
-
-## PM 校验规则（与服务端一致）
-
-每条假设（`#### A1` …）必须包含：
-
-| 字段         | 要求                                                            |
-| ------------ | --------------------------------------------------------------- |
-| **问**       | 业务语言；≥6 字；含下列业务动词之一；禁止字段名/路径/SQL/反引号 |
-| **场景**     | 非空                                                            |
-| **选项**     | ≥2 项，格式 `- opt_id：说明`                                    |
-| **研发备注** | 可选；技术细节放这里，**不要**写进「问」                        |
-
-**问句须含以下动词之一**：
-
-`提交` `展示` `校验` `驳回` `审批` `允许` `禁止` `筛选` `列表` `详情` `暂存` `删除` `新增` `修改` `导出` `导入`
-
-**问句禁止**：`status=`、文件扩展名、反引号代码、SQL、`类.字段`、snake_case 字段名。
-
-### 正反例
-
-| 假设    | 问句                                           | 结果                   |
-| ------- | ---------------------------------------------- | ---------------------- |
-| A2      | 编辑已有记录时，「落实人员」应如何处理？       | **失败**（无业务动词） |
-| A2 修正 | 编辑已有记录时，是否**允许修改**「落实人员」？ | 通过                   |
-| A3      | 「落实人员」可选择的范围是？                   | **失败**               |
-| A3 修正 | 「落实人员」下拉**列表**应**展示**哪些人员？   | 通过                   |
-
----
-
-## 与其他技能
-
-- 由 **`apm-write-plan`** 在 sync PLAN 前调用本技能
-- PM 确认后由 **`apm-update-plan`** 更新 PLAN

package/template/skills/apm-write-assumptions/assumptions-template.md

@@ -1,18 +0,0 @@
-# 前端待确认口径
-
-> 本文件由 apm sync-document 写入；PM 确认后服务端回写「状态/确认结果」。
-> **禁止**手动编辑；已确认条目 AI 禁止修改。
-> 编写与校验规则见 `.apm/skills/apm-write-assumptions/SKILL.md`。
-
-#### A1
-
-- **问**：（业务语言问句；须含：提交/展示/校验/驳回/审批/允许/禁止/筛选/列表/详情/暂存/删除/新增/修改/导出/导入 之一）
-- **场景**：（需求未说明的背景）
-- **选项**：
-  - opt_a：（选项说明）
-  - opt_b：（选项说明）
-- **研发备注**：（仅研发可见的技术说明，可选）
-- **状态**：待确认
-- **确认结果**：
-
-> 无假设时正文仅一行：无，口径均有依据。

package/template/skills/apm-write-backend-api/SKILL.md

@@ -1,40 +0,0 @@
-## 适用范围
-
-后端工程师在需求评审通过后，编写两份文档：
-
-| 文档         | 路径              | 定位                                     |
-| ------------ | ----------------- | ---------------------------------------- |
-| `BACKEND.md` | `docs/BACKEND.md` | **Plan**：后端怎么改、分几步、动哪些文件 |
-| `API.md`     | `docs/API.md`     | **联调契约**：给前端看的 URL、参数、示例 |
-
-两份文档禁止合并；`API.md` 不写 Service/SQL 等实现细节。
-
----
-
-## 工作流程
-
-1. **Read** `docs/PRD.md`；不存在则退出。
-2. 按需调研代码库，确认现网接口与表结构。
-3. **Read** `backend-template.md`，按模板 **Write** `docs/BACKEND.md`。
-4. **Read** `api-template.md`，按模板 **Write** `docs/API.md`。
-5. @ 前端阅读 `API.md` 并编写 `FRONTEND.md`。
-
-（模板路径：`.apm/skills/apm-write-backend-api/`）
-
----
-
-## 写作要求
-
-**BACKEND.md**（对齐 Cursor Plan，通常 **30 ～ 80 行**）
-
-- 背景 → 实现步骤 → 涉及文件 → 数据与规则 → 验收
-- 可写表名、关键字段；不要大段 SQL、不要完整参数表（那些放 `API.md`）
-
-**API.md**
-
-- 写清前端联调所需：Path、参数、示例、联调注意点
-- 不复制 `BACKEND.md` 的实现步骤
-
-## 何时使用
-
-协作流程阶段 3；或用户要求写 `BACKEND.md` / `API.md`。

package/template/skills/apm-write-backend-api/api-template.md

@@ -1,35 +0,0 @@
-# API.md 模板
-
-给前端联调用。实现步骤见 `BACKEND.md`；本文只写契约，篇幅尽量克制。
-
-```markdown
-# <功能名称> — 接口
-
-## 背景
-
-<1～2 句：本次新增/变更/复用哪些接口>
-
-## <接口名称>（新增）
-
-- **GET** `/实际/path`
-- **用途**：…
-- **参数**：`pageNo`、`pageSize`（可选，默认 …）；`xxx`（何时传、何时不传）
-- **成功**：`result` 结构简述 + 简短 JSON 示例
-- **失败**：格式非法 → `message` 示例；无数据 → 空列表算成功
-
-## <接口名称>（现网，不变）
-
-- **GET** `/实际/path/{id}`
-- **用途**：…
-- **前端关注字段**：`fieldA` → 模板 xxx
-
-## 联调说明
-
-1. 首屏：只传 …
-2. 筛选：…
-3. 选中后：必须先调详情，禁止 …
-```
-
-## 不要写
-
-SQL、Java 类路径、Service 实现、后端验收清单。

package/template/skills/apm-write-backend-api/backend-template.md

@@ -1,41 +0,0 @@
-# Plan 模板（BACKEND.md）
-
-对齐 Cursor Plan：背景 → 实现步骤 → 涉及文件 → 数据与规则 → 验收。全文尽量一页以内。
-
-```markdown
-# <功能名称>
-
-## 背景
-
-<2 ～ 3 句：交付什么能力、改哪些模块、现网什么保持不变>
-
-## 实现步骤
-
-1. <例如：新增 VO，字段来自哪张表>
-2. <例如：Service 组装查询条件、分页>
-3. <例如：Mapper/SQL，关联哪张表>
-4. <例如：Controller 新增端点；路由顺序等约束>
-5. <例如：复用现网某方法，保持详情接口不变>
-
-## 涉及文件
-
-- `<路径>` — <新增/修改，一句话>
-- `<路径>` — <…>
-
-## 数据与规则
-
-（几条 bullet，不写长表）
-
-- 数据源：`<表名>`，关键字段 …
-- 筛选：默认范围 …；与 `deathMonth`、住院号 AND …
-- 注意：<易错点，如固定路径须写在 `{id}` 路由之前>
-
-## 验收
-
-- [ ] <接口行为可对照 PRD 检查>
-- [ ] <…>
-```
-
-## 不要写
-
-完整接口参数表、JSON 示例、大段 SQL、mermaid、风险大表——参数示例放 `API.md`，实现细节开发时再展开。

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

@@ -1,42 +0,0 @@
-# apm-write-checklist：编写人工回归要点清单
-
-## 适用范围
-
-测试智能体在前后端计划（`BACKEND-PLAN.md` / `FRONTEND-PLAN.md`）就绪后，编写 `docs/CHECKLIST.md`。
-
-这份清单是**给人做回归验收用的**，不是自动化测试用例：把需求的关键点过一遍即可，一条一行，人拿着它在测试环境点一遍就能判断需求做没做对。
-
----
-
-## 工作流程
-
-### 步骤 1：读需求与计划
-
-1. **Read** `.apm/sessions/<会话ID>/TASK.md` —— **以需求原文为准出题**，不要只从计划推导（计划理解错了，照着计划出的题也会跟着错）。
-2. **Read** `docs/BACKEND-PLAN.md`、`docs/FRONTEND-PLAN.md`（存在哪份读哪份）。
-
-### 步骤 2：交叉校验（这一步是打回机制）
-
-逐条对照需求原文与计划：
-
-- **计划与需求矛盾、或需求关键点在计划中没有覆盖**：不要写清单，先用 `AppendMessage` 指出问题并 `@` 对应工程师打回，等计划修订后再写。
-- **开发门禁未通过**（`apm dev-gate` 返回 `readyForDev: false`）：**不要写清单**，先提醒 PM / 执行 `apm-update-plan`。
-- 计划覆盖完整：进入步骤 3。
-
-### 步骤 3：按模板写清单
-
-**Read** `.apm/skills/apm-write-checklist/checklist-template.md`，按模板 **Write** `docs/CHECKLIST.md`。
-
-要求：
-
-- **5 ～ 15 条**，关键点级别，不写入参出参细节、不写接口路径。
-- 每条 = 在哪个页面、做什么操作、预期看到什么。
-- 必须覆盖：需求的每个功能点至少 1 条、关键互斥/边界规则至少 1 条、对既有功能的回归至少 1 条（确认没改坏原有逻辑）。
-
-### 步骤 4：回复
-
-回复消息说明清单已就绪，可进入开发。
-
-## 何时使用
-
-协作流程阶段 2（测试要点）；或用户要求写 `CHECKLIST.md`。

package/template/skills/apm-write-checklist/checklist-template.md

@@ -1,34 +0,0 @@
-# 回归要点清单模板
-
-```markdown
-# <需求名> · 人工回归要点
-
-> 验收人按编号逐条验证；某条不通过时，直接在群里回复「第 N 条不通过，实际现象：xxx」即可。
-
-## 新功能验证
-
-| # | 页面 / 位置 | 操作 | 预期 |
-|---|-------------|------|------|
-| 1 | 检查项目维护 → 编辑 | 勾选「是否加分」 | 「是否扣分」自动取消，两者不可同时勾选 |
-| 2 | 检查项目维护 → 保存 | 同时勾选加分与扣分后保存 | 保存被拦截并提示互斥 |
-| 3 | 检查模板维护 → 新增 | 选择检查分类 | 「检查分类分值」自动带入，加分项不计入汇总 |
-
-## 边界与兼容
-
-| # | 页面 / 位置 | 操作 | 预期 |
-|---|-------------|------|------|
-| 4 | 检查录入 | 对加分项录入加分并保存 | 总分正确增加且不设上限，重新打开回显一致 |
-| 5 | 检查录入 | 打开改造前创建的历史单据 | 正常显示，原扣分逻辑不变 |
-
-## 既有功能回归
-
-| # | 页面 / 位置 | 操作 | 预期 |
-|---|-------------|------|------|
-| 6 | 检查录入 | 普通扣分项的录入与保存 | 与改造前行为完全一致 |
-```
-
-写作要求：
-
-- 表格三列固定：位置、操作、预期；每条一行，禁止嵌套步骤。
-- 「预期」写人肉眼可判断的现象，不写「接口返回 200」这类机器口径。
-- 总数控制在 5～15 条，超出说明粒度太细，合并。

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

@@ -1,27 +0,0 @@
-## 适用范围
-
-前端工程师在 `API.md` 就绪后，编写 `.apm/sessions/<会话ID>/docs/FRONTEND.md`。
-
-这是一份 **Plan**（实现计划），不是技术方案：说清楚改什么、分几步做、动哪些文件；接口细节读 `API.md`，代码细节留给 `apm-dev`。
-
----
-
-## 工作流程
-
-1. **Read** `docs/PRD.md`、`docs/API.md`；`API.md` 不存在则退出并 @ 后端。
-2. 按需调研代码库，确认改动入口。
-3. **Read** `.apm/skills/apm-write-frontend-plan/plan-template.md`，按模板 **Write** `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,51 +0,0 @@
-# apm-write-plan：直接基于需求写实现计划
-
-## 适用范围
-
-前端 / 后端工程师在任务启动后**直接读原始需求写实现计划**，不经过 PRD。
-
-| 角色 | 产出文档                                       | 路径                                                    |
-| ---- | ---------------------------------------------- | ------------------------------------------------------- |
-| 后端 | `BACKEND-PLAN.md` + `API.md`                   | `docs/BACKEND-PLAN.md`、`docs/API.md`                   |
-| 前端 | `FRONTEND-PLAN.md` + `FRONTEND-ASSUMPTIONS.md` | `docs/FRONTEND-PLAN.md`、`docs/FRONTEND-ASSUMPTIONS.md` |
-| 后端 | 同上                                           | `docs/BACKEND-ASSUMPTIONS.md`                           |
-
----
-
-## 工作流程
-
-### 步骤 1：判断本端是否需要参与
-
-**Read** `.apm/sessions/<会话ID>/TASK.md`。
-
-- **不涉及本端改动**：`AppendMessage` 回复理由后结束。
-- **涉及本端改动**：进入步骤 2。
-
-### 步骤 2：有限调研
-
-1. 优先读 `docs/` 现成结论。
-2. 代码调研预算：**最多 15 个文件**。
-3. 口径不清 → 记入 **ASSUMPTIONS 文件**，禁止编造。
-
-### 步骤 3：写计划与假设
-
-1. **Read** `.apm/skills/apm-write-plan/plan-template.md`，**Write** 本端 `*-PLAN.md`（**不含**假设章节）。
-2. **Read** 并完整执行 **`.apm/skills/apm-write-assumptions/SKILL.md`**（编写 `*-ASSUMPTIONS.md` → sync；报错则改完重 sync）。
-
-### 步骤 4：同步 PLAN 与回复
-
-1. `apm sync-document --file FRONTEND-PLAN.md`（或 BACKEND）。
-2. **有假设且 ASSUMPTIONS 已成功 sync**：@项目经理 请其在 Web **「待您确认」** Panel 点选；说明「以上假设确认前不开始开发」。
-3. **无假设**：`AppendMessage` 发送「本端需求理解」摘要并 @项目经理 请确认。
-
-> **禁止**在 ASSUMPTIONS sync 未成功时 @ 项目经理确认假设；PLAN 中「待确认 N 项」由服务端 sync ASSUMPTIONS 后自动更新，AI 不要手写具体数字。
-
-### 假设确认后更新计划
-
-项目经理在 Web 确认假设后，执行 **`apm-update-plan`** 技能（读 ASSUMPTIONS.md，**禁止**读 assumptions.json）。
-
----
-
-## 何时使用
-
-协作流程阶段 1（实现计划）。

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

@@ -1,35 +0,0 @@
-# API.md 模板
-
-给前端联调用。实现步骤见 `BACKEND-PLAN.md`；本文只写契约，篇幅尽量克制。
-
-```markdown
-# <功能名称> — 接口
-
-## 背景
-
-<1 ～ 2 句：本次新增/变更/复用哪些接口>
-
-## <接口名称>（新增）
-
-- **GET** `/实际/path`
-- **用途**：…
-- **参数**：`pageNo`、`pageSize`（可选，默认 …）；`xxx`（何时传、何时不传）
-- **成功**：`result` 结构简述 + 简短 JSON 示例
-- **失败**：格式非法 → `message` 示例；无数据 → 空列表算成功
-
-## <接口名称>（现网，不变）
-
-- **GET** `/实际/path/{id}`
-- **用途**：…
-- **前端关注字段**：`fieldA` → 模板 xxx
-
-## 联调说明
-
-1. 首屏：只传 …
-2. 筛选：…
-3. 选中后：必须先调详情，禁止 …
-```
-
-## 不要写
-
-SQL、Java 类路径、Service 实现、后端验收清单。