@rpamis/comet 0.3.8 → 0.4.0-beta.1

package/assets/skills-zh/comet/reference/debug-gate.md

@@ -1,8 +1,8 @@
-# Debug Gate 协议
+# 异常调试协议
 
 规范路径：`comet/reference/debug-gate.md`
 
-本协议由 build、hotfix、tweak 等会直接修改代码的 comet 子 skill 共享。当运行程序、测试、构建或手动验证时出现崩溃、异常行为、测试失败或构建失败，必须进入 Debug Gate。
+本协议由 build、hotfix、tweak 等会直接修改代码的 comet 子 skill 共享。当运行程序、测试、构建或手动验证时出现崩溃、异常行为、测试失败或构建失败，必须进入异常调试协议。
 
 ## 核心规则
 
@@ -14,4 +14,20 @@
 1. 先复现并定位根因，读取完整错误、检查近期变更、追踪数据流
 2. 若根因指向源码 bug，先补充能复现该崩溃/异常的最小失败测试，再修改源码
 3. 修复后运行该失败测试、相关测试和项目构建/验证命令，确认全部通过
-4. 将测试、源码修复和 tasks.md 勾选保留在当前 change 内；不得通过另起一个“写测试用例”的 change 来替代当前 change 的验证闭环
+4. 将测试、源码修复和 tasks.md 勾选保留在当前 change 内；不得通过另起一个“写测试用例”的 change 来替代当前 change 的验证闭环
+
+## 多失败并发调查
+
+进入四阶段流程前，先做一次失败独立性评估，决定串行还是并发调查：
+
+- **不并发（维持现有串行 `systematic-debugging`）**：失败 ≤ 2 个；失败之间相关（改一个可能修好其他）；共享状态；会改动同一批文件；尚未识别出失败是否独立
+- **并发（加载 Superpowers `dispatching-parallel-agents` 技能）**：≥ 3 个失败，且来自不同问题域（不同测试文件不同根因、不同子系统独立损坏），互不依赖、互不干扰
+
+当满足并发条件时：
+
+1. 立即使用 Skill 工具加载 Superpowers `dispatching-parallel-agents` 技能
+2. 按问题域为每个独立失败派发一个后台调查 agent，所有派发放在同一次回复里以并发执行；每个 agent 的 prompt 必须自包含（具体失败、错误信息、允许的调查范围、不得改动其他问题域的代码）
+3. 所有 agent 都受本协议“根因未明前不得动源码”的约束；它们只负责定位根因并返回调查结论，**不直接提交修复**
+4. 调查全部返回后，由主会话串行整合结论、串行执行修复，修复仍走当前 `review_mode` 的验证与评审闭环
+
+> 并发只用于**调查**阶段。修复始终串行，避免多个 agent 同时改同一批文件冲突——这与 `subagent-driven-development` “禁止并行派发多个实现 agent”的红线一致。

package/assets/skills-zh/comet/reference/decision-point.md

@@ -7,14 +7,25 @@
 ## 核心规则
 
 - 决策点是阻塞点。到达决策点时必须暂停，等待用户明确选择后才能继续
-- 必须使用当前平台可用的用户输入/确认机制获取选择
+- 必须使用当前平台可用的用户输入/确认机制获取选择；Claude Code 等平台提供 `AskUserQuestion` 时，优先使用 `AskUserQuestion` 展示单选/多选选项
+- 若当前工具列表没有 `AskUserQuestion`，或第一次调用 `AskUserQuestion` 失败，则判定本会话结构化提问不可用；本会话后续决策点不得反复重试 `AskUserQuestion`，直接使用文本选项降级模式
 - 若当前平台没有结构化提问工具，则必须在对话中提出明确选项并停止流程，等待用户回复
 - 不得用推荐规则、默认值、历史偏好或“用户应该会同意”的推断代替当前确认
 - 用户明确选择前，不得写入对应状态字段、执行对应分支操作或自动继续下一阶段
 
+## `AskUserQuestion` 优先策略
+
+使用结构化提问时：
+
+- 单选决策点用 `AskUserQuestion` 的单选问题；多选决策点用多选问题
+- 选项必须携带简短标签和影响说明；推荐项只能作为说明，不能自动选择
+- 若工具调用成功，等待用户通过该问题作答；不得同时再输出一套文本选项
+- 若工具不存在、工具调用失败或宿主报错，记录“本会话结构化提问不可用”，然后进入文本选项降级模式
+
 ## 最低呈现要求
 
 - 说明当前决策点正在决定什么
 - 给出清晰可选项；需要用户单选时，选项必须互斥且可执行
+- 文本降级模式必须明确写出“单选”或“多选”、编号选项、每项影响，并要求用户回复编号；随后停止流程，等待用户回复
 - 如有推荐，只能作为说明，不能替代用户确认
-- 用户选择后，再执行对应命令或状态更新
+- 用户选择后，再执行对应命令或状态更新

package/assets/skills-zh/comet/reference/dirty-worktree.md

