ai-project-manage-cli 5.0.14 → 5.0.16

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

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

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

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

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

@@ -1,69 +1,16 @@
-## 输入
-1. 口头需求要求：如果是用户口头需求要求则根据下面需求模板编写PRD
-2. 已有PRD+用户提要求：这个场景是润色现有的PRD文档，一般是原有PRD中的一些问题被解决了
-
-**注意**：
-- 编写/润色PRD时禁止提出额外的问题，一切以用户要求为准。
-- 已有PRD的地址为:  `../../sessions/<需求ID>/docs/PRD.md`，可用 **Read** 工具读取。
-- 需求要始终保持干净，模板规定以外的，比如历史沟通记录不需要
-
 ## 工作流程
-### 步骤1: 读取PRD
-### 步骤2: 按照下面的模板要求编写PRD
-### 步骤3: 同步PRD到远程
-
-
-## 需求模板
-### 正文骨架
-```markdown
-## 背景
-（1 ～ 3 句：业务背景、要解决的问题、预期效果，如果没有可空着，不要强行编）
-
-## 范围
-- **包含**：…
-- **不包含**：…
-
-## 需求说明
-
-### 需求点 1：[简短名称]
-- …
-- …
-
-### 需求点 2：…
-```
-
-### 需求点编写规范
-
-每条 bullet 写清一个可验收点，优先覆盖：
-
-| 类型      | 写法要点                                               |
-| --------- | ------------------------------------------------------ |
-| 展示/选项 | 展示或隐藏；保留/去掉哪些选项；新建默认值              |
-| 文案      | 原名称 → 新名称；界面、提示、校验文案一并统一          |
-| 按钮      | 场景 + 按钮名 + 行为（对照哪个既有按钮、是否仅改文案） |
-| 校验      | 场景 + 字段展示条件 + 必填时机（暂存 / 提交分别怎样）  |
-| 边界      | **不考虑** …（历史数据、迁移、导出等明确排除项）       |
 
-材料中的技术名可译为业务表述，例如：`audit1` → 一级审批；保存不推进流程 → **暂存**；办理并推进流程 → **提交**。
+### 步骤 1: 获取当前版本 PRD 的内容
 
-编写示例如下：
+先用 **Read** 工具阅读 `.apm/sessions/<会话ID>/docs/PRD.md`，如果存在，则这个目录下的内容为需求文档，否则用 **Read** 工具阅读 `.apm/sessions/<会话ID>/TASK.md`，并把这个文件里面的内容视为需求文档
 
-```markdown
-### 需求点 2：新增/编辑弹窗底部操作
+### 步骤 2: 按照下面的模板要求编写 PRD
 
-- 在**新增、编辑**场景下，弹窗底部新增 **「暂存」** 按钮。
-- **「暂存」**：沿用原 **「确定」** 按钮的业务逻辑（含校验与保存/流程行为），**仅将按钮展示文案改为「暂存」**。
+用 **Read** 工具阅读 `.apm/skills/apm-write-prd/template.md`，按照模板来写，写完保存到 `.apm/sessions/<会话ID>/docs/PRD.md` 。
 
-### 需求点 3：「科室医德考评小组人员名单」字段
+内容要求如下：
+**不管是第几版需求，都要当成第一版来看，禁止有历史版本或者修订版本或者第几版更新的字样**
 
-- 原字段展示名 **「科室医德考评人员名单」** 统一改为 **「科室医德考评小组人员名单」**；凡界面、提示、校验文案等涉及该名称处**一并修改**。
-- 当流程处于 **一级审批** 且该字段**展示**时，须校验为**必填**（在展示场景下触发，而非所有保存入口一律校验）。
-```
+### 步骤 3: 同步 PRD 到远程
 
-### 自检列表
-- [ ] 含 **背景与目标、范围、需求说明** 三章，叙述完整
-- [ ] 2 分钟内可通读；每个需求点 2 ～ 5 条 bullet，一层列表
-- [ ] 场景、按钮行为、校验时机表述清楚，前后一致
-- [ ] 「范围」与需求点中的 **「不考虑」** 口径一致
-- [ ] 全文使用业务语言，术语统一
-- [ ] 仅材料明确涉及时才有「非功能」「待确认」
+执行命令：`apm sync-document <会话 ID> --file=PRD.md`

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

@@ -0,0 +1,55 @@
+
+## 需求模板
+### 正文骨架
+```markdown
+## 背景
+（1 ～ 3 句：业务背景、要解决的问题、预期效果，如果没有可空着，不要强行编）
+
+## 范围
+- **包含**：…
+- **不包含**：…
+
+## 需求说明
+
+### 需求点 1：[简短名称]
+- …
+- …
+
+### 需求点 2：…
+```
+
+### 需求点编写规范
+
+每条 bullet 写清一个可验收点，优先覆盖：
+
+| 类型      | 写法要点                                               |
+| --------- | ------------------------------------------------------ |
+| 展示/选项 | 展示或隐藏；保留/去掉哪些选项；新建默认值              |
+| 文案      | 原名称 → 新名称；界面、提示、校验文案一并统一          |
+| 按钮      | 场景 + 按钮名 + 行为（对照哪个既有按钮、是否仅改文案） |
+| 校验      | 场景 + 字段展示条件 + 必填时机（暂存 / 提交分别怎样）  |
+| 边界      | **不考虑** …（历史数据、迁移、导出等明确排除项）       |
+
+材料中的技术名可译为业务表述，例如：`audit1` → 一级审批；保存不推进流程 → **暂存**；办理并推进流程 → **提交**。
+
+编写示例如下：
+
+```markdown
+### 需求点 2：新增/编辑弹窗底部操作
+
+- 在**新增、编辑**场景下，弹窗底部新增 **「暂存」** 按钮。
+- **「暂存」**：沿用原 **「确定」** 按钮的业务逻辑（含校验与保存/流程行为），**仅将按钮展示文案改为「暂存」**。
+
+### 需求点 3：「科室医德考评小组人员名单」字段
+
+- 原字段展示名 **「科室医德考评人员名单」** 统一改为 **「科室医德考评小组人员名单」**；凡界面、提示、校验文案等涉及该名称处**一并修改**。
+- 当流程处于 **一级审批** 且该字段**展示**时，须校验为**必填**（在展示场景下触发，而非所有保存入口一律校验）。
+```
+
+### 自检列表
+- [ ] 含 **背景与目标、范围、需求说明** 三章，叙述完整
+- [ ] 2 分钟内可通读；每个需求点 2 ～ 5 条 bullet，一层列表
+- [ ] 场景、按钮行为、校验时机表述清楚，前后一致
+- [ ] 「范围」与需求点中的 **「不考虑」** 口径一致
+- [ ] 全文使用业务语言，术语统一
+- [ ] 仅材料明确涉及时才有「非功能」「待确认」