@rpamis/comet 0.4.0-beta.1 → 0.4.0-beta.10

package/eval/local/skills/benchmarks/040-beta/comet-tweak/SKILL.md

@@ -0,0 +1,183 @@
+---
+name: comet-tweak
+description: "Use when 用户要进行可收敛为单一 OpenSpec change 的轻量或中等变更，且不需要完整设计；也用于恢复 tweak workflow。"
+---
+
+# Comet 预设路径：Tweak
+
+Tweak 是 Comet 五阶段能力的预设工作流，不是独立的平行流程。它串联 OpenSpec 的核心流程，复用 open、build、verify、archive 能力，仅跳过 Superpowers brainstorming 和完整 plan。
+
+适用于串联 OpenSpec 的轻量改动，例如配置调整、文档或 prompt 优化，以及需 spec 驱动（含 delta spec）但不需要完整 `/comet` 深度设计流程的中等变更。delta spec 在 tweak 中是一等公民正常产物，需要 delta spec 本身不构成升级理由。
+
+**适用条件**（必须全部满足）：
+1. 可收敛为**单一 OpenSpec change**
+2. 不需要 Superpowers Design Doc 和完整 plan 才能澄清方案
+3. 不涉及跨模块、跨层级的架构协调
+4. 任务规模可预估（文件数和任务数仅作提示，不作为硬性升级条件，见下方升级判定）
+
+**不适用**：如变更过程中命中质变信号（见「升级判定」章节），由用户决定是否升级为完整 `/comet` 流程。
+
+---
+
+## 流程（预设流程，4 阶段）
+
+### 0. 输出语言约束
+
+精简版 OpenSpec 产物必须使用触发本次工作流的用户请求语言。
+
+执行链路：open → OpenSpec apply → verify → archive。Tweak 为每个阶段提供默认决策：精简开启、通过 OpenSpec apply 直接构建、按规模与 delta spec 判定验证轻重、验证通过后进入归档前最终确认。
+
+开始前按 `comet/reference/scripts.md` 定位 Comet 脚本（定位 `comet-env.mjs`）；从任意入口恢复时先按 `comet/reference/context-recovery.md` 确认 phase/workflow。
+
+### 1. 快速开启（预设 open）
+
+复用 Comet open 能力创建 change，但使用 tweak 默认值：不执行 `openspec-explore` 长探索，直接进入精简 change 创建。
+
+**立即执行：** 使用 Skill 工具加载 `openspec-new-change` 技能。禁止跳过此步骤。
+
+技能加载后，按其指引创建精简版产物：
+  - `proposal.md` — 变更动机 + 目标 + 范围
+  - `design.md` — 简短实现说明（无需方案对比）
+  - `tasks.md` — 任务清单（建议控制在合理规模，数量本身不触发升级，见「升级判定」）
+  - `delta spec`（可选）— 若变更影响已有 spec 的验收场景，作为正常产物创建（仅含 `## MODIFIED Requirements` 或 `## ADDED Requirements`）。delta spec 是 OpenSpec brownfield 改动的核心产物，需要 delta spec 本身不构成升级理由
+
+初始化 Comet 状态文件：
+
+```bash
+node "$COMET_STATE" init <name> tweak
+```
+
+初始化后验证状态：
+
+```bash
+node "$COMET_STATE" check <name> open
+```
+
+阶段守卫完成 open → build 过渡：
+
+```bash
+node "$COMET_GUARD" <change-name> open --apply
+```
+
+### 2. OpenSpec apply 构建（tweak 专用预设 build）
+
+使用 tweak 默认值：`build_mode: direct`。跳过 Superpowers `brainstorming` 和 `writing-plans`，改由 OpenSpec 的 apply action 执行当前 change 的 tasks。
+
+<IMPORTANT>
+这条 apply 路径只属于 tweak。完整 `/comet` 或 `workflow: full` 不得套用 tweak 的 `openspec-apply-change` 构建路径；full 仍必须先通过 `/comet-design` 生成 Design Doc，再由 `/comet-build` 通过 Superpowers `writing-plans`、执行方式选择和对应执行技能完成构建。
+</IMPORTANT>
+
+继续或开始修改前，按 `comet/reference/dirty-worktree.md` 协议处理未提交改动。若归因后发现命中质变信号或文件数 tripwire，按本文件「升级判定」处理。
+
+**立即执行：** 使用 Skill 工具加载 `openspec-apply-change` 技能。禁止跳过此步骤。
+
+技能加载后，以当前 `<change-name>` 作为输入，按 `openspec-apply-change` 的指引执行 OpenSpec apply 流程：
+
+1. 运行或遵循 `openspec status --change "<name>" --json`，确认 schema 和任务 artifact
+2. 运行或遵循 `openspec instructions apply --change "<name>" --json`，读取 OpenSpec 返回的 apply 指令、`contextFiles`、任务进度和动态 instruction
+3. 读取 apply 指令列出的所有 context files，不得只凭旧对话或手写 tasks 循环实现
+4. 按 apply 指令逐个完成未勾选任务，保持改动最小且聚焦
+5. 每完成一个任务后：
+   - 运行项目格式化命令（如 `mvn spotless:apply`、`npm run format` 等）
+   - 运行相关测试确认通过
+   - 按 `openspec-apply-change` 规则将对应 task 勾选为完成
+   - 提交代码，commit message 格式：`tweak: <简述变更>`
+6. 全部任务完成后，显式运行项目相关测试和构建命令
+7. 运行阶段守卫完成 build → verify 过渡
+
+执行 tweak 期间，只要运行程序、测试、构建或手动验证时出现崩溃、异常行为、测试失败或构建失败，必须使用 Skill 工具加载 Superpowers `systematic-debugging` 技能。在完成根因调查前，不得提出或实施源码修复。
+
+具体调查、最小失败测试、修复验证和保持当前 change 验证闭环的要求，按 `comet/reference/debug-gate.md` 执行。
+
+**升级判定检查**：build 全程持续判断，并在 build→verify 守卫执行前做一次集中复核。判定采用三层分工（详见「升级判定」章节）：质变信号靠 agent 语义识别、文件数仅作提示交用户拍板、scale 脚本仅管验证轻重。命中质变信号或文件数超提示阈值时，**不得自行升级或自行判定可继续**，必须按 `comet/reference/decision-point.md` 暂停并把决策权交给用户：继续 tweak 轻量流程，还是升级为完整 `/comet`。
+
+运行阶段守卫完成 build → verify 过渡：
+
+```bash
+node "$COMET_GUARD" <change-name> build --apply
+```
+
+状态文件自动更新为 `phase: verify`、`verify_result: pending`，然后进入验证。
+
+### 3. 验证（预设 verify）
+
+复用 `/comet-verify`，由 comet-verify 的规模评估决定轻量或完整验证。
+
+**立即执行：** 使用 Skill 工具加载 `comet-verify` 技能。禁止跳过此步骤。
+
+**带 delta spec 的验证分流**：tweak 接受 delta spec 作为正常产物。若本次 change 创建了 delta spec，进入 comet-verify 前显式设置完整验证模式，走 OpenSpec 原生验证（`openspec-verify-change`）以覆盖 delta spec 一致性：
+
+```bash
+node "$COMET_STATE" set <change-name> verify_mode full
+```
+
+无 delta spec 的 tweak 通常满足轻量验证条件（≤ 3 tasks、改动文件数低于 scale 阈值），由 comet-verify 的规模评估选择轻量验证路径（6 项快速检查）。若用户希望增加审查，可在验证前运行 `node "$COMET_STATE" set <name> review_mode standard` 或 `thorough`。
+
+验证通过后，按 `/comet-verify` 的规则将 `.comet.yaml` 的 `verify_result` 记录为 `pass`，归档前不得跳过该状态。验证通过后仍必须进入 `/comet-archive` 的归档前最终确认，不得自动运行归档脚本。
+
+### 4. 归档（预设 archive）
+
+复用 `/comet-archive`。归档前必须满足 `.comet.yaml` 中 `verify_result: pass`，并等待 `/comet-archive` 的归档前最终确认。
+
+**立即执行：** 使用 Skill 工具加载 `comet-archive` 技能进行归档。禁止跳过此步骤。
+
+---
+
+## 连续执行模式
+
+<IMPORTANT>
+Tweak 流程默认 **一次性连续执行**。调用 `/comet-tweak` 后，agent 在 tweak 自有步骤间自动推进，不主动停顿。**例外**：若 `auto_transition: false`，则在每个 phase 边界（build/verify/archive 之间）停下，由用户手动运行下一阶段命令——此时连续执行降级为逐阶段手动推进，详见下方「自动衔接下一阶段」。但无论 `auto_transition` 取何值，以下情况都必须暂停等待用户确认：
+
+1. 遇到升级判定信号（见「升级判定」章节），**必须使用当前平台可用的用户输入/确认机制暂停并等待用户明确选择**：继续 tweak 轻量流程，还是升级为完整 `/comet` 流程
+2. 验证阶段（comet-verify）的验证失败决策和分支处理决策
+3. 归档前最终确认（comet-archive 执行归档脚本前）
+
+执行顺序：快速开启 → 构建（含升级判定检查）→ 验证 → 归档 → 完成
+
+每个阶段完成后立即进入下一阶段。阶段内部仍必须按上文要求调用对应 Comet/OpenSpec/Superpowers skill，被调用的 skill 如有自己的用户决策点，按该 skill 规则执行。
+</IMPORTANT>
+
+---
+
+## 升级判定
+
+tweak 的升级判定只决定是否从轻量预设转为 full；delta spec 本身不是升级理由，文件数不自动升级，`comet-state scale` 只决定验证轻重。
+
+若由 `/comet` 入口传入 intent frame，tweak 在 build 前只复核 `risk_signal` 和升级信号：新增 capability、public API、schema 变更、跨模块协调或深层架构问题。命中时进入现有升级决策点；delta spec 仍是 tweak 的正常产物，不因存在 delta spec 自动升级；不得重新实现入口意图识别。
+
+持续检查以下质变信号：跨模块协调修改、需要新增 capability、数据库 schema 变更、引入新的 public API、触及深层架构问题；以及 tweak 特有信号：需要拆分为多个 OpenSpec changes。命中任一信号时，agent **不得自行升级或自行判定可继续**。
+
+文件数 tripwire 仅作提示：改动文件数超过提示阈值（如 > 6 个文件）时，也交给用户决定继续 tweak 还是升级 full；文件数多不等于质变。tweak 常伴随 delta spec 或配置调整，波及面天然比 bug 修复宽，故提示阈值高于 hotfix。
+
+命中质变信号或文件数 tripwire 时，**必须按 `comet/reference/decision-point.md` 的协议暂停并等待用户明确选择**。不得直接进入 `/comet-design`，不得自动补充 Design Doc。
+
+用户选择升级（选项 B）后，使用状态机合法的升级通道，单条命令完成预设流程 → full 转换并回退到 design 阶段：
+
+```bash
+node "$COMET_STATE" transition <name> preset-escalate
+```
+
+该命令原子地把 `workflow`/`classic_profile` 置为 `full`、`phase` 回退到 `design`、清空 `design_doc`（满足 comet-design 入口要求）。然后在当前 change 基础上补充 Design Doc：**立即使用 Skill 工具加载 `comet-design` skill**，后续正常走完整流程。
+
+用户选择继续（选项 A）时，继续 tweak 流程，并记录用户确认继续的原因。
+
+---
+
+## 退出条件
+
+- 变更已完成，测试通过
+- change 已归档
+- 如有 spec 变更，已同步到 main spec
+- **阶段守卫**：build → verify 前运行 `node "$COMET_GUARD" <change-name> build --apply`，verify → archive 前按 `/comet-verify` 规则运行 `node "$COMET_GUARD" <change-name> verify --apply`
+
+## 自动衔接下一阶段
+
+按 `comet/reference/auto-transition.md` 执行。关键命令：
+
+```bash
+node "$COMET_STATE" next <name>
+```
+
+- `NEXT: auto` → 调用 `SKILL` 指向的 skill 继续 tweak 流程（`phase: build` 返回 `comet-tweak`，`verify` 返回 `comet-verify`，`archive` 返回 `comet-archive`）
+- `NEXT: manual` → 不要调用下一 skill，按 `HINT` 提示用户手动运行 `/<SKILL>`
+- `NEXT: done` → 流程已完成，无需继续