@@ -1,59 +1,59 @@
-# Dirty Worktree 协议
-
-规范路径：`comet/reference/dirty-worktree.md`
-
-本协议由所有涉及代码修改的 comet 子 skill 共享。当 agent 恢复上下文或继续执行时，必须按本协议处理未提交的工作区改动。各子 skill 可在本协议基础上定义阶段特例（如 verify 阶段对实现改动的特殊处理），详见对应子 skill 文件。本文件不重复阶段特例。
-
-## 1. 检查步骤
-
-继续或开始修改前，必须先运行以下命令：
-
-```bash
-git status --short
-git diff --stat
-git diff --cached --stat
-git ls-files --others --exclude-standard
-```
-
-必要时再查看 `git diff` / `git diff --cached` / 新建文件内容。
-
-## 2. 核心规则
-
-- 用户可能不会说明自己改了哪里。只要存在 dirty worktree（包括 Git 状态里显示为 `??` 的新建文件），就先假设改动可能来自用户或混合来源
-- **构建产物排除**：`??` 文件若匹配 `.gitignore` 中的模式（如 `node_modules/`、`dist/`、`__pycache__/`、`*.o`、`target/`、`build/` 等），自动跳过归因，不视为用户改动
-- dirty worktree 只代表代码事实，不会自动推进 `.comet.yaml` 的 `phase` 或勾选 `tasks.md`；只有完成归因、验证、同步必要文档，并通过对应阶段 guard 后，才允许推进 Comet 状态
-
-## 3. 归因分类
-
-将 dirty diff 分为三类：
-
-1. **属于当前 change**：文件和内容能对应当前 change 的目标、tasks.md、plan 或 delta spec。将其纳入当前任务继续，不重复改同一处
-2. **不属于当前 change**：文件或内容与当前目标无关。暂停并询问用户：并入当前 change、拆成新 change、保留不处理，或明确授权丢弃
-3. **来源不确定**：无法从 diff 和文档判断归属。暂停并向用户汇报文件列表和判断依据，不继续推进阶段
-
-## 4. 常见处理模式
-
-### 已实现但 tasks.md 未勾选
-
-先验证实现（运行构建和测试），通过后补勾任务。不要因为任务未勾选就重做一遍，也不要因为状态文件滞后而忽略代码事实。若当前子 skill 定义了阶段特例，以子 skill 为准。
-
-### 暗示计划或范围已变化
-
-按当前子 skill 的升级、增量更新或回退规则处理，本协议不重复阶段特例。
-
-### 模糊恢复意图
-
-用户说"继续""接着跑""我改了一点""刚才不满意""重新弄""代码动过""先按现在的来"等模糊恢复意图时，按本协议处理。不要要求用户先回忆具体改了哪里。
-
-### open/design 阶段出现代码改动
-
-若当前仍处于 `open` 或 `design`，但 dirty worktree 已经包含代码改动，先按本协议归因，不要直接推进阶段：
-
-- 属于当前 change 的改动：作为需求或设计输入记录到 proposal/design/spec/design doc/tasks 中；进入 build 前仍需完成对应阶段 guard
-- 不属于当前 change 或来源不确定：暂停询问用户是并入当前 change、拆成新 change、保留不处理，还是明确授权丢弃
-- 禁止在 open/design 阶段直接把代码改动当作已完成实现并推进到 verify
-
-## 5. 禁令
-
-- 禁止在未理解 dirty diff 来源时覆盖、回滚、格式化重写或忽略用户改动
-- 禁止在 dirty diff 未解释清楚时判定验证通过
+# Dirty Worktree 协议
+
+规范路径：`comet/reference/dirty-worktree.md`
+
+本协议由所有涉及代码修改的 comet 子 skill 共享。当 agent 恢复上下文或继续执行时，必须按本协议处理未提交的工作区改动。各子 skill 可在本协议基础上定义阶段特例（如 verify 阶段对实现改动的特殊处理），详见对应子 skill 文件。本文件不重复阶段特例。
+
+## 1. 检查步骤
+
+继续或开始修改前，必须先运行以下命令：
+
+```bash
+git status --short
+git diff --stat
+git diff --cached --stat
+git ls-files --others --exclude-standard
+```
+
+必要时再查看 `git diff` / `git diff --cached` / 新建文件内容。
+
+## 2. 核心规则
+
+- 用户可能不会说明自己改了哪里。只要存在 dirty worktree（包括 Git 状态里显示为 `??` 的新建文件），就先假设改动可能来自用户或混合来源
+- **构建产物排除**：`??` 文件若匹配 `.gitignore` 中的模式（如 `node_modules/`、`dist/`、`__pycache__/`、`*.o`、`target/`、`build/` 等），自动跳过归因，不视为用户改动
+- dirty worktree 只代表代码事实，不会自动推进 `.comet.yaml` 的 `phase` 或勾选 `tasks.md`；只有完成归因、验证、同步必要文档，并通过对应阶段 guard 后，才允许推进 Comet 状态
+
+## 3. 归因分类
+
+将 dirty diff 分为三类：
+
+1. **属于当前 change**：文件和内容能对应当前 change 的目标、tasks.md、plan 或 delta spec。将其纳入当前任务继续，不重复改同一处
+2. **不属于当前 change**：文件或内容与当前目标无关。暂停并询问用户：并入当前 change、拆成新 change、保留不处理，或明确授权丢弃
+3. **来源不确定**：无法从 diff 和文档判断归属。暂停并向用户汇报文件列表和判断依据，不继续推进阶段
+
+## 4. 常见处理模式
+
+### 已实现但 tasks.md 未勾选
+
+先验证实现（运行构建和测试），通过后补勾任务。不要因为任务未勾选就重做一遍，也不要因为状态文件滞后而忽略代码事实。若当前子 skill 定义了阶段特例，以子 skill 为准。
+
+### 暗示计划或范围已变化
+
+按当前子 skill 的升级、增量更新或回退规则处理，本协议不重复阶段特例。
+
+### 模糊恢复意图
+
+用户说"继续""接着跑""我改了一点""刚才不满意""重新弄""代码动过""先按现在的来"等模糊恢复意图时，按本协议处理。不要要求用户先回忆具体改了哪里。
+
+### open/design 阶段出现代码改动
+
+若当前仍处于 `open` 或 `design`，但 dirty worktree 已经包含代码改动，先按本协议归因，不要直接推进阶段：
+
+- 属于当前 change 的改动：作为需求或设计输入记录到 proposal/design/spec/design doc/tasks 中；进入 build 前仍需完成对应阶段 guard
+- 不属于当前 change 或来源不确定：暂停询问用户是并入当前 change、拆成新 change、保留不处理，还是明确授权丢弃
+- 禁止在 open/design 阶段直接把代码改动当作已完成实现并推进到 verify
+
+## 5. 禁令
+
+- 禁止在未理解 dirty diff 来源时覆盖、回滚、格式化重写或忽略用户改动
+- 禁止在 dirty diff 未解释清楚时判定验证通过

