ai-project-manage-cli 2.0.10 → 2.0.11

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

@@ -0,0 +1,114 @@
+# specs 工件：写作说明（供 apm-propose 读取）
+
+在工作项目录下生成 **`specs/`** 内的规格文件，定义系统 **应做什么**，与 **`design.md`**（如何实现）区分。内容须可验证：**每条「需求」下须有至少一个「场景」**。
+
+**工件 DAG、单会话减少重复 Read**：见 **`.cursor/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

@@ -0,0 +1,90 @@
+# tasks 工件：写作说明（供 apm-propose 读取）
+
+生成 **`tasks.md`**：把实现工作拆成**可勾选、可追踪**的条款。后续 **apm-apply-change** 依赖 **`- [ ]` / `- [x]`** 勾选推进，格式须严格遵守。
+
+**工件 DAG、单会话减少重复 Read**：见 **`.cursor/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/code-change-summary/SKILL.md

@@ -0,0 +1,84 @@
+---
+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

@@ -0,0 +1,55 @@
+# 代码变更摘要 - {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

@@ -0,0 +1,39 @@
+---
+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/mr-review-brief/SKILL.md

@@ -1,79 +0,0 @@
----
-name: mr-review-brief
-description: 在功能分支上相对 main/master 生成 MR 评审说明：功能变更、复杂项实现思路、对照仓库约定的规范符合性、建议验证步骤。供人类审核 AI 或大批量 diff，避免看不懂直接打回。用户主动触发；提及 MR 评审说明、评审摘要、变更说明、代码评审说明、release-checklist（历史名称）时使用。
----
-
-# MR 评审说明（供人类审核）
-
-**目的**：把相对基准分支的改动整理成评审者可读的说明，**不是**上线清单。重点三件事：
-
-1. **功能面**：改了什么、用户侧前后差异、该验什么。  
-2. **实现思路（复杂项）**：AI/作者为何这样拆问题、数据流或调用链、与现有模块如何衔接，避免评审者对着大段 diff 无从读起。  
-3. **规范符合性**：对照本仓库已有约定（`AGENTS.md`、`.cursor/rules` 等）做**诚实对照**，便于确认 AI 是否按项目规矩办事。
-
-## 触发前提
-
-- **仅在新分支执行**：当前分支必须不是 `main` 或 `master`
-- **用户主动触发**：如「生成 MR 评审说明」「评审摘要」「给 MR 写说明」等
-
-若当前在 main/master，提示：请先切换到功能分支再生成。
-
-## 核心原则
-
-- **按功能写正文**，不把「文件 M/A/D 列表」当正文主体；需要指到代码时，用少量**关键路径**（文件或模块名）辅助复杂项说明即可。  
-- **实现思路**用自然语言与少量结构化小标题，**禁止**大段粘贴源码。  
-- **规范符合性**：只能写**有据可查**的结论；不确定一律标为 **待评审核对** 并写明要查什么，**禁止**无依据写「已全部遵守规范」。  
-- 功能描述要**具体**：「之前 → 现在」，禁止空泛「调整了 XX 模块」。
-
-## 执行流程
-
-1. **获取变更**（只读 git）：
-
-```bash
-git branch --show-current
-git log main..HEAD --oneline   # 或 master..HEAD
-git diff main..HEAD --name-status
-git diff main..HEAD            # 必要时查看具体 diff
-```
-
-2. **按功能归纳**：业务功能维度、影响页面/流程；识别**复杂项**（填法见模板文件末尾注释中的 `{RATIONALE_COMPLEX}`）。
-
-3. **规范对照**（按变更范围选读，不必全文背诵）：
-
-   - 仓库根：`AGENTS.md`（Rush、子项目命令、Prisma 等）
-   - 若涉及前端：`apps/fe/AGENTS.md`
-   - 若涉及后端：`servers/be/AGENTS.md`
-   - 与改动相关的 `.cursor/rules`（如 Rush 命令规范）
-
-   将**与本次 diff 可能相关的条目**逐条对照，写入 `{CONVENTION_COMPLIANCE}`。
-
-4. **填充模板**：`mr-review-template.md`，替换全部占位符。
-
-5. **交付**：
-
-   - **必须在对话中输出完整 Markdown**，便于粘贴到 MR 描述或首条评论；**勿包含**模板末尾的 `<!-- 填法... -->` 注释块。
-   - **落盘**（可选）：仅当用户明确要求且提供保存位置时写入，默认**不落盘**。
-
-## 模板占位符
-
-模板路径：`mr-review-template.md`。
-
-| 占位符 | 含义 |
-|--------|------|
-| `{BRANCH_NAME}` | 当前分支名 |
-| `{DATE}` | 生成日期 |
-| `{BASE_BRANCH}` | main 或 master |
-| `{SCOPE}` | 前端 / 后端 / 全栈 / 公共 等 |
-| `{FUNCTION_CHANGES}` | 功能变更正文 |
-| `{RATIONALE_COMPLEX}` | 复杂项实现思路 |
-| `{CONVENTION_COMPLIANCE}` | 规范符合性 |
-| `{VERIFY_SUGGESTIONS}` | 建议验证步骤 |
-
-**各占位符的正文结构、字段与示例**：见模板**文件末尾** `<!-- ... -->` 填法注释。生成粘贴到 MR 的 Markdown 时**不要输出该 HTML 注释块**。
-
-**仅在 SKILL 强调（注释里不重复展开）**：规范结论须与「核心原则」一致——有据才写「已遵守」，否则标「待评审核对」并写清查什么。
-
-## 实现注意
-
-- 只读命令：`git branch`、`git diff`、`git log`、`git show-ref`  
-- 基准分支：优先 `main`，否则 `master`

