ai-project-manage-cli 2.0.10 → 2.0.12

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/bug-fix/SKILL.md

@@ -1,159 +0,0 @@
----
-name: bug-fix
-description: 基于分支名和缺陷描述执行标准化的缺陷修复流程：先做工作区检查点提交，再切换分支、完成修复、生成发布检查清单、落盘 bugfix 留痕，并提交推送分支；主 Agent 须在最终回复用表格汇总各步骤执行情况。适用于用户明确要求按流程修 bug，或提到修复流程、分支修复、创建 bug-fix 任务等场景。
----
-
-# 缺陷修复流程
-
-## 目的
-
-使用本技能可基于以下输入执行一致的端到端缺陷修复流程：
-- `branchName`：目标分支名
-- `bugDescription`：清晰的缺陷描述与期望行为
-- `defectId`：缺陷 ID（可选；用于调用 CLI 更新缺陷状态）
-
-**主 Agent 收尾（必选）**：在协调子 Agent 完成步骤 1～8 后，**必须在面向用户的最终回复中附上一张 Markdown 表格**，逐行对应每个步骤，汇总**执行状态**（如：已完成 / 已跳过 / 失败）与**简要说明**（关键结果、commit、失败原因等），便于审阅者核对流程是否闭环。
-
-## 输入
-
-收集并确认：
-- `branchName`
-- `bugDescription`
-- `defectId`（可选）
-
-若 `branchName` 或 `bugDescription` 缺失，需先向用户补充确认后再继续。
-
-## 执行步骤
-
-严格按以下顺序执行，且每一步都必须由子 Agent 独立执行并回传结果。
-
-### 步骤 1 — 子 Agent：分支切换与未提交处理
-
-1. 执行 `git fetch origin`，确保可获取最新远程分支信息。
-2. 记录 `TARGET=<branchName>` 与当前分支 `CURRENT`，并检查工作区是否有未提交变更（staged/unstaged/untracked）。
-3. 若 `CURRENT != TARGET` 且工作区有变更：先执行 `git stash push -u` 保存现场，再切换到 `TARGET`。
-4. 若 `CURRENT == TARGET` 且工作区有变更：不要 stash，直接将当前改动作为“修复前检查点”提交，提交文案需明确说明这是 bugfix 前的检查点（例如：`chore: checkpoint before bugfix on <branchName>`）。
-5. 切换到 `TARGET`：本地分支不存在时，从远程跟踪分支创建并切换。
-6. 若在第 3 步执行过 stash，切换成功后不要自动 `stash pop`，避免与后续修复流程冲突。
-7. 最终必须确认当前分支与 `branchName` 完全一致。
-
-**完成判定**：当前分支等于 `branchName`，且步骤 3/4 的语义已正确执行（按分支状态选择了 stash 或 checkpoint commit）。
-
-### 步骤 2 — 子 Agent：按缺陷描述修改代码
-
-1. 基于 `bugDescription` 复现并分析缺陷。
-2. 实施最小化、针对性的修复。
-3. 运行相关验证（tests/lint/build 或最接近的校验命令）。
-4. 若验证失败，持续迭代直至通过；如遇阻塞，输出具体报错信息并说明阻塞点。
-
-**完成判定**：修复代码已落地，且验证通过；或明确输出可复现的阻塞错误与原因。
-
-### 步骤 3 — 子 Agent：更新分支对应的变更说明文件
-
-代码改动稳定后，必须调用技能 `mr-review-brief` 生成评审说明内容；随后定位当前分支产出的 workitem 名称 `<name>`，并处理 `.apm/workitems/<name>/change.md`：
-- 若文件不存在：创建该文件并写入本次变更说明。
-- 若文件已存在：在原文件上更新内容，反映本次最新变更。
-
-变更说明应包含：
-- 功能变更摘要
-- 自检项
-- 发布备注/注意事项
-
-注意：`<name>` 必须取当前分支对应且由本分支产出的 workitem，禁止误用其他分支的 `<name>`。
-
-**完成判定**：`.apm/workitems/<name>/change.md` 已创建或更新，且内容包含功能变更摘要、自检项、发布备注/注意事项。
-
-### 步骤 4 — 子 Agent：提交修复改动（不推送）
-
-1. 先执行 `git status`；若存在未跟踪或已修改文件，执行 `git add -A`。
-2. 若存在暂存变更，则执行 `git commit`；commit 文案必须明确描述“本次改了什么”，必要时补充变更原因。
-3. 记录本次 bugfix 提交的 `commit id`（例如 `git rev-parse --short HEAD`），供下一步留痕文件使用。
-
-**完成判定**：本次 bugfix commit 已创建成功，且已拿到对应 `commit id`。
-
-### 步骤 5 — 子 Agent：落盘 bugfix 留痕文档
-
-在完成步骤 4 后，定位当前分支产出的 workitem 名称 `<name>`，在 `.apm/workitems/<name>/` 下写入本次留痕文档：
-
-1. 文件名规则：`bugfixN.md`，其中 `N` 为递增序号（`1/2/3/...`）。
-   - 若目录中无 `bugfix*.md`，创建 `bugfix1.md`。
-   - 若已有 `bugfix1.md`、`bugfix2.md`...，本次创建下一个序号文件（如 `bugfix3.md`）。
-2. 文档内容必须包含以下结构（按顺序）：
-   - 一级标题：`# <commit id>`（标题直接使用步骤 4 产出的 commit id）
-   - `## Bug 描述`：写入 `bugDescription` 的关键信息
-   - `## 解决方案`：说明本次修复的实现方案
-   - `## 原因复盘`：说明问题根因、为何发生、后续如何避免
-3. 该文件用于沉淀每次 bug 修复记录，禁止覆盖历史 `bugfixN.md`。
-4. 写入内容时使用以下固定模板（将占位符替换为实际内容）：
-
-```markdown
-# <commit id>
-
-## Bug 描述
-<一句话描述现象 + 影响范围>
-
-## 解决方案
-- <改动点 1>
-- <改动点 2>
-
-## 原因复盘
-- 根因：<根因说明>
-- 触发条件：<在什么条件下触发>
-- 防再发措施：<测试/校验/流程上的防护>
-```
-
-注意：`<name>` 必须取当前分支对应且由本分支产出的 workitem，禁止误用其他分支的 `<name>`。
-
-**完成判定**：`.apm/workitems/<name>/bugfixN.md` 创建成功，且内容包含 commit id、Bug 描述、解决方案、原因复盘四部分。
-
-### 步骤 6 — 子 Agent：推送分支提交
-
-1. 必须将 `branchName` 推送到远程：优先使用 `git push -u origin "<branchName>"`；若当前分支已配置 upstream，可直接 `git push`。
-2. 若推送失败，输出失败原因并将流程标记为失败，不得宣称完成。
-
-最低完成标准：
-- 推送成功
-- 工作区干净（或仅保留需用户自行处理的 stash 提示）
-
-**完成判定**：推送成功，且满足最低完成标准。
-
-### 步骤 7 — 子 Agent：可选调用 CLI 更新缺陷状态为已解决
-
-1. 仅当输入包含 `defectId` 时才执行本步骤；若未提供 `defectId`，则跳过并继续完成流程。
-2. 在仓库根目录调用 CLI，将当前缺陷状态更新为 `RESOLVED`：
-
-```bash
-apm requirement defect set-status --defect-id <defectId> --status RESOLVED
-```
-
-3. 若命令执行失败，输出 stderr 并将流程标记为失败。
-
-**完成判定**：未提供 `defectId` 时本步骤被正确跳过；提供 `defectId` 时 CLI 返回成功且缺陷状态为 `RESOLVED`。
-
-### 步骤 8 — 子 Agent：调用 `test-env-release` 部署测试环境
-
-1. 本步骤必须在“全部代码提交完成”后执行（至少已完成步骤 4；若有推送要求则需先完成步骤 6）。
-2. 调用技能 `test-env-release`，按项目根目录 `.apm/deploy/README.md` 部署测试环境。
-3. 若部署失败，输出失败原因并将流程标记为失败，不得宣称 bug-fix 全流程完成。
-
-**完成判定**：`test-env-release` 执行成功，测试环境部署完成。
-
-### 汇总表格式（主 Agent 最终输出）
-
-主 Agent 在流程结束时的表格应至少包含以下列，行数覆盖步骤 1～8（步骤 7 未提供 `defectId` 时可为「已跳过」）：
-
-| 步骤 | 内容概要 | 状态 | 说明 |
-|------|----------|------|------|
-| 1 | 分支切换与未提交处理 | 已完成 | 例：当前分支 `feat/xxx`，已 checkpoint / stash |
-| 2 | 按缺陷描述修改代码 | 已完成 | 例：验证通过（lint/test） |
-| … | … | … | … |
-
-状态列建议统一用语：`已完成`、`已跳过`（并写明跳过原因）、`失败`（并附报错或阻塞点）。
-
-## 约束
-
-- 主 Agent 交付本流程结果时，应以「步骤汇总表」为主、文字为辅；禁止仅用零散叙述代替逐步状态说明。
-- 存在未提交变更时，禁止跳过步骤 1。
-- 当前分支错误时，禁止继续后续步骤。
-- 步骤 8 完成前，不得宣称完成。
-- 修复必须保持最小改动，并与 `bugDescription` 保持一致。

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，不要假定具体文件名
-
-**与流动工作流的衔接**
-
-本技能支持「对变更执行操作」模型：
-
-- **可随时调用**：不必等所有工件就绪（若已有任务）、可在部分实现之后、可与其他操作穿插
-- **允许更新工件**：若实现暴露设计问题，建议更新工件——不锁阶段，可灵活推进