package/assets/skills-zh/comet/reference/intent-frame.md

@@ -0,0 +1,74 @@
+# CometIntentFrame 字段参考
+
+本文件只在需要解释字段含义时读取。正常 `/comet` 路由只需按主 Skill 的最小骨架填写；runtime 会补齐省略字段并输出最终 `route`。
+
+## 顶层字段
+
+| 字段 | 含义 |
+|------|------|
+| `schema_version` | frame 版本，当前固定为 `comet.intent.v1`。 |
+| `utterance` | 触发 `/comet` 的用户原话。 |
+| `intent` | 用户高层意图和置信度。低于 runtime 阈值时会路由到 `ask_user`。 |
+| `slots` | 从用户原话归一化出来的路由槽位。 |
+| `context` | 从仓库状态读取的上下文，不是用户原话抽取结果。 |
+| `evidence` | 支撑关键判断的证据。缺少关键 evidence 时 runtime 会倾向 `ask_user`。 |
+| `proposed_route` | Agent 提交的候选路由。最小输入只需 `name` 和 `confidence`，runtime 会复核并输出最终 `route`。 |
+
+## `intent`
+
+| 字段 | 含义 |
+|------|------|
+| `intent.name` | 用户高层意图：启动、恢复、修 bug、小改、提问或未知。 |
+| `intent.confidence` | Agent 对高层意图判断的置信度。它参与低置信度 fallback；`proposed_route.confidence` 不参与。 |
+
+## `slots`
+
+| 字段 | 含义 |
+|------|------|
+| `requested_action` | 用户想执行的动作，例如 `start`、`resume`、`continue`、`fix`、`modify`、`create`、`verify`、`archive`、`question`。 |
+| `workflow_candidate` | Agent 推断的候选流程：`full`、`hotfix`、`tweak` 或 `null`。这是推断值，runtime 会复核。 |
+| `user_explicit_workflow` | 用户是否明确指定流程。用户说“走 hotfix”时填 `hotfix`；没明确说时填 `null`。显式流程与风险信号冲突时仍会 `ask_user`。 |
+| `change_id` | 用户指定要恢复或操作的 active change 名。没有指定时填 `null`。 |
+| `existing_behavior` | 是否在修复已有行为或回归。`true` 且没有新增能力/API/schema/跨模块风险时倾向 `hotfix`。 |
+| `new_capability` | 是否新增能力。命中时通常倾向 `full`。 |
+| `public_api_change` | 是否改变用户可见接口或契约，例如 CLI 参数、配置字段、输出 JSON、Skill 对外流程。命中时通常倾向 `full`。 |
+| `schema_change` | 是否改变结构化数据格式，例如 `.comet.yaml`、`run-state.json`、eval manifest、bundle manifest、配置 schema。命中时通常倾向 `full`。 |
+| `cross_module_change` | 是否跨模块或跨 workflow 边界协作。命中时通常倾向 `full`。 |
+| `target_area` | 可选解释字段，表示用户提到的目标区域。最小骨架不需要填写。 |
+| `scope` | 可选解释字段，表示粗略范围大小。当前 scorer 不让它单独主导路由，最小骨架不需要填写。 |
+
+## `context`
+
+| 字段 | 含义 |
+|------|------|
+| `active_changes_count` | `openspec list --json` 得到的未归档 active change 数量。多个 active change 且用户未指定 `change_id` 时会 `ask_user`。 |
+| `active_change_names` | active change 名称列表。用户指定 `change_id` 时，runtime 用它检查 change 是否存在。 |
+| `dirty_worktree` | 可选状态字段。入口路由最小骨架不需要填写；dirty worktree 由 `comet/reference/dirty-worktree.md` 专门处理。 |
+
+## `evidence`
+
+每条 evidence 包含：
+
+| 字段 | 含义 |
+|------|------|
+| `field` | evidence 支撑的 frame 字段，例如 `intent.name` 或 `slots.workflow_candidate`。 |
+| `quote` | 来自用户原话、仓库状态或 `.comet.yaml` 的证据片段。 |
+| `source` | 证据来源：`user`、`repo` 或 `state`。 |
+
+## `proposed_route`
+
+| 字段 | 含义 |
+|------|------|
+| `name` | Agent 候选路由：`full`、`hotfix`、`tweak`、`resume`、`ask_user` 或 `out_of_scope`。 |
+| `confidence` | Agent 对候选路由的置信度，只用于诊断，不参与低置信度 fallback。 |
+| `next_skill` | 派生字段，runtime 会规范化；最小骨架不需要填写。 |
+| `requires_confirmation` | 派生字段，runtime 会规范化；最小骨架不需要填写。 |
+| `fallback_reason` | 派生字段，runtime 会规范化；最小骨架不需要填写。 |
+
+## 路由判断要点
+
+- 修复已有异常、回归、错误行为，且没有新增能力/API/schema/跨模块风险：倾向 `hotfix`。
+- 文案、配置、文档、prompt 或单一 OpenSpec change 的轻中量修改：倾向 `tweak`。
+- 新增能力、public API、schema 变更、跨模块协调或架构调整：倾向 `full`。
+- 多个 active change 且用户没指定 change：`ask_user`。
+- 低置信度、关键 evidence 缺失、显式流程与风险信号冲突：`ask_user`。

