ai-project-manage-cli 2.0.10 → 2.0.11

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` 中定义的「完成」或「验证」为准（例如健康检查、访问地址、接口返回等）。文档未写成功条件时，以文档列出的最后一步无错误执行完毕为准。