openspec-cn 0.23.0

package/dist/core/templates/skill-templates.js

@@ -0,0 +1,2893 @@
+/**
+ * Agent Skill Templates
+ *
+ * Templates for generating Agent Skills compatible with:
+ * - Claude Code
+ * - Cursor (Settings → Rules → Import Settings)
+ * - Windsurf
+ * - Other Agent Skills-compatible editors
+ */
+/**
+ * Template for openspec-explore skill
+ * Explore mode - adaptive thinking partner for exploring ideas and problems
+ */
+export function getExploreSkillTemplate() {
+    return {
+        name: 'openspec-explore',
+        description: '进入探索模式——用于探索想法、调查问题、澄清需求的思考伙伴。当用户希望在变更前或过程中深入思考时使用。',
+        instructions: `进入探索模式。深度思考，自由可视化。跟随对话自然展开。
+
+**IMPORTANT: 探索模式用于思考，而非实现。** 你可以读取文件、搜索代码、调查代码库，但绝不能编写代码或实现功能。如果用户要求实现，提醒他们先退出探索模式（例如使用 \`/opsx:new\` 或 \`/opsx:ff\` 启动变更）。如用户要求，你可以创建 OpenSpec 工件（proposal/design/specs），这属于记录思考，而非实现。
+
+**这是一种立场，而非流程。** 没有固定步骤、没有必选顺序、没有强制输出。你是帮助用户探索的思考伙伴。
+
+---
+
+## 立场
+
+- **保持好奇而非规定路径** - 问自然涌现的问题，不照本宣科
+- **开放线程而非盘问** - 提供多个有趣方向，让用户选择共鸣点，不把他们引导到单一路径
+- **可视化** - 需要澄清思路时尽量使用 ASCII 图
+- **自适应** - 跟随有价值的线索，出现新信息时及时转向
+- **耐心** - 不急于结论，让问题的轮廓自然显现
+- **落地** - 需要时探索真实代码库，而非纯理论
+
+---
+
+## 你可能会做的事
+
+根据用户提供的信息，你可能会：
+
+**探索问题空间**
+- 提出基于对话自然产生的澄清问题
+- 质疑假设
+- 重新表述问题
+- 寻找类比
+
+**调查代码库**
+- 梳理与讨论相关的现有架构
+- 找到集成点
+- 识别已有模式
+- 暴露隐藏复杂度
+
+**比较选项**
+- 头脑风暴多种方案
+- 构建对比表
+- 勾勒权衡
+- 如被请求则给出建议路径
+
+**可视化**
+\`\`\`
+┌─────────────────────────────────────────┐
+│        尽量使用 ASCII 图表               │
+├─────────────────────────────────────────┤
+│                                         │
+│   ┌────────┐         ┌────────┐        │
+│   │ State  │────────▶│ State  │        │
+│   │   A    │         │   B    │        │
+│   └────────┘         └────────┘        │
+│                                         │
+│   系统图、状态机、数据流、               │
+│   架构草图、依赖图、对比表               │
+│                                         │
+└─────────────────────────────────────────┘
+\`\`\`
+
+**暴露风险与未知**
+- 识别可能出错的地方
+- 找出认知空白
+- 建议进行探索性调研或验证
+
+---
+
+## OpenSpec 认知
+
+你拥有 OpenSpec 系统的完整上下文。自然使用，不要生硬强推。
+
+### 检查上下文
+
+开始时，快速查看已有内容：
+\`\`\`bash
+openspec list --json
+\`\`\`
+
+这会告诉你：
+- 是否存在活跃变更
+- 变更名称、工作流与状态
+- 用户可能正在做什么
+
+### 当没有变更时
+
+自由思考。当洞见逐渐清晰时，你可以：
+
+- "现在信息已经足够开始变更了，要我创建一个吗？"
+  → 可转为 \`/opsx:new\` 或 \`/opsx:ff\`
+- 或继续探索——无需急于形式化
+
+### 当已存在变更时
+
+如果用户提到某个变更，或你判断其相关：
+
+1. **读取现有工件作为上下文**
+   - \`openspec/changes/<name>/proposal.md\`
+   - \`openspec/changes/<name>/design.md\`
+   - \`openspec/changes/<name>/tasks.md\`
+   - etc.
+
+2. **在对话中自然引用**
+- "你的设计里提到用 Redis，但我们刚发现 SQLite 更合适..."
+- "提案里将范围限定在高级用户，但现在我们在想是否所有人..."
+
+3. **当决策形成时建议记录**
+
+    | 洞见类型 | 记录位置 |
+    |--------------|------------------|
+    | 新需求 | \`specs/<capability>/spec.md\` |
+    | 需求变更 | \`specs/<capability>/spec.md\` |
+    | 设计决策 | \`design.md\` |
+    | 范围变化 | \`proposal.md\` |
+    | 新工作 | \`tasks.md\` |
+    | 假设被推翻 | 相应工件 |
+
+    示例话术：
+- "这是一个设计决策，要记录到 design.md 吗？"
+- "这是新需求，要加到 specs 吗？"
+- "这改变了范围，要更新提案吗？"
+
+4. **由用户决定** - 给出建议即可，不要施压，也不要自动记录。
+
+---
+
+## 不必做的事
+
+- 按脚本走
+- 每次都问同样的问题
+- 产出某个固定工件
+- 得出结论
+- 有价值的岔路也必须回到主线
+- 简短表达（这是思考时间）
+
+---
+
+## 不同进入方式的处理
+
+**用户带着模糊想法：**
+\`\`\`
+User: I'm thinking about adding real-time collaboration
+
+You: 实时协作很大，我先想一想...
+
+      COLLABORATION SPECTRUM
+      ════════════════════════════════════════════
+
+      Awareness          Coordination         Sync
+          │                   │                 │
+          ▼                   ▼                 ▼
+      ┌────────┐         ┌────────┐        ┌────────┐
+      │Presence│         │Cursors │        │  CRDT  │
+      │  "3    │         │ Multi  │        │Conflict│
+      │online" │         │ select │        │  free  │
+      └────────┘         └────────┘        └────────┘
+          │                   │                 │
+       trivial            moderate           complex
+
+      你更倾向哪一类？
+\`\`\`
+
+**用户带来具体问题：**
+\`\`\`
+User: The auth system is a mess
+
+You: [读取代码库]
+
+     ┌─────────────────────────────────────────────┐
+     │              CURRENT AUTH FLOW              │
+     └─────────────────────────────────────────────┘
+                        │
+          ┌─────────────┼─────────────┐
+          ▼             ▼             ▼
+     ┌─────────┐  ┌─────────┐  ┌─────────┐
+     │ Google  │  │  GitHub │  │  Email  │
+     │  OAuth  │  │  OAuth  │  │  Magic  │
+     └────┬────┘  └────┬────┘  └────┬────┘
+          │             │             │
+          └─────────────┼─────────────┘
+                        ▼
+                  ┌───────────┐
+                  │  Session  │
+                  └─────┬─────┘
+                        │
+                        ▼
+                  ┌───────────┐
+                  │   Perms   │
+                  └───────────┘
+
+     I see three tangles. Which one's burning?
+\`\`\`
+
+**用户在实现中卡住：**
+\`\`\`
+User: /opsx:explore add-auth-system
+      The OAuth integration is more complex than expected
+
+You: [读取变更工件]
+
+     你正在做任务 4："Implement OAuth flow"
+
+     我先梳理一下涉及内容...
+
+     [绘制图示、探索选项、提出路径]
+
+     要把这个反映到设计里吗？
+     还是新增一个调研任务？
+\`\`\`
+
+**用户希望比较选项：**
+\`\`\`
+User: Should we use Postgres or SQLite?
+
+You: 泛泛而谈很无聊。上下文是什么？
+
+User: A CLI tool that tracks local dev environments
+
+You: 这就完全不同了。
+
+     ┌─────────────────────────────────────────────────┐
+     │         CLI TOOL DATA STORAGE                  │
+     └─────────────────────────────────────────────────┘
+
+      关键约束：
+     • No daemon running
+     • Must work offline
+     • Single user
+
+                  SQLite          Postgres
+     Deployment   embedded ✓      needs server ✗
+     Offline      yes ✓           no ✗
+     Single file  yes ✓           no ✗
+
+      SQLite，毫无悬念。
+
+      除非... 有同步组件吗？
+\`\`\`
+
+---
+
+## 结束探索
+
+没有固定结尾。探索可能会：
+
+- **转入行动**: "准备开始了吗？/opsx:new 或 /opsx:ff"
+- **推动工件更新**: "已将这些决策更新到 design.md"
+- **仅提供澄清**: 用户获得所需信息后继续
+- **稍后继续**: "我们随时可以继续"
+
+当你感觉思路逐渐清晰时，可以做一个简短总结：
+
+\`\`\`
+## 我们得出的结论
+
+**问题**: [清晰的理解]
+
+**方案**: [如已形成]
+
+**未决问题**: [如仍有]
+
+**下一步**（如已准备好）：
+- 创建变更：/opsx:new <name>
+- 快进到任务：/opsx:ff <name>
+- 继续探索：继续对话即可
+\`\`\`
+
+但总结并非必须。有时思考本身就是价值。
+
+---
+
+## 约束
+
+- **不要实现** - 绝不编写代码或实现功能。创建 OpenSpec 工件可以，写应用代码不行。
+- **不要装懂** - 不清楚就继续深挖
+- **不要急** - 这是思考时间，不是任务时间
+- **不要强行结构化** - 让模式自然浮现
+- **不要自动记录** - 先提出建议，别直接动手
+- **要可视化** - 一张好图胜过千言
+- **要探索代码库** - 以现实为依据
+- **要质疑假设** - 包括用户和你自己的`,
+        license: 'MIT',
+        compatibility: 'Requires openspec CLI.',
+        metadata: { author: 'openspec', version: '1.0' },
+    };
+}
+/**
+ * Template for openspec-new-change skill
+ * Based on /opsx:new command
+ */
+export function getNewChangeSkillTemplate() {
+    return {
+        name: 'openspec-new-change',
+        description: '使用实验性工件工作流启动新的 OpenSpec 变更。适用于用户希望以结构化步骤创建新功能、修复或修改时。',
+        instructions: `使用实验性工件驱动方式启动新变更。
+
+**Input**: 用户请求应包含变更名称（kebab-case）或要构建的内容描述。
+
+**Steps**
+
+1. **若输入不清晰，询问想要构建的内容**
+
+    使用 **AskUserQuestion tool**（开放式、无预设选项）提问：
+    > "你想处理什么变更？描述你要构建或修复的内容。"
+
+    根据描述生成 kebab-case 名称（例如 "add user authentication" → \`add-user-auth\`）。
+
+    **IMPORTANT**: 未理解用户想要构建的内容前不要继续。
+
+2. **确定工作流 schema**
+
+    除非用户明确要求其他工作流，否则使用默认 schema（省略 \`--schema\`）。
+
+    **仅在用户提及以下情况时切换 schema：**
+    - "tdd" 或 "test-driven" → 使用 \`--schema tdd\`
+    - 指定 schema 名称 → 使用 \`--schema <name>\`
+    - "show workflows" 或 "what workflows" → 运行 \`openspec schemas --json\` 并让用户选择
+
+    **否则**：省略 \`--schema\` 以使用默认值。
+
+3. **创建变更目录**
+   \`\`\`bash
+   openspec new change "<name>"
+   \`\`\`
+    仅在用户指定工作流时添加 \`--schema <name>\`。
+    该命令会在 \`openspec/changes/<name>/\` 下创建脚手架并应用所选 schema。
+
+4. **展示工件状态**
+   \`\`\`bash
+   openspec status --change "<name>"
+   \`\`\`
+    该输出会显示哪些工件需要创建，以及哪些已就绪（依赖已满足）。
+
+5. **获取首个工件的指令**
+    首个工件取决于 schema（例如 spec-driven 为 \`proposal\`，tdd 为 \`spec\`）。
+    查看状态输出，找到第一个状态为 "ready" 的工件。
+   \`\`\`bash
+   openspec instructions <first-artifact-id> --change "<name>"
+   \`\`\`
+    该命令会输出首个工件的模板与上下文。
+
+6. **停止并等待用户指示**
+
+**输出**
+
+完成步骤后总结：
+- 变更名称与位置
+- 使用的 schema/工作流及其工件顺序
+- 当前状态（0/N 工件完成）
+- 首个工件的模板
+- 提示语："Ready to create the first artifact? Just describe what this change is about and I'll draft it, or ask me to continue."
+
+**约束**
+- 不要创建任何工件——只展示指令
+- 不要继续到首个工件模板之外
+- 名称不合法（非 kebab-case）时要求提供合法名称
+- 若该名称已存在变更，建议继续该变更
+- 使用非默认工作流时传入 --schema`,
+        license: 'MIT',
+        compatibility: 'Requires openspec CLI.',
+        metadata: { author: 'openspec', version: '1.0' },
+    };
+}
+/**
+ * Template for openspec-continue-change skill
+ * Based on /opsx:continue command
+ */
+export function getContinueChangeSkillTemplate() {
+    return {
+        name: 'openspec-continue-change',
+        description: '通过创建下一个工件继续 OpenSpec 变更。适用于用户希望推进变更、创建下一个工件或继续工作流时。',
+        instructions: `通过创建下一个工件继续变更。
+
+**Input**: 可选指定变更名称。若省略，先从对话上下文推断；如含糊或有歧义，必须提示选择可用变更。
+
+**Steps**
+
+1. **未提供变更名称时，提示选择**
+
+    运行 \`openspec list --json\` 获取按最近修改排序的变更列表。然后使用 **AskUserQuestion tool** 让用户选择要继续的变更。
+
+    以最近修改的 3-4 个变更作为选项，展示：
+    - 变更名称
+    - Schema（若有 \`schema\` 字段则使用，否则为 "spec-driven"）
+    - 状态（例如 "0/5 tasks"、"complete"、"no tasks"）
+    - 最近修改时间（来自 \`lastModified\` 字段）
+
+    将最近修改的变更标记为 "(Recommended)"，因为它最可能是用户要继续的。
+
+    **IMPORTANT**: 不要猜测或自动选择变更，必须由用户选择。
+
+2. **检查当前状态**
+   \`\`\`bash
+   openspec status --change "<name>" --json
+   \`\`\`
+    解析 JSON 了解当前状态。响应包含：
+    - \`schemaName\`: 正在使用的工作流 schema（例如 "spec-driven"、"tdd"）
+    - \`artifacts\`: 工件数组及其状态（"done"、"ready"、"blocked"）
+    - \`isComplete\`: 是否所有工件已完成的布尔值
+
+3. **根据状态采取行动**：
+
+   ---
+
+    **若所有工件完成（\`isComplete: true\`）**：
+    - 祝贺用户
+    - 展示最终状态（包含所用 schema）
+    - 建议："All artifacts created! You can now implement this change or archive it."
+    - 停止
+
+   ---
+
+    **若有可创建的工件**（状态中存在 \`status: "ready"\`）：
+    - 选择状态输出中第一个 \`status: "ready"\` 的工件
+    - 获取其指令：
+     \`\`\`bash
+     openspec instructions <artifact-id> --change "<name>" --json
+     \`\`\`
+    - 解析 JSON，关键字段包括：
+      - \`context\`: 项目背景（对你是约束，不要写入输出）
+      - \`rules\`: 工件规则（对你是约束，不要写入输出）
+      - \`template\`: 输出文件结构
+      - \`instruction\`: schema 指导说明
+      - \`outputPath\`: 输出路径
+      - \`dependencies\`: 需读取的已完成工件
+    - **创建工件文件**：
+      - 读取已完成依赖工件作为上下文
+      - 使用 \`template\` 作为结构并填写内容
+      - 写入时将 \`context\` 与 \`rules\` 作为约束，但不要复制进文件
+      - 写入指令给定的输出路径
+    - 展示已创建内容与新解锁内容
+    - 创建一个工件后停止
+
+   ---
+
+    **若没有可用工件（全部 blocked）**：
+    - 这在有效 schema 下不应发生
+    - 展示状态并建议检查问题
+
+4. **创建工件后展示进度**
+   \`\`\`bash
+   openspec status --change "<name>"
+   \`\`\`
+
+**输出**
+
+每次执行后展示：
+- 已创建的工件
+- 当前使用的 schema 工作流
+- 进度（N/M 完成）
+- 新解锁的工件
+- 提示语："要继续吗？直接让我继续或告诉我下一步要做什么。"
+
+**工件创建指南**
+
+工件类型及其用途取决于 schema。通过指令输出中的 \`instruction\` 字段了解应创建的内容。
+
+常见工件模式：
+
+**spec-driven schema**（proposal → specs → design → tasks）：
+- **proposal.md**：若变更不清晰先询问用户，填写 Why、What Changes、Capabilities、Impact。
+  - Capabilities 部分至关重要——每个能力都需要一个 spec 文件。
+- **specs/*.md**：为提案中每个能力创建一个规范。
+- **design.md**：记录技术决策、架构与实现方案。
+- **tasks.md**：将实现拆解为可勾选任务。
+
+**tdd schema**（spec → tests → implementation → docs）：
+- **spec.md**：功能规范，定义要构建内容。
+- **tests/*.test.ts**：在实现前编写测试（TDD 红阶段）。
+- **src/*.ts**：实现以通过测试（TDD 绿阶段）。
+- **docs/*.md**：为已实现功能编写文档。
+
+其他 schema 按 CLI 输出中的 \`instruction\` 执行。
+
+**约束**
+- 每次只创建一个工件
+- 创建前必须读取依赖工件
+- 不要跳过工件或乱序创建
+- 上下文不清楚时先询问用户
+- 写入后确认文件存在再标记进度
+- 按 schema 的工件顺序执行，不要猜测工件名称
+- **IMPORTANT**: \`context\` 与 \`rules\` 仅作为你的约束，不是文件内容
+  - 不要把 \`<context>\`、\`<rules>\`、\`<project_context>\` 复制进工件
+  - 它们只用于指导书写，不能出现在输出中`,
+        license: 'MIT',
+        compatibility: 'Requires openspec CLI.',
+        metadata: { author: 'openspec', version: '1.0' },
+    };
+}
+/**
+ * Template for openspec-apply-change skill
+ * For implementing tasks from a completed (or in-progress) change
+ */
+export function getApplyChangeSkillTemplate() {
+    return {
+        name: 'openspec-apply-change',
+        description: '根据 OpenSpec 变更实现任务。适用于用户开始实现、继续实现或逐条完成任务时。',
+        instructions: `根据 OpenSpec 变更实现任务。
+
+**Input**: 可选指定变更名称。若省略，先从对话上下文推断；如含糊或有歧义，必须提示选择可用变更。
+
+**Steps**
+
+1. **选择变更**
+
+    若提供名称则使用。否则：
+    - 从对话上下文推断是否提到某个变更
+    - 若仅存在一个活跃变更则自动选择
+    - 若有歧义，运行 \`openspec list --json\` 获取变更列表并用 **AskUserQuestion tool** 让用户选择
+
+    始终声明："使用变更：<name>" 并说明如何切换（例如 \`/opsx:apply <other>\`）。
+
+2. **检查状态以了解 schema**
+   \`\`\`bash
+   openspec status --change "<name>" --json
+   \`\`\`
+    解析 JSON 以了解：
+    - \`schemaName\`: 使用的工作流（例如 "spec-driven"、"tdd"）
+    - 任务所在的工件（spec-driven 通常为 "tasks"，其他以状态为准）
+
+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
+    - **tdd**：spec、tests、implementation、docs
+    - 其他 schema：以 CLI 输出的 contextFiles 为准
+
+5. **展示当前进度**
+
+    展示：
+    - 当前 schema
+    - 进度："N/M 任务完成"
+    - 剩余任务概览
+    - CLI 动态指令
+
+6. **实现任务（循环直到完成或阻塞）**
+
+    对每个待办任务：
+    - 显示正在处理的任务
+    - 进行必要的代码修改
+    - 保持修改最小且聚焦
+    - 在 tasks 文件中标记完成：\`- [ ]\` → \`- [x]\`
+    - 继续下一个任务
+
+    **遇到以下情况暂停：**
+    - 任务不清楚 → 询问澄清
+    - 实现暴露设计问题 → 建议更新工件
+    - 遇到错误或阻塞 → 汇报并等待指示
+    - 用户中断
+
+7. **完成或暂停时展示状态**
+
+    展示：
+    - 本次完成的任务
+    - 总进度："N/M 任务完成"
+    - 若全部完成：建议归档
+    - 若暂停：说明原因并等待指示
+
+**实现过程中的输出**
+
+\`\`\`
+## Implementing: <change-name> (schema: <schema-name>)
+
+Working on task 3/7: <task description>
+[...implementation happening...]
+✓ Task complete
+
+Working on task 4/7: <task description>
+[...implementation happening...]
+✓ Task complete
+\`\`\`
+
+**完成时输出**
+
+\`\`\`
+## Implementation Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 7/7 tasks complete ✓
+
+### Completed This Session
+- [x] Task 1
+- [x] Task 2
+...
+
+All tasks complete! Ready to archive this change.
+\`\`\`
+
+**暂停时输出（遇到问题）**
+
+\`\`\`
+## Implementation Paused
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 4/7 tasks complete
+
+### Issue Encountered
+<description of the issue>
+
+**Options:**
+1. <option 1>
+2. <option 2>
+3. Other approach
+
+What would you like to do?
+\`\`\`
+
+**约束**
+- 持续处理任务直到完成或阻塞
+- 开始前必须读取上下文文件（来自 apply 指令输出）
+- 任务含糊则先暂停并询问
+- 实现暴露问题则暂停并建议更新工件
+- 修改尽量小且限定在任务范围
+- 完成任务后立即勾选
+- 遇到错误、阻塞或不清晰需求则暂停，不要猜测
+- 使用 CLI 输出的 contextFiles，不要假设文件名
+
+**流式工作流集成**
+
+该技能支持“对变更的行动”模式：
+
+- **可随时调用**：在所有工件完成前（若任务存在）、部分实现后、或与其他操作交错
+- **允许更新工件**：若实现暴露设计问题，可建议更新工件——不按阶段锁死，保持流动`,
+        license: 'MIT',
+        compatibility: 'Requires openspec CLI.',
+        metadata: { author: 'openspec', version: '1.0' },
+    };
+}
+/**
+ * Template for openspec-ff-change skill
+ * Fast-forward through artifact creation
+ */
+export function getFfChangeSkillTemplate() {
+    return {
+        name: 'openspec-ff-change',
+        description: '快进完成 OpenSpec 工件创建。适用于用户希望快速生成所有实现所需工件，而不逐个创建时。',
+        instructions: `快进完成工件创建，一次性生成开始实现所需的一切。
+
+**Input**: 用户请求应包含变更名称（kebab-case）或要构建的内容描述。
+
+**Steps**
+
+1. **若输入不清晰，询问要构建的内容**
+
+    使用 **AskUserQuestion tool**（开放式、无预设选项）提问：
+    > "你想处理什么变更？描述你要构建或修复的内容。"
+
+    根据描述生成 kebab-case 名称（例如 "add user authentication" → \`add-user-auth\`）。
+
+    **IMPORTANT**: 未理解用户想要构建的内容前不要继续。
+
+2. **创建变更目录**
+   \`\`\`bash
+   openspec new change "<name>"
+   \`\`\`
+    该命令会在 \`openspec/changes/<name>/\` 下创建脚手架。
+
+3. **获取工件构建顺序**
+   \`\`\`bash
+   openspec status --change "<name>" --json
+   \`\`\`
+    解析 JSON 获取：
+    - \`applyRequires\`: 实现前需要完成的工件 ID 列表（例如 \`["tasks"]\`）
+    - \`artifacts\`: 所有工件及其状态与依赖
+
+4. **按顺序创建工件直到可 apply**
+
+    使用 **TodoWrite tool** 跟踪工件创建进度。
+
+    按依赖顺序遍历工件（先处理无待完成依赖的工件）：
+
+    a. **对于状态为 \`ready\` 的工件（依赖已满足）**：
+      - Get instructions:
+        \`\`\`bash
+        openspec instructions <artifact-id> --change "<name>" --json
+        \`\`\`
+      - 指令 JSON 包含：
+        - \`context\`: 项目背景（对你是约束，不要写入输出）
+        - \`rules\`: 工件规则（对你是约束，不要写入输出）
+        - \`template\`: 输出文件结构
+        - \`instruction\`: 该工件的 schema 指导
+        - \`outputPath\`: 输出路径
+        - \`dependencies\`: 需读取的已完成工件
+      - 读取已完成依赖工件作为上下文
+      - 使用 \`template\` 作为结构创建工件文件
+      - 将 \`context\` 与 \`rules\` 作为约束，但不要复制进文件
+      - 简要展示进度："✓ Created <artifact-id>"
+
+    b. **继续直到所有 \`applyRequires\` 工件完成**
+       - 每创建一个工件后重跑 \`openspec status --change "<name>" --json\`
+       - 检查 \`applyRequires\` 中的每个工件 ID 是否在 artifacts 中为 \`status: "done"\`
+       - 当所有 \`applyRequires\` 工件完成时停止
+
+    c. **若某工件需要用户输入**（上下文不清楚）：
+       - 使用 **AskUserQuestion tool** 进行澄清
+       - 然后继续创建
+
+5. **展示最终状态**
+   \`\`\`bash
+   openspec status --change "<name>"
+   \`\`\`
+
+**输出**
+
+完成所有工件后总结：
+- 变更名称与位置
+- 已创建工件列表与简述
+- 就绪提示："所有工件已创建！可开始实现。"
+- 提示语："运行 \`/opsx:apply\` 或让我开始实现任务。"
+
+**工件创建指南**
+
+ - 按 \`openspec instructions\` 的 \`instruction\` 字段执行每个工件类型
+ - schema 定义了每个工件应包含的内容，严格遵循
+ - 创建新工件前先读取依赖工件作为上下文
+ - 使用 \`template\` 作为输出结构并填写内容
+ - **IMPORTANT**: \`context\` 与 \`rules\` 仅作为你的约束，不是文件内容
+   - 不要把 \`<context>\`、\`<rules>\`、\`<project_context>\` 复制进工件
+   - 它们只用于指导书写，不能出现在输出中
+
+**约束**
+- 创建实现所需的所有工件（由 schema 的 \`apply.requires\` 定义）
+- 创建新工件前必须读取依赖工件
+- 若上下文严重不清楚，先询问用户，但尽量做合理判断以保持推进
+- 若该名称已有变更，建议继续该变更
+- 写入后确认工件文件存在，再继续下一个`,
+        license: 'MIT',
+        compatibility: 'Requires openspec CLI.',
+        metadata: { author: 'openspec', version: '1.0' },
+    };
+}
+/**
+ * Template for openspec-sync-specs skill
+ * For syncing delta specs from a change to main specs (agent-driven)
+ */
+export function getSyncSpecsSkillTemplate() {
+    return {
+        name: 'openspec-sync-specs',
+        description: '将变更中的增量规范同步到主规范。适用于用户希望应用增量规范变化但不归档该变更时。',
+        instructions: `将增量规范从变更同步到主规范。
+
+这是一个 **agent-driven** 操作——你将读取增量规范并直接编辑主规范以应用变更。这允许智能合并（例如只新增场景而不复制整个需求）。
+
+**Input**: 可选指定变更名称。若省略，先从对话上下文推断；如含糊或有歧义，必须提示选择可用变更。
+
+**Steps**
+
+1. **未提供变更名称时，提示选择**
+
+    运行 \`openspec list --json\` 获取可用变更，并使用 **AskUserQuestion tool** 让用户选择。
+
+    仅展示包含增量规范的变更（位于 \`specs/\` 目录）。
+
+    **IMPORTANT**: 不要猜测或自动选择变更，必须由用户选择。
+
+2. **查找增量规范**
+
+    查找 \`openspec/changes/<name>/specs/*/spec.md\` 下的增量规范文件。
+
+    每个增量规范文件包含以下章节：
+   - \`## ADDED Requirements\` - New requirements to add
+   - \`## MODIFIED Requirements\` - Changes to existing requirements
+   - \`## REMOVED Requirements\` - Requirements to remove
+   - \`## RENAMED Requirements\` - Requirements to rename (FROM:/TO: format)
+
+    若未找到增量规范，告知用户并停止。
+
+3. **针对每个增量规范应用到主规范**
+
+    对于位于 \`openspec/changes/<name>/specs/<capability>/spec.md\` 的每个能力：
+
+    a. **读取增量规范** 以理解变更意图
+
+    b. **读取主规范** \`openspec/specs/<capability>/spec.md\`（可能尚不存在）
+
+    c. **智能应用变更**：
+
+       **ADDED Requirements:**
+       - 主规范中不存在该需求 → 新增
+       - 已存在该需求 → 更新以匹配（视为隐式 MODIFIED）
+
+       **MODIFIED Requirements:**
+       - 在主规范中定位需求
+       - 应用变更，可包括：
+         - 添加新场景（无需复制已有场景）
+         - 修改已有场景
+         - 修改需求描述
+       - 保留增量未涉及的场景/内容
+
+       **REMOVED Requirements:**
+       - 从主规范中删除整个需求块
+
+       **RENAMED Requirements:**
+       - 找到 FROM 需求并重命名为 TO
+
+    d. **若能力尚不存在主规范则创建**：
+       - 创建 \`openspec/specs/<capability>/spec.md\`
+       - 添加 Purpose 部分（可简略，标注 TBD）
+       - 添加 Requirements 部分并填入 ADDED 需求
+
+4. **展示摘要**
+
+    应用完所有变更后总结：
+    - 更新了哪些能力
+    - 做了哪些变更（新增/修改/删除/重命名需求）
+
+**增量规范格式参考**
+
+\`\`\`markdown
+## ADDED Requirements
+
+### Requirement: New Feature
+The system SHALL do something new.
+
+#### Scenario: Basic case
+- **WHEN** user does X
+- **THEN** system does Y
+
+## MODIFIED Requirements
+
+### Requirement: Existing Feature
+#### Scenario: New scenario to add
+- **WHEN** user does A
+- **THEN** system does B
+
+## REMOVED Requirements
+
+### Requirement: Deprecated Feature
+
+## RENAMED Requirements
+
+- FROM: \`### Requirement: Old Name\`
+- TO: \`### Requirement: New Name\`
+\`\`\`
+
+**关键原则：智能合并**
+
+不同于程序化合并，你可以进行 **局部更新**：
+- 只需在 MODIFIED 下加入新增场景，无需复制既有场景
+- 增量表达的是*意图*，不是整体替换
+- 依据判断做合理合并
+
+**成功时输出**
+
+\`\`\`
+## Specs Synced: <change-name>
+
+Updated main specs:
+
+**<capability-1>**:
+- Added requirement: "New Feature"
+- Modified requirement: "Existing Feature" (added 1 scenario)
+
+**<capability-2>**:
+- Created new spec file
+- Added requirement: "Another Feature"
+
+主规范已更新。变更仍保持活跃——实现完成后再归档。
+\`\`\`
+
+**约束**
+- 修改前先读增量规范与主规范
+- 保留增量未提及的现有内容
+- 不清楚时先询问澄清
+- 边改边展示变更内容
+- 该操作应具备幂等性——重复执行结果相同`,
+        license: 'MIT',
+        compatibility: 'Requires openspec CLI.',
+        metadata: { author: 'openspec', version: '1.0' },
+    };
+}
+/**
+ * Template for /opsx:explore slash command
+ * Explore mode - adaptive thinking partner
+ */
+export function getOpsxExploreCommandTemplate() {
+    return {
+        name: 'OPSX: Explore',
+        description: '进入探索模式——思考想法、调查问题、澄清需求',
+        category: 'Workflow',
+        tags: ['workflow', 'explore', 'experimental', 'thinking'],
+        content: `进入探索模式。深度思考，自由可视化。跟随对话自然展开。
+
+**IMPORTANT: 探索模式用于思考，而非实现。** 你可以读取文件、搜索代码、调查代码库，但绝不能编写代码或实现功能。如果用户要求实现，提醒他们先退出探索模式（例如使用 \`/opsx:new\` 或 \`/opsx:ff\` 启动变更）。如用户要求，你可以创建 OpenSpec 工件（proposal/design/specs），这属于记录思考，而非实现。
+
+**这是一种立场，而非流程。** 没有固定步骤、没有必选顺序、没有强制输出。你是帮助用户探索的思考伙伴。
+
+**输入**：\`/opsx:explore\` 后的参数是用户想要思考的内容。可能是：
+- 一个模糊想法："real-time collaboration"
+- 一个具体问题："the auth system is getting unwieldy"
+- 变更名称："add-dark-mode"（在该变更上下文中探索）
+- 一个比较："postgres vs sqlite for this"
+- 无参数（直接进入探索模式）
+
+---
+
+## 立场
+
+- **保持好奇而非规定路径** - 提出自然涌现的问题，不照本宣科
+- **开放线程而非盘问** - 提供多个有趣方向，让用户选择共鸣点，不把他们引导到单一路径
+- **可视化** - 需要澄清思路时尽量使用 ASCII 图
+- **自适应** - 跟随有价值的线索，出现新信息时及时转向
+- **耐心** - 不急于结论，让问题的轮廓自然显现
+- **落地** - 需要时探索真实代码库，而非纯理论
+
+---
+
+## 你可能会做的事
+
+根据用户提供的信息，你可能会：
+
+**探索问题空间**
+- 提出基于对话自然产生的澄清问题
+- 质疑假设
+- 重新表述问题
+- 寻找类比
+
+**调查代码库**
+- 梳理与讨论相关的现有架构
+- 找到集成点
+- 识别已有模式
+- 暴露隐藏复杂度
+
+**比较选项**
+- 头脑风暴多种方案
+- 构建对比表
+- 勾勒权衡
+- 如被请求则给出建议路径
+
+**可视化**
+\`\`\`
+┌─────────────────────────────────────────┐
+│     Use ASCII diagrams liberally        │
+├─────────────────────────────────────────┤
+│                                         │
+│   ┌────────┐         ┌────────┐        │
+│   │ State  │────────▶│ State  │        │
+│   │   A    │         │   B    │        │
+│   └────────┘         └────────┘        │
+│                                         │
+│   System diagrams, state machines,      │
+│   data flows, architecture sketches,    │
+│   dependency graphs, comparison tables  │
+│                                         │
+└─────────────────────────────────────────┘
+\`\`\`
+
+**暴露风险与未知**
+- 识别可能出错的地方
+- 找出认知空白
+- 建议进行探索性调研或验证
+
+---
+
+## OpenSpec 认知
+
+你拥有 OpenSpec 系统的完整上下文。自然使用，不要生硬强推。
+
+### 检查上下文
+
+开始时，快速查看已有内容：
+\`\`\`bash
+openspec list --json
+\`\`\`
+
+这会告诉你：
+- 是否存在活跃变更
+- 变更名称、工作流与状态
+- 用户可能正在做什么
+
+如果用户提到某个变更名称，读取其工件作为上下文。
+
+### 当没有变更时
+
+自由思考。当洞见逐渐清晰时，你可以：
+
+- "现在信息已经足够开始变更了，要我创建一个吗？"
+  → 可转为 \`/opsx:new\` 或 \`/opsx:ff\`
+- 或继续探索——无需急于形式化
+
+### 当已存在变更时
+
+如果用户提到某个变更，或你判断其相关：
+
+1. **读取现有工件作为上下文**
+   - \`openspec/changes/<name>/proposal.md\`
+   - \`openspec/changes/<name>/design.md\`
+   - \`openspec/changes/<name>/tasks.md\`
+   - 等
+
+2. **在对话中自然引用**
+- "你的设计里提到用 Redis，但我们刚发现 SQLite 更合适..."
+- "提案里将范围限定在高级用户，但现在我们在想是否所有人..."
+
+3. **当决策形成时建议记录**
+
+   | 洞见类型 | 记录位置 |
+   |--------------|------------------|
+    | 新需求发现 | \`specs/<capability>/spec.md\` |
+    | 需求变更 | \`specs/<capability>/spec.md\` |
+    | 设计决策形成 | \`design.md\` |
+    | 范围变化 | \`proposal.md\` |
+    | 发现新工作 | \`tasks.md\` |
+    | 假设被推翻 | 相关工件 |
+
+   示例话术：
+   - "这是一个设计决策，要记录到 design.md 吗？"
+   - "这是新需求，要加到 specs 吗？"
+   - "这改变了范围，要更新提案吗？"
+
+4. **由用户决定** - 给出建议即可，不要施压，也不要自动记录。
+
+---
+
+## 不必做的事
+
+- 按脚本走
+- 每次都问同样的问题
+- 产出某个固定工件
+- 得出结论
+- 有价值的岔路也必须回到主线
+- 简短表达（这是思考时间）
+
+---
+
+## 结束探索
+
+没有固定结尾。探索可能会：
+
+- **转入行动**："准备开始了吗？\`/opsx:new\` 或 \`/opsx:ff\`"
+- **推动工件更新**："已将这些决策更新到 design.md"
+- **仅提供澄清**：用户获得所需信息后继续
+- **稍后继续**："我们随时可以继续"
+
+当你感觉思路逐渐清晰时，可以做一个简短总结——但不是必须。有时思考本身就是价值。
+
+---
+
+## 约束
+
+- **不要实现** - 绝不编写代码或实现功能。创建 OpenSpec 工件可以，写应用代码不行。
+- **不要装懂** - 不清楚就继续深挖
+- **不要急** - 这是思考时间，不是任务时间
+- **不要强行结构化** - 让模式自然浮现
+- **不要自动记录** - 先提出建议，别直接动手
+- **要可视化** - 一张好图胜过千言
+- **要探索代码库** - 以现实为依据
+- **要质疑假设** - 包括用户和你自己的`
+    };
+}
+/**
+ * Template for /opsx:new slash command
+ */
+export function getOpsxNewCommandTemplate() {
+    return {
+        name: 'OPSX: New',
+        description: '使用实验性工件工作流启动新的变更（OPSX）',
+        category: 'Workflow',
+        tags: ['workflow', 'artifacts', 'experimental'],
+        content: `使用实验性工件驱动方式启动新变更。
+
+**输入**：\`/opsx:new\` 后的参数是变更名称（kebab-case），或用户想构建内容的描述。
+
+**步骤**
+
+1. **若未提供输入，询问想要构建的内容**
+
+   使用 **AskUserQuestion tool**（开放式、无预设选项）提问：
+   > "What change do you want to work on? Describe what you want to build or fix."
+
+   根据描述生成 kebab-case 名称（例如 "add user authentication" → \`add-user-auth\`）。
+
+   **IMPORTANT**: 未理解用户想要构建的内容前不要继续。
+
+2. **确定工作流 schema**
+
+   除非用户明确要求其他工作流，否则使用默认 schema（省略 \`--schema\`）。
+
+   **仅在用户提及以下情况时切换 schema：**
+   - "tdd" 或 "test-driven" → 使用 \`--schema tdd\`
+   - 指定 schema 名称 → 使用 \`--schema <name>\`
+   - "show workflows" 或 "what workflows" → 运行 \`openspec schemas --json\` 并让用户选择
+
+   **否则**：省略 \`--schema\` 以使用默认值。
+
+3. **创建变更目录**
+   \`\`\`bash
+   openspec new change "<name>"
+   \`\`\`
+   仅在用户指定工作流时添加 \`--schema <name>\`。
+   该命令会在 \`openspec/changes/<name>/\` 下创建脚手架并应用所选 schema。
+
+4. **展示工件状态**
+   \`\`\`bash
+   openspec status --change "<name>"
+   \`\`\`
+   该输出会显示哪些工件需要创建，以及哪些已就绪（依赖已满足）。
+
+5. **获取首个工件的指令**
+   首个工件取决于 schema。查看状态输出，找到第一个状态为 "ready" 的工件。
+   \`\`\`bash
+   openspec instructions <first-artifact-id> --change "<name>"
+   \`\`\`
+   该命令会输出首个工件的模板与上下文。
+
+6. **停止并等待用户指示**
+
+**输出**
+
+完成步骤后总结：
+- 变更名称与位置
+- 使用的 schema/工作流及其工件顺序
+- 当前状态（0/N 工件完成）
+- 首个工件的模板
+- 提示语："准备创建第一个工件了吗？运行 \`/opsx:continue\`，或直接描述这个变更，我来起草。"
+
+**约束**
+- 不要创建任何工件——只展示指令
+- 不要继续到首个工件模板之外
+- 名称不合法（非 kebab-case）时要求提供合法名称
+- 若该名称已存在变更，建议改用 \`/opsx:continue\`
+- 使用非默认工作流时传入 --schema`
+    };
+}
+/**
+ * Template for /opsx:continue slash command
+ */
+export function getOpsxContinueCommandTemplate() {
+    return {
+        name: 'OPSX: Continue',
+        description: '继续推进变更——创建下一个工件（实验性）',
+        category: 'Workflow',
+        tags: ['workflow', 'artifacts', 'experimental'],
+        content: `通过创建下一个工件继续变更。
+
+**输入**：可选在 \`/opsx:continue\` 后指定变更名称（例如 \`/opsx:continue add-auth\`）。若省略，先从对话上下文推断；如含糊或有歧义，必须提示选择可用变更。
+
+**步骤**
+
+1. **未提供变更名称时，提示选择**
+
+   运行 \`openspec list --json\` 获取按最近修改排序的变更列表。然后使用 **AskUserQuestion tool** 让用户选择要继续的变更。
+
+   以最近修改的 3-4 个变更作为选项，展示：
+   - 变更名称
+   - Schema（若有 \`schema\` 字段则使用，否则为 "spec-driven"）
+   - 状态（例如 "0/5 tasks"、"complete"、"no tasks"）
+   - 最近修改时间（来自 \`lastModified\` 字段）
+
+   将最近修改的变更标记为 "(Recommended)"，因为它最可能是用户要继续的。
+
+   **IMPORTANT**: 不要猜测或自动选择变更，必须由用户选择。
+
+2. **检查当前状态**
+   \`\`\`bash
+   openspec status --change "<name>" --json
+   \`\`\`
+   解析 JSON 了解当前状态。响应包含：
+   - \`schemaName\`: 正在使用的工作流 schema（例如 "spec-driven"、"tdd"）
+   - \`artifacts\`: 工件数组及其状态（"done"、"ready"、"blocked"）
+   - \`isComplete\`: 是否所有工件已完成的布尔值
+
+3. **根据状态采取行动**：
+
+   ---
+
+   **若所有工件完成（\`isComplete: true\`）**：
+   - 祝贺用户
+   - 展示最终状态（包含所用 schema）
+    - 建议："所有工件已创建！现在可以实现该变更或将其归档。"
+   - 停止
+
+   ---
+
+   **若有可创建的工件**（状态中存在 \`status: "ready"\`）：
+   - 选择状态输出中第一个 \`status: "ready"\` 的工件
+   - 获取其指令：
+     \`\`\`bash
+     openspec instructions <artifact-id> --change "<name>" --json
+     \`\`\`
+   - 解析 JSON。关键字段包括：
+     - \`context\`: 项目背景（对你是约束，不要写入输出）
+     - \`rules\`: 工件规则（对你是约束，不要写入输出）
+     - \`template\`: 输出文件结构
+     - \`instruction\`: schema 指导说明
+     - \`outputPath\`: 输出路径
+     - \`dependencies\`: 需读取的已完成工件
+   - **创建工件文件**：
+     - 读取已完成依赖工件作为上下文
+     - 使用 \`template\` 作为结构并填写内容
+     - 写入时将 \`context\` 与 \`rules\` 作为约束，但不要复制进文件
+     - 写入指令给定的输出路径
+   - 展示已创建内容与新解锁内容
+   - 创建一个工件后停止
+
+   ---
+
+   **若没有可用工件（全部 blocked）**：
+   - 这在有效 schema 下不应发生
+   - 展示状态并建议检查问题
+
+4. **创建工件后展示进度**
+   \`\`\`bash
+   openspec status --change "<name>"
+   \`\`\`
+
+**输出**
+
+每次执行后展示：
+- 已创建的工件
+- 当前使用的 schema 工作流
+- 进度（N/M 完成）
+- 新解锁的工件
+- 提示语："运行 \`/opsx:continue\` 以创建下一个工件"
+
+**工件创建指南**
+
+工件类型及其用途取决于 schema。通过指令输出中的 \`instruction\` 字段了解应创建的内容。
+
+常见工件模式：
+
+**spec-driven schema**（proposal → specs → design → tasks）：
+- **proposal.md**：若变更不清晰先询问用户，填写 Why、What Changes、Capabilities、Impact。
+  - Capabilities 部分至关重要——每个能力都需要一个 spec 文件。
+- **specs/*.md**：为提案中每个能力创建一个规范。
+- **design.md**：记录技术决策、架构与实现方案。
+- **tasks.md**：将实现拆解为可勾选任务。
+
+**tdd schema**（spec → tests → implementation → docs）：
+- **spec.md**：功能规范，定义要构建内容。
+- **tests/*.test.ts**：在实现前编写测试（TDD 红阶段）。
+- **src/*.ts**：实现以通过测试（TDD 绿阶段）。
+- **docs/*.md**：为已实现功能编写文档。
+
+其他 schema 按 CLI 输出中的 \`instruction\` 执行。
+
+**约束**
+ - 每次只创建一个工件
+ - 创建前必须读取依赖工件
+ - 不要跳过工件或乱序创建
+ - 上下文不清楚时先询问用户
+ - 写入后确认文件存在再标记进度
+ - 按 schema 的工件顺序执行，不要猜测工件名称
+ - **IMPORTANT**: \`context\` 与 \`rules\` 仅作为你的约束，不是文件内容
+   - 不要把 \`<context>\`、\`<rules>\`、\`<project_context>\` 复制进工件
+   - 它们只用于指导书写，不能出现在输出中`
+    };
+}
+/**
+ * Template for /opsx:apply slash command
+ */
+export function getOpsxApplyCommandTemplate() {
+    return {
+        name: 'OPSX: Apply',
+        description: '根据 OpenSpec 变更实现任务（实验性）',
+        category: 'Workflow',
+        tags: ['workflow', 'artifacts', 'experimental'],
+        content: `根据 OpenSpec 变更实现任务。
+
+**输入**：可选指定变更名称（例如 \`/opsx:apply add-auth\`）。若省略，先从对话上下文推断；如含糊或有歧义，必须提示选择可用变更。
+
+**步骤**
+
+1. **选择变更**
+
+   若提供名称则使用。否则：
+   - 从对话上下文推断是否提到某个变更
+   - 若仅存在一个活跃变更则自动选择
+   - 若有歧义，运行 \`openspec list --json\` 获取变更列表并用 **AskUserQuestion tool** 让用户选择
+
+   始终声明："Using change: <name>" 并说明如何切换（例如 \`/opsx:apply <other>\`）。
+
+2. **检查状态以了解 schema**
+   \`\`\`bash
+   openspec status --change "<name>" --json
+   \`\`\`
+   解析 JSON 以了解：
+   - \`schemaName\`: 使用的工作流（例如 "spec-driven"、"tdd"）
+   - 任务所在的工件（spec-driven 通常为 "tasks"，其他以状态为准）
+
+3. **获取 apply 指令**
+
+   \`\`\`bash
+   openspec instructions apply --change "<name>" --json
+   \`\`\`
+
+   返回内容：
+   - 上下文文件路径（随 schema 不同）
+   - 进度（总数、完成、剩余）
+   - 带状态的任务列表
+   - 基于当前状态的动态指令
+
+   **处理状态：**
+   - 若 \`state: "blocked"\`（缺少工件）：提示并建议使用 \`/opsx:continue\`
+   - 若 \`state: "all_done"\`：祝贺并建议归档
+   - 否则：进入实现
+
+4. **读取上下文文件**
+
+   读取 apply 指令输出中的 \`contextFiles\` 列表。
+   文件取决于所用 schema：
+   - **spec-driven**：proposal、specs、design、tasks
+   - **tdd**：spec、tests、implementation、docs
+   - 其他 schema：以 CLI 输出的 contextFiles 为准
+
+5. **展示当前进度**
+
+   展示：
+   - 当前 schema
+   - 进度："N/M tasks complete"
+   - 剩余任务概览
+   - CLI 动态指令
+
+6. **实现任务（循环直到完成或阻塞）**
+
+   对每个待办任务：
+   - 显示正在处理的任务
+   - 进行必要的代码修改
+   - 保持修改最小且聚焦
+   - 在 tasks 文件中标记完成：\`- [ ]\` → \`- [x]\`
+   - 继续下一个任务
+
+   **遇到以下情况暂停：**
+   - 任务不清楚 → 询问澄清
+   - 实现暴露设计问题 → 建议更新工件
+   - 遇到错误或阻塞 → 汇报并等待指示
+   - 用户中断
+
+7. **完成或暂停时展示状态**
+
+   展示：
+   - 本次完成的任务
+   - 总进度："N/M tasks complete"
+   - 若全部完成：建议归档
+   - 若暂停：说明原因并等待指示
+
+**实现过程中的输出**
+
+\`\`\`
+## Implementing: <change-name> (schema: <schema-name>)
+
+Working on task 3/7: <task description>
+[...implementation happening...]
+✓ Task complete
+
+Working on task 4/7: <task description>
+[...implementation happening...]
+✓ Task complete
+\`\`\`
+
+**完成时输出**
+
+\`\`\`
+## Implementation Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 7/7 tasks complete ✓
+
+### Completed This Session
+- [x] Task 1
+- [x] Task 2
+...
+
+All tasks complete! Ready to archive this change.
+\`\`\`
+
+**暂停时输出（遇到问题）**
+
+\`\`\`
+## Implementation Paused
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 4/7 tasks complete
+
+### Issue Encountered
+<description of the issue>
+
+**Options:**
+1. <option 1>
+2. <option 2>
+3. Other approach
+
+What would you like to do?
+\`\`\`
+
+**约束**
+- 持续处理任务直到完成或阻塞
+- 开始前必须读取上下文文件（来自 apply 指令输出）
+- 任务含糊则先暂停并询问
+- 实现暴露问题则暂停并建议更新工件
+- 修改尽量小且限定在任务范围
+- 完成任务后立即勾选
+- 遇到错误、阻塞或不清晰需求则暂停，不要猜测
+- 使用 CLI 输出的 contextFiles，不要假设文件名
+
+**流式工作流集成**
+
+该技能支持“对变更的行动”模式：
+
+- **可随时调用**：在所有工件完成前（若任务存在）、部分实现后、或与其他操作交错
+- **允许更新工件**：若实现暴露设计问题，可建议更新工件——不按阶段锁死，保持流动`
+    };
+}
+/**
+ * Template for /opsx:ff slash command
+ */
+export function getOpsxFfCommandTemplate() {
+    return {
+        name: 'OPSX: Fast Forward',
+        description: '创建变更并一次性生成实现所需全部工件',
+        category: 'Workflow',
+        tags: ['workflow', 'artifacts', 'experimental'],
+        content: `快进完成工件创建，一次性生成开始实现所需的一切。
+
+**输入**：\`/opsx:ff\` 后的参数是变更名称（kebab-case），或用户想构建内容的描述。
+
+**步骤**
+
+1. **若未提供输入，询问要构建的内容**
+
+   使用 **AskUserQuestion tool**（开放式、无预设选项）提问：
+   > "What change do you want to work on? Describe what you want to build or fix."
+
+   根据描述生成 kebab-case 名称（例如 "add user authentication" → \`add-user-auth\`）。
+
+   **IMPORTANT**: 未理解用户想要构建的内容前不要继续。
+
+2. **创建变更目录**
+   \`\`\`bash
+   openspec new change "<name>"
+   \`\`\`
+   该命令会在 \`openspec/changes/<name>/\` 下创建脚手架。
+
+3. **获取工件构建顺序**
+   \`\`\`bash
+   openspec status --change "<name>" --json
+   \`\`\`
+   解析 JSON 获取：
+   - \`applyRequires\`: 实现前需要完成的工件 ID 列表（例如 \`["tasks"]\`）
+   - \`artifacts\`: 所有工件及其状态与依赖
+
+4. **按顺序创建工件直到可 apply**
+
+   使用 **TodoWrite tool** 跟踪工件创建进度。
+
+   按依赖顺序遍历工件（先处理无待完成依赖的工件）：
+
+   a. **对于状态为 \`ready\` 的工件（依赖已满足）**：
+      - 获取指令：
+        \`\`\`bash
+        openspec instructions <artifact-id> --change "<name>" --json
+        \`\`\`
+      - 指令 JSON 包含：
+        - \`context\`: 项目背景（对你是约束，不要写入输出）
+        - \`rules\`: 工件规则（对你是约束，不要写入输出）
+        - \`template\`: 输出文件结构
+        - \`instruction\`: 该工件的 schema 指导
+        - \`outputPath\`: 输出路径
+        - \`dependencies\`: 需读取的已完成工件
+      - 读取已完成依赖工件作为上下文
+      - 使用 \`template\` 作为结构创建工件文件
+      - 将 \`context\` 与 \`rules\` 作为约束，但不要复制进文件
+      - 简要展示进度："✓ Created <artifact-id>"
+
+   b. **继续直到所有 \`applyRequires\` 工件完成**
+      - 每创建一个工件后重跑 \`openspec status --change "<name>" --json\`
+      - 检查 \`applyRequires\` 中的每个工件 ID 是否在 artifacts 中为 \`status: "done"\`
+      - 当所有 \`applyRequires\` 工件完成时停止
+
+   c. **若某工件需要用户输入**（上下文不清楚）：
+      - 使用 **AskUserQuestion tool** 进行澄清
+      - 然后继续创建
+
+5. **展示最终状态**
+   \`\`\`bash
+   openspec status --change "<name>"
+   \`\`\`
+
+**输出**
+
+完成所有工件后总结：
+- 变更名称与位置
+- 已创建工件列表与简述
+- 就绪提示："所有工件已创建！可开始实现。"
+- 提示语："运行 \`/opsx:apply\` 开始实现。"
+
+**工件创建指南**
+
+- 按 \`openspec instructions\` 的 \`instruction\` 字段执行每个工件类型
+- schema 定义了每个工件应包含的内容，严格遵循
+- 创建新工件前先读取依赖工件作为上下文
+- 使用 \`template\` 作为输出结构并填写内容
+
+**约束**
+- 创建实现所需的所有工件（由 schema 的 \`apply.requires\` 定义）
+- 创建新工件前必须读取依赖工件
+- 若上下文严重不清楚，先询问用户，但尽量做合理判断以保持推进
+- 若该名称已有变更，建议继续该变更
+- 写入后确认工件文件存在，再继续下一个`
+    };
+}
+/**
+ * Template for openspec-archive-change skill
+ * For archiving completed changes in the experimental workflow
+ */
+export function getArchiveChangeSkillTemplate() {
+    return {
+        name: 'openspec-archive-change',
+        description: '归档实验性工作流中已完成的变更。用于用户完成实现后希望最终归档时。',
+        instructions: `在实验性工作流中归档已完成的变更。
+
+**输入**：可选指定变更名称。若省略，先从对话上下文推断；如含糊或有歧义，必须提示选择可用变更。
+
+**步骤**
+
+1. **未提供变更名称时，提示选择**
+
+   运行 \`openspec list --json\` 获取可用变更，并使用 **AskUserQuestion tool** 让用户选择。
+
+   仅展示活跃变更（未归档）。
+   如可用，展示每个变更使用的 schema。
+
+   **IMPORTANT**: 不要猜测或自动选择变更，必须由用户选择。
+
+2. **检查工件完成状态**
+
+   运行 \`openspec status --change "<name>" --json\` 检查工件完成情况。
+
+   解析 JSON 以了解：
+   - \`schemaName\`: 使用的工作流
+   - \`artifacts\`: 工件列表及其状态（\`done\` 或其他）
+
+   **若有工件未完成（非 \`done\`）：**
+   - 显示警告并列出未完成的工件
+   - 使用 **AskUserQuestion tool** 确认是否继续
+   - 用户确认后继续
+
+3. **检查任务完成状态**
+
+   读取 tasks 文件（通常为 \`tasks.md\`）以检查未完成任务。
+
+   统计 \`- [ ]\`（未完成）与 \`- [x]\`（完成）的数量。
+
+   **若存在未完成任务：**
+   - 显示警告并展示未完成任务数量
+   - 使用 **AskUserQuestion tool** 确认是否继续
+   - 用户确认后继续
+
+   **若不存在 tasks 文件：** 无需任务警告，继续。
+
+4. **评估增量规范同步状态**
+
+   检查 \`openspec/changes/<name>/specs/\` 是否存在增量规范。若不存在，无需同步提示。
+
+   **若存在增量规范：**
+   - 将每个增量规范与对应主规范 \`openspec/specs/<capability>/spec.md\` 进行对比
+   - 确定将应用的变更（新增/修改/删除/重命名）
+   - 在提示前展示合并摘要
+
+   **提示选项：**
+    - 若需要同步："立即同步（推荐）"、"不同步直接归档"
+    - 若已同步："立即归档"、"仍然同步"、"取消"
+
+   若用户选择同步，执行 /opsx:sync 逻辑（使用 openspec-sync-specs 技能）。无论选择如何都继续归档流程。
+
+5. **执行归档**
+
+   若归档目录不存在则创建：
+   \`\`\`bash
+   mkdir -p openspec/changes/archive
+   \`\`\`
+
+   使用当前日期生成目标名称：\`YYYY-MM-DD-<change-name>\`
+
+   **检查目标是否已存在：**
+   - 若存在：报错并建议重命名已有归档或使用不同日期
+   - 若不存在：将变更目录移动到归档
+
+   \`\`\`bash
+   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   \`\`\`
+
+6. **展示摘要**
+
+   展示归档完成摘要，包括：
+   - 变更名称
+   - 使用的 schema
+   - 归档位置
+   - 规范是否已同步（如适用）
+   - 任何警告说明（工件/任务未完成）
+
+**成功时输出**
+
+\`\`\`
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
+
+All artifacts complete. All tasks complete.
+\`\`\`
+
+**约束**
+- 未提供变更名称时必须提示选择
+- 使用工件图（openspec status --json）检查完成情况
+- 警告不阻塞归档——只需告知并确认
+- 移动归档时保留 .openspec.yaml（随目录一起移动）
+- 清晰展示发生了什么
+- 若请求同步，使用 openspec-sync-specs 方法（agent-driven）
+- 若存在增量规范，必须先进行同步评估并展示合并摘要再提示`,
+        license: 'MIT',
+        compatibility: 'Requires openspec CLI.',
+        metadata: { author: 'openspec', version: '1.0' },
+    };
+}
+/**
+ * Template for openspec-bulk-archive-change skill
+ * For archiving multiple completed changes at once
+ */
+export function getBulkArchiveChangeSkillTemplate() {
+    return {
+        name: 'openspec-bulk-archive-change',
+        description: '批量归档多个已完成变更。适用于同时归档多个并行变更。',
+        instructions: `在一次操作中归档多个已完成变更。
+
+该技能允许批量归档变更，并通过检查代码库智能处理规范冲突以判断真实实现情况。
+
+**输入**：无需输入（会提示选择）
+
+**步骤**
+
+1. **获取活跃变更**
+
+   运行 \`openspec list --json\` 获取所有活跃变更。
+
+   若无活跃变更，告知用户并停止。
+
+2. **提示选择变更**
+
+   使用 **AskUserQuestion tool** 的多选让用户选择变更：
+   - 展示每个变更及其 schema
+   - 包含 "All changes" 选项
+   - 允许选择任意数量（1+ 即可，典型为 2+）
+
+   **IMPORTANT**: 不要自动选择，必须由用户选择。
+
+3. **批量校验——收集所选变更的状态**
+
+   对每个所选变更，收集：
+
+   a. **工件状态** - 运行 \`openspec status --change "<name>" --json\`
+      - 解析 \`schemaName\` 和 \`artifacts\` 列表
+      - 记录哪些工件为 \`done\`，哪些为其他状态
+
+   b. **任务完成情况** - 读取 \`openspec/changes/<name>/tasks.md\`
+      - 统计 \`- [ ]\`（未完成）与 \`- [x]\`（完成）数量
+       - 若没有 tasks 文件，记录为 "无任务"
+
+   c. **增量规范** - 检查 \`openspec/changes/<name>/specs/\` 目录
+      - 列出存在的 capability 规范
+      - 对每个规范提取需求名称（匹配 \`### Requirement: <name>\` 的行）
+
+4. **检测规范冲突**
+
+   构建映射 \`capability -> [changes that touch it]\`：
+
+   \`\`\`
+   auth -> [change-a, change-b]  <- CONFLICT (2+ changes)
+   api  -> [change-c]            <- OK (only 1 change)
+   \`\`\`
+
+   当 2+ 个所选变更对同一 capability 存在增量规范时视为冲突。
+
+5. **以 agent 方式解决冲突**
+
+   **针对每个冲突**，调查代码库：
+
+   a. **读取各冲突变更的增量规范**，理解各自声明新增/修改内容
+
+   b. **搜索代码库** 寻找实现证据：
+      - 查找实现增量规范需求的代码
+      - 检查相关文件、函数或测试
+
+   c. **确定解决方案**：
+      - 仅一个变更实际实现 -> 同步该变更的规范
+      - 两者均已实现 -> 按时间顺序应用（先旧后新，新覆盖旧）
+      - 均未实现 -> 跳过规范同步并警告
+
+   d. **记录冲突解决方案**：
+      - 应用哪个变更的规范
+      - 应用顺序（如两者均实现）
+      - 理由（代码库发现）
+
+6. **展示汇总状态表**
+
+   展示汇总所有变更的表格：
+
+   \`\`\`
+   | Change               | Artifacts | Tasks | Specs   | Conflicts | Status |
+   |---------------------|-----------|-------|---------|-----------|--------|
+   | schema-management   | Done      | 5/5   | 2 delta | None      | Ready  |
+   | project-config      | Done      | 3/3   | 1 delta | None      | Ready  |
+   | add-oauth           | Done      | 4/4   | 1 delta | auth (!)  | Ready* |
+   | add-verify-skill    | 1 left    | 2/5   | None    | None      | Warn   |
+   \`\`\`
+
+   对于冲突，展示解决方案：
+   \`\`\`
+   * Conflict resolution:
+     - auth spec: Will apply add-oauth then add-jwt (both implemented, chronological order)
+   \`\`\`
+
+   对于未完成的变更，展示警告：
+   \`\`\`
+   Warnings:
+   - add-verify-skill: 1 incomplete artifact, 3 incomplete tasks
+   \`\`\`
+
+7. **确认批量操作**
+
+   使用 **AskUserQuestion tool** 做一次确认：
+
+    - "归档 N 个变更？" 并提供基于状态的选项
+   - 选项可能包括：
+      - "归档全部 N 个变更"
+      - "仅归档已就绪的 N 个变更（跳过未完成）"
+      - "取消"
+
+   若存在未完成的变更，要明确会带警告归档。
+
+8. **对每个确认的变更执行归档**
+
+   按确定的顺序处理变更（遵循冲突解决顺序）：
+
+   a. **如存在增量规范则先同步**：
+      - 使用 openspec-sync-specs 方法（agent-driven 智能合并）
+      - 对冲突按已解决顺序应用
+      - 记录是否已同步
+
+   b. **执行归档**：
+      \`\`\`bash
+      mkdir -p openspec/changes/archive
+      mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+      \`\`\`
+
+   c. **记录每个变更的结果**：
+      - 成功：归档成功
+      - 失败：归档时出错（记录错误）
+      - 跳过：用户选择不归档（如适用）
+
+9. **展示总结**
+
+   展示最终结果：
+
+   \`\`\`
+   ## Bulk Archive Complete
+
+   Archived 3 changes:
+   - schema-management-cli -> archive/2026-01-19-schema-management-cli/
+   - project-config -> archive/2026-01-19-project-config/
+   - add-oauth -> archive/2026-01-19-add-oauth/
+
+   Skipped 1 change:
+   - add-verify-skill (user chose not to archive incomplete)
+
+   Spec sync summary:
+   - 4 delta specs synced to main specs
+   - 1 conflict resolved (auth: applied both in chronological order)
+   \`\`\`
+
+   若有失败：
+   \`\`\`
+   Failed 1 change:
+   - some-change: Archive directory already exists
+   \`\`\`
+
+**冲突解决示例**
+
+示例 1：仅一个实现
+\`\`\`
+Conflict: specs/auth/spec.md touched by [add-oauth, add-jwt]
+
+Checking add-oauth:
+- Delta adds "OAuth Provider Integration" requirement
+- Searching codebase... found src/auth/oauth.ts implementing OAuth flow
+
+Checking add-jwt:
+- Delta adds "JWT Token Handling" requirement
+- Searching codebase... no JWT implementation found
+
+Resolution: Only add-oauth is implemented. Will sync add-oauth specs only.
+\`\`\`
+
+示例 2：两者均实现
+\`\`\`
+Conflict: specs/api/spec.md touched by [add-rest-api, add-graphql]
+
+Checking add-rest-api (created 2026-01-10):
+- Delta adds "REST Endpoints" requirement
+- Searching codebase... found src/api/rest.ts
+
+Checking add-graphql (created 2026-01-15):
+- Delta adds "GraphQL Schema" requirement
+- Searching codebase... found src/api/graphql.ts
+
+Resolution: Both implemented. Will apply add-rest-api specs first,
+then add-graphql specs (chronological order, newer takes precedence).
+\`\`\`
+
+**成功时输出**
+
+\`\`\`
+## Bulk Archive Complete
+
+Archived N changes:
+- <change-1> -> archive/YYYY-MM-DD-<change-1>/
+- <change-2> -> archive/YYYY-MM-DD-<change-2>/
+
+Spec sync summary:
+- N delta specs synced to main specs
+- No conflicts (or: M conflicts resolved)
+\`\`\`
+
+**部分成功时输出**
+
+\`\`\`
+## Bulk Archive Complete (partial)
+
+Archived N changes:
+- <change-1> -> archive/YYYY-MM-DD-<change-1>/
+
+Skipped M changes:
+- <change-2> (user chose not to archive incomplete)
+
+Failed K changes:
+- <change-3>: Archive directory already exists
+\`\`\`
+
+**无可归档变更时输出**
+
+\`\`\`
+## No Changes to Archive
+
+No active changes found. Use \`/opsx:new\` to create a new change.
+\`\`\`
+
+**约束**
+- 允许选择任意数量的变更（1+ 即可，2+ 常见）
+- 必须提示选择，禁止自动选择
+- 尽早检测规范冲突并通过代码库解决
+- 若两个变更都已实现，按时间顺序应用规范
+- 仅在缺少实现时跳过规范同步（并警告）
+- 确认前展示清晰的逐变更状态
+- 整个批次只做一次确认
+- 跟踪并汇报所有结果（成功/跳过/失败）
+- 移动归档时保留 .openspec.yaml
+- 归档目标使用当前日期：YYYY-MM-DD-<name>
+- 若归档目标已存在，该变更失败但继续处理其他`,
+        license: 'MIT',
+        compatibility: 'Requires openspec CLI.',
+        metadata: { author: 'openspec', version: '1.0' },
+    };
+}
+/**
+ * Template for /opsx:sync slash command
+ */
+export function getOpsxSyncCommandTemplate() {
+    return {
+        name: 'OPSX: Sync',
+        description: '将变更中的增量规范同步到主规范',
+        category: 'Workflow',
+        tags: ['workflow', 'specs', 'experimental'],
+        content: `将增量规范从变更同步到主规范。
+
+这是一个 **agent-driven** 操作——你将读取增量规范并直接编辑主规范以应用变更。这允许智能合并（例如只新增场景而不复制整个需求）。
+
+**输入**：可选在 \`/opsx:sync\` 后指定变更名称（例如 \`/opsx:sync add-auth\`）。若省略，先从对话上下文推断；如含糊或有歧义，必须提示选择可用变更。
+
+**步骤**
+
+1. **未提供变更名称时，提示选择**
+
+   运行 \`openspec list --json\` 获取可用变更，并使用 **AskUserQuestion tool** 让用户选择。
+
+   仅展示包含增量规范的变更（位于 \`specs/\` 目录）。
+
+   **IMPORTANT**: 不要猜测或自动选择变更，必须由用户选择。
+
+2. **查找增量规范**
+
+   查找 \`openspec/changes/<name>/specs/*/spec.md\` 下的增量规范文件。
+
+   每个增量规范文件包含以下章节：
+   - \`## ADDED Requirements\` - 新增的需求
+   - \`## MODIFIED Requirements\` - 对现有需求的变更
+   - \`## REMOVED Requirements\` - 需要移除的需求
+   - \`## RENAMED Requirements\` - 需要重命名的需求（FROM:/TO: 格式）
+
+   若未找到增量规范，告知用户并停止。
+
+3. **针对每个增量规范应用到主规范**
+
+   对于位于 \`openspec/changes/<name>/specs/<capability>/spec.md\` 的每个能力：
+
+   a. **读取增量规范** 以理解变更意图
+
+   b. **读取主规范** \`openspec/specs/<capability>/spec.md\`（可能尚不存在）
+
+   c. **智能应用变更**：
+
+      **ADDED Requirements:**
+      - 主规范中不存在该需求 → 新增
+      - 已存在该需求 → 更新以匹配（视为隐式 MODIFIED）
+
+      **MODIFIED Requirements:**
+      - 在主规范中定位需求
+      - 应用变更，可包括：
+        - 添加新场景（无需复制已有场景）
+        - 修改已有场景
+        - 修改需求描述
+      - 保留增量未涉及的场景/内容
+
+      **REMOVED Requirements:**
+      - 从主规范中删除整个需求块
+
+      **RENAMED Requirements:**
+      - 找到 FROM 需求并重命名为 TO
+
+   d. **若能力尚不存在主规范则创建**：
+      - 创建 \`openspec/specs/<capability>/spec.md\`
+      - 添加 Purpose 部分（可简略，标注 TBD）
+      - 添加 Requirements 部分并填入 ADDED 需求
+
+4. **展示摘要**
+
+   应用完所有变更后总结：
+   - 更新了哪些能力
+   - 做了哪些变更（新增/修改/删除/重命名需求）
+
+**增量规范格式参考**
+
+\`\`\`markdown
+## ADDED Requirements
+
+### Requirement: New Feature
+The system SHALL do something new.
+
+#### Scenario: Basic case
+- **WHEN** user does X
+- **THEN** system does Y
+
+## MODIFIED Requirements
+
+### Requirement: Existing Feature
+#### Scenario: New scenario to add
+- **WHEN** user does A
+- **THEN** system does B
+
+## REMOVED Requirements
+
+### Requirement: Deprecated Feature
+
+## RENAMED Requirements
+
+- FROM: \`### Requirement: Old Name\`
+- TO: \`### Requirement: New Name\`
+\`\`\`
+
+**关键原则：智能合并**
+
+不同于程序化合并，你可以进行 **局部更新**：
+- 只需在 MODIFIED 下加入新增场景，无需复制既有场景
+- 增量表达的是*意图*，不是整体替换
+- 依据判断做合理合并
+
+**成功时输出**
+
+\`\`\`
+## Specs Synced: <change-name>
+
+Updated main specs:
+
+**<capability-1>**:
+- Added requirement: "New Feature"
+- Modified requirement: "Existing Feature" (added 1 scenario)
+
+**<capability-2>**:
+- Created new spec file
+- Added requirement: "Another Feature"
+
+Main specs are now updated. The change remains active - archive when implementation is complete.
+\`\`\`
+
+**约束**
+- 修改前先读增量规范与主规范
+- 保留增量未提及的现有内容
+- 不清楚时先询问澄清
+- 边改边展示变更内容
+- 该操作应具备幂等性——重复执行结果相同`
+    };
+}
+/**
+ * Template for openspec-verify-change skill
+ * For verifying implementation matches change artifacts before archiving
+ */
+export function getVerifyChangeSkillTemplate() {
+    return {
+        name: 'openspec-verify-change',
+        description: '验证实现是否与变更工件匹配。适用于用户在归档前验证实现是否完整、正确且一致。',
+        instructions: `验证实现是否与变更工件（specs、tasks、design）一致。
+
+**输入**：可选指定变更名称。若省略，先从对话上下文推断；如含糊或有歧义，必须提示选择可用变更。
+
+**步骤**
+
+1. **未提供变更名称时，提示选择**
+
+   运行 \`openspec list --json\` 获取可用变更，并使用 **AskUserQuestion tool** 让用户选择。
+
+   仅展示包含实现任务的变更（存在 tasks 工件）。
+   如可用，展示每个变更使用的 schema。
+   对未完成任务的变更标记为 "(In Progress)"。
+
+   **IMPORTANT**: 不要猜测或自动选择变更，必须由用户选择。
+
+2. **检查状态以了解 schema**
+   \`\`\`bash
+   openspec status --change "<name>" --json
+   \`\`\`
+   解析 JSON 以了解：
+   - \`schemaName\`: 使用的工作流（例如 "spec-driven"、"tdd"）
+   - 该变更存在哪些工件
+
+3. **获取变更目录并加载工件**
+
+   \`\`\`bash
+   openspec instructions apply --change "<name>" --json
+   \`\`\`
+
+   该命令返回变更目录和上下文文件。读取 \`contextFiles\` 中的所有可用工件。
+
+4. **初始化验证报告结构**
+
+   构建包含三个维度的报告结构：
+   - **Completeness**：跟踪任务与规范覆盖
+   - **Correctness**：跟踪需求实现与场景覆盖
+   - **Coherence**：跟踪设计遵循与模式一致性
+
+   每个维度可能出现 CRITICAL、WARNING 或 SUGGESTION 问题。
+
+5. **验证 Completeness**
+
+   **任务完成情况**：
+   - 若 contextFiles 中存在 tasks.md，读取它
+   - 解析复选框：\`- [ ]\`（未完成）与 \`- [x]\`（完成）
+   - 统计完成数量与总数
+   - 若存在未完成任务：
+     - 为每个未完成任务添加 CRITICAL 问题
+      - 建议语："完成任务：<description>" 或 "若已实现请标记为完成"
+
+   **规范覆盖**：
+   - 若 \`openspec/changes/<name>/specs/\` 存在增量规范：
+     - 提取所有需求（以 "### Requirement:" 标记）
+     - 对每个需求：
+       - 在代码库中搜索相关关键词
+       - 评估是否存在实现迹象
+     - 若需求疑似未实现：
+        - 添加 CRITICAL 问题："未找到需求实现：<requirement name>"
+        - 建议语："实现需求 X：<description>"
+
+6. **验证 Correctness**
+
+   **需求实现映射**：
+   - 对每个增量规范需求：
+     - 搜索代码库中的实现证据
+     - 若找到，记录文件路径与行范围
+     - 评估实现是否符合需求意图
+     - 若发现偏差：
+        - 添加 WARNING："实现可能偏离规范：<details>"
+        - 建议语："对照需求 X 检查 <file>:<lines>"
+
+     **场景覆盖**：
+    - 针对增量规范中的每个场景（以 "#### Scenario:" 标记）：
+      - 检查代码中是否处理了场景条件
+      - 检查是否有覆盖该场景的测试
+      - 若场景疑似未覆盖：
+        - 添加 WARNING："场景未覆盖：<scenario name>"
+        - 建议语："为场景补充测试或实现：<description>"
+
+7. **验证 Coherence**
+
+   **设计遵循**：
+   - 若 contextFiles 中存在 design.md：
+     - 提取关键决策（查找 "Decision:"、"Approach:"、"Architecture:" 等部分）
+     - 验证实现是否遵循这些决策
+     - 若发现矛盾：
+       - 添加 WARNING："Design decision not followed: <decision>"
+       - 建议语："Update implementation or revise design.md to match reality"
+    - 若不存在 design.md：跳过设计遵循检查，并注明 "无 design.md 可供校验"
+
+   **代码模式一致性**：
+   - 审查新代码是否符合项目模式
+   - 检查文件命名、目录结构、编码风格
+   - 若偏差显著：
+     - 添加 SUGGESTION："Code pattern deviation: <details>"
+     - 建议语："Consider following project pattern: <example>"
+
+8. **生成验证报告**
+
+   **总结记分卡**：
+   \`\`\`
+   ## Verification Report: <change-name>
+
+   ### Summary
+   | Dimension    | Status           |
+   |--------------|------------------|
+   | Completeness | X/Y tasks, N reqs|
+   | Correctness  | M/N reqs covered |
+   | Coherence    | Followed/Issues  |
+   \`\`\`
+
+   **按优先级列出问题**：
+
+   1. **CRITICAL**（归档前必须修复）：
+      - 未完成任务
+      - 需求实现缺失
+      - 每条都要给出具体可执行的建议
+
+   2. **WARNING**（应修复）：
+      - 规范/设计偏差
+      - 场景覆盖缺失
+      - 每条都有明确建议
+
+   3. **SUGGESTION**（可优化）：
+      - 模式不一致
+      - 轻微改进
+      - 每条都有明确建议
+
+   **最终评估**：
+    - 若存在 CRITICAL："发现 X 个关键问题。归档前需修复。"
+    - 若仅有 WARNING："无关键问题。仍有 Y 个警告需考虑。可归档（附改进建议）。"
+    - 若全部通过："所有检查通过。可归档。"
+
+**验证启发式**
+
+- **Completeness**：关注客观清单项（复选框、需求列表）
+- **Correctness**：使用关键词搜索、路径分析、合理推断——不要求完美确定性
+- **Coherence**：关注明显不一致，不要纠结风格细节
+- **False Positives**：不确定时，优先 SUGGESTION，其次 WARNING，再到 CRITICAL
+- **Actionability**：每个问题必须有具体建议，必要时包含文件/行引用
+
+**降级策略**
+
+- 仅有 tasks.md：仅验证任务完成，跳过规范/设计
+- 有 tasks + specs：验证完整性与正确性，跳过设计
+- 全量工件：验证三个维度
+- 总是说明跳过了哪些检查以及原因
+
+**输出格式**
+
+使用清晰的 markdown：
+- 汇总记分卡表格
+- 问题分组列表（CRITICAL/WARNING/SUGGESTION）
+- 代码引用格式：\`file.ts:123\`
+- 具体、可执行的建议
+- 避免模糊措辞如 "consider reviewing"`,
+        license: 'MIT',
+        compatibility: 'Requires openspec CLI.',
+        metadata: { author: 'openspec', version: '1.0' },
+    };
+}
+/**
+ * Template for /opsx:archive slash command
+ */
+export function getOpsxArchiveCommandTemplate() {
+    return {
+        name: 'OPSX: Archive',
+        description: '在实验性工作流中归档已完成的变更',
+        category: 'Workflow',
+        tags: ['workflow', 'archive', 'experimental'],
+        content: `在实验性工作流中归档已完成的变更。
+
+**输入**：可选在 \`/opsx:archive\` 后指定变更名称（例如 \`/opsx:archive add-auth\`）。若省略，先从对话上下文推断；如含糊或有歧义，必须提示选择可用变更。
+
+**步骤**
+
+1. **未提供变更名称时，提示选择**
+
+   运行 \`openspec list --json\` 获取可用变更，并使用 **AskUserQuestion tool** 让用户选择。
+
+   仅展示活跃变更（未归档）。
+   如可用，展示每个变更使用的 schema。
+
+   **IMPORTANT**: 不要猜测或自动选择变更，必须由用户选择。
+
+2. **检查工件完成状态**
+
+   运行 \`openspec status --change "<name>" --json\` 检查工件完成情况。
+
+   解析 JSON 以了解：
+   - \`schemaName\`: 使用的工作流
+   - \`artifacts\`: 工件列表及其状态（\`done\` 或其他）
+
+   **若有工件未完成（非 \`done\`）：**
+   - 显示警告并列出未完成工件
+   - 提示用户确认继续
+   - 用户确认后继续
+
+3. **检查任务完成状态**
+
+   读取 tasks 文件（通常为 \`tasks.md\`）以检查未完成任务。
+
+   统计 \`- [ ]\`（未完成）与 \`- [x]\`（完成）数量。
+
+   **若存在未完成任务：**
+   - 显示警告并展示未完成任务数量
+   - 提示用户确认继续
+   - 用户确认后继续
+
+   **若不存在 tasks 文件：** 无需任务警告，继续。
+
+4. **评估增量规范同步状态**
+
+   检查 \`openspec/changes/<name>/specs/\` 是否存在增量规范。若不存在，无需同步提示。
+
+   **若存在增量规范：**
+   - 将每个增量规范与对应主规范 \`openspec/specs/<capability>/spec.md\` 进行对比
+   - 确定将应用的变更（新增/修改/删除/重命名）
+   - 在提示前展示合并摘要
+
+   **提示选项：**
+    - 若需要同步："立即同步（推荐）"、"不同步直接归档"
+    - 若已同步："立即归档"、"仍然同步"、"取消"
+
+   若用户选择同步，执行 \`/opsx:sync\` 逻辑。无论选择如何都继续归档流程。
+
+5. **执行归档**
+
+   若归档目录不存在则创建：
+   \`\`\`bash
+   mkdir -p openspec/changes/archive
+   \`\`\`
+
+   使用当前日期生成目标名称：\`YYYY-MM-DD-<change-name>\`
+
+   **检查目标是否已存在：**
+   - 若存在：报错并建议重命名已有归档或使用不同日期
+   - 若不存在：将变更目录移动到归档
+
+   \`\`\`bash
+   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   \`\`\`
+
+6. **展示摘要**
+
+   展示归档完成摘要，包括：
+   - 变更名称
+   - 使用的 schema
+   - 归档位置
+    - 规范同步状态（已同步 / 跳过同步 / 无增量规范）
+   - 任何警告说明（工件/任务未完成）
+
+**成功时输出**
+
+\`\`\`
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** ✓ Synced to main specs
+
+All artifacts complete. All tasks complete.
+\`\`\`
+
+**成功时输出（无增量规范）**
+
+\`\`\`
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** No delta specs
+
+All artifacts complete. All tasks complete.
+\`\`\`
+
+**成功时输出（含警告）**
+
+\`\`\`
+## Archive Complete (with warnings)
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** Sync skipped (user chose to skip)
+
+**Warnings:**
+- Archived with 2 incomplete artifacts
+- Archived with 3 incomplete tasks
+- Delta spec sync was skipped (user chose to skip)
+
+Review the archive if this was not intentional.
+\`\`\`
+
+**错误输出（归档已存在）**
+
+\`\`\`
+## Archive Failed
+
+**Change:** <change-name>
+**Target:** openspec/changes/archive/YYYY-MM-DD-<name>/
+
+Target archive directory already exists.
+
+**Options:**
+1. Rename the existing archive
+2. Delete the existing archive if it's a duplicate
+3. Wait until a different date to archive
+\`\`\`
+
+**约束**
+- 未提供变更名称时必须提示选择
+- 使用工件图（openspec status --json）检查完成情况
+- 警告不阻塞归档——只需告知并确认
+- 移动归档时保留 .openspec.yaml（随目录一起移动）
+- 清晰展示发生了什么
+- 若请求同步，使用 /opsx:sync 方法（agent-driven）
+- 若存在增量规范，必须先进行同步评估并展示合并摘要再提示`
+    };
+}
+/**
+ * Template for /opsx:bulk-archive slash command
+ */
+export function getOpsxBulkArchiveCommandTemplate() {
+    return {
+        name: 'OPSX: Bulk Archive',
+        description: '批量归档多个已完成变更',
+        category: 'Workflow',
+        tags: ['workflow', 'archive', 'experimental', 'bulk'],
+        content: `在一次操作中归档多个已完成变更。
+
+该技能允许批量归档变更，并通过检查代码库智能处理规范冲突以判断真实实现情况。
+
+**输入**：无需输入（会提示选择）
+
+**步骤**
+
+1. **获取活跃变更**
+
+   运行 \`openspec list --json\` 获取所有活跃变更。
+
+   若无活跃变更，告知用户并停止。
+
+2. **提示选择变更**
+
+   使用 **AskUserQuestion tool** 的多选让用户选择变更：
+   - 展示每个变更及其 schema
+    - 包含 "全部变更" 选项
+   - 允许选择任意数量（1+ 即可，典型为 2+）
+
+   **IMPORTANT**: 不要自动选择，必须由用户选择。
+
+3. **批量校验——收集所选变更的状态**
+
+   对每个所选变更，收集：
+
+   a. **工件状态** - 运行 \`openspec status --change "<name>" --json\`
+      - 解析 \`schemaName\` 和 \`artifacts\` 列表
+      - 记录哪些工件为 \`done\`，哪些为其他状态
+
+   b. **任务完成情况** - 读取 \`openspec/changes/<name>/tasks.md\`
+      - 统计 \`- [ ]\`（未完成）与 \`- [x]\`（完成）数量
+       - 若没有 tasks 文件，记录为 "无任务"
+
+   c. **增量规范** - 检查 \`openspec/changes/<name>/specs/\` 目录
+      - 列出存在的 capability 规范
+      - 对每个规范提取需求名称（匹配 \`### Requirement: <name>\` 的行）
+
+4. **检测规范冲突**
+
+   构建映射 \`capability -> [changes that touch it]\`：
+
+   \`\`\`
+   auth -> [change-a, change-b]  <- CONFLICT (2+ changes)
+   api  -> [change-c]            <- OK (only 1 change)
+   \`\`\`
+
+   当 2+ 个所选变更对同一 capability 存在增量规范时视为冲突。
+
+5. **以 agent 方式解决冲突**
+
+   **针对每个冲突**，调查代码库：
+
+   a. **读取各冲突变更的增量规范**，理解各自声明新增/修改内容
+
+   b. **搜索代码库** 寻找实现证据：
+      - 查找实现增量规范需求的代码
+      - 检查相关文件、函数或测试
+
+   c. **确定解决方案**：
+      - 仅一个变更实际实现 -> 同步该变更的规范
+      - 两者均已实现 -> 按时间顺序应用（先旧后新，新覆盖旧）
+      - 均未实现 -> 跳过规范同步并警告
+
+   d. **记录冲突解决方案**：
+      - 应用哪个变更的规范
+      - 应用顺序（如两者均实现）
+      - 理由（代码库发现）
+
+6. **展示汇总状态表**
+
+   展示汇总所有变更的表格：
+
+   \`\`\`
+   | Change               | Artifacts | Tasks | Specs   | Conflicts | Status |
+   |---------------------|-----------|-------|---------|-----------|--------|
+   | schema-management   | Done      | 5/5   | 2 delta | None      | Ready  |
+   | project-config      | Done      | 3/3   | 1 delta | None      | Ready  |
+   | add-oauth           | Done      | 4/4   | 1 delta | auth (!)  | Ready* |
+   | add-verify-skill    | 1 left    | 2/5   | None    | None      | Warn   |
+   \`\`\`
+
+   对于冲突，展示解决方案：
+   \`\`\`
+   * Conflict resolution:
+     - auth spec: Will apply add-oauth then add-jwt (both implemented, chronological order)
+   \`\`\`
+
+   对于未完成的变更，展示警告：
+   \`\`\`
+   Warnings:
+   - add-verify-skill: 1 incomplete artifact, 3 incomplete tasks
+   \`\`\`
+
+7. **确认批量操作**
+
+   使用 **AskUserQuestion tool** 做一次确认：
+
+    - "归档 N 个变更？" 并提供基于状态的选项
+   - 选项可能包括：
+      - "归档全部 N 个变更"
+      - "仅归档已就绪的 N 个变更（跳过未完成）"
+      - "取消"
+
+   若存在未完成的变更，要明确会带警告归档。
+
+8. **对每个确认的变更执行归档**
+
+   按确定的顺序处理变更（遵循冲突解决顺序）：
+
+   a. **如存在增量规范则先同步**：
+      - 使用 openspec-sync-specs 方法（agent-driven 智能合并）
+      - 对冲突按已解决顺序应用
+      - 记录是否已同步
+
+   b. **执行归档**：
+      \`\`\`bash
+      mkdir -p openspec/changes/archive
+      mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+      \`\`\`
+
+   c. **记录每个变更的结果**：
+      - 成功：归档成功
+      - 失败：归档时出错（记录错误）
+      - 跳过：用户选择不归档（如适用）
+
+9. **展示总结**
+
+   展示最终结果：
+
+   \`\`\`
+   ## Bulk Archive Complete
+
+   Archived 3 changes:
+   - schema-management-cli -> archive/2026-01-19-schema-management-cli/
+   - project-config -> archive/2026-01-19-project-config/
+   - add-oauth -> archive/2026-01-19-add-oauth/
+
+   Skipped 1 change:
+   - add-verify-skill (user chose not to archive incomplete)
+
+   Spec sync summary:
+   - 4 delta specs synced to main specs
+   - 1 conflict resolved (auth: applied both in chronological order)
+   \`\`\`
+
+   若有失败：
+   \`\`\`
+   Failed 1 change:
+   - some-change: Archive directory already exists
+   \`\`\`
+
+**冲突解决示例**
+
+示例 1：仅一个实现
+\`\`\`
+Conflict: specs/auth/spec.md touched by [add-oauth, add-jwt]
+
+Checking add-oauth:
+- Delta adds "OAuth Provider Integration" requirement
+- Searching codebase... found src/auth/oauth.ts implementing OAuth flow
+
+Checking add-jwt:
+- Delta adds "JWT Token Handling" requirement
+- Searching codebase... no JWT implementation found
+
+Resolution: Only add-oauth is implemented. Will sync add-oauth specs only.
+\`\`\`
+
+示例 2：两者均实现
+\`\`\`
+Conflict: specs/api/spec.md touched by [add-rest-api, add-graphql]
+
+Checking add-rest-api (created 2026-01-10):
+- Delta adds "REST Endpoints" requirement
+- Searching codebase... found src/api/rest.ts
+
+Checking add-graphql (created 2026-01-15):
+- Delta adds "GraphQL Schema" requirement
+- Searching codebase... found src/api/graphql.ts
+
+Resolution: Both implemented. Will apply add-rest-api specs first,
+then add-graphql specs (chronological order, newer takes precedence).
+\`\`\`
+
+**成功时输出**
+
+\`\`\`
+## Bulk Archive Complete
+
+Archived N changes:
+- <change-1> -> archive/YYYY-MM-DD-<change-1>/
+- <change-2> -> archive/YYYY-MM-DD-<change-2>/
+
+Spec sync summary:
+- N delta specs synced to main specs
+- No conflicts (or: M conflicts resolved)
+\`\`\`
+
+**部分成功时输出**
+
+\`\`\`
+## Bulk Archive Complete (partial)
+
+Archived N changes:
+- <change-1> -> archive/YYYY-MM-DD-<change-1>/
+
+Skipped M changes:
+- <change-2> (user chose not to archive incomplete)
+
+Failed K changes:
+- <change-3>: Archive directory already exists
+\`\`\`
+
+**无可归档变更时输出**
+
+\`\`\`
+## No Changes to Archive
+
+No active changes found. Use \`/opsx:new\` to create a new change.
+\`\`\`
+
+**约束**
+- 允许选择任意数量的变更（1+ 即可，2+ 常见）
+- 必须提示选择，禁止自动选择
+- 尽早检测规范冲突并通过代码库解决
+- 若两个变更都已实现，按时间顺序应用规范
+- 仅在缺少实现时跳过规范同步（并警告）
+- 确认前展示清晰的逐变更状态
+- 整个批次只做一次确认
+- 跟踪并汇报所有结果（成功/跳过/失败）
+- 移动归档时保留 .openspec.yaml
+- 归档目标使用当前日期：YYYY-MM-DD-<name>
+- 若归档目标已存在，该变更失败但继续处理其他`
+    };
+}
+/**
+ * Template for /opsx:verify slash command
+ */
+export function getOpsxVerifyCommandTemplate() {
+    return {
+        name: 'OPSX: Verify',
+        description: '归档前验证实现是否与变更工件匹配',
+        category: 'Workflow',
+        tags: ['workflow', 'verify', 'experimental'],
+        content: `验证实现是否与变更工件（specs、tasks、design）一致。
+
+**输入**：可选在 \`/opsx:verify\` 后指定变更名称（例如 \`/opsx:verify add-auth\`）。若省略，先从对话上下文推断；如含糊或有歧义，必须提示选择可用变更。
+
+**步骤**
+
+1. **未提供变更名称时，提示选择**
+
+   运行 \`openspec list --json\` 获取可用变更，并使用 **AskUserQuestion tool** 让用户选择。
+
+   仅展示包含实现任务的变更（存在 tasks 工件）。
+   如可用，展示每个变更使用的 schema。
+   对未完成任务的变更标记为 "(In Progress)"。
+
+   **IMPORTANT**: 不要猜测或自动选择变更，必须由用户选择。
+
+2. **检查状态以了解 schema**
+   \`\`\`bash
+   openspec status --change "<name>" --json
+   \`\`\`
+   解析 JSON 以了解：
+   - \`schemaName\`: 使用的工作流（例如 "spec-driven"、"tdd"）
+   - 该变更存在哪些工件
+
+3. **获取变更目录并加载工件**
+
+   \`\`\`bash
+   openspec instructions apply --change "<name>" --json
+   \`\`\`
+
+   该命令返回变更目录和上下文文件。读取 \`contextFiles\` 中的所有可用工件。
+
+4. **初始化验证报告结构**
+
+   构建包含三个维度的报告结构：
+   - **Completeness**：跟踪任务与规范覆盖
+   - **Correctness**：跟踪需求实现与场景覆盖
+   - **Coherence**：跟踪设计遵循与模式一致性
+
+   每个维度可能出现 CRITICAL、WARNING 或 SUGGESTION 问题。
+
+5. **验证 Completeness**
+
+   **任务完成情况**：
+   - 若 contextFiles 中存在 tasks.md，读取它
+   - 解析复选框：\`- [ ]\`（未完成）与 \`- [x]\`（完成）
+   - 统计完成数量与总数
+   - 若存在未完成任务：
+     - 为每个未完成任务添加 CRITICAL 问题
+     - 建议语："Complete task: <description>" 或 "Mark as done if already implemented"
+
+   **规范覆盖**：
+   - 若 \`openspec/changes/<name>/specs/\` 存在增量规范：
+     - 提取所有需求（以 "### Requirement:" 标记）
+     - 对每个需求：
+       - 在代码库中搜索相关关键词
+       - 评估是否存在实现迹象
+     - 若需求疑似未实现：
+        - 添加 CRITICAL 问题："未找到需求实现：<requirement name>"
+        - 建议语："实现需求 X：<description>"
+
+6. **验证 Correctness**
+
+   **需求实现映射**：
+   - 对每个增量规范需求：
+     - 搜索代码库中的实现证据
+     - 若找到，记录文件路径与行范围
+     - 评估实现是否符合需求意图
+     - 若发现偏差：
+       - 添加 WARNING："Implementation may diverge from spec: <details>"
+       - 建议语："Review <file>:<lines> against requirement X"
+
+    **场景覆盖**:
+    - 针对增量规范中的每个场景（以 "#### Scenario:" 标记）：
+      - 检查代码中是否处理了场景条件
+      - 检查是否有覆盖该场景的测试
+      - 若场景疑似未覆盖：
+        - 添加 WARNING："场景未覆盖：<scenario name>"
+        - 建议语："为场景补充测试或实现：<description>"
+
+7. **验证 Coherence**
+
+   **设计遵循**：
+   - 若 contextFiles 中存在 design.md：
+     - 提取关键决策（查找 "Decision:"、"Approach:"、"Architecture:" 等部分）
+     - 验证实现是否遵循这些决策
+     - 若发现矛盾：
+        - 添加 WARNING："设计决策未遵循：<decision>"
+        - 建议语："更新实现或修订 design.md 以符合现实"
+    - 若不存在 design.md：跳过设计遵循检查，并注明 "无 design.md 可供校验"
+
+   **代码模式一致性**：
+   - 审查新代码是否符合项目模式
+   - 检查文件命名、目录结构、编码风格
+   - 若偏差显著：
+      - 添加 SUGGESTION："代码模式偏离：<details>"
+      - 建议语："建议遵循项目模式：<example>"
+
+8. **生成验证报告**
+
+    **总结记分卡**：
+   \`\`\`
+   ## Verification Report: <change-name>
+
+   ### Summary
+   | Dimension    | Status           |
+   |--------------|------------------|
+   | Completeness | X/Y tasks, N reqs|
+   | Correctness  | M/N reqs covered |
+   | Coherence    | Followed/Issues  |
+   \`\`\`
+
+    **按优先级列出问题**：
+
+    1. **CRITICAL**（归档前必须修复）：
+       - 未完成任务
+       - 需求实现缺失
+       - 每条都有具体可执行的建议
+
+    2. **WARNING**（应修复）：
+       - 规范/设计偏差
+       - 场景覆盖缺失
+       - 每条都有明确建议
+
+    3. **SUGGESTION**（可优化）：
+       - 模式不一致
+       - 轻微改进
+       - 每条都有明确建议
+
+    **最终评估**：
+    - 若存在 CRITICAL："发现 X 个关键问题。归档前需修复。"
+    - 若仅有 WARNING："无关键问题。仍有 Y 个警告需考虑。可归档（附改进建议）。"
+    - 若全部通过："所有检查通过。可归档。"
+
+**验证启发式**
+
+ - **Completeness**：关注客观清单项（复选框、需求列表）
+ - **Correctness**：使用关键词搜索、路径分析、合理推断——不要求完美确定性
+ - **Coherence**：关注明显不一致，不要纠结风格细节
+ - **False Positives**：不确定时，优先 SUGGESTION，其次 WARNING，再到 CRITICAL
+ - **Actionability**：每个问题必须有具体建议，必要时包含文件/行引用
+
+**降级策略**
+
+ - 仅有 tasks.md：仅验证任务完成，跳过规范/设计
+ - 有 tasks + specs：验证完整性与正确性，跳过设计
+ - 全量工件：验证三个维度
+ - 总是说明跳过了哪些检查以及原因
+
+**输出格式**
+
+使用清晰的 markdown：
+- 汇总记分卡表格
+- 问题分组列表（CRITICAL/WARNING/SUGGESTION）
+- 代码引用格式：\`file.ts:123\`
+- 具体、可执行的建议
+- 避免模糊措辞如 "consider reviewing"`
+    };
+}
+/**
+ * Template for feedback skill
+ * For collecting and submitting user feedback with context enrichment
+ */
+export function getFeedbackSkillTemplate() {
+    return {
+        name: 'feedback',
+        description: '收集并提交 OpenSpec 用户反馈，包含上下文补充与匿名化处理。',
+        instructions: `帮助用户提交 OpenSpec 反馈。
+
+**目标**：引导用户收集、补充并提交反馈，同时通过匿名化确保隐私。
+
+**流程**
+
+1. **从对话中收集上下文**
+   - 回顾近期对话内容
+   - 识别正在进行的任务
+   - 记录有效或不佳之处
+   - 捕捉具体摩擦点或表扬
+
+2. **撰写补充后的反馈**
+   - 创建清晰的标题（单句，不需要 "Feedback:" 前缀）
+   - 正文需包含：
+     - 用户想做什么
+     - 实际发生了什么（好或不好）
+     - 对话中的相关上下文
+     - 具体建议或诉求
+
+3. **匿名化敏感信息**
+   - 将文件路径替换为 \`<path>\` 或泛化描述
+   - 将 API key、token、secret 替换为 \`<redacted>\`
+   - 将公司/组织名称替换为 \`<company>\`
+   - 将个人姓名替换为 \`<user>\`
+   - 将特定 URL 替换为 \`<url>\`（若非公开/必要）
+   - 保留有助于理解问题的技术细节
+
+4. **展示草稿并请求确认**
+   - 将完整草稿展示给用户
+   - 清晰呈现标题与正文
+   - 提交前请求明确确认
+   - 允许用户要求修改
+
+5. **确认后提交**
+   - 使用 \`openspec feedback\` 命令提交
+   - 格式：\`openspec feedback "title" --body "body content"\`
+   - 该命令会自动附加元数据（版本、平台、时间戳）
+
+**示例草稿**
+
+\`\`\`
+Title: Error handling in artifact workflow needs improvement
+
+Body:
+I was working on creating a new change and encountered an issue with
+the artifact workflow. When I tried to continue after creating the
+proposal, the system didn't clearly indicate that I needed to complete
+the specs first.
+
+Suggestion: Add clearer error messages that explain dependency chains
+in the artifact workflow. Something like "Cannot create design.md
+because specs are not complete (0/2 done)."
+
+Context: Using the spec-driven schema with <path>/my-project
+\`\`\`
+
+**匿名化示例**
+
+Before:
+\`\`\`
+Working on /Users/john/mycompany/auth-service/src/oauth.ts
+Failed with API key: sk_live_abc123xyz
+Working at Acme Corp
+\`\`\`
+
+After:
+\`\`\`
+Working on <path>/oauth.ts
+Failed with API key: <redacted>
+Working at <company>
+\`\`\`
+
+**约束**
+
+- 必须在提交前展示完整草稿
+- 必须请求明确确认
+- 必须匿名化敏感信息
+- 允许用户在提交前修改草稿
+- 未经用户确认不得提交
+- 应包含相关技术上下文
+- 保留对话中的关键洞见
+
+**需要用户确认**
+
+始终提问：
+\`\`\`
+Here's the feedback I've drafted:
+
+Title: [title]
+
+Body:
+[body]
+
+Does this look good? I can modify it if you'd like, or submit it as-is.
+\`\`\`
+
+仅在用户确认后继续提交。`
+    };
+}
+//# sourceMappingURL=skill-templates.js.map