package/assets/skills-zh/comet/reference/scripts.md

@@ -0,0 +1,69 @@
+# 脚本定位与命令
+
+规范路径：`comet/reference/scripts.md`
+
+本文件是 Comet 脚本定位和 state/guard/handoff/archive 命令面的单一事实来源。每会话加载一次，然后复用缓存的环境变量。
+
+## 引导（每会话运行一次）
+
+Comet 脚本随 skill 包分发在 `comet/scripts/` 下。**不硬编码路径** — 定位一次，缓存到环境变量。子 Skill 可以直接引用本节，只有需要完全自包含执行时才内联此块；修改时以本文件为单一事实源：
+
+```bash
+COMET_ENV="${COMET_ENV:-$(find . "$HOME"/.*/skills "$HOME/.config" "$HOME/.gemini" -path '*/comet/scripts/comet-env.mjs' -type f -print -quit 2>/dev/null)}"
+if [ -z "$COMET_ENV" ]; then
+  echo "ERROR: comet-env.mjs not found. Ensure the comet skill is installed." >&2
+  return 1
+fi
+COMET_SCRIPTS_DIR="$(node "$COMET_ENV")"
+COMET_STATE="$COMET_SCRIPTS_DIR/comet-state.mjs"
+COMET_GUARD="$COMET_SCRIPTS_DIR/comet-guard.mjs"
+COMET_HANDOFF="$COMET_SCRIPTS_DIR/comet-handoff.mjs"
+COMET_ARCHIVE="$COMET_SCRIPTS_DIR/comet-archive.mjs"
+COMET_INTENT="$COMET_SCRIPTS_DIR/comet-intent.mjs"
+
+# 脚本定位失败时停止流程
+if [ -z "$COMET_SCRIPTS_DIR" ]; then
+  echo "ERROR: Comet scripts not found. Ensure the comet skill is installed." >&2
+  return 1
+fi
+```
+
+加载 comet 后，agent 应执行以上变量赋值一次，后续全程复用 `$COMET_GUARD`、`$COMET_STATE`、`$COMET_HANDOFF`、`$COMET_ARCHIVE`、`$COMET_INTENT`。
+
+## 自动状态更新
+
+guard 支持 `--apply` 参数，验证通过后自动更新 `.comet.yaml` 状态字段：
+
+```bash
+node "$COMET_GUARD" <change-name> <phase> --apply
+```
+
+`--apply` 内部委托给 `comet-state transition`。需要直接表达状态事件时使用：
+
+```bash
+node "$COMET_STATE" transition <change-name> open-complete
+node "$COMET_STATE" transition <change-name> design-complete
+node "$COMET_STATE" transition <change-name> build-complete
+node "$COMET_STATE" transition <change-name> verify-pass
+node "$COMET_STATE" transition <change-name> verify-fail
+```
+
+归档完成由 `node "$COMET_ARCHIVE" <change-name>` 负责；OpenSpec 会把 change 移到带日期前缀的归档目录，不要手动 transition 一个 `<archive-name>`。
+
+## 解析下一步
+
+阶段守卫推进 phase 后，用 `next` 子命令解析是否自动调用下一个 skill：
+
+```bash
+node "$COMET_STATE" next <change-name>
+```
+
+输出 `NEXT: auto|manual|done` + `SKILL: <skill-name>`（`done` 时省略）+ `HINT`（仅 `manual` 时）。`auto_transition: false` 时输出 `manual`，只暂停下一 skill 调用，不影响已发生的 phase 推进。
+
+## 归档脚本
+
+一键完成归档全部步骤：
+
+```bash
+node "$COMET_ARCHIVE" <change-name>
+```

package/assets/skills-zh/comet/reference/subagent-dispatch.md

@@ -2,14 +2,14 @@
 
 规范路径：`comet/reference/subagent-dispatch.md`
 
-本文档提供在 Superpowers `subagent-driven-development` 技能**之上**应用的 Comet 专属扩展。该技能负责核心派发循环（每个 task 派发全新 implementer → spec compliance review → code quality review → 下一个 task）并强制连续执行。本文档添加 Comet 特有的真实后台调度、任务追踪、状态验证和上下文恢复。若 Superpowers 技能与本文档发生冲突时，以本文档中更具体的 Comet 约束为准。
+本文档提供在 Superpowers `subagent-driven-development` 技能**之上**应用的 Comet 专属扩展。Superpowers `subagent-driven-development` 技能提供基础连续派发循环（每个 task 派发全新 implementer，并包含默认 task reviewer 节点）并强制连续执行。本文档添加 Comet 特有的真实后台调度、任务追踪、状态验证、上下文恢复，以及审查/修复预算；Comet 的 `review_mode` 接管 reviewer 阶段，决定哪些任务需要 reviewer、需要几轮修复和最终审查。若 Superpowers 技能与本文档发生冲突时，以本文档中更具体的 Comet 约束为准。
 
 > **⚠️ 关键约束 — 任务之间禁止暂停**
 >