package/eval/local/skills/benchmarks/040-beta/comet-verify/SKILL.md

@@ -0,0 +1,230 @@
+---
+name: comet-verify
+description: "Use when Comet change 已完成 build 阶段，需要验证实现、处理验证失败决策或完成分支收尾。"
+---
+
+# Comet 阶段 4：验证与收尾（Verify）
+
+## 前置条件
+
+- 代码已提交（阶段 3 完成）
+- tasks.md 全部任务已完成
+
+## 步骤
+
+### 0a. 输出语言约束
+
+验证报告和分支处理说明必须使用触发本次工作流的用户请求语言。
+
+### 0b. 入口状态验证（Entry Check）
+
+按 `comet/reference/scripts.md` 定位脚本（定位 `comet-env.mjs`），然后执行入口验证；从任意入口恢复时先按 `comet/reference/context-recovery.md` 运行恢复检查：
+
+```bash
+node "$COMET_STATE" check <change-name> verify
+```
+
+验证通过后继续 Step 1。验证失败时脚本会输出具体失败原因。
+
+**幂等性**：verify 阶段所有检查可安全重复执行。如 `verify_result` 已为 `pass` 且 `branch_status` 已为 `handled`，说明验证已完成，直接执行 guard 流转。如 `verify_result` 为 `pending`，从头开始验证。
+
+### 1. 改动规模评估
+
+执行规模评估：
+
+```bash
+node "$COMET_STATE" scale <change-name>
+```
+
+脚本自动统计任务数、增量规格数、变更文件数，判断使用 light 或 full 验证模式，并设置 verify_mode 字段。判定规则（满足任一即 full）：任务数 > 3、delta spec 能力数 > 1、变更文件数 > 8。
+
+验证开始前，按 `comet/reference/dirty-worktree.md` 协议检查并处理未提交改动。verify 阶段的特殊处理：
+
+1. 若 dirty diff 属于当前 change 且涉及实现、测试、tasks、delta spec 或 design doc 变更，不在 verify 阶段直接修复或提交；报告失败项并进入 Step 1b 的验证失败决策阻塞点
+2. 若 dirty diff 只是 verify 本阶段产物（例如验证报告草稿、分支处理记录），可继续在 verify 阶段完成并记录状态
+3. 若 dirty diff 已实现但 tasks.md 未勾选，视为 build 状态滞后；报告失败项并进入 Step 1b，由用户决定回退修复或接受偏差
+
+用户选择修复后，才允许回退到 build 阶段：
+
+```bash
+# 仅在用户确认修复后执行
+node "$COMET_STATE" transition <change-name> verify-fail
+```
+
+注意：verify-fail 回退到 build 时 `branch_status` 不会被重置。如果首次 verify 已完成分支处理，修复后再次进入 verify 时跳过已完成的分支处理步骤，直接使用 `node "$COMET_STATE" set <change-name> branch_status handled` 保留原有分支处理结果。
+
+注意：如果 build 阶段每个任务都已提交，脚本基于工作区 diff 的文件数可能低估改动规模。此时必须读取 plan 文件头的 `base-ref` 并用提交区间复核：
+
+```bash
+PLAN=$(node "$COMET_STATE" get <change-name> plan)
+BASE_REF=$(grep '^base-ref:' "$PLAN" 2>/dev/null | head -1 | sed 's/^base-ref: *//')
+git diff --stat "$BASE_REF"...HEAD
+```
+
+若提交区间显示改动超过轻量阈值（> 8 个文件、跨模块协调、或 delta spec 超过 1 个 capability），手动设置为完整验证：
+
+```bash
+node "$COMET_STATE" set <change-name> verify_mode full
+```
+
+**覆盖机制**：如 agent 或用户认为自动评估结果不合适，可随时通过 `node "$COMET_STATE" set <change-name> verify_mode <light|full>` 手动覆盖。
+
+### 1b. 验证失败决策（阻塞点）
+
+验证不通过时**必须按 `comet/reference/decision-point.md` 的协议暂停并等待用户决定修复或接受偏差**。不得自动运行 `node "$COMET_STATE" transition <change-name> verify-fail`，也不得自动调用 `/comet-build`。
+
+暂停时必须列出：
+- 失败项
+- 是否属于 CRITICAL 或 IMPORTANT（构建失败、测试失败、安全问题、核心验收场景失败、简化代码审查发现的正确性/安全/边界问题）
+- 推荐处理方式
+
+**不确定性原则**：无法确定严重程度时，降级处理（SUGGESTION > WARNING > CRITICAL）。仅对构建失败、测试失败、安全问题使用 CRITICAL；模糊或不确定的问题标为 WARNING 或 SUGGESTION。
+
+用户选择后按以下方式继续：
+- **全部修复**：运行 `node "$COMET_STATE" transition <change-name> verify-fail`，然后调用 `/comet-build` 修复
+- **逐项处理**：CRITICAL 或 IMPORTANT 失败项必须修复；WARNING/SUGGESTION 失败项可选择接受偏差，但必须在验证报告中记录接受原因和影响范围。若存在任何 CRITICAL 或 IMPORTANT 失败项，不允许跳过修复直接全部接受
+
+**重试上限**：连续 3 次 verify-fail 循环后，第 4 次失败时代理不得自动选择继续修复；**必须使用当前平台可用的用户输入/确认机制暂停**，仅给出两个选项：「接受所有偏差并记录」或「继续修复」，由用户明确决定。
+
+### 2. 产物上下文加载（Hash 按需读）
+
+验证需要读取 OpenSpec 产物时，先检查产物是否自 design 阶段以来发生变化：
+
+```bash
+RECORDED_HASH=$(node "$COMET_STATE" get <change-name> handoff_hash)
+CURRENT_HASH=$(node "$COMET_HANDOFF" <change-name> --hash-only 2>/dev/null || echo "")
+```
+
+- 若 `RECORDED_HASH` = `CURRENT_HASH` 且均非空且均非 `null`：OpenSpec 产物未变化，**tasks.md 无需重新读取全文**（用 `grep -c '\- \[ \]' tasks.md` 确认完成数即可）。proposal.md、design.md、delta spec 仍需读取用于对照检查。
+- 若 `RECORDED_HASH` 为空、为 `null`、或与 `CURRENT_HASH` 不一致：产物已变化或 hash 未记录，正常读取所有所需文件全文。
+
+此优化仅跳过 tasks.md 的重复全文读取。proposal.md 和 design.md 包含验证检查项所需的完整上下文，不得因 hash 匹配而跳过。
+
+**立即执行：** 使用 Skill 工具加载 Superpowers `verification-before-completion` 技能。禁止跳过此步骤。
+
+技能加载后，按 verify_mode 分支执行：
+
+### 2a. 轻量验证（小改动）
+
+按以下 6 项进行检查：
+
+1. tasks.md 全部任务已完成 `[x]`
+2. 改动文件与 tasks.md 描述一致（`git diff --stat` / `git diff --cached --stat` / `git diff --stat <base-ref>...HEAD` 对照 tasks 内容）
+3. 编译通过（执行项目对应的构建命令，如 `npm run build`、`mvn compile`、`cargo build` 等）
+4. 相关测试通过
+5. 无明显安全问题（无硬编码密钥、无新增 unsafe 操作）
+6. 代码审查策略：当 `review_mode: standard` 或 `thorough` 时，必须使用 Skill 工具加载 Superpowers `requesting-code-review` 技能，请求只检查正确性、安全、边界条件的轻量代码审查；当 `review_mode: off` 时跳过自动代码审查，并在验证报告中记录跳过原因
+
+简化代码审查的输入应限定为本次改动 diff、tasks.md 和必要的测试结果；审查范围只覆盖实现正确性、安全风险和边界条件，不执行 spec 覆盖率、Design Doc 一致性或漂移检查。若审查发现 CRITICAL 或 IMPORTANT 问题，按验证失败处理并进入 Step 1b。`review_mode: off` 只跳过自动 code review，不跳过构建、测试、安全检查或异常调试协议。
+
+**与 build 阶段审查的去重**：若 build 阶段（`executing-plans` 或 `subagent-driven-development`）已按 `review_mode` 对同一 diff 完成最终代码审查，verify 的这次轻量审查聚焦「实现是否符合 spec/tasks 的正确性」与「build 之后新增的改动」，不重复评审 build 已审过且未变化的 diff。
+
+**通过标准**：6 项全部 OK，无 CRITICAL 或 IMPORTANT 问题。
+
+**不通过时**：报告失败项，进入 Step 1b 的验证失败决策阻塞点。用户选择修复后，才执行以下命令记录失败并回退到 build 阶段，然后调用 `/comet-build` 修复：
+
+```bash
+# 仅在用户确认修复后执行
+node "$COMET_STATE" transition <change-name> verify-fail
+```
+
+**报告格式**：简表列出 6 项检查结果 + PASS/FAIL。
+
+**跳过项**（不在轻量验证中检查）：
+- spec scenario 覆盖率
+- design doc 一致性深度比对
+- 不影响正确性、安全、边界条件的 code pattern consistency 建议
+- delta spec 与 design doc 漂移检测
+
+### 2b. 完整验证（大改动）
+
+当规模评估结果为"大"时：
+
+**立即执行：** 使用 Skill 工具加载 `openspec-verify-change` 技能。禁止跳过此步骤。
+
+技能加载后，按其指引验证。检查项：
+1. tasks.md 全部任务已完成（`[x]`）
+2. 实现符合 `openspec/changes/<name>/design.md` 高层设计决策
+3. 实现符合 Design Doc（`docs/superpowers/specs/` 下的技术设计文档）
+4. 能力规格场景全部通过
+5. proposal.md 目标已满足
+6. delta spec 与 design doc 无矛盾（若 Build 阶段有增量修改 spec，检查 design doc 是否有对应记录）
+7. `docs/superpowers/specs/` 关联的设计文档可定位（文件存在且与当前 change 相关）
+
+验证不通过时：报告缺失项，进入 Step 1b 的验证失败决策阻塞点。用户选择修复后，才执行以下命令记录失败并回退到 build 阶段，然后调用 `/comet-build` 补充：
+
+```bash
+# 仅在用户确认修复后执行
+node "$COMET_STATE" transition <change-name> verify-fail
+```
+
+**Spec 漂移处理**（用户决策点）：
+- 若检查项 6 发现矛盾（delta spec 有内容但 design doc 未体现），**必须使用当前平台可用的用户输入/确认机制以单选题形式暂停并等待用户选择处理方式**，不得自动选择。选项：
+  - 选项 A：在 design doc 追加 "Implementation Divergence" 节记录偏差原因。选项 A 属于 verify 阶段允许产物；写入后不得因该 design doc 变更再次触发 Step 1b dirty-worktree 决策
+  - 选项 B：用户选择 B 后，运行 `node "$COMET_STATE" transition <change-name> verify-fail`，然后调用 `/comet-build`；由 `/comet-build` 的 Spec 增量更新规则加载 Superpowers `brainstorming` 更新 Design Doc + delta spec
+  - 选项 C：确认偏差可接受，继续验证（归档时 design doc 将标记为 `superseded-by-main-spec`）
+
+### 3. 收尾（Superpowers）
+
+**立即执行：** 使用 Skill 工具加载 Superpowers `finishing-a-development-branch` 技能。禁止跳过此步骤。
+
+如 Superpowers `finishing-a-development-branch` 技能不可用，停止流程并提示安装或启用 Superpowers 技能，不要用普通对话替代该步骤。
+
+技能加载后，按其指引收尾。分支处理选项：
+1. 本地合并到主分支
+2. 推送并创建 PR
+3. 保持分支（稍后处理）
+4. 丢弃工作
+
+这是用户决策点。**必须按 `comet/reference/decision-point.md` 的协议暂停并等待用户选择分支处理方式**，不得根据推荐、默认值或当前分支状态自行选择。只有在用户完成选择且对应操作完成后，才允许写入 `branch_status: handled`。
+
+**确认项**：
+- 全部测试通过
+- 无硬编码密钥或安全问题
+
+### 4. 记录验证证据
+
+验证报告必须落盘，并在 `.comet.yaml` 中记录；分支处理完成后也必须写入状态字段。不要手动设置 `verify_result: pass`，由阶段守卫 `--apply` 推进。
+
+```bash
+mkdir -p docs/superpowers/reports
+# 将本次验证结论写入报告文件，例如：
+# docs/superpowers/reports/YYYY-MM-DD-<change-name>-verify.md
+
+node "$COMET_STATE" set <change-name> verification_report docs/superpowers/reports/YYYY-MM-DD-<change-name>-verify.md
+node "$COMET_STATE" set <change-name> branch_status handled
+```
+
+## 退出条件
+
+- 验证报告通过
+- 分支已处理
+- `.comet.yaml` 中 `verification_report` 指向已存在的验证报告文件
+- `.comet.yaml` 中 `branch_status: handled`
+- **阶段守卫**：运行 `node "$COMET_GUARD" <change-name> verify --apply`，全部 PASS 后由守卫通过 `comet-state transition verify-pass` 推进到 `phase: archive`（此步骤更新 `phase` 字段，与 `auto_transition` 无关）
+
+验证和分支处理均完成后，运行阶段守卫推进 phase（此步骤与 `auto_transition` 无关）：
+
+```bash
+node "$COMET_GUARD" <change-name> verify --apply
+```
+
+状态文件自动更新为 `phase: archive`、`verify_result: pass`、`verified_at: YYYY-MM-DD`。
+
+## 上下文压缩恢复
+
+按 `comet/reference/context-recovery.md` 执行，phase 参数为 `verify`。
+
+## 自动衔接下一阶段
+
+按 `comet/reference/auto-transition.md` 执行。关键命令：
+
+```bash
+node "$COMET_STATE" next <change-name>
+```
+
+- `NEXT: auto` → 调用 `SKILL` 指向的 skill 进入下一阶段
+- `NEXT: manual` → 不要调用下一 skill，按 `HINT` 提示用户手动运行 `/<SKILL>`
+- `NEXT: done` → 流程已完成，无需继续
+
+注意：无论 `NEXT` 为 `auto` 还是 `manual`，`comet-archive` 进入后必须先执行归档前最终确认阻塞点，等待用户明确选择「确认归档」后才允许运行归档脚本。不得因为验证已通过就自动归档。