package/templates/skills/openspec-propose/SKILL.md

@@ -1,127 +0,0 @@
----
-name: openspec-propose
-description: 以明确的需求文档为输入，一步生成 OpenSpec 变更工件（proposal/design/tasks/specs）。在用户只需要规格与实现规划、不需要手工测试用例时使用。
-license: MIT
-compatibility: 需要 openspec CLI。
-metadata:
-  author: openspec
-  version: "1.1"
-  generatedBy: "1.2.0"
----
-
-提出新变更——在**需求文档**基础上创建变更并生成 OpenSpec 工件。
-
-范围边界：
-- 本技能仅用于规格/规划类工件（`proposal.md`、`design.md`、`tasks.md`、specs）。
-
-将创建包含以下内容的变更：
-- proposal.md（做什么、为什么）
-- design.md（怎么做）
-- tasks.md（实现步骤）
-
----
-
-**输入（必须满足）**
-
-1. **明确的需求文档**——二选一或同时提供：
-   - 文档**正文**（粘贴到对话中），或
-   - 仓库内**文件路径**（由你读取该文件）。
-2. **变更名**（kebab-case）——可选；若未给出，由你从需求文档中归纳 kebab-case 名称，**不要**为命名向用户追问。
-
-**不满足时不继续**：仅有模糊想法、没有可引用的需求正文/文件时，说明本技能需要「可对照的需求文档」，请用户先整理需求或指明文档路径后再触发。
-
----
-
-**执行流程**
-
-### 1. 锚定需求与变更名
-
-- 若给的是路径：用 Read 读取全文，确认可读、无截断。
-- 通读需求文档，标记：目标用户/场景、功能范围、非目标、约束、验收口径。文档未写明的部分：**不要**向用户追问；在 `proposal.md` / `design.md` 中写明合理**假设**，或列为**已知缺口/风险/待后续补充**，并在任务中体现需实现侧拍板的内容。
-- 确定或推导变更目录名 `<name>`（kebab-case）。若与已有 `openspec/changes/<name>/` 冲突：在 `proposal.md` 中说明与既有变更的关系；若需新建目录则自动采用不冲突名称（例如在原名后加 `-2`、`-extend` 等），**不要**为此反问用户。
-
-### 2. 创建变更脚手架
-
-```bash
-openspec new change "<name>"
-```
-
-会在 `openspec/changes/<name>/` 下生成带 `.openspec.yaml` 的变更脚手架。
-
-### 3. 获取工件构建顺序
-
-```bash
-openspec status --change "<name>" --json
-```
-
-解析 JSON：
-
-- `applyRequires`：实现前需完成的工件 ID 列表（例如 `["tasks"]`）
-- `artifacts`：所有工件及其状态与依赖
-
-### 4. 按依赖顺序生成工件（需求文档为唯一事实来源）
-
-使用 **TodoWrite** 跟踪各工件进度。按依赖顺序遍历（先处理无待处理依赖的工件）。
-
-对每一个依赖已满足的 `ready` 工件：
-
-a. 获取该工件的生成说明：
-
-```bash
-openspec instructions <artifact-id> --change "<name>" --json
-```
-
-说明 JSON 含：`context`、`rules`、`template`、`instruction`、`outputPath`、`dependencies`（**不要**把 `context`/`rules` 写入输出文件）。
-
-b. 读取已完成的依赖文件；**撰写正文时严格以需求文档为准**，将需求中的条目映射到 `template` 各节，避免臆造未在需求中出现的范围。
-
-c. 按 `template` 结构写入 `outputPath`。创建 `tasks` 时，每项任务须含可追溯元数据：
-
-- `Requirement IDs`：对应规格中的需求 ID
-- `Planned Files`：预期改动的文件路径
-- `Validation Case IDs`：验证用例 ID（若有）
-- `Done Criteria`：可观察的完成标准
-
-d. 简短提示：「已创建 <artifact-id>」
-
-e. 每完成一个工件后重新执行：
-
-```bash
-openspec status --change "<name>" --json
-```
-
-直到 `applyRequires` 中所有工件在 `artifacts` 里均为 `status: "done"`。
-
-### 5. 展示最终状态
-
-```bash
-openspec status --change "<name>"
-```
-
----
-
-**输出**
-
-完成所有工件后汇总：
-
-- 变更名称与路径
-- 已创建工件列表及简要说明
-- 说明需求文档如何反映在各工件中（一两句即可）
-- 就绪说明：「所有工件已创建！可以开始实现。」
-- 提示：「执行 `/opsx:apply` 或让我来实现，即可开始处理任务。」
-
----
-
-**工件编写指引**
-
-- 各工件类型遵循 `openspec instructions` 返回的 `instruction` 与 `template`。
-- **需求文档**是范围与验收的权威来源；`context`/`rules` 是给你的约束，**不得**写入输出文件。
-- 创建新工件前先读依赖工件，保持与已写规格一致。
-- 实现细节优先落在 `tasks.md`：spec 写行为与需求，task 写可追溯的实现与验证映射。
-
-**护栏**
-
-- 按模式中 `apply.requires` 创建**全部**必需工件。
-- 每写入一个工件后确认文件存在，再进入下一个。
-- 对任务项保留 Requirement IDs、Planned Files、Validation Case IDs、Done Criteria，便于后续审计。
-- 需求与现有变更冲突或同名目录已存在时：按上文规则在文档中说明关系或自动换名，**不要**反问用户。