-> 当一个 task 通过双审查并被勾选后，**立即派发下一个 task**，不得停止、总结或询问用户是否继续。用户期望所有 task 按顺序自动执行，无需手动干预。任务之间暂停会中断工作流，导致用户每次都需要手动恢复。
+> 当一个 task 按 `review_mode` 完成验收并被勾选后，**立即派发下一个 task**，不得停止、总结或询问用户是否继续。用户期望所有 task 按顺序自动执行，无需手动干预。任务之间暂停会中断工作流，导致用户每次都需要手动恢复。
 >
 > 仅在以下情况才停止并等待用户输入：
-> - 任务处于 **BLOCKED** 状态（3 轮审查-修复仍未通过）
+> - 任务处于 **BLOCKED** 状态（`review_mode: standard` 下风险任务 1 轮 review-fix 或最终轻量复查仍未通过，或 `review_mode: thorough` 下任务级/最终审查 2 轮审查-修复仍未通过）
 > - 存在无法从仓库、计划或既有上下文消除的真实歧义
 > - 平台没有真实后台 agent 调度能力，需要用户改选 `executing-plans`
 > - 用户**明确**要求暂停
@@ -18,9 +18,10 @@
 
 ## 开始前
 
-1. 读取计划一次，按顺序提取所有未勾选 task 的完整文本。
-2. 为每个 task 保存唯一标识：plan 中 checkbox 后的完整任务文本，以及它映射的 OpenSpec task 完整文本（若存在）。若文本不唯一，停止并先修正计划，禁止依赖"第一个匹配项"。
-3. 尊重依赖关系；依赖尚未完成的 task 不得提前派发。
+1. 派发第一个 task 前，必须完成 Superpowers `subagent-driven-development` 技能的预检计划审查：扫描 plan 和全局约束中是否存在互相矛盾的要求，或 plan 明确要求但 reviewer 会判为缺陷的内容。若发现问题，实施前一次性向用户提出成组问题并附上冲突的 plan 原文；若没有问题，直接继续。
+2. 读取计划一次，按顺序提取所有未勾选 task 的完整文本。
+3. 为每个 task 保存唯一标识：plan 中 checkbox 后的完整任务文本，以及它映射的 OpenSpec task 完整文本（若存在）。若文本不唯一，停止并先修正计划，禁止依赖"第一个匹配项"。
+4. 尊重依赖关系；依赖尚未完成的 task 不得提前派发。
 
 ## 每个 Task 的 Comet 扩展
 
@@ -28,9 +29,9 @@
 
 ### 0. 派发强制约束（关键）
 
-主会话**仅负责协调**，禁止直接执行 task。主会话禁止修改源代码。协调者唯一允许的文件修改是 plan、OpenSpec task 和 subagent 进度检查点的持久化更新。不得把多个 task 打包给同一个 agent。每个 task 派发一个全新的后台 implementer agent，spec reviewer、code quality reviewer、修复 agent 和 final reviewer 也必须分别使用全新的后台 agent：
+主会话**仅负责协调**，禁止直接执行 task。主会话禁止修改源代码。协调者唯一允许的文件修改是 plan、OpenSpec task 和 subagent 进度检查点的持久化更新。不得把多个 task 打包给同一个 agent。每个 task 派发一个全新的后台 implementer agent；当 `review_mode` 需要审查或修复时，task reviewer、修复 agent 和 final reviewer 也必须分别使用全新的后台 agent：
 
-- **Claude Code**：对每个 implementer、spec reviewer、code quality reviewer、修复 agent 和 final reviewer 使用 `Agent` 工具并设置 `run_in_background: true`。禁止内联执行 task，禁止错误进入需要预先创建 team 的团队模式。
+- **Claude Code**：对每个 implementer，以及 `review_mode` 要求的 task reviewer、修复 agent 和 final reviewer 使用 `Agent` 工具并设置 `run_in_background: true`。禁止内联执行 task，禁止错误进入需要预先创建 team 的团队模式。
 - **其他平台**：使用平台等效的后台 agent / Task / 多 agent 派发机制。
 - **禁止**跨 task 或角色复用 implementer、reviewer 或修复 agent。每个 agent 拥有全新的隔离上下文，并且只接收当前角色所需的单个 task 上下文。
 - 若平台无真实后台派发能力，不得继续；暂停并等待用户改选 `build_mode: executing-plans`。
@@ -40,14 +41,40 @@
 每个 implementer 或修复 agent prompt 必须包含：
 
 - 当前单个 task 的完整文本、架构背景和依赖上下文
-- `Language: 使用触发本次工作流的用户请求语言输出`
+- `Language: 使用 "$COMET_BASH" "$COMET_STATE" get <name> language 读取到的 Comet 配置产物语言输出`
 - 允许修改的文件范围和禁止修改的范围
 - 必须执行的测试命令和提交要求
 - 修复 agent 还必须收到对应 reviewer 的完整反馈
 