package/templates/skills/mr-review-brief/mr-review-template.md

@@ -1,47 +0,0 @@
-# MR 评审说明 - {BRANCH_NAME}
-
-**生成时间**：{DATE}  
-**对比基准**：{BASE_BRANCH}  
-**变更范围**：{SCOPE}
-
----
-
-## 功能变更
-
-{FUNCTION_CHANGES}
-
----
-
-## 实现思路（复杂项）
-
-{RATIONALE_COMPLEX}
-
----
-
-## 项目规范符合性
-
-{CONVENTION_COMPLIANCE}
-
----
-
-## 建议验证
-
-{VERIFY_SUGGESTIONS}
-
-<!--
-填法（勿粘贴到 MR 正文）：输出时去掉本注释块。
-
-{FUNCTION_CHANGES} — 每个功能一段：
-### N. {功能/页面名称}
-- 之前：{行为}
-- 现在：{行为}
-- 影响范围：{入口、流程、页面（产品语言）}
-
-{RATIONALE_COMPLEX} — 仅复杂项展开（多文件联动、新抽象、非直观重构、关键算法或状态机）；简单增删改写「本次以局部增删为主，无单独展开的实现思路。」
-每复杂项可用二级标题，含：要解决的问题（1～2 句）；实现要点（拆分、数据流/调用链、与现有代码接点）；若有明显取舍可一句说明。
-
-{CONVENTION_COMPLIANCE} — 列表或表格，每条：规范来源；状态：已遵守 | 不适用 | 待评审核对；说明一句。
-已遵守须能指向本次改动中的体现；待评审核对须写清评审要查什么；未触及的规范勿强行已遵守。
-
-{VERIFY_SUGGESTIONS} — 与功能对应或可合并为场景流；步骤可执行，写清预期结果。
--->

package/templates/skills/openspec-apply-change/SKILL.md

