ai-project-manage-cli 1.0.3 → 1.0.5

package/dist/cli.js.map

@@ -1 +1 @@
-{"version":3,"file":"cli.js","sourceRoot":"","sources":["../src/cli.ts"],"names":[],"mappings":";;;AACA,yCAAoC;AACpC,iDAAkD;AAClD,8CAA2D;AAC3D,oDAAiE;AACjE,kDAA+D;AAC/D,4DAAyE;AACzE,0CAAuD;AACvD,mDAG2B;AAE3B,MAAM,OAAO,GAAG,IAAI,mBAAO,EAAE;KAC1B,IAAI,CAAC,KAAK,CAAC;KACX,WAAW,CAAC,eAAe,CAAC;KAC5B,IAAI,CAAC,WAAW,EAAE,GAAG,EAAE;IACtB,MAAM,IAAI,GAAG,OAAO,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC;IACnC,MAAM,KAAK,GAAG,IAAI,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,CAAC,UAAU,CAAC,GAAG,CAAC,CAAC,CAAC;IACnD,IACE,KAAK,KAAK,QAAQ;QAClB,KAAK,KAAK,OAAO;QACjB,KAAK,KAAK,QAAQ;QAClB,KAAK,KAAK,IAAI,EACd,CAAC;QACD,OAAO;IACT,CAAC;IACD,MAAM,IAAI,GAAG,IAAA,yCAA2B,GAAE,CAAC;IAC3C,IAAI,OAAO,IAAI,IAAI,EAAE,CAAC;QACpB,OAAO,CAAC,KAAK,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC;QAC1B,OAAO,CAAC,KAAK,CAAC,QAAQ,IAAA,+BAAgB,GAAE,EAAE,CAAC,CAAC;QAC5C,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;IAClB,CAAC;IACD,IAAA,qCAAuB,EAAC,IAAI,CAAC,CAAC;AAChC,CAAC,CAAC,CAAC;AAEL,IAAA,+BAAsB,EAAC,OAAO,CAAC,CAAC;AAChC,IAAA,2BAAoB,EAAC,OAAO,CAAC,CAAC;AAC9B,IAAA,iCAAuB,EAAC,OAAO,CAAC,CAAC;AACjC,IAAA,yCAA2B,EAAC,OAAO,CAAC,CAAC;AACrC,IAAA,uBAAkB,EAAC,OAAO,CAAC,CAAC;AAE5B,OAAO,CAAC,UAAU,CAAC,OAAO,CAAC,IAAI,CAAC,CAAC,KAAK,CAAC,CAAC,GAAG,EAAE,EAAE;IAC7C,OAAO,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC;IACnB,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;AAClB,CAAC,CAAC,CAAC"}
+{"version":3,"file":"cli.js","sourceRoot":"","sources":["../src/cli.ts"],"names":[],"mappings":";;;AACA,yCAAoC;AACpC,iDAAkD;AAClD,8CAA2D;AAC3D,oDAAiE;AACjE,kDAA+D;AAC/D,8CAA2D;AAC3D,4DAAyE;AACzE,0CAAuD;AACvD,mDAG2B;AAE3B,MAAM,OAAO,GAAG,IAAI,mBAAO,EAAE;KAC1B,IAAI,CAAC,KAAK,CAAC;KACX,WAAW,CAAC,eAAe,CAAC;KAC5B,IAAI,CAAC,WAAW,EAAE,GAAG,EAAE;IACtB,MAAM,IAAI,GAAG,OAAO,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC;IACnC,MAAM,KAAK,GAAG,IAAI,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,CAAC,UAAU,CAAC,GAAG,CAAC,CAAC,CAAC;IACnD,IACE,KAAK,KAAK,QAAQ;QAClB,KAAK,KAAK,MAAM;QAChB,KAAK,KAAK,OAAO;QACjB,KAAK,KAAK,QAAQ;QAClB,KAAK,KAAK,IAAI,EACd,CAAC;QACD,OAAO;IACT,CAAC;IACD,MAAM,IAAI,GAAG,IAAA,yCAA2B,GAAE,CAAC;IAC3C,IAAI,OAAO,IAAI,IAAI,EAAE,CAAC;QACpB,OAAO,CAAC,KAAK,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC;QAC1B,OAAO,CAAC,KAAK,CAAC,QAAQ,IAAA,+BAAgB,GAAE,EAAE,CAAC,CAAC;QAC5C,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;IAClB,CAAC;IACD,IAAA,qCAAuB,EAAC,IAAI,CAAC,CAAC;AAChC,CAAC,CAAC,CAAC;AAEL,IAAA,+BAAsB,EAAC,OAAO,CAAC,CAAC;AAChC,IAAA,2BAAoB,EAAC,OAAO,CAAC,CAAC;AAC9B,IAAA,2BAAoB,EAAC,OAAO,CAAC,CAAC;AAC9B,IAAA,iCAAuB,EAAC,OAAO,CAAC,CAAC;AACjC,IAAA,yCAA2B,EAAC,OAAO,CAAC,CAAC;AACrC,IAAA,uBAAkB,EAAC,OAAO,CAAC,CAAC;AAE5B,OAAO,CAAC,UAAU,CAAC,OAAO,CAAC,IAAI,CAAC,CAAC,KAAK,CAAC,CAAC,GAAG,EAAE,EAAE;IAC7C,OAAO,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC;IACnB,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;AAClB,CAAC,CAAC,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ai-project-manage-cli",
-  "version": "1.0.3",
+  "version": "1.0.5",
   "private": false,
   "description": "CLI / SDK for AI项目管理",
   "main": "./dist/index.js",
@@ -16,7 +16,8 @@
     }
   },
   "files": [
-    "dist"
+    "dist",
+    "templates"
   ],
   "scripts": {
     "build": "tsc -p tsconfig.json",
@@ -25,13 +26,15 @@
     "apm:logout": "node ./dist/cli.js logout",
     "apm:login": "node ./dist/cli.js login",
     "apm:config:get-base-url": "node ./dist/cli.js config get base-url",
+    "apm:init": "node ./dist/cli.js init",
     "apm:comment:help": "node ./dist/cli.js comment --help",
     "apm:comment:update": "node ./dist/cli.js comment update",
     "apm:comment:process": "node ./dist/cli.js comment process",
     "apm:requirement:help": "node ./dist/cli.js requirement --help",
     "apm:requirement:test-case:import": "node ./dist/cli.js requirement test-case import",
     "apm:requirement:branch:set-status": "node ./dist/cli.js requirement branch set-status",
-    "apm:requirement:defect:set-status": "node ./dist/cli.js requirement defect set-status"
+    "apm:requirement:defect:set-status": "node ./dist/cli.js requirement defect set-status",
+    "apm:requirement:version:content": "node ./dist/cli.js requirement version content"
   },
   "dependencies": {
     "commander": "^13.1.0",

package/templates/skills/apm-auto-dev/SKILL.md

@@ -0,0 +1,137 @@
+---
+name: apm-auto-dev
+description: 按分支 ID、分支名、基准分支、需求 ID、版本序号全自动拉分支、更新分支状态、落盘 PRD、串联 openspec-propose 与 openspec-apply-change、生成 MR 评审说明并推送远程。在用户要求全自动开发、APM 自动交付、或给出上述参数时使用。
+---
+
+# APM 全自动开发（编排技能）
+
+**角色**：主 Agent 只做参数传递、**串行**启动子 Agent、校验上一步产物、失败则停止并汇总；**禁止**在同一对话里自己执行完整 propose+apply 长流程而不用子 Agent。
+
+**输入（必填）**
+
+| 字段 | 说明 |
+|------|------|
+| 分支名称 | 远程已存在、本地可无；检出目标 |
+| 基准分支 | 作为 MR 对比基线（通常由服务端 prompt 直接给出） |
+| 需求文档 ID | `--requirement-id` |
+| 需求版本序号 | `--version-seq`（与界面 v1/v2 一致） |
+| 分支记录 ID | `--branch-id`，用于更新需求分支状态 |
+
+---
+
+## 子 Agent 强制隔离
+
+- 下列步骤 **1～7** 各对应一次 **Task 子 Agent**（或等价：独立子会话），**严格串行**：仅当上一步子 Agent **明确结束**且主 Agent **已校验产物**后，再启动下一步。
+- **禁止**并行启动多个子 Agent 执行本流程中的步骤。
+- 子 Agent 需执行完毕：读 SKILL、跑命令、写文件、回报结构化结果（路径、变更名、成功/失败）。
+
+---
+
+## 步骤 1 — 子 Agent：Git 分支与未提交处理
+
+在仓库根目录执行（仅读写 git，逻辑如下）。
+
+1. `git fetch origin`（确保能拿到远程分支）。
+2. 记 `TARGET=<用户分支名>`，`CURRENT=$(git branch --show-current)`。
+3. 判断是否脏：`git status --porcelain` 非空即为脏。
+4. 若 `CURRENT != TARGET` 且脏 → `git stash push -u -m "apm-auto-dev: wip before checkout ${TARGET}"`，再检出目标分支。
+5. 若 `CURRENT == TARGET` 且脏 → **不 stash**：根据当前 diff 生成提交说明并提交（例如用 `git diff --stat` 与关键文件摘要凑成一句 subject + 可选 body；或 `git commit -am` 等价操作），**不得**无消息提交。
+6. 检出 `TARGET`（本地无则跟踪远程，例如 `git switch -c "$TARGET" "origin/$TARGET"` 或 `git checkout --track "origin/$TARGET"`，以当前 git 版本可用命令为准）。
+7. 若第 4 步曾 stash，检出成功后 **不要** 自动 pop（避免与后续自动化冲突）；在最终结果中提醒用户稍后自行 `git stash pop` 如需取回。
+
+**完成判定**：`git branch --show-current` 等于 `TARGET`；第 4/5 步语义已执行。
+
+---
+
+## 步骤 2 — 子 Agent：拉取需求正文并落盘
+
+1. 执行：
+
+```bash
+apm requirement version content --requirement-id <ID> --version-seq <SEQ>
+```
+
+2. 解析 **stdout** JSON：取版本对象中的 **`content`** 字段（字符串）作为 PRD 正文。
+3. 由正文推导目录名 `<name>`（**kebab-case**）：优先取第一行 Markdown 标题（去 `#`）、否则取首行摘要；小写、空格与下划线改为 `-`，移除非 URL/路径安全字符；过长则截断至约 48 字符。若 `.apm/<name>` 已存在则加后缀 `-2`、`-3`… 直至不冲突。
+4. 创建目录并**覆盖写入**：
+
+`.apm/<name>/prd.md`
+
+5. 将最终采用的 `<name>` 回报主 Agent（后续步骤共用同一目录）。
+
+**完成判定**：`prd.md` 存在且非空；`<name>` 已确定。
+
+---
+
+## 步骤 3 — 子 Agent：更新需求分支状态为开发中
+
+1. 在仓库根目录或任意目录执行（只依赖 apm 配置，不依赖当前 cwd）：确保已通过 `apm login`，并已配置 `base-url`。
+2. 调用 CLI 更新分支状态为“开发中”，命令形如：
+
+```bash
+apm requirement branch set-status --branch-id <BRANCH_ID> --status 开发中
+```
+
+3. 子 Agent 需检查命令退出码，非 0 时读取 stderr，返回失败原因并终止全流程（不要静默继续后续步骤）。
+
+**完成判定**：命令成功返回（退出码 0），且无错误输出。
+
+---
+
+## 步骤 4 — 子 Agent：openspec-propose
+
+1. 读取并遵循项目内技能：`.cursor/skills/openspec-propose/SKILL.md`。
+2. **输入**：仓库内文件路径 **`.apm/<name>/prd.md`**（子 Agent 应用 Read 读全文）；变更名可据 PRD 归纳 kebab-case；**不要**向用户追问。
+3. **输出**：子 Agent 必须回报 **`openspec/changes/<change-name>/` 的绝对或仓库相对路径** 以及 **`<change-name>`**（若与 `<name>` 不同，以 openspec 目录名为准）。
+
+**完成判定**：`openspec status --change "<change-name>"` 无「缺工件」类阻塞；`proposal.md`、`tasks.md` 等应已按该 SKILL 就绪。
+
+---
+
+## 步骤 5 — 子 Agent：openspec-apply-change
+
+1. 读取并遵循：`.cursor/skills/openspec-apply-change/SKILL.md`。
+2. **输入（必须）**：上一步回报的变更目录路径或 **`<change-name>`**（与 openspec-propose 产出一致）；主 Agent 必须将步骤 3 的结构化结果传入本子 Agent。
+3. 按该 SKILL 执行任务直至完成或**硬阻塞**（硬阻塞时停止全流程，汇总原因）。
+
+**完成判定**：该 SKILL 定义的完成/暂停语义达成；代码与任务勾选与仓库状态一致。
+
+---
+
+## 步骤 6 — 子 Agent：MR 评审说明 → change.md
+
+1. 读取并遵循：`.cursor/skills/mr-review-brief/SKILL.md`；模板使用 **`.cursor/skills/mr-review-brief/mr-review-template.md`**（若仓库内另有 `release-checklist` 副本，以实际存在路径为准）。
+2. **对比基准**：使用**必填输入**中的 `baseBranch`。生成前先校验该分支可被 git 识别（本地或远程任一可解析）；不可解析则失败并报错，不再回退读取 `AGENTS.md`。
+3. 只读 git：`git branch --show-current`、`git log ${BASE_BRANCH}..HEAD --oneline`、`git diff ${BASE_BRANCH}..HEAD`（必要时按文件展开），按模板生成完整 Markdown（**不含**模板末尾 HTML 注释块）。
+4. **落盘（强制）**：写入 **`.apm/<name>/change.md`**，与 `prd.md` 同目录；**已存在则覆盖**。
+5. 可在对话中摘要说明已生成，但**文件以 `change.md` 为准**。
+
+**完成判定**：`change.md` 存在且含模板主要章节；`{BASE_BRANCH}` 与所选基准一致。
+
+---
+
+## 步骤 7 — 子 Agent：全量提交并推送
+
+1. `git status`：若有未跟踪或已修改文件，则 `git add -A`。
+2. 若有暂存变更：生成一条概括「全自动交付 + PRD/MR 文档 + OpenSpec 实现」的提交说明（可附 `change-name`、requirement id、version-seq），执行 `git commit`。
+3. **必须** `git push -u origin "<TARGET>"`（或当前分支已设 upstream 则 `git push`）；推送失败则回报 stderr，全流程标记失败。
+
+**完成判定**：推送成功；工作区干净或仅剩用户需自理的 stash 提示。
+
+---
+
+## 主 Agent 汇总输出
+
+用精简 Markdown 汇总：
+
+- 分支名、`.apm/<name>/` 路径、`openspec/changes/<change-name>/`
+- 各子步骤成功/失败
+- 最终 commit SHA（若有）、远程推送结果
+- 若有 stash：提醒用户在其他分支上 `git stash pop` 时注意冲突
+
+---
+
+## 护栏
+
+- 任一步子 Agent 失败：**不要**静默跳过；停止后续步骤，输出失败步骤与可复现命令。
+- 全程**不向用户追问**澄清需求；歧义按 openspec / apply 技能中的「合理假设、不反问」处理。

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

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

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

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

@@ -0,0 +1,127 @@
+---
+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，便于后续审计。
+- 需求与现有变更冲突或同名目录已存在时：按上文规则在文档中说明关系或自动换名，**不要**反问用户。