-agent 回报状态必须为 `DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT`，并包含实现内容、测试结果、提交哈希、变更文件和顾虑。进入审查前，主会话必须确认提交和文件在当前工作树可见；若平台使用隔离副本，先拉取或合并变更。
+大型 task 文本、实现报告和审查材料必须通过已加载的 Superpowers `subagent-driven-development` 技能提供的文件交接机制传递，不得整段粘贴进主会话。派发 prompt 应指向这些交接产物，同时保留角色、允许范围、必跑测试、报告契约和 Comet 特有约束。Comet 可以记录 agent 回传的产物路径或短摘要用于恢复，但不得依赖这些产物的内部名称或目录布局。
 
-每个 reviewer prompt 必须包含完整 task、实现提交或差异以及 RED/GREEN 证据（`tdd_mode: tdd` 时）。reviewer 不得只依据 implementer 的总结进行审查。
+agent 回报状态必须为 `DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT`，并包含或指向实现内容、测试结果、提交哈希、变更文件和顾虑。**implementer/修复 agent 还必须回报本任务是否命中任一风险信号**（见下方清单），命中则逐条列出；这是 `review_mode: standard` 下是否派发每任务 reviewer 的第一信号源。进入审查前，主会话必须确认提交和文件在当前工作树可见；若平台使用隔离副本，先拉取或合并变更。
+
+**风险信号清单**（命中任一即视为风险任务）：
+
+- 跨模块/跨子系统协调改动
+- 安全敏感面：认证、授权、加解密、SQL、外部输入处理、密钥/凭证
+- 并发、锁、共享可变状态
+- 数据或 schema 迁移
+- 公共 API 契约或对外接口变更
+- implementer 返回 `DONE_WITH_CONCERNS`
+- 单任务 diff 超过 200 行
+
+当 `review_mode` 需要 reviewer 时，每个 reviewer prompt 必须包含或指向完整 task 需求、实现提交或差异以及 RED/GREEN 证据（`tdd_mode: tdd` 时）。reviewer 不得只依据 implementer 的总结进行审查。
+
+reviewer prompt 必须保持中立：
+
+- 不得要求 reviewer 重新运行 implementer 已经运行并报告的同一批测试；reviewer 负责核验已报告的证据和代码/diff。
+- 不得在 reviewer prompt 中预判、压低或禁止报告某个发现。若某个可能发现与 plan 冲突，让 reviewer 先报告，再询问用户以哪个要求为准。
+- 不得把之前 task 的累计历史粘贴进后续派发。只提供当前 task、相关接口/约束，以及已加载的 Superpowers `subagent-driven-development` 技能暴露的交接产物。
+
+**Model 选择（强制）**：每次派发必须显式指定 model，省略会静默继承会话最贵 model，拖慢执行并抬高成本。遵循 Superpowers `subagent-driven-development` 的 Model Selection 规则：
+
+- **implementer / 修复 agent**：用 prose 描述的实现任务至少使用中档；多文件集成、需要模式匹配或调试 → 中档；需要设计判断或广泛理解代码库 → 高档。只有当 plan 文本已含完整待写代码（转写+测试），或只是单文件机械修复时，才用最便宜档。
+- **reviewer（任务级/最终）**：按 diff 大小、复杂度和风险缩放。小机械 diff 不需要最高档；微妙并发改动才上高档。
+- **final whole-branch review**：使用可用的最高档 model，不用会话默认档。
+
+省略 model 等于让它跑会话最贵 model，直接违背本节目标。
 
 ### 2. Implementer 范围限制
 