package/templates/skills/test-env-release/SKILL.md

@@ -1,31 +0,0 @@
----
-name: test-env-release
-description: 部署测试环境。必须先阅读项目根目录下的 `.apm/deploy/README.md` 并按文档执行（文档不存在则终止，不猜测命令）。Use when 用户提到「部署测试环境」「测试环境部署」「发布测试环境」等与测试环境部署相关诉求。
----
-
-# 部署测试环境
-
-## 目标
-
-在目标项目根目录完成一次**可复现**的测试环境部署。所有具体命令、前置条件、校验方式**以项目内文档为准**，本技能不替代该文档。
-
-## 唯一权威：`.apm/deploy/README.md`
-
-1. **执行任何部署命令之前**，必须先使用 Read 工具阅读**项目根目录**下的：
-
-   `.apm/deploy/README.md`
-
-2. **若该文件不存在或无法读取**：立即终止，明确告知用户需在项目根目录补充 `.apm/deploy/README.md` 部署说明；**不要**用 README、package.json 或其它文件猜测部署方式。
-
-3. **严格按文档步骤执行**：文档中写明的命令、目录、环境变量、顺序即为执行依据；文档未提及的操作不要自行发明。
-
-4. 若文档要求先构建再发布/上传等：仅在文档允许的前提下，再参考文档中指向的其它路径（例如某子目录 README）；仍**不得**绕过 `.apm/deploy/README.md` 中已写明的流程。
-
-## 失败处理
-
-- 文档缺失或步骤无法执行：终止并说明缺少什么或哪一步失败。
-- 某一步命令非 0 退出：按文档是否有「失败时」说明处理；若无，则终止并输出错误信息，不静默重试无关命令。
-
-## 成功判定
-
-以 `.apm/deploy/README.md` 中定义的「完成」或「验证」为准（例如健康检查、访问地址、接口返回等）。文档未写成功条件时，以文档列出的最后一步无错误执行完毕为准。