@@ -1,167 +0,0 @@
----
-name: openspec-apply-change
-description: 根据 OpenSpec 变更实施任务。在用户希望开始实现、继续实现或逐项完成任务时使用。
-license: MIT
-compatibility: 需要 openspec CLI。
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.2.0"
----
-
-根据 OpenSpec 变更实施任务。
-
-**输入**：可选指定变更名称。若未指定，先尝试从对话上下文推断；若仍无法唯一确定，按步骤 1 的固定规则选定变更。**不要**向用户发起反问式确认或交互式选题。
-
-**步骤**
-
-1. **选择变更**
-
-   若已提供名称则直接使用。否则：
-   - 若用户在对话中提到了变更，从上下文推断
-   - 若仅存在一个活跃变更，自动选中
-   - 若仍有歧义：运行 `openspec list --json`，**按 CLI 返回列表中的第一个候选**作为本次变更（若你的环境有更稳定的排序字段，以「列表顺序优先」为准）；在回复中列出当时可见的候选名，并声明「使用变更：<name>」以及如何覆盖（例如 `/opsx:apply <其他>`）。**不要**调用 AskUserQuestion，**不要**停下来让用户当场选择。
-
-   始终声明：「使用变更：<name>」以及如何覆盖（例如 `/opsx:apply <其他>`）。
-
-2. **查看状态以理解 schema**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   解析 JSON 以了解：
-   - `schemaName`：当前工作流（例如 `"spec-driven"`）
-   - 任务清单在哪个工件中（spec-driven 通常为 `tasks`，其他 schema 以 status 为准）
-
-3. **获取 apply 说明**
-
-   ```bash
-   openspec instructions apply --change "<name>" --json
-   ```
-
-   返回内容包括：
-   - 上下文文件路径（因 schema 而异，可能是 proposal/specs/design/tasks 或 spec/tests/implementation/docs）
-   - 进度（总数、已完成、剩余）
-   - 带状态的任务列表
-   - 基于当前状态的动态说明
-
-   **处理状态：**
-   - 若 `state: "blocked"`（缺少工件）：展示提示，建议使用 openspec-continue-change
-   - 若 `state: "all_done"`：祝贺完成，建议归档
-   - 其他情况：进入实现
-
-4. **阅读上下文文件**
-
-   阅读 apply 说明输出中 `contextFiles` 列出的文件。
-   文件取决于所用 schema：
-   - **spec-driven**：proposal、specs、design、tasks
-   - 其他 schema：以 CLI 输出的 contextFiles 为准
-
-5. **展示当前进度**
-
-   展示：
-   - 所用 schema
-   - 进度：「N/M 个任务已完成」
-   - 剩余任务概览
-   - CLI 返回的动态说明
-
-6. **实现任务（循环直至完成或阻塞）**
-
-   对每个待办任务：
-   - 说明正在处理哪一项
-   - 完成所需代码改动
-   - 保持改动最小、聚焦
-   - 在标记完成前收集依据：
-     - `Requirement IDs`：本实现满足哪些需求
-     - `Planned Files` 与实际改动文件：若有合理偏差需注明
-     - `Validation Case IDs`：为验证行为执行了哪些用例
-     - `Validation Result`：通过/失败及简要断言摘要
-   - 仅在依据已记录且验证通过后，在任务文件中将 `- [ ]` 改为 `- [x]`
-   - **Git**：本待办对应的实现与任务勾选等改动，**单独提交一个 commit**（一项待办 = 一个 commit；不要把多项待办混在同一 commit）。提交信息建议包含变更名与任务标识或简述。
-   - 继续下一项
-
-   **暂停条件：**
-   - 任务不清晰 → 依据上下文与已有工件做合理推断并继续；必要时在说明中写明假设，**不反问用户**
-   - 实现暴露设计问题 → 建议更新工件（陈述式说明，不提问）
-   - 遇到错误或阻塞 → 报告原因与可选后续，**不反问用户**
-   - 用户中断
-
-7. **完成或暂停时展示状态**
-
-   展示：
-   - 本会话完成的任务
-   - 总体进度：「N/M 个任务已完成」
-   - 若全部完成：建议归档
-   - 若暂停：说明原因并列出可选后续（陈述式，**不反问用户**）
-
-**实现过程中的输出**
-
-```
-## 正在实施：<change-name>（schema: <schema-name>）
-
-处理任务 3/7：<task description>
-[...实现过程...]
-✓ 任务完成 · commit <short-sha> <subject>
-
-处理任务 4/7：<task description>
-[...实现过程...]
-✓ 任务完成 · commit <short-sha> <subject>
-```
-
-**完成时的输出**
-
-```
-## 实现完成
-
-**变更：** <change-name>
-**Schema：** <schema-name>
-**进度：** 7/7 个任务已完成 ✓
-
-### 本会话已完成
-- [x] Task 1
-- [x] Task 2
-...
-
-（每项待办均已对应独立 commit。）
-
-全部任务完成！可以归档此变更。
-```
-
-**暂停时的输出（遇到问题）**
-
-```
-## 实现已暂停
-
-**变更：** <change-name>
-**Schema：** <schema-name>
-**进度：** 4/7 个任务已完成
-
-### 遇到的问题
-<问题描述>
-
-**可选后续：**
-1. <选项 1>
-2. <选项 2>
-3. <选项 3>
-
-（陈述即可；不要求用户当场作答。）
-```
-
-**约束**
-- 持续执行任务直至完成或阻塞
-- 开始前务必阅读上下文文件（来自 apply 说明输出）
-- 若任务有歧义，先依据上下文与 spec 做合理推断并实现；**不**为澄清而反问用户
-- 若实现暴露问题，暂停并建议更新工件
-- 代码改动保持最小、与每项任务范围一致
-- 未完成需求映射与验证依据前，**不要**将任务勾为完成
-- 若验证失败或缺少依据，保持任务未勾选并明确报告缺口
-- 若任务元数据缺失（Requirement IDs / Planned Files / Validation Case IDs / Done Criteria），在可能的情况下于实现前补全
-- 每完成一项任务并记录依据后，立即更新对应勾选框，并**随即**为该待办单独 `git commit`（一项待办一个 commit）
-- 遇错误或硬阻塞时暂停并说明原因；需求不清时在任务说明中记录假设与风险，**不反问用户**
-- 使用 CLI 输出的 contextFiles，不要假定具体文件名
-
-**与流动工作流的衔接**
-
-本技能支持「对变更执行操作」模型：
-
-- **可随时调用**：不必等所有工件就绪（若已有任务）、可在部分实现之后、可与其他操作穿插
-- **允许更新工件**：若实现暴露设计问题，建议更新工件——不锁阶段，可灵活推进