@@ -61,27 +88,53 @@ implementer 只负责实现、测试和提交代码。**implementer 不得勾选
 You MUST follow TDD: write a failing test first, watch it fail, then write minimal code to pass. No production code without a failing test first.
 ```
 
-implementer 或修复 agent 回报必须提供 **RED 失败命令与失败摘要**、**GREEN 通过命令与通过摘要**；缺少任一证据不得进入审查。spec compliance reviewer 和 code quality reviewer 都必须核验 RED/GREEN 证据与测试覆盖。
+implementer 或修复 agent 回报必须提供 **RED 失败命令与失败摘要**、**GREEN 通过命令与通过摘要**；缺少任一证据不得进入审查。当 `review_mode` 需要 task reviewer 时，该 reviewer 必须核验 RED/GREEN 证据与测试覆盖，并同时检查 spec compliance 与 code quality。
 
 ### 4. 持久进度检查点
 
 主会话必须维护 `openspec/changes/<name>/.comet/subagent-progress.md`，并在每次派发、agent 回报、审查结果、修复轮次变化和 task 勾选后立即更新。检查点至少记录：
 
 - 当前 plan task 唯一文本及映射的 OpenSpec task 文本
-- 当前阶段：`implementing | spec-review | quality-review | checkoff | done | blocked | final-review | final-fix`
+- 当前阶段：`implementing | task-review | checkoff | done | blocked | final-review | final-fix`
 - 实现提交哈希、变更文件和 RED/GREEN 证据
+- 已选择的 `review_mode`
 - 已通过的审查阶段及尚未解决的 reviewer 反馈
-- 当前 task 或 final review 的审查-修复轮次（最多 3 轮）
+- 当前 task 或 final review 的审查-修复轮次（`standard` 最多 1 轮，`thorough` 最多 2 轮，`off` 为 0 轮）
+- `review_mode: standard` 时，本 task 是否已触发风险任务级 review 及命中的风险信号（恢复时不得重复派发已完成的任务级 review）
 
 该文件只保存恢复所需的协调状态，不替代 plan 或 OpenSpec checkbox。当前 task 完成后保留其最终记录，开始下一个 task 时用下一 task 的记录替换。
 
-### 5. 审查-修复轮次限制
+Comet 不读取、不写入、也不要求任何 Superpowers `subagent-driven-development` 内部脚本或工作区路径。如果当前安装的 Superpowers `subagent-driven-development` 技能维护自己的临时产物、审查材料、任务需求文件或进度记录，这些都由 Superpowers 自行管理。Comet 的持久事实来源只限于 Comet workflow 状态、plan/OpenSpec checkbox 和本协调检查点。
+
+### 5. 代码审查模式与轮次限制
+
+> **⚠️ CRITICAL — review_mode 接管 Superpowers 默认流程，禁止双重审查**
+>
+> Superpowers `subagent-driven-development` 的 Process 流程图把"每个 task 后派发 task reviewer"设为必经节点。**Comet 的 `review_mode` 接管这一环节，决定哪些任务派发每任务 reviewer**（见下表每任务 reviewer 列）。**不得在 review_mode 已规定的每任务 reviewer 之外，额外按 Superpowers 默认派发 reviewer**。未派发 reviewer 的任务（`off` 全部、`standard` 非风险任务）必须直接进入 task 勾选与下一个 task 的派发。
+>
+> 一个 change 的审查次数由下表唯一决定，不得自行追加。
+
+**build 阶段审查次数预算**（仅这些，不得额外增加）。本表只覆盖 build 阶段；verify 阶段有自己的审查处理（见下方说明）：
+
+| `review_mode` | build 阶段每任务 reviewer | build 阶段最终审查 |
+|---------------|--------------------------|-------------------|
+| `off` | 0 | 0 |
+| `standard` | 仅风险任务（见下方规则） | 1（轻量） |
+| `thorough` | 每个任务（spec + quality） | 1（完整） |
+
+**verify 阶段的审查不在此表内。** verify 阶段的审查由 `verify_mode`（light/full）驱动规模，`review_mode` 只决定是否触发自动代码审查（`off` 跳过；`standard`/`thorough` 在轻量验证下做一次轻量代码审查，在全量验证下依赖 `openspec-verify-change`）。verify 阶段没有按 `review_mode` 区分的独立"完整"代码审查——verify 阶段的权威行为见 `comet-verify`。
+
+当 `review_mode: standard` 时，默认不为每个 task 派发 reviewer，而是按**风险触发**决定：implementer 自测、提交并回报证据（含风险信号自报）后，协调者读取自报信号并复核该 task 的 diff。**仅当 implementer 自报命中任一风险信号、或协调者复核 diff 发现命中任一风险信号时**，为该 task 单独派发一个每任务 reviewer，同时检查 spec compliance 与 code quality，发现 CRITICAL/IMPORTANT 问题进入一轮 review-fix（最多 1 轮），复查未通过则标记 **BLOCKED**。未命中风险信号的 task 直接做定向勾选验证后放行。所有 task 完成后仍派发一次最终轻量 code reviewer（范围：正确性、安全、边界）。若最终轻量审查发现 CRITICAL 或 IMPORTANT 问题，最多自动派发一轮修复 agent 并复查一次；复查仍未通过时标记 **BLOCKED**，暂停并把反馈交给用户。非 CRITICAL 发现可记录接受理由后继续。
+
+当 `review_mode: thorough` 时，**每个 task 派发一个每任务 reviewer，同时检查 spec compliance 与 code quality**：implementer 自测、提交并回报证据后，协调者为该 task 派发一个全新后台 reviewer。reviewer 发现 CRITICAL/IMPORTANT 问题进入审查-修复（最多 2 轮），仍未通过则标记 **BLOCKED**，暂停并把反馈交给用户。所有 task 完成后再派发一次最终完整 reviewer。thorough 不做批次合并审查——高风险 change 要求每个任务即时、专注的审查，等批次边界才抓到问题代价过大。
+
+当 reviewer 返回无法仅从审查材料验证的发现时，协调者必须在 task 勾选前自行核对。若直接检查仓库后确认是真实缺口，按失败的 spec/quality review 处理，进入对应修复与复查流程；若该项已由未改动代码或跨任务约束满足，在检查点记录理由后继续。
 
-每个 task 最多 3 轮审查-修复。任一 reviewer 发现问题时，派发全新的后台修复 agent，并从对应审查重新开始。3 轮后仍未通过则将 task 标记为 **BLOCKED**，暂停并把累计反馈交给用户。
+当 `review_mode: off` 时，不自动派发 task reviewer、final reviewer 或审查修复 agent。任务完成依据 implementer 的测试/构建证据、当前工作树确认、任务唯一文本勾选验证和用户显式要求。若执行过程中出现测试失败、构建失败或异常行为，仍必须按异常调试协议处理，不得用 `off` 跳过真实问题。
 
 ### 6. Task 勾选与验证
 
-**两个审查都通过后**，主会话：
+**按 `review_mode` 完成验收后**，主会话：
 
 1. 将 plan 中保存的唯一 task 文本从 `- [ ]` 改为 `- [x]`
 2. 若存在映射，再同步勾选 OpenSpec task
@@ -89,25 +142,28 @@ implementer 或修复 agent 回报必须提供 **RED 失败命令与失败摘要
 4. 运行定向验证：
 
 ```bash