package/eval/local/skills/benchmarks/dependency/claude-md/comet-workflow/CLAUDE.md

@@ -0,0 +1,12 @@
+# Eval Comet Workflow Contract
+
+This workspace is running a Comet workflow evaluation.
+
+You MUST begin the task by invoking the `/comet` Skill/slash command with the user's task request.
+When `/comet` routes to a nested Comet stage Skill such as `/comet-hotfix`, `/comet-open`, `/comet-build`, `/comet-verify`, or `/comet-archive`, you MUST invoke that nested Comet stage Skill with the Skill tool instead of hand-executing its instructions from memory or prose.
+When a Comet stage requires an OpenSpec or Superpowers dependency Skill, you MUST invoke that OpenSpec or Superpowers dependency Skill with the Skill tool as well. These nested and dependency Skill invocations are required eval evidence.
+Do not simulate the Comet workflow in ordinary prose.
+Do not manually create OpenSpec or Comet workflow artifacts before invoking `/comet`.
+The run is invalid unless the actual Comet Skill is invoked and leaves real OpenSpec/Comet workflow artifacts.
+
+When the Comet workflow reaches a decision point, ask the user for the required choice and then continue after the user replies.

package/eval/local/skills/benchmarks/dependency/openspec/openspec-apply-change/SKILL.md

