@rpamis/comet 0.4.0-beta.5 → 0.4.0-beta.7

package/assets/skills/comet-open/SKILL.md

@@ -13,7 +13,7 @@ description: "Use only when explicitly invoked as /comet-open or routed by the r
 
 ### 0. Output Language Constraint
 
-Every prompt and artifact request passed to OpenSpec must include the resolved Comet artifact language, using normalized ids such as `en` or `zh-CN`. Before `.comet.yaml` exists, read `language` from project `.comet/config.yaml`, then fall back to global `~/.comet/config.yaml`; after the change is initialized, use `comet state get <name> language`. If no configured language exists, fall back to the current user request language. The generated `proposal.md`, `design.md`, and `tasks.md` must use that language as their main language.
+Every prompt and artifact request passed to OpenSpec must include the resolved Comet artifact language, using normalized ids such as `en` or `zh-CN`. Before `.comet.yaml` exists, read `classic.language` from project `.comet/config.yaml`, then fall back to global `~/.comet/config.yaml`; after the change is initialized, use `comet state get <name> language`. If no configured language exists, fall back to the current user request language. The generated `proposal.md`, `design.md`, and `tasks.md` must use that language as their main language.
 
 ### 0a. Current Change Binding
 
@@ -85,7 +85,7 @@ Immediately after the user confirms multiple changes, persist the accepted split
 
 In batch split mode, entering `/comet-open` for each split item must explicitly mark it as a "confirmed split item" and carry that split item's goals, scope, non-goals, and acceptance scenarios. Confirmed split items skip the PRD split preflight by default, unless the split item itself still clearly contains multiple independent capabilities.
 
-In batch split mode, a single split item must not auto-advance to `/comet-design` after completing the open phase.
+In batch split mode, a single split item must not auto-advance to `/comet-design` after completing the open phase. After splitting is complete, must pause and ask the user which change to start; after the user chooses, advance only that change into `/comet-design`, while other changes remain active and can be resumed later through `/comet-classic`.
 
 **Batch completion hard check (must not be skipped)**: after every split item completes its own open phase, run the following for each `<name>` in the user-confirmed list:
 
@@ -103,7 +103,7 @@ The OpenSpec JSON must satisfy all of these conditions:
 
 If any split item fails these checks, must not report splitting complete or ask which change to start. Stop and resume `/comet-open` from that change's first `ready` or `blocked` artifact. If OpenSpec passes but Comet state fails, repair `.comet.yaml` initialization or phase, then rerun the checks for the entire batch.
 
-Only after every split item passes both CLI checks may you pause and ask which change to start. Mark the chosen item `selected` in the batch manifest, then advance only that change into `/comet-design`; other changes remain active and can be resumed later through `/comet`.
+Only after every split item passes both CLI checks may you pause and ask which change to start. Mark the chosen item `selected` in the batch manifest, then advance only that change into `/comet-design`; other changes remain active and can be resumed later through `/comet-classic`.
 
 On resume, read `.comet/batches/<batch-id>.json` first, then run the CLI checks above for already-created active changes. Do not recreate items that fully pass; resume incomplete items from the first `ready` artifact returned by OpenSpec. Create missing items from the persisted manifest. If the manifest is missing or damaged, stop and ask the user to rebuild/confirm it instead of inferring the original batch boundary from directory names.
 
@@ -124,7 +124,7 @@ Do not run `openspec new change` or create proposal/design/tasks while the resol
 
 **Immediately execute:** Use the Skill tool to load the `openspec-new-change` skill. Skipping this step is prohibited.
 
-Full `/comet` workflow must not use the Skill tool to load the `openspec-propose` skill by default; only load it when the user explicitly requests generating the proposal and artifacts in one pass.
+Full `/comet-classic` workflow must not use the Skill tool to load the `openspec-propose` skill by default; only load it when the user explicitly requests generating the proposal and artifacts in one pass.
 
 After the skill loads, follow its guidance to create the change skeleton. When Step 1b has produced an unambiguous resolved brief, override its "STOP and wait for user direction" behavior to avoid a duplicate question.
 

package/assets/skills/comet-tweak/SKILL.md

@@ -7,7 +7,7 @@ description: "Use only when explicitly invoked as /comet-tweak or routed by the
 
 Tweak is a preset workflow of Comet's five-phase capabilities, not an independent parallel process. It chains OpenSpec's core flow, reusing open, build, verify, archive capabilities, only skipping Superpowers brainstorming and full plan.
 
-Applicable for OpenSpec-chained lightweight changes, such as configuration adjustments, documentation or prompt optimization, and spec-driven (including delta spec) medium changes that do not need the full `/comet` deep design workflow. Delta spec is a first-class normal artifact in tweak; needing delta spec alone does not constitute an upgrade reason.
+Applicable for OpenSpec-chained lightweight changes, such as configuration adjustments, documentation or prompt optimization, and spec-driven (including delta spec) medium changes that do not need the full `/comet-classic` deep design workflow. Delta spec is a first-class normal artifact in tweak; needing delta spec alone does not constitute an upgrade reason.
 
 **Applicable conditions** (all must be met):
 1. Can fit a **single OpenSpec change**
@@ -15,7 +15,7 @@ Applicable for OpenSpec-chained lightweight changes, such as configuration adjus
 3. Does not involve cross-module or cross-layer architecture coordination
 4. Task scope is estimable (file count and task count are hints only, not hard upgrade conditions; see Upgrade Assessment below)
 
-**Not applicable**: If the change process hits a qualitative-change signal (see "Upgrade Assessment" section), the user decides whether to upgrade to the full `/comet` workflow.
+**Not applicable**: If the change process hits a qualitative-change signal (see "Upgrade Assessment" section), the user decides whether to upgrade to the full `/comet-classic` workflow.
 
 ---
 
@@ -23,7 +23,7 @@ Applicable for OpenSpec-chained lightweight changes, such as configuration adjus
 
 ### 0. Output Language Constraint
 
-Streamlined OpenSpec artifacts must use the configured Comet artifact language. Before `.comet.yaml` exists, read `language` from project `.comet/config.yaml`, then fall back to global `~/.comet/config.yaml`; after initialization, use `comet state get <name> language`.
+Streamlined OpenSpec artifacts must use the configured Comet artifact language. Before `.comet.yaml` exists, read `classic.language` from project `.comet/config.yaml`, then fall back to global `~/.comet/config.yaml`; after initialization, use `comet state get <name> language`.
 
 Execution chain: open → OpenSpec apply → verify → archive. Tweak provides default decisions for each phase: streamlined open, direct build through OpenSpec apply, scale- and delta-spec-driven verification weight, and final archive confirmation after verification passes.
 
@@ -50,14 +50,26 @@ comet state init <name> tweak
 comet state select <name>
 ```
 
-Tweak defaults to `isolation: current`, truthfully indicating execution in the current workspace. Change it to `branch` or `worktree` only after that workspace is actually created/selected.
-
 Verify initialized state:
 
 ```bash
 comet state check <name> open
 ```
 
+If the `select` / `check` output is `BLOCKED` because `bound_branch` does not match the current branch, immediately pause under `comet/reference/decision-point.md` and let the user choose one option: switch back to the bound branch and rerun entry verification, or run `comet state rebind <change-name>` after the user explicitly confirms the current branch should take over this change, then rerun entry verification. Do not switch branches or rebind on your own.
+
+Entry workspace isolation is a user decision point; do not use `current` as the default isolation mode. Pause under `comet/reference/decision-point.md` and let the user choose one option:
+
+- A. Work directly on the current branch: run `comet state set <name> isolation current` to truthfully bind the current branch
+- B. Create a branch: create and switch to `tweak/YYYYMMDD/<change-name>`, then run `comet state set <name> isolation branch`
+- C. Create a worktree: first use the Skill tool to load Superpowers `using-git-worktrees`; let that skill create the isolated workspace, then run `comet state set <name> isolation worktree` inside the worktree
+
+After B/C, rerun this in the actual execution branch or worktree:
+
+```bash
+comet state select <name>
+```
+
 Run phase guard to transition open → build:
 
 ```bash
@@ -66,10 +78,10 @@ comet guard <change-name> open --apply
 
 ### 2. OpenSpec Apply Build (tweak-only preset build)
 
-Use tweak defaults: `build_mode: direct`. Skip Superpowers `brainstorming` and `writing-plans`, and let OpenSpec's apply action execute the current change's tasks.
+Use tweak defaults: `build_mode: direct`. `isolation` must keep the entry workspace isolation the user confirmed in Step 1; do not change it back to `current` on your own. Skip Superpowers `brainstorming` and `writing-plans`, and let OpenSpec's apply action execute the current change's tasks.
 
 <IMPORTANT>
-This apply path belongs only to tweak. Full `/comet` or `workflow: full` must not use tweak's `openspec-apply-change` build path; full must still generate a Design Doc through `/comet-design`, then let `/comet-build` use Superpowers `writing-plans`, execution-method selection, and the corresponding execution skill to build.
+This apply path belongs only to tweak. Full `/comet-classic` or `workflow: full` must not use tweak's `openspec-apply-change` build path; full must still generate a Design Doc through `/comet-design`, then let `/comet-build` use Superpowers `writing-plans`, execution-method selection, and the corresponding execution skill to build.
 </IMPORTANT>
 
 Before continuing or starting changes, handle uncommitted changes through `comet/reference/dirty-worktree.md`. If attribution shows a qualitative-change signal or file-count tripwire is hit, handle it through this file's "Upgrade Assessment".
@@ -93,7 +105,7 @@ During tweak execution, whenever running programs, tests, builds, or manual veri
 
 For specific investigation, minimal failing test, fix verification, and keeping the current change verification loop, follow `comet/reference/debug-gate.md`.
 
-**Upgrade assessment check**: Continuously judge throughout build, and do a consolidated re-check before running the build→verify guard. Assessment uses a three-layer division of labor (see "Upgrade Assessment" section): qualitative-change signals rely on agent semantic recognition, file count is only a hint delegated to the user, and the scale script only governs verification weight. When a qualitative-change signal or file-count tripwire is hit, **do not upgrade on your own or decide to continue on your own** — must pause per `comet/reference/decision-point.md` and delegate the decision to the user: continue the tweak lightweight flow, or upgrade to the full `/comet`.
+**Upgrade assessment check**: Continuously judge throughout build, and do a consolidated re-check before running the build→verify guard. Assessment uses a three-layer division of labor (see "Upgrade Assessment" section): qualitative-change signals rely on agent semantic recognition, file count is only a hint delegated to the user, and the scale script only governs verification weight. When a qualitative-change signal or file-count tripwire is hit, **do not upgrade on your own or decide to continue on your own** — must pause per `comet/reference/decision-point.md` and delegate the decision to the user: continue the tweak lightweight flow, or upgrade to the full `/comet-classic`.
 
 7. Run phase guard to transition build → verify:
 
@@ -136,7 +148,7 @@ Exception: when `.comet.yaml` has `auto_transition: false`, end the current invo
 
 The following genuine user decisions still pause:
 
-1. Encountering an upgrade-assessment signal (see "Upgrade Assessment" section). **Must use the current platform's available user input/confirmation mechanism to pause and wait for the user to explicitly choose**: continue the tweak lightweight flow, or upgrade to the full `/comet` workflow
+1. Encountering an upgrade-assessment signal (see "Upgrade Assessment" section). **Must use the current platform's available user input/confirmation mechanism to pause and wait for the user to explicitly choose**: continue the tweak lightweight flow, or upgrade to the full `/comet-classic` workflow
 2. Verify-phase acceptance of WARNING/SUGGESTION deviations, Spec drift handling, or strategy after the automatic repair limit; the first 3 clearly repairable failures close automatically
 3. Final archive confirmation and the branch-handling decision after the archive commit
 
@@ -151,7 +163,7 @@ After each phase completes, immediately enter next phase. Within each phase, mus
 
 Tweak upgrade assessment only decides whether to move from the lightweight preset to full; delta spec alone is not an upgrade reason, file count never upgrades automatically, and `comet state scale` only decides verification weight.
 
-If `/comet` passes an intent frame from the entry, tweak must recheck `risk_signal` and escalation signals only before build: new capability, public API, schema change, cross-module coordination, or deep architecture work. When any signal matches, enter the existing escalation decision point. Delta spec remains a normal tweak artifact and must not trigger escalation by itself; do not reimplement entry intent recognition.
+If `/comet-classic` passes an intent frame from the entry, tweak must recheck `risk_signal` and escalation signals only before build: new capability, public API, schema change, cross-module coordination, or deep architecture work. When any signal matches, enter the existing escalation decision point. Delta spec remains a normal tweak artifact and must not trigger escalation by itself; do not reimplement entry intent recognition.
 
 Continuously check these qualitative-change signals: cross-module coordination, needing a new capability, database schema changes, introducing a new public API, or touching a deep architecture problem; plus the tweak-specific signal: needing to split into multiple OpenSpec changes. If any signal appears, the agent **must not self-upgrade or self-decide to continue**.
 

package/assets/skills/comet-verify/SKILL.md

@@ -27,6 +27,8 @@ comet state check <change-name> verify
 
 Proceed to Step 1 after verification passes. The script outputs specific failure reasons when verification fails.
 
+If the `select` / `check` output is `BLOCKED` because `bound_branch` does not match the current branch, immediately pause under `comet/reference/decision-point.md` and let the user choose one option: switch back to the bound branch and rerun entry verification, or run `comet state rebind <change-name>` after the user explicitly confirms the current branch should take over this change, then rerun entry verification. Do not switch branches or rebind on your own.
+
 **Idempotency**: All verify checks are safe to repeat. If `verify_result` is already `pass`, verification is complete and archive should continue; keep `branch_status: pending` until archive changes are committed and final branch handling finishes. If `verify_result` is `pending`, start verification from the beginning.
 
 ### 1. Scale Assessment

package/assets/skills-zh/comet/SKILL.md

@@ -1,281 +1,28 @@
 ---
 name: comet
-description: "用于用户明确调用 /comet、要求启动或恢复 Comet 托管工作流，或仓库中存在可无歧义恢复的 active Comet change；负责通过 intent runtime 和 .comet.yaml 路由阶段。"
+description: "当用户调用 /comet 或需要恢复 active Comet change 时，按项目配置路由到永久的 Comet Native 或 Comet Classic 入口。"
 ---
 
-# Comet — OpenSpec + Superpowers 双星开发流程
+# Comet 入口
 
-OpenSpec 与 Superpowers 如双星系统围绕同一目标运转。
+`/comet` 只负责选择入口，不包含任何一种工作流的执行方法。
 
-```
-OpenSpec 负责 WHAT  — 大纲、提案、spec 生命周期、归档
-Superpowers 负责 HOW — 技术设计、计划、执行、收尾
-```
+1. 先在当前项目尝试 PATH 中安装的 Comet CLI：
 
-**核心原则：brainstorming 必不可跳过。每次变更都必须经过深度设计（hotfix 和 tweak 预设除外）。**
+   ```text
+   comet workflow resolve . --json
+   ```
 
----
-
-## 决策核心（Decision Core）
-
-agent 做决策只需读本节，参考附录按需查阅。
-
-### 输出语言规则
-
-所有 OpenSpec 和 Superpowers 产物都必须使用 Comet 配置的产物语言。配置值是规范化语言 ID，`en` 或 `zh-CN`。已有 change 优先通过 `comet state get <name> language` 读取 `openspec/changes/<name>/.comet.yaml` 中的 `language`；`.comet.yaml` 尚不存在时依次读取项目 `.comet/config.yaml` 和全局 `~/.comet/config.yaml` 的 `language`；都不存在时才回退到当前用户请求语言。调用外部 OpenSpec/Superpowers skill 时，必须把解析后的语言显式写入 prompt 或 ARGUMENTS。
-
-### 阶段自动检测
-
-**Step 0: 活跃 Change 发现与意图判定**
-
-1. 先按 `comet/reference/scripts.md` 完成脚本定位，确保 `$COMET_INTENT` 可用。
-2. 运行 `openspec list --json` 获取所有活跃 change。
-3. 根据用户请求、active change 列表和必要仓库状态填写 `CometIntentFrame`。
-4. 优先用 `node "$COMET_INTENT" route --stdin` 传入 frame JSON，获取 runtime 规范化路由。`CometIntentFrame + runtime scorer` 是事实源；本节自然语言规则只用于意图识别槽位提取。
-5. 按 runtime route 处理：
-   - `hotfix` → 直接调用 `/comet-hotfix`
-   - `tweak` → 直接调用 `/comet-tweak`
-   - `full` → 按活跃 change 表决定 `/comet-open` 或用户确认
-   - `resume` → 进入 Step 1 读取对应 change 的 `.comet.yaml`
-   - `ask_user` → 按 `comet/reference/decision-point.md` 暂停并等待用户选择
-   - `out_of_scope` → 说明本次输入不是 Comet workflow 启动/恢复请求，不初始化 change
-
-当 runtime route、Ambient Resume 或用户选择已经解析出明确 change 后，进入对应阶段 Skill 前必须先绑定当前执行上下文：
-
-```bash
-comet state select <change-name>
-```
-
-多个 active change 且用户尚未明确选择时，不得提前绑定；继续按 `ask_user` 决策点等待选择。
-
-### Comet Ambient Resume
-
-当用户未显式输入 `/comet`，但当前仓库可能已有 active Comet change 时，开始处理需要改动或调查的任务前先运行只读探针：
-
-```bash
-node "$COMET_RESUME_PROBE" probe --stdin
-```
-
-探针只读仓库状态，不修改文件。按返回值处理：
-
-- `auto_resume`：输出一行 `[COMET] 检测到 active change <name>，按 <nextCommand> 恢复。`，然后进入 `nextCommand`。
-- `ask_user`：只问一个短问题并等待用户回复。
-- `out_of_scope` 或 `none`：不要进入 Comet workflow。
-
-原则：不把无关任务挂到 active Comet change，尤其不能只因为存在 `.comet.yaml` 就这样做。
-
-**CometIntentFrame 最小骨架**：
-
-```json
-{
-  "schema_version": "comet.intent.v1",
-  "utterance": "<用户原话>",
-  "intent": { "name": "start_change", "confidence": 0.8 },
-  "slots": {
-    "requested_action": "start",
-    "workflow_candidate": "full",
-    "user_explicit_workflow": null,
-    "change_id": null,
-    "existing_behavior": null,
-    "new_capability": null,
-    "public_api_change": null,
-    "schema_change": null,
-    "cross_module_change": null
-  },
-  "context": {
-    "active_changes_count": 0,
-    "active_change_names": []
-  },
-  "evidence": [],
-  "proposed_route": {
-    "name": "ask_user",
-    "confidence": 0.5
-  }
-}
-```
-
-**意图识别槽位提取**：
-字段完整含义见 `comet/reference/intent-frame.md`；正常路由只需按上方最小骨架填写。
-
-- `fix_bug` + `existing_behavior: true` + 无新增 capability/public API/schema/cross-module 信号 → 倾向 `hotfix`
-- 用户明确描述为可收敛为单一 OpenSpec change 的轻量/中等变更，需通过 OpenSpec apply 执行，且不需要完整 `/comet` 深度设计/plan → 倾向 `tweak`
-- 文案、配置、文档、prompt 或单一 OpenSpec change 的轻中量修改 → 倾向 `tweak`
-- 新增 capability、public API、schema 变更、跨模块协调或架构调整 → 倾向 `full`
-- 多个 active change 且用户未明确 change → `ask_user`
-- 置信度不足、关键 evidence 缺失或用户显式 workflow 与风险信号冲突 → `ask_user`
-
-| 活跃 change | 用户输入 | 行为 |
-|-------------|---------|------|
-| 无 | `full` 路由 | → 调用 `/comet-open` |
-| 恰好 1 个 | `/comet <描述>` | → **询问**：继续该变更 or 创建新变更 |
-| 多个 | `/comet <描述>` | → **询问**：继续现有变更 or 创建新变更；若选继续 → 列出清单让用户选择 |
-| 恰好 1 个 | `/comet`（无描述） | → 自动选中，进入 Step 1 |
-| 多个 | `/comet`（无描述） | → 列出清单让用户选择 |
-
-<IMPORTANT>
-当用户选择「创建新变更」时，**必须调用 `/comet-open`**（禁止直接调用 `/opsx:new`）。
-`/comet-open` 负责完整双初始化：OpenSpec artifacts（由内部 `/opsx:new` 创建）+ `.comet.yaml` 状态文件。
-直接调用 `/opsx:new` 会缺失 `.comet.yaml`，导致后续阶段判定失败。
-</IMPORTANT>
-
-**Step 1: 读取 `.comet.yaml` 状态元数据**
-
-优先读取 `openspec/changes/<name>/.comet.yaml`。不存在时回退到 `openspec status --change "<name>" --json`、`tasks.md` 和 `docs/superpowers/` 文件检查。
-
-**断点恢复规则**：
-- 每次恢复上下文时，先重新执行 Step 0 和 Step 1，不依赖对话历史判断阶段
-- 只要存在 active change 且工作区有未提交改动，必须按 `comet/reference/dirty-worktree.md` 协议处理。该协议定义了检查步骤、归因分类和禁令，本文件不重复
-- 若 `phase: build`，先检查 `build_pause`、`plan`、`isolation`、`build_mode`、`tdd_mode` 和 `review_mode`（详见下方）：
-  - 若 `build_pause: plan-ready` 但 `isolation`、`build_mode`、`tdd_mode` 和 `review_mode` 都已经设置，则视为 stale pause：先输出 `[COMET] 检测到 stale pause（build_pause=plan-ready 但 isolation/build_mode/tdd_mode/review_mode 已设置），自动清除并继续`，再运行 `comet state set <name> build_pause null`，然后读取 tasks.md 的下一个未勾选任务并按 `build_mode` 恢复执行
-  - 若 `build_pause: plan-ready` 且 plan 文件存在，但 `isolation`、`build_mode`、`tdd_mode` 或 `review_mode` 尚未设置，回到 `/comet-build` 的 plan-ready 恢复点，提示用户继续补齐/确认工作区隔离、执行方式、TDD 模式和代码审查模式，不重新生成 plan
-  - 若 `build_pause: plan-ready` 但 plan 文件缺失，回到 `/comet-build` 处理状态损坏或重新生成 plan
-  - 若 `isolation`、`build_mode`、`tdd_mode` 或 `review_mode` 未设置，回到 `/comet-build` 对应步骤补充后再执行
-  - 若均已设置，读取 tasks.md 的下一个未勾选任务，并按 `build_mode` 恢复执行：
-    - 若 `build_mode: subagent-driven-development`，不得在主窗口直接执行任务；必须回到 `/comet-build` 的后台 subagent 调度规则，由主窗口只做协调
-    - 其他执行方式按 `/comet-build` 的对应规则继续
-- 若 `verify_result: fail`，读取 `verify_failures`：未超过 3 次时直接调用 `/comet-build` 继续已记录的修复循环，不重复询问；超过自动修复上限时回到 `/comet-verify` 的例外决策点。只有接受 WARNING/SUGGESTION 偏差或超限后的继续/停止策略需要用户选择
-- 若 `phase: open` 但 OpenSpec `applyRequires` 已完整，先运行 `comet guard <change-name> open --apply` 修正状态，再继续判定
-- 若 `phase: archive`，只允许调用 `/comet-archive`；归档前先等待最终确认，归档后精确提交归档改动，再处理分支并运行 archive guard
-
-**Step 2: 阶段判定**（按顺序，命中即停）
-
-1. `archived: true` 或 change 已移入 archive → 流程已完成
-2. `verify_result: pass` 且 `archived` 不是 `true` → `/comet-archive`（先进行归档前最终确认）
-3. `verify_result: fail` → 自动调用 `/comet-build` 继续修复；若 `verify_failures` 已超过自动修复上限，则进入 `/comet-verify` 的超限策略决策点
-4. `phase: verify` 或 tasks.md 全部勾选 → `/comet-verify`
-5. `phase: build` 或已有 Design Doc 但计划/执行未完成 → 优先按 workflow 路由：`hotfix` → `/comet-hotfix`，`tweak` → `/comet-tweak`，`full` → `/comet-build`
-6. `phase: design` 或有 change 但无 Design Doc → `/comet-design`
-7. `phase: open` 或有活跃 change 但 `.comet.yaml` 缺失 → `/comet-open`
-8. 无活跃 change → `/comet-open`
-
-如果元数据与文件状态冲突，以文件状态为准，修正 `.comet.yaml` 后继续。
-
-### 预设升级判定
-
-hotfix/tweak 的范围判定采用三层分工，避免「用纯文件数当硬性升级条件」误杀正常小改动：
-
-1. **质变信号**（agent 语义识别，命中任一即暂停交用户二选一）：跨模块协调修改、需要新增 capability、数据库 schema 变更、引入新的 public API、触及深层架构问题（各预设沿用这套核心信号，并可追加自身语境的特有信号，如 tweak 的「需要拆分为多个 OpenSpec changes」）
-2. **文件数 tripwire**（用户拍板，非自动升级）：改动文件数超提示阈值时，暂停交用户决定继续预设流程还是升级 full，不自动踢
-3. **验证级别**（scale 脚本判定）：`comet state scale` 仅决定 `verify_mode`（验证轻重），不卡流程、不触发升级
-
-**升级决策点（用户二选一）**：
-- 继续预设轻量流程（用户确认范围可控）
-- 升级为完整 `/comet`（使用 `comet state transition <name> preset-escalate` 合法回退到 design 阶段，同时清除预设专属的 build 配置；补 Design Doc 后重新联合选择完整工作方式）
-
-详细判定规则见 `comet-hotfix` / `comet-tweak` 各自的「升级判定」章节。
-
-### 错误处理速查
-
-| 场景 | 处理方式 |
-|------|---------|
-| `openspec list --json` 失败 | 检查 openspec 是否已安装，提示 `openspec init` |
-| 子 skill 不可用 | 停止流程，提示安装或启用对应 skill |
-| `.comet.yaml` 缺失 | 进入对应 preset 的 `/comet-open` 初始化状态，再运行 `comet state select`；不得跳过初始化 |
-| `.comet.yaml` 格式异常 | 停止并报告解析错误；从版本控制、备份或可验证产物人工修复，不能用 `comet state set` 覆盖损坏文件 |
-| 构建/测试失败 | 返回 build 阶段修复，不进入 verify |
-| change 目录结构不完整 | 按 `comet-open` 产物要求补齐 |
-
-### 阶段衔接
-
-<IMPORTANT>
-单次 `/comet` 调用从检测到的阶段开始，退出条件满足后进入下一阶段。
-
-流转链：open → design → build → verify → archive
-
-**连续执行要求**：从检测到的阶段开始，agent 自动推进后续阶段。但**自动推进仅适用于没有用户决策的衔接点**。遇到用户决策点时，**必须使用当前平台可用的用户输入/确认机制暂停并等待用户明确回复**，不得用推荐规则、默认值或历史偏好代替用户确认，也不得仅输出文字提示后继续执行。
-
-**阶段推进与自动衔接的区分**：每个子 skill 退出前都会运行阶段守卫 `--apply` 推进 `.comet.yaml` 的 `phase` 字段——这一步**始终发生**，与 `auto_transition` 无关。之后子 skill 运行 `comet state next <name>` 解析下一步：`auto_transition` 不为 `false` 时输出 `NEXT: auto`（自动调用下一 skill），为 `false` 时输出 `NEXT: manual`（不调用下一 skill，按 `HINT` 交还控制权）。`NEXT: manual` 不是用户决策点，不得再询问“是否继续”。因此 `auto_transition` **只控制是否自动调用下一个 skill，不影响 phase 推进**。无论 `auto_transition` 取何值，下方真正的用户决策点都必须阻塞等待。
-
-**决策点是阻塞点**：只要到达下列任一节点，当前 `/comet` 调用必须停住，并按 `comet/reference/decision-point.md` 的协议获取用户明确选择。用户明确选择后才能写入对应状态字段、执行对应操作，随后再继续自动流转。
-
-需要用户参与的节点（仅在这些节点暂停）：
-1. workflow 目标选择：多个 active changes、继续现有 change/创建新 change、或批量拆分完成后选择先启动哪一个
-2. open 阶段 proposal/design/tasks 最终审视确认（同时确认 change 名称与范围；清晰请求不做前置摘要/命名确认）
-3. brainstorming 确认设计方案
-4. build 阶段一次性联合选择 plan-ready 暂停或完整工作方式（可用的工作区隔离 + 执行方式 + TDD 模式 + 代码审查模式；选择 branch 时同时确认分支名）
-5. verify 阶段接受 WARNING/SUGGESTION 偏差、处理 Spec 漂移，或第 4 次失败后选择继续修复/停止；前 3 次明确可修复失败自动闭环
-6. archive 阶段执行归档脚本前的最终确认
-7. 归档改动精确提交后选择 finishing-branch 分支处理方式
-8. 遇到升级判定信号（hotfix/tweak → 用户二选一：继续预设流程 / 升级完整流程）
-9. build 阶段范围扩张需重新设计或拆分新 change
-10. open 阶段大型 PRD 是否拆分为多个 changes
-
-agent 不应跳过这些决策点；其他明确无歧义的阶段衔接必须自动继续推进，不得中途退出。到达决策点时，**禁止跳过用户确认或自动选择——必须通过当前平台可用的用户输入/确认机制明确获取用户选择后才能继续**。
-
-**红旗清单** — 以下想法出现时立即停止并检查：
-
-| Agent 心理 | 实际风险 |
-|-----------|---------|
-| "用户应该会同意这个方案" | 不能替用户决策，必须等待用户明确选择 |
-| "这只是个小改动，不需要确认" | 决策点无大小之分，阻塞点必须等待 |
-| "用户之前选过 A，这次也选 A" | 历史偏好不能替代当前确认 |
-| "我已经解释了方案，用户没反对" | 没反对 ≠ 同意，必须用工具获取明确选择 |
-| "流程走到这里应该没问题了" | 验证不通过 ≠ 通过，检查 verify_result |
-</IMPORTANT>
-
----
-
-## 子命令速查
-
-| 命令 | 阶段 | 归属 | 产物 |
-|------|------|------|------|
-| `/comet-open` | 1. 开启 | OpenSpec | proposal.md、design.md、tasks.md |
-| `/comet-design` | 2. 深度设计 | Superpowers | Design Doc、delta spec |
-| `/comet-build` | 3. 计划与构建 | Superpowers | 实施计划、代码提交 |
-| `/comet-verify` | 4. 验证 | Both | 验证报告 |
-| `/comet-archive` | 5. 归档与收尾 | OpenSpec | delta→main spec 同步、design doc 标注、归档提交、分支处理 |
-| `/comet-hotfix` | 预设路径 | Both | 快速修复（跳过 brainstorming） |
-| `/comet-tweak` | 预设路径 | Both | 串联 OpenSpec 的中等改动（delta spec 为一等公民，跳过 brainstorming 和完整 plan） |
-
-```
-/comet
-  ↓ 自动检测
-/comet-open ──→ /comet-design ──→ /comet-build ──→ /comet-verify ──→ /comet-archive
-  (OpenSpec)      (Superpowers)     (Superpowers)     (Both)          (OpenSpec)
-
-/comet-hotfix（预设路径，跳过 brainstorming）
-  open ──→ build ──→ verify ──→ archive
-    ↑ 命中升级判定信号 → 用户二选一（继续预设流程 / 升级 full）→ 升级则 transition preset-escalate → 补 Design Doc → 回到完整流程
-
-/comet-tweak（轻量预设路径，串联 OpenSpec，delta spec 为一等公民）
-  open ──→ build ──→ verify ──→ archive
-    ↑ 命中升级判定信号 → 用户二选一（继续预设流程 / 升级 full）→ 升级则 transition preset-escalate → 补 Design Doc → 回到完整流程
-```
-
----
-
-## 参考附录（Reference Appendix）
-
-> 字段说明、文件结构和自动衔接协议已提取为渐进式加载参考文档，按需查阅：
-> - **`.comet.yaml` 完整字段表**：按 `comet/reference/comet-yaml-fields.md` 查阅（含必需字段、可选字段和完整示例）
-> - **文件结构**：按 `comet/reference/file-structure.md` 查阅
-> - **自动衔接协议**：按 `comet/reference/auto-transition.md` 查阅
-> - **上下文压缩恢复**：按 `comet/reference/context-recovery.md` 查阅
-> - **用户决策点协议**：按 `comet/reference/decision-point.md` 查阅
-> - **异常调试协议**：按 `comet/reference/debug-gate.md` 查阅
-
-### 状态机硬约束
-
-- full workflow 的 `build → verify` 前，`isolation` 必须是 `branch` 或 `worktree`；hotfix/tweak 可如实使用 `current`
-- `build → verify` 前，`build_mode` 必须已选择
-- `build_mode: subagent-driven-development` 必须同时有 `subagent_dispatch: confirmed`
-- full workflow 离开 build 阶段前 `tdd_mode` 必须已选择为 `tdd` 或 `direct`
-- full workflow 离开 build 阶段前 `review_mode` 必须已选择为 `off`、`standard` 或 `thorough`
-- `build_mode: direct` 默认只允许 `hotfix` / `tweak`；full workflow 需要 `direct_override: true`
-- `build_pause` 不是执行方式，不得写入 `build_mode`
-- 这些约束同时由 `comet guard <name> build --apply` 和 `comet state transition <name> build-complete` 执行
-
-### 脚本定位
-
-面向 workflow 的状态、守卫、handoff 和 archive 操作统一使用稳定 `comet` CLI；只有尚无公开子命令的 intent/resume probe 才按 `comet/reference/scripts.md` 定位内部 launcher。关键入口：
+2. **只有**宿主明确报告 `command not found`、`executable not found` 或 `ENOENT`，能够证明 `comet` 不在 PATH 时，才从当前 `SKILL.md` 所在目录定位 `<comet-skill-root>`，运行自带入口 runtime：
 
-```bash
-comet guard <change-name> <phase> --apply             # 阶段守卫 + 自动状态更新
-comet state transition <change-name> <event>          # open-complete | design-complete | build-complete | verify-pass | verify-fail
-comet state next <change-name>                        # NEXT: auto|manual|done + SKILL: <skill-name>
-comet archive <change-name>                           # 一键完成归档
-```
+   ```text
+   node <comet-skill-root>/scripts/comet-entry-runtime.mjs . --json
+   ```
 
-### 文件结构
+   CLI 已启动但返回非零、配置解析失败、输出不是 JSON 或字段无效，都不得使用 bundled runtime 重试；停止并原样说明错误，不要回退或猜测。
+3. 解析 JSON。只接受 `schema: comet.workflow-resolution.v1`，且 `skill` 必须是下列两个值之一。
+4. 只按返回的 `skill` 调用一个入口，并把用户原始请求完整交给它：
+   - `comet-native` → `/comet-native`
+   - `comet-classic` → `/comet-classic`
 
-按 `comet/reference/file-structure.md` 查阅完整目录结构。
+不根据任务大小、文件数量、活跃 change 或模型判断改选另一套工作流。Native 与 Classic 的 change、状态和产物始终彼此独立。

package/assets/skills-zh/comet/reference/comet-yaml-fields.md

@@ -20,6 +20,7 @@ tdd_mode: tdd
 review_mode: standard
 auto_transition: true
 isolation: branch
+bound_branch: null
 verify_mode: light
 verify_result: pending
 verify_failures: 0
@@ -36,7 +37,7 @@ archived: false
 | 字段 | 含义 |
 |------|------|
 | `workflow` | `full`、`hotfix` 或 `tweak` |
-| `language` | 产物语言，仅支持 `en` 或 `zh-CN`。由 `comet init` 按安装范围写入项目或全局 `.comet/config.yaml`，创建 change 时按“项目优先、全局回退”快照到 `.comet.yaml`，用于约束 OpenSpec / Superpowers 产物主语言 |
+| `language` | 产物语言，仅支持 `en` 或 `zh-CN`。由 `comet init` 按安装范围写入项目或全局 `.comet/config.yaml` 的 `classic.language`，创建 change 时按“项目优先、全局回退”快照到 `.comet.yaml`，用于约束 OpenSpec / Superpowers 产物主语言 |
 | `phase` | 当前阶段：`open`、`design`、`build`、`verify`、`archive`（init 统一设为 `open`，guard 负责过渡） |
 | `design_doc` | 关联的 Superpowers Design Doc 路径，可为空 |
 | `plan` | 关联的 Superpowers Plan 路径，可为空 |
@@ -46,7 +47,8 @@ archived: false
 | `subagent_dispatch` | `null` 或 `confirmed`。仅当已确认当前平台存在真实后台 subagent / Task / multi-agent 调度能力时，`build_mode: subagent-driven-development` 才能写入并用于离开 build 阶段 |
 | `tdd_mode` | `tdd` 或 `direct`。full workflow 离开 build 阶段前必须已选择。`tdd` 强制每个任务先写失败测试再实现；`direct` 不强制逐任务 TDD，但仍需相关测试与 bug 回归证据。hotfix/tweak 默认 `direct` |
 | `review_mode` | `off`、`standard` 或 `thorough`。full workflow 离开 build 阶段前必须已选择；hotfix/tweak 默认 `off` |
-| `isolation` | `current`、`branch` 或 `worktree`。full 初始化可为 `null`，离开 build 前必须实际创建/选择 `branch` 或 `worktree`；hotfix/tweak 默认 `current`，不得在未创建分支时虚构为 `branch` |
+| `isolation` | `current`、`branch` 或 `worktree`。full 初始化可为 `null`，离开 build 前必须由用户显式选择 `current`、实际创建/选择 `branch`，或实际创建/选择 `worktree`；hotfix/tweak 在入口用户决策点后也可如实使用三种模式，不得在未创建分支时虚构为 `branch` |
+| `bound_branch` | 工作区分支绑定记录，可为空。`isolation: current` / `branch` / `worktree` 首次设置或入口检查时记录命令执行目录所在的当前 Git 分支（worktree 模式请在对应工作区内执行 set/check/guard，否则会绑定/比对错误的分支）；在不同工作区模式之间切换 `isolation` 会重新绑定到当前分支，重复设置同一模式保持原绑定。后续 `comet state select` / `comet state check` 必须确认绑定分支与当前分支一致；漂移时 `select` 直接拒绝、检查进入 `BLOCKED`，按决策点协议让用户选择切回绑定分支或明确确认后运行 `comet state rebind <change-name>`。清空 `isolation` 时会清空该字段 |
 | `verify_mode` | `light` 或 `full`，可为空 |
 | `auto_transition` | `true` 或 `false`。只控制阶段守卫推进 phase 后是否自动调用下一个 skill；`false` 时由 `comet-state next` 输出 `manual`，暂停下一 skill 调用，但不阻止 phase 字段更新 |
 | `verify_result` | `pending`、`pass` 或 `fail` |
@@ -66,7 +68,7 @@ archived: false
 
 ## 状态机硬约束
 
-- full workflow 的 `build → verify` 前，`isolation` 必须是 `branch` 或 `worktree`；hotfix/tweak 可使用 `current`
+- `build → verify` 前，`isolation` 必须是 `current`、`branch` 或 `worktree`
 - `build → verify` 前，`build_mode` 必须已选择
 - `build_mode: subagent-driven-development` 必须同时有 `subagent_dispatch: confirmed`
 - full workflow 离开 build 阶段前 `tdd_mode` 必须已选择为 `tdd` 或 `direct`

package/assets/skills-zh/comet/reference/context-recovery.md

@@ -12,11 +12,11 @@
 comet state check <change-name> <phase> --recover
 ```
 
-若检查结果显示实际 phase、workflow 或 evidence 应由其他 Skill 处理，按脚本输出和 `/comet` 路由规则切换；不要在错误阶段继续补写状态。若存在未提交改动，先按 `comet/reference/dirty-worktree.md` 归因。
+若检查结果显示实际 phase、workflow 或 evidence 应由其他 Skill 处理，按脚本输出和 `/comet-classic` 路由规则切换；不要在错误阶段继续补写状态。若存在未提交改动，先按 `comet/reference/dirty-worktree.md` 归因。
 
-## 未显式 `/comet` 的恢复
+## 未显式 `/comet-classic` 的恢复
 
-如果用户没有提 `/comet`，但本仓库可能有 active change，开始处理需要改动或调查的任务前先运行 Ambient Resume 探针。先按 `comet/reference/scripts.md` 定位脚本并确保 `$COMET_RESUME_PROBE` 可用，然后把当前用户请求从 stdin 传入：
+如果用户没有提 `/comet-classic`，但本仓库可能有 active Classic change，开始处理需要改动或调查的任务前先运行 Ambient Resume 探针。先按 `comet/reference/scripts.md` 定位脚本并确保 `$COMET_RESUME_PROBE` 可用，然后把当前用户请求从 stdin 传入：
 
 ```bash
 node "$COMET_RESUME_PROBE" probe --stdin

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

@@ -1,13 +1,13 @@
 # CometIntentFrame 字段参考
 
-本文件只在需要解释字段含义时读取。正常 `/comet` 路由只需按主 Skill 的最小骨架填写；runtime 会补齐省略字段并输出最终 `route`。
+本文件只在需要解释字段含义时读取。正常 `/comet-classic` 路由只需按主 Skill 的最小骨架填写；runtime 会补齐省略字段并输出最终 `route`。
 
 ## 顶层字段
 
 | 字段 | 含义 |
 |------|------|
 | `schema_version` | frame 版本，当前固定为 `comet.intent.v1`。 |
-| `utterance` | 触发 `/comet` 的用户原话。 |
+| `utterance` | 触发 `/comet-classic` 的用户原话。 |
 | `intent` | 用户高层意图和置信度。低于 runtime 阈值时会路由到 `ask_user`。 |
 | `slots` | 从用户原话归一化出来的路由槽位。 |
 | `context` | 从仓库状态读取的上下文，不是用户原话抽取结果。 |

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

@@ -24,7 +24,7 @@ guard 的 `--apply` 在检查通过后推进状态。需要直接表达状态事
 
 ## 兼容、恢复与内部命令引导
 
-以下脚本定位只用于旧版兼容、CLI 不可用时的恢复，以及 `/comet` 内部入口命令。正常公开工作流不得优先采用此方式。Comet 脚本随 Skill 包分发在 `comet/scripts/` 下；需要恢复时不要硬编码路径，而应定位一次并缓存环境变量：
+以下脚本定位只用于旧版兼容、CLI 不可用时的恢复，以及 `/comet-classic` 内部入口命令。正常公开工作流不得优先采用此方式。Comet 脚本随 Skill 包分发在 `comet/scripts/` 下；需要恢复时不要硬编码路径，而应定位一次并缓存环境变量：
 
 ```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)}"
@@ -55,7 +55,7 @@ fi
 | `COMET_GUARD` | 阶段退出守卫和 `--apply` 状态推进 |
 | `COMET_HANDOFF` | Design/Build handoff 上下文包生成 |
 | `COMET_ARCHIVE` | 一键归档和主 spec 同步 |
-| `COMET_INTENT` | `/comet` 入口意图识别和路由评分 |
+| `COMET_INTENT` | `/comet-classic` 入口意图识别和路由评分 |
 | `COMET_RESUME_PROBE` | 只读 Ambient Resume 探针，判断是否应恢复 active Comet workflow |
 
 ## 自动状态更新

package/assets/skills-zh/comet-any/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: comet-any
-description: "仅在用户明确调用 /comet-any，或明确要求定制 Comet 五阶段流程、创建或升级由 Comet Creator 管理的 workflow Skill 时使用；不要用于一般 Skill 的编写、整理或评审。"
+description: "仅在用户明确调用 /comet-any，或明确要求定制 /comet-classic 五阶段流程、创建或升级由 Comet Creator 管理的 workflow Skill 时使用；不要用于一般 Skill 的编写、整理或评审。"
 ---
 
 # Comet Any - Skill Creator
@@ -9,7 +9,7 @@ description: "仅在用户明确调用 /comet-any，或明确要求定制 Comet
 
 普通用户第一层只看到三种起点：
 
-- `基于 Comet 现有 Skill 的五阶段定制`：覆盖 `open / design / build / verify / archive` 五阶段的 Skill 编排，但不修改 `/comet` 命令本身。
+- `基于 /comet-classic 的五阶段定制`：覆盖 `open / design / build / verify / archive` 五阶段的 Skill 编排，但不修改 `/comet-classic` 永久入口本身。
 - `创建全新 workflow Skill`：从目标和候选 Skills 生成新的 `workflow-kernel`。
 - `整理已有 Skill`：读取已有 Skill，补齐 Workflow Node、Skill Binding、Output Schema、Guardrail、Handoff、eval 和 readiness。
 
@@ -30,7 +30,7 @@ description: "仅在用户明确调用 /comet-any，或明确要求定制 Comet
 
 ## 受保护边界
 
-`comet-five-phase-overlay` 保留 Comet 主流程和 `.comet.yaml` 状态语义。普通模式下：
+`comet-five-phase-overlay` 保留 Comet Classic 五阶段主流程和 `.comet.yaml` 状态语义。普通模式下：
 
 - `comet-five-phase-overlay` 的主状态只来自 `openspec/changes/<name>/.comet.yaml`；没有 active change 或多个 active changes 时必须阻塞并请用户选择。
 - 不得创建 `.comet/runs/<workflow>/state.json` 作为 Comet overlay 主状态。Bundle 草稿、eval evidence 和 publish readiness 可以有自己的证据文件，但不能替代 `.comet.yaml`。
@@ -59,7 +59,7 @@ description: "仅在用户明确调用 /comet-any，或明确要求定制 Comet
 
 ```json
 {
-  "goal": "基于 Comet 现有 Skill 的五阶段定制，要求组件库和白盒审查。",
+  "goal": "基于 /comet-classic 的五阶段定制，要求组件库和白盒审查。",
   "skillCreatorIntent": "customize-comet",
   "workflow": {
     "kind": "comet-five-phase-overlay",

package/assets/skills-zh/comet-any/reference/authoring-subagents.md

@@ -63,7 +63,7 @@ Claude Code、Codex、Gemini、Copilot 等平台的 subagent 调用方式不同
 - `plan.json` 中的 `goal`、`workflow.kind`、`workflow.nodes`、`engineMode`、`runnerMode`，以及规范化后的 `workflow-protocol.json`。
 - `reference/resolved-skills.json` 或等价的真实 Skill 来源摘要。
 - `reference/workflow-protocol.json` 或即将写入该文件的 workflow protocol。
-- `/comet` 定制场景下的受保护边界：`open / design / build / verify / archive`、`.comet.yaml`、decision point、verify-result-transition、archive-delta-sync。
+- `/comet-classic` 定制场景下的受保护边界：`open / design / build / verify / archive`、`.comet.yaml`、decision point、verify-result-transition、archive-delta-sync。
 - 项目级偏好、缺失/歧义候选处理结果、偏离原因、scripts/hooks 可执行披露。
 
 ## 输出格式

package/assets/skills-zh/comet-any/reference/bundle-authoring.md

@@ -8,7 +8,7 @@
 
 ```json
 {
-  "goal": "基于 Comet 现有 Skill 的五阶段定制，要求组件库和白盒审查。",
+  "goal": "基于 /comet-classic 的五阶段定制，要求组件库和白盒审查。",
   "skillCreatorIntent": "customize-comet",
   "workflow": {
     "kind": "comet-five-phase-overlay",

package/assets/skills-zh/comet-any/reference/subagents/reference-author.md

@@ -21,7 +21,7 @@ reference 层承载证据，不把内部审计内容塞进用户可见 `SKILL.md
 - resolved Skill 的名称、来源、description、hash、reference、rules、scripts、hooks。
 - `sourceSummaries`，必须来自真实 `SKILL.md` 正文和直接 reference。
 - 项目级偏好、缺失/歧义候选处理、偏离原因和可执行披露。
-- `/comet` 定制时保留的五阶段语义。
+- `/comet-classic` 定制时保留的五阶段语义。
 
 使用文件交接：主会话提供路径，不粘贴大段全文。不要读取主会话历史，也不要把来源 Skill 原文整段搬进
 reference。

package/assets/skills-zh/comet-any/reference/subagents/script-author.md

@@ -22,7 +22,7 @@ factory 还会从同一份 `workflow-protocol.json` 确定性生成 `scripts/com
 - `reference/workflow-protocol.json`
 - `plan.json` 的 `workflow.kind`、`workflow.nodes`、`engineMode`、`runnerMode`，以及规范化后的 `workflow-protocol.json`
 - `reference/resolved-skills.json`
-- `/comet` 定制时的 `.comet.yaml` 受保护语义；`comet-five-phase-overlay` 的主状态只来自 `openspec/changes/<name>/.comet.yaml`，不得创建 `.comet/runs/<workflow>/state.json` 作为 Comet overlay 主状态
+- `/comet-classic` 定制时的 `.comet.yaml` 受保护语义；`comet-five-phase-overlay` 的主状态只来自 `openspec/changes/<name>/.comet.yaml`，不得创建 `.comet/runs/<workflow>/state.json` 作为 Comet overlay 主状态
 
 使用文件交接：主会话提供路径，不粘贴大段全文。不要读取主会话历史，也不要要求用户重新解释已经写入
 artifact 的内容。