-"$COMET_BASH" "$COMET_STATE" task-checkoff "$PLAN_FILE" "$PLAN_TASK_TEXT"
-"$COMET_BASH" "$COMET_STATE" task-checkoff "openspec/changes/<name>/tasks.md" "$OPENSPEC_TASK_TEXT"
+node "$COMET_STATE" task-checkoff "$PLAN_FILE" "$PLAN_TASK_TEXT"
+node "$COMET_STATE" task-checkoff "openspec/changes/<name>/tasks.md" "$OPENSPEC_TASK_TEXT"
 ```
 
 仅在对应映射存在时运行第二条。脚本会要求任务文本恰好出现一次且该项已勾选；验证失败时不得进入下一个 task。
 
 ## 收尾
 
-- **自动继续**：双审查通过并勾选 task 后，立即派发下一个未勾选的 task。禁止总结、禁止询问用户是否继续、禁止在任务之间等待用户输入。这是不可协商的 —— Superpowers 技能强制连续执行，文档顶部的关键约束进一步强化此规则。
-- 所有 task 完成后，将检查点切换为 `final-review`，然后派发全新的后台 final code quality reviewer 审查整体实现。CRITICAL 问题必须将检查点切换为 `final-fix`，记录反馈和轮次，派发新的后台修复 agent 并重新审查；final review 同样最多 3 轮，耗尽后标记 `blocked` 并暂停。接受非 CRITICAL 发现时，在 tasks.md 中记录理由。
+- **自动继续**：按 `review_mode` 完成验收并勾选 task 后，立即派发下一个未勾选的 task。禁止总结、禁止询问用户是否继续、禁止在任务之间等待用户输入。这是不可协商的 —— Superpowers 技能强制连续执行，文档顶部的关键约束进一步强化此规则。
+- 所有 task 完成后，若 `review_mode: standard`，将检查点切换为 `final-review`，只派发一次最终轻量 code reviewer。CRITICAL 或 IMPORTANT 问题最多自动修复和复查一轮；仍未通过则暂停交给用户。通过或接受非 CRITICAL 发现后继续返回 `comet-build`。
+- 所有 task 完成后，若 `review_mode: thorough`，将检查点切换为 `final-review`，派发一次最终完整 reviewer。CRITICAL 或 IMPORTANT 问题最多自动修复和复查两轮；仍未通过则暂停交给用户。通过或接受非 CRITICAL 发现后继续返回 `comet-build`。
+- 所有 task 完成后，若 `review_mode: off`，不进入 `final-review` 或 `final-fix`，但必须在持久产物中记录跳过自动代码审查的原因，然后返回 `comet-build`。
 - final review 通过后，结束的只是 subagent 派发循环，不是 Comet workflow。不得加载 `finishing-a-development-branch`，不得停下来询问用户下一步；必须返回 `comet-build` 继续执行退出条件、阶段守卫和后续阶段衔接。
 
 ## 上下文恢复
 
 重新加载 Superpowers `subagent-driven-development` 技能并重新阅读本文档。先读取 `openspec/changes/<name>/.comet/subagent-progress.md`，再与第一个未勾选 task 和当前工作树核对：
 
-- 检查点与未勾选 task 匹配时，从记录的精确阶段恢复，保留实现提交、RED/GREEN 证据、已通过的审查阶段、未解决反馈和当前审查-修复轮次；不得重置轮次或重复已经通过的阶段。
+- 检查点与未勾选 task 匹配时，从记录的精确阶段恢复，保留实现提交、RED/GREEN 证据、`review_mode`、已通过的审查阶段、未解决反馈和当前审查-修复轮次；不得重置轮次或重复已经通过的阶段。
+- 若已加载的 Superpowers `subagent-driven-development` 技能通过自己的进度记录报告某个 task 已完成，先对照 git 历史和 Comet plan/OpenSpec checkbox 完成恢复判断。若提交和任务身份匹配，更新 Comet 检查点/勾选状态，不得重复派发已完成工作。
 - 检查点缺失或与未勾选 task 不匹配时，为第一个未勾选 task 创建新检查点并从 implementer 派发开始。
 - 检查点中的提交或文件在当前工作树不可见时，先拉取、合并或恢复对应变更；不得假定实现已存在。
 - 所有 task 已勾选且检查点处于 `final-review` 或 `final-fix` 时，从最终审查的精确阶段恢复，并保留最终反馈和审查-修复轮次；不得重新进入已完成的 task。
 
-已提交但未通过双审查的 task 保持未勾选，并按检查点重新进入审查或修复循环。
+已提交但未按 `review_mode` 完成验收的 task 保持未勾选，并按检查点重新进入对应的验证、审查或修复流程。

package/assets/skills-zh/comet/runtime/classic/checks.yaml

@@ -0,0 +1,6 @@
+runtime:
+  - id: classic-completed
+    scope: completion
+    type: state_equals
+    field: status
+    equals: completed

package/assets/skills-zh/comet/runtime/classic/guardrails.yaml

@@ -0,0 +1,13 @@
+allowedSkills:
+  - comet-open
+  - comet-design
+  - comet-build
+  - comet-verify
+  - comet-archive
+  - comet-hotfix
+  - comet-tweak
+allowedAgents: []
+allowedTools: []
+maxIterations: 500
+maxRetriesPerAction: 3
+confirmationRequiredFor: []