@@ -0,0 +1,156 @@
+---
+name: openspec-apply-change
+description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.3.1"
+---
+
+Implement tasks from an OpenSpec change.
+
+**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **Select the change**
+
+   If a name is provided, use it. Otherwise:
+   - Infer from conversation context if the user mentioned a change
+   - Auto-select if only one active change exists
+   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
+
+   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
+
+2. **Check status to understand the schema**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
+
+3. **Get apply instructions**
+
+   ```bash
+   openspec instructions apply --change "<name>" --json
+   ```
+
+   This returns:
+   - `contextFiles`: artifact ID -> array of concrete file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
+   - Progress (total, complete, remaining)
+   - Task list with status
+   - Dynamic instruction based on current state
+
+   **Handle states:**
+   - If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change
+   - If `state: "all_done"`: congratulate, suggest archive
+   - Otherwise: proceed to implementation
+
+4. **Read context files**
+
+   Read every file path listed under `contextFiles` from the apply instructions output.
+   The files depend on the schema being used:
+   - **spec-driven**: proposal, specs, design, tasks
+   - Other schemas: follow the contextFiles from CLI output
+
+5. **Show current progress**
+
+   Display:
+   - Schema being used
+   - Progress: "N/M tasks complete"
+   - Remaining tasks overview
+   - Dynamic instruction from CLI
+
+6. **Implement tasks (loop until done or blocked)**
+
+   For each pending task:
+   - Show which task is being worked on
+   - Make the code changes required
+   - Keep changes minimal and focused
+   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
+   - Continue to next task
+
+   **Pause if:**
+   - Task is unclear → ask for clarification
+   - Implementation reveals a design issue → suggest updating artifacts
+   - Error or blocker encountered → report and wait for guidance
+   - User interrupts
+
+7. **On completion or pause, show status**
+
+   Display:
+   - Tasks completed this session
+   - Overall progress: "N/M tasks complete"
+   - If all done: suggest archive
+   - If paused: explain why and wait for guidance
+
+**Output During Implementation**
+
+```
+## 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
+```
+
+**Output On Completion**
+
+```
+## 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.
+```
+
+**Output On Pause (Issue Encountered)**
+
+```
+## 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?
+```
+
+**Guardrails**
+- Keep going through tasks until done or blocked
+- Always read context files before starting (from the apply instructions output)
+- If task is ambiguous, pause and ask before implementing
+- If implementation reveals issues, pause and suggest artifact updates
+- Keep code changes minimal and scoped to each task
+- Update task checkbox immediately after completing each task
+- Pause on errors, blockers, or unclear requirements - don't guess
+- Use contextFiles from CLI output, don't assume specific file names
+
+**Fluid Workflow Integration**
+
+This skill supports the "actions on a change" model:
+
+- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
+- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly