@house365/comate 0.10.2 → 0.10.3

package/docs/superpowers/plans/2026-09-13-fast-workflow.md

@@ -0,0 +1,62 @@
+# Fast Workflow Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task with review checkpoints.
+
+**Goal:** Add a constrained `fast` workflow that runs open → agent implementation/test evidence → archive while preserving state, scope, and verification guards.
+
+**Architecture:** Extend the existing flat `.comate.yaml` state machine with `workflow: fast` and a `fast-execute` phase. Reuse the existing proposal/tasks artifacts and archive command, add a machine-owned fast handoff plus verification report requirements, and keep full/fix behavior unchanged.
+
+**Tech Stack:** Bash, flat YAML state files, Bats tests, Markdown skills.
+
+**Spec:** This plan implements the fast workflow design agreed in conversation: skip standalone design/build/verify phases, but require bounded scope, implementation evidence, tests, and a guarded archive.
+
+## Global Constraints
+
+- Fast workflow must not add capability, change public interfaces, change database schema, add dependencies, or cross module boundaries.
+- Fast workflow must be recoverable from `.comate.yaml` and must not rely on conversation context.
+- Archive is allowed only after a successful fast verification report and handled branch status.
+- Existing `full` and `fix` workflows must retain their current behavior.
+
+### Task 1: Add fast state-machine support
+
+**Files:**
+- Modify: `skills/comate/scripts/comate-lib.sh`
+- Modify: `skills/comate/scripts/comate.sh`
+- Test: `skills/comate/tests/comate.bats`
+
+- [ ] **Step 1: Write failing state tests** for `workflow: fast`, `fast-execute` phase, and `fast-complete` transition.
+- [ ] **Step 2: Run the focused tests and confirm they fail** because the enum/transition is unsupported.
+- [ ] **Step 3: Implement the minimal enum, state fields, transition, and phase checks.** Fast initialization starts in `phase: open`; open completion routes to `phase: fast-execute`; fast completion routes to `phase: archive`.
+- [ ] **Step 4: Run focused tests and the full Bats suite.**
+
+### Task 2: Add fast execution handoff and guard
+
+**Files:**
+- Modify: `skills/comate/scripts/comate.sh`
+- Test: `skills/comate/tests/comate.bats`
+
+- [ ] **Step 1: Write failing tests** requiring a fast context package, verification report, test result, and bounded changed-file count before `fast-complete`.
+- [ ] **Step 2: Run focused tests and confirm the guard rejects missing evidence.**
+- [ ] **Step 3: Implement `handoff <name> fast --write` and `guard <name> fast --apply`.** The context hashes proposal/tasks and records changed files; the guard validates the report, test command/result, scope marker, and branch handling.
+- [ ] **Step 4: Run focused tests and the full Bats suite.**
+
+### Task 3: Add the fast skill and orchestrator routing
+
+**Files:**
+- Create: `skills/comate-fast/SKILL.md`
+- Modify: `skills/comate/SKILL.md`
+- Modify: `README.md`
+
+- [ ] **Step 1: Write the skill contract** for fast open, bounded implementation, evidence, upgrade conditions, and archive.
+- [ ] **Step 2: Add orchestrator detection** so explicit small bug/fix requests can select fast only when the user asks for the fast path; ordinary fixes continue using `comate-fix`.
+- [ ] **Step 3: Document commands, limits, recovery, and upgrade behavior.**
+- [ ] **Step 4: Run documentation consistency checks and the full Bats suite.**
+
+### Task 4: Verify branch and workflow behavior
+
+**Files:**
+- Test: `skills/comate/tests/comate.bats`
+
+- [ ] **Step 1: Add an end-to-end Bats scenario** covering fast init → open guard → implementation evidence → fast guard → archive preconditions.
+- [ ] **Step 2: Run the complete test suite.**
+- [ ] **Step 3: Review the diff for unchanged full/fix semantics and commit the feature.**

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@house365/comate",
-  "version": "0.10.2",
+  "version": "0.10.3",
   "description": "comate —— SDD (规约驱动开发) 的 AI 开发编排器（Agent Skills）",
   "type": "module",
   "license": "MIT",

package/skills/comate-gate/SKILL.md

@@ -267,12 +267,14 @@ bash "$COMATE" gate <prd路径> fanout-status --json
 
 对 `missing` 里的每个 change，逐个调用 comate-open。**每次都在 change 描述里点明**：本 change 承接 PRD 的哪些功能项、范围边界、以及（多 change 时）相邻职责归哪个 change（In/Out 显式互引，防重复防遗漏）。若同名目录或 `.comate.yaml` 已存在，视为中断恢复：让 comate-open 复用现有状态、补齐缺失产物和源追踪后登记，不得重复执行 `state init`。
 
+**澄清结论必须随描述过桥**：从评审报告的问题台账/澄清扫描里，摘录与本 change 相关的**已确认结论**（每条一行：台账 `ID` + 用户拍定的结论），一并传给 comate-open，让它写进 proposal 对应章节。未解决的 TBD 项另行标 **「⚠ 待确认」**（见后文），二者都要给。理由：澄清答案只落在评审报告，gate.yaml 仅存计数与报告路径，后续 design/build 不读 PRD 也不读报告；不摘录则一旦上下文压缩或跨会话恢复，用户拍过的阈值、状态流转、失败处理就永久丢失。摘录范围以本 change 认领的功能项为界，无相关结论时明确说明「本 change 无关联澄清结论」，不得留空跳过。
+
 **立即执行**：用 Skill 工具加载 `comate-open`，传入 change 名与来源 PRD，并明确使用“gate 扇出骨架模式”。该模式创建/补齐并校验当前 change 的 `.openspec.yaml`、open 三件套、`.comate.yaml` 和 PRD 源追踪，最后登记 `gate spawned` 并保持 `phase: open` 返回本 gate 循环；不得在同一次 gate 调用中自动进入该 change 的 design/build。
 
 comate-open 内部会：
 - 先跑 `gate check <prd>` 前置守卫（未通过则阻断）；
-- 生成 proposal.md（范围/目标/非目标承接该 change 的功能项，不脱离 PRD 另起炉灶）；
-- `sources track <prd>` 钉住 PRD 为源（`source_kind=file`）；
+- 生成 proposal.md（范围/目标/非目标承接该 change 的功能项，不脱离 PRD 另起炉灶；澄清结论写入对应章节）；
+- `sources track <prd>` 钉住 PRD 为源（`source_kind=file`），并追加追踪评审报告，使后续阶段能顺 manifest 找回澄清台账；
 - design.md / tasks.md 由后续 comate-design 细化。
 
 每建成一个，记录到门禁（目录已存在后才能登记）：
@@ -309,6 +311,7 @@ bash "$COMATE" gate <prd> spawned <change-name>
 - AskUserQuestion 是真实阻塞点：文字输出/推荐/默认值/历史选择/用户未反对都不能替代明确回答。
 - 拆分粒度（1 PRD → 几个 change）由用户定，AI 只给建议不拍板。
 - 每个 change 承接 PRD 对应功能项，不另起炉灶；范围/依赖/验收与 PRD 对齐。
+- 澄清结论必须随 change 描述过桥并落进 proposal，评审报告必须被 `sources track` 追踪；不得依赖对话上下文传递用户已拍定的决策。
 - 多 change 时在各 change 的 In/Out Scope 显式互引边界职责归属。
 - 扇出必须以 `gate fanout-status` 为持久化进度真相；`TaskCreate` 仅作展示，不得替代 gate.yaml 状态。
 - 门禁通过后 PRD 若被改（哈希漂移），gate 转 stale，禁止再扇出 change，须重跑本 skill。

package/skills/comate-open/SKILL.md

@@ -36,23 +36,23 @@ bash "$COMATE" gate <prd路径> check
 
 需求**来自对话**（非 PRD）时跳过本步——门禁只约束「PRD → change」这条路径。
 
-### 3. 创建 Change 结构 + 初始化状态
-
-#### Gate 扇出骨架模式
-
-当调用方明确说明本次来自 `comate-gate` 的批量扇出时，使用独立的骨架模式：
-
-1. 运行 gate check；
-2. 创建或补齐 `.openspec.yaml`、proposal.md、design.md、tasks.md；
-3. `.comate.yaml` 不存在时才执行 `state init full`，已存在时读取并复用，不能重复 init；
-4. 追踪源 PRD；
-5. 运行 `state check open` 并检查所有骨架文件非空、proposal 范围忠实承接映射；
-6. 最后执行 `gate spawned`。脚本会再次校验 gate 未 stale、骨架完整且源 manifest 确实追踪该 PRD；
-7. 登记成功后保持 `phase: open`，立即返回 comate-gate 的扇出循环。
-
-骨架模式不执行 Step 4 后的 `phase_step` 记录、Step 5 产物确认、open guard 或本文“自动流转”；**不得**在同一次 gate 调用中加载 `comate-design`。下一项由 gate 根据 `fanout-status` 的 `missing` 列表继续处理。
-
-若不是 gate 扇出调用，保持普通 open 流程并按本文退出条件进入 design。
+### 3. 创建 Change 结构 + 初始化状态
+
+#### Gate 扇出骨架模式
+
+当调用方明确说明本次来自 `comate-gate` 的批量扇出时，使用独立的骨架模式：
+
+1. 运行 gate check；
+2. 创建或补齐 `.openspec.yaml`、proposal.md、design.md、tasks.md；调用方传来的**澄清结论**（台账 ID + 用户拍定的结论）必须落进 proposal 对应章节，未解决项标 **「⚠ 待确认」**；调用方未给结论时，从 gate.yaml 的 `review_report` 路径读报告自行摘录；
+3. `.comate.yaml` 不存在时才执行 `state init full`，已存在时读取并复用，不能重复 init；
+4. 追踪源 PRD **与评审报告**（见 Step 3b）；
+5. 运行 `state check open` 并检查所有骨架文件非空、proposal 范围忠实承接映射；
+6. 最后执行 `gate spawned`。脚本会再次校验 gate 未 stale、骨架完整且源 manifest 确实追踪该 PRD；
+7. 登记成功后保持 `phase: open`，立即返回 comate-gate 的扇出循环。
+
+骨架模式不执行 Step 4 后的 `phase_step` 记录、Step 5 产物确认、open guard 或本文“自动流转”；**不得**在同一次 gate 调用中加载 `comate-design`。下一项由 gate 根据 `fanout-status` 的 `missing` 列表继续处理。
+
+若不是 gate 扇出调用，保持普通 open 流程并按本文退出条件进入 design。
 
 **立即执行：** 使用 Skill 工具加载 `openspec-new-change` 技能。若用户意图未明确、需先形成建议，改为加载 `openspec-propose`。禁止跳过。
 
@@ -79,12 +79,12 @@ if [ -z "$COMATE" ]; then
   return 1 2>/dev/null || exit 1
 fi
 
-bash "$COMATE" state <name> init full
-```
-
-这会创建 `openspec/changes/<name>/.comate.yaml`，初始状态：`workflow: full`, `phase: open`, `phase_step: null`。
-
-**恢复规则**：若 change 目录或 `.comate.yaml` 已存在，逐项检查并补齐缺失产物；`.comate.yaml` 存在时跳过 `state init`。这覆盖“骨架已创建但尚未 gate spawned”中断点，完成校验后直接补登记。
+bash "$COMATE" state <name> init full
+```
+
+这会创建 `openspec/changes/<name>/.comate.yaml`，初始状态：`workflow: full`, `phase: open`, `phase_step: null`。
+
+**恢复规则**：若 change 目录或 `.comate.yaml` 已存在，逐项检查并补齐缺失产物；`.comate.yaml` 存在时跳过 `state init`。这覆盖“骨架已创建但尚未 gate spawned”中断点，完成校验后直接补登记。
 
 ### 3b. 判定需求来源(源文件追踪)
 
@@ -100,15 +100,25 @@ bash "$COMATE" sources <name> track docs/knowledge-base/<path>.md --note "<可
 - 仅 `docs/knowledge-base/` 范围内的文件可追踪;范围外文件会被跳过并提示,`source_kind` 保持 `conversation`,不影响流程。
 - 边追踪边产生:若开题时为对话来源、设计中途才拿到知识库文档,后续任意阶段补 `sources <name> track` 即可,无需回到 open。
 
+**来自 PRD 时同时追踪评审报告**：报告与 PRD 同级、同在可追踪范围内，路径取自 `<PRD>.gate.yaml` 的 `review_report` 字段。
+
+```bash
+bash "$COMATE" sources <name> track <review_report路径> --note "gate 评审报告：澄清台账与 TBD 项"
+```
+
+理由：澄清结论只落在该报告，后续 design/build/verify 不读 PRD；追踪后可顺 `sources.manifest` 找回用户拍定的阈值、状态流转与失败处理，不依赖对话上下文。追踪失败（如报告不在可追踪范围）时报告原因并继续，不阻断开题。
+
+**副作用（已知且刻意保留）**：报告被追踪后纳入漂移检查，design/build 守卫会在报告变更时 FAIL。这是想要的行为——报告变更意味着澄清结论变了，应重读而非静默放行。确认变更已知悉后重新 `sources <name> track <review_report路径>` 重钉即可放行。
+
 ### 3c. PRD 扇出记录（从 PRD 建 change 时必须登记）
 
-若本 change 来自 PRD，在创建、源追踪和完整性校验全部完成后，把该 change 记回门禁：
+若本 change 来自 PRD，在创建、源追踪和完整性校验全部完成后，把该 change 记回门禁：
 
 ```bash
 bash "$COMATE" gate <prd路径> spawned <name>
 ```
 
-此步将 change 名称追加到 `<PRD>.gate.yaml` 的 `spawned_changes` 列表，用于追溯 PRD → change 的完整扇出关系。不得在文件不完整或源追踪前提前登记。
+此步将 change 名称追加到 `<PRD>.gate.yaml` 的 `spawned_changes` 列表，用于追溯 PRD → change 的完整扇出关系。不得在文件不完整或源追踪前提前登记。
 
 需求**来自对话**时跳过本步。
 
@@ -125,7 +135,7 @@ bash "$COMATE" state <name> check open
 1. 读取 `.comate.yaml` 的 `phase`、`phase_step`、workflow、以及三件套文件路径
 
 2. **已完成 Step 5（产物已审视确认）** 的判定条件：
-   - `phase_step` 值为 `open.review-confirmed`（旧版 `5-confirmed` 兼容一次）
+   - `phase_step` 值为 `open.review-confirmed`（旧版 `5-confirmed` 兼容一次）
    - 或 `phase` 已经不是 `open`（说明已流转到下一阶段）
 
 3. **幂等分支**：
@@ -135,26 +145,26 @@ bash "$COMATE" state <name> check open
      - 任一文件缺失或为空 → 从 Step 1 开始（如果是首次）或 Step 3b/3c（如果是 PRD 来源）
 
 4. **断点恢复**（根据 `phase_step` 值）：
-   - `phase_step` 为 `open.artifacts-created` → 从 Step 4 开始
-   - `phase_step` 为 `open.review-awaiting`（或旧版 `4`）→ 恢复 Step 5 的用户确认，并改写为新格式
-   - `phase_step` 为 `open.review-confirmed`（或旧版 `5-confirmed`）→ 见第 3 点幂等分支
+   - `phase_step` 为 `open.artifacts-created` → 从 Step 4 开始
+   - `phase_step` 为 `open.review-awaiting`（或旧版 `4`）→ 恢复 Step 5 的用户确认，并改写为新格式
+   - `phase_step` 为 `open.review-confirmed`（或旧版 `5-confirmed`）→ 见第 3 点幂等分支
 
-5. **open 阶段特点**：open 阶段的所有操作（explore、创建三件套、状态初始化）可安全重复执行。但**产物审视（Step 5）的用户确认不可重复**，一旦 `phase_step: open.review-confirmed` 被记录，即使上下文压缩也不得重新要求用户确认。
+5. **open 阶段特点**：open 阶段的所有操作（explore、创建三件套、状态初始化）可安全重复执行。但**产物审视（Step 5）的用户确认不可重复**，一旦 `phase_step: open.review-confirmed` 被记录，即使上下文压缩也不得重新要求用户确认。
 
 ### 4. 内容完整性检查
 
-逐个确认三个文件路径存在且非空：
+逐个确认三个文件路径存在且非空：
 - **proposal.md**：问题背景、目标、范围、非目标
 - **design.md**：高层架构决策、方案选型、数据流
 - **tasks.md**：任务列表，每个任务有明确描述
 
-任一文件缺失或为空时，不得进入 Step 5 或执行守卫，必须回创建步骤补充。
-
-完整性检查通过后记录：
-
-```bash
-bash "$COMATE" state <name> set phase_step open.artifacts-created
-```
+任一文件缺失或为空时，不得进入 Step 5 或执行守卫，必须回创建步骤补充。
+
+完整性检查通过后记录：
+
+```bash
+bash "$COMATE" state <name> set phase_step open.artifacts-created
+```
 
 ### 5. 产物审视（决策阻塞点 1，按来源分类）
 
@@ -175,7 +185,7 @@ bash "$COMATE" state <name> set phase_step open.artifacts-created
 
 1. **记录自动确认状态**：
    ```bash
-   bash "$COMATE" state <name> set phase_step open.review-confirmed
+   bash "$COMATE" state <name> set phase_step open.review-confirmed
    ```
 
 2. **如实报告**：「本 change 承接自 PRD <prd-name>，认领功能项：<列出项>。已核对范围与映射一致，自动进入下一阶段。」
@@ -187,27 +197,27 @@ bash "$COMATE" state <name> set phase_step open.artifacts-created
 - **对话来源**（`source_kind: conversation`）：范围此前未经用户拍板，三件套第一次成形。
 - **PRD 扇出但 5a 第 4 条不成立**（范围与映射有偏差）：分歧重新出现。
 
-以上任一情形，**必须使用 AskUserQuestion 工具暂停等待用户确认**。以单选题呈现摘要（proposal 问题/目标/范围、design 架构决策/选型、tasks 数量与关键任务；PRD 偏差场景额外列出偏差点）和选项：
+以上任一情形，**必须使用 AskUserQuestion 工具暂停等待用户确认**。以单选题呈现摘要（proposal 问题/目标/范围、design 架构决策/选型、tasks 数量与关键任务；PRD 偏差场景额外列出偏差点）和选项：
 - 「确认，继续下一阶段」— 记录确认状态后执行守卫流转
 - 「需要调整」— 附调整说明（PRD 偏差场景默认建议按映射修正），修改后重新请求确认
 
-**提问前先持久化等待状态**：
-
-```bash
-bash "$COMATE" state <name> set phase_step open.review-awaiting
-```
-
-**用户确认后立即记录**：
+**提问前先持久化等待状态**：
 
 ```bash
-bash "$COMATE" state <name> set phase_step open.review-confirmed
+bash "$COMATE" state <name> set phase_step open.review-awaiting
+```
+
+**用户确认后立即记录**：
+
+```bash
+bash "$COMATE" state <name> set phase_step open.review-confirmed
 ```
 
 然后继续执行退出条件（guard）。
 
-## 退出条件
-
-以下退出条件仅适用于普通 open；gate 扇出骨架模式使用 Step 3 的专用返回条件。
+## 退出条件
+
+以下退出条件仅适用于普通 open；gate 扇出骨架模式使用 Step 3 的专用返回条件。
 
 - 三件套已创建且内容完整
 - **用户已确认**
@@ -221,9 +231,9 @@ bash "$COMATE" guard <name> open --apply
 
 full 流程自动更新为 `phase: design`；fix 预设自动更新为 `phase: build`。
 
-## 自动流转
-
-仅普通 open 在用户确认后自动流转：
+## 自动流转
+
+仅普通 open 在用户确认后自动流转：
 
 > **REQUIRED NEXT SKILL（完整流程）：** 调用 `comate-design` skill 进入深度设计。
 >

package/docs/CLEANUP_SUPERPOWERS.md

@@ -1,128 +0,0 @@
-# Superpowers 重复安装清理指南
-
-## 背景
-
-如果你在 Claude Code 中通过 plugin 安装了 superpowers，然后又运行了 `comate init`（在检测功能添加之前），可能会导致系统中同时存在两份 superpowers：
-
-1. **Claude Code plugin 版本**：`~/.claude/plugins/cache/.../superpowers/`
-2. **Skills CLI 版本**：`~/.agents/skills/using-superpowers/` 和 `~/.agents/skills/brainstorming/`
-
-这会导致：
-- 占用额外的磁盘空间
-- 可能的版本冲突
-- 用户困惑（不清楚在用哪个版本）
-
-## 解决方案
-
-### 自动清理（推荐）
-
-运行清理命令：
-
-```bash
-comate cleanup
-```
-
-该命令会：
-1. 检查是否存在 Claude Code plugin 版本的 superpowers
-2. 如果存在，扫描并删除 skills CLI 安装的版本
-3. 保留 plugin 版本（更新更方便）
-
-### 输出示例
-
-**有重复安装时：**
-```
-=== Superpowers 重复安装清理工具 ===
-
-1. 检查 Claude Code plugin 安装...
-   ✓ 检测到 Claude Code plugin 版本
-
-2. 扫描 skills CLI 安装...
-   发现: C:\Users\xxx\.agents\skills\using-superpowers
-   发现: C:\Users\xxx\.agents\skills\brainstorming
-
-   共找到 2 个目录需要清理
-
-3. 执行清理...
-   ✓ 已删除 2 个目录:
-     - C:\Users\xxx\.agents\skills\using-superpowers
-     - C:\Users\xxx\.agents\skills\brainstorming
-
-=== 清理完成 ===
-现在只使用 Claude Code plugin 版本的 superpowers
-相关 skill 在 Claude 中仍然可用
-```
-
-**无需清理时：**
-```
-=== Superpowers 重复安装清理工具 ===
-
-1. 检查 Claude Code plugin 安装...
-   ✓ 检测到 Claude Code plugin 版本
-
-2. 扫描 skills CLI 安装...
-   ✓ 未发现 skills CLI 版本的 superpowers
-
-无需清理，已经是最优状态！
-```
-
-### 手动清理
-
-如果你更喜欢手动操作：
-
-```bash
-# 删除 skills CLI 安装的 superpowers
-rm -rf ~/.agents/skills/using-superpowers
-rm -rf ~/.agents/skills/brainstorming
-rm -rf ~/.claude/skills/using-superpowers
-rm -rf ~/.claude/skills/brainstorming
-```
-
-## 预防措施
-
-从 comate v0.9.24 开始，`comate init` 会自动检测 Claude Code plugin 安装的 superpowers，并跳过重复安装。
-
-如果你使用的是旧版本，建议升级：
-
-```bash
-npm install -g @house365/comate@latest
-```
-
-## 常见问题
-
-### Q: 清理后 superpowers 还能用吗？
-
-A: 能！只要你有 Claude Code plugin 版本，所有 superpowers 的功能都正常可用。
-
-### Q: 如果我没有 plugin 版本会怎样？
-
-A: `comate cleanup` 会检测并拒绝清理，提示你需要先安装 plugin 版本。
-
-### Q: 我应该用哪个版本？
-
-A: 推荐使用 **Claude Code plugin 版本**，因为：
-- 通过 Claude 内置的 plugin 管理器自动更新
-- 与 Claude Code 集成更好
-- 不需要手动运行 `skills add` 更新
-
-### Q: 清理是否安全？
-
-A: 是的，清理脚本：
-- 仅在检测到 plugin 版本时才执行
-- 只删除明确的 superpowers 目录
-- 不会影响其他 skills
-- 不会删除 plugin 版本
-
-## 技术细节
-
-清理脚本检查以下位置：
-- `~/.agents/skills/`
-- `~/.claude/skills/`
-- `~/.config/skills/`
-- `~/.cursor/skills/`
-
-删除的目录：
-- `using-superpowers/`
-- `brainstorming/`
-
-保留的位置：
-- `~/.claude/plugins/cache/.../superpowers/`（plugin 版本）

package/docs/SUPERPOWERS_FIX_SUMMARY.md

@@ -1,114 +0,0 @@
-# Superpowers 重复安装问题修复总结
-
-## 问题描述
-
-在 v0.9.24 之前，`comate init` 无法检测 Claude Code plugin 安装的 superpowers，导致：
-- 即使 plugin 已安装，仍会通过 skills CLI 再次安装
-- 用户目录下出现重复的 superpowers 副本
-- 浪费磁盘空间和安装时间
-
-## 解决方案
-
-### 1. 预防重复安装（v0.9.24+）
-
-**修改文件：** `bin/init.mjs`
-
-扩展 `superpowersInstalled()` 函数，增加 plugin 检测：
-
-```javascript
-// 检查 skills CLI 安装（原有逻辑）
-if (roots.some((root) => SUPERPOWERS_MARKERS.some((m) => existsSync(join(root, ...m))))) {
-  return true;
-}
-
-// 检查 Claude Code plugin 安装（新增逻辑）
-if (scope === 'global') {
-  const pluginRegistry = join(home, '.claude', 'plugins', 'installed_plugins.json');
-  try {
-    const registry = JSON.parse(readFileSync(pluginRegistry, 'utf8'));
-    return Object.keys(registry.plugins || {}).some((key) =>
-      key.startsWith('superpowers@') && 
-      Array.isArray(registry.plugins[key]) && 
-      registry.plugins[key].length > 0
-    );
-  } catch {
-    return false;
-  }
-}
-```
-
-**效果：**
-- `comate init` 检测到 plugin 版本后会显示"已安装"并跳过
-- 避免未来的重复安装
-
-### 2. 清理已有重复（cleanup 命令）
-
-**新增文件：** `bin/cleanup-duplicate-superpowers.mjs`
-
-**新增命令：** `comate cleanup`
-
-**工作流程：**
-1. 检查是否有 Claude Code plugin 版本
-2. 扫描 skills CLI 安装的 superpowers
-3. 安全删除重复的目录
-4. 保留 plugin 版本
-
-**安全机制：**
-- 只在检测到 plugin 版本时才执行清理
-- 只删除明确的 superpowers 目录
-- 不影响其他 skills
-
-## 测试覆盖
-
-### init.test.mjs
-- ✅ 检测空注册表
-- ✅ 检测有效的 plugin 安装
-- ✅ 检测其他 plugin 不误判
-- ✅ project scope 不检查 plugin（仅 global）
-
-### cli.test.mjs
-- ✅ cleanup 命令在帮助中列出
-- ✅ cleanup 命令可执行
-
-## 使用指南
-
-### 新用户（v0.9.24+）
-直接运行 `comate init`，系统会自动检测并跳过重复安装。
-
-### 已有重复安装的用户
-运行 `comate cleanup` 清理。
-
-### 验证状态
-```bash
-# 检查是否有重复
-ls ~/.agents/skills | grep -E "(using-super|brainstorm)"
-
-# 检查 plugin 版本
-cat ~/.claude/plugins/installed_plugins.json | grep superpowers
-```
-
-## 提交记录
-
-1. **7cee6e6** - fix: detect Claude Code plugin install to avoid duplicate superpowers
-   - 扩展检测逻辑
-   - 添加测试用例
-
-2. **82dd387** - feat: add cleanup command to remove duplicate superpowers install
-   - 新增清理命令
-   - 添加文档
-
-## 影响范围
-
-- **向后兼容：** 完全兼容，不影响现有功能
-- **新功能：** `comate cleanup` 命令
-- **行为变化：** `comate init` 会跳过 plugin 已安装的 superpowers
-- **磁盘空间：** 清理后可节省约 10-20MB
-
-## 相关文件
-
-- `bin/init.mjs` - 检测逻辑
-- `bin/init.test.mjs` - 检测测试
-- `bin/cleanup-duplicate-superpowers.mjs` - 清理脚本
-- `bin/cli.mjs` - CLI 入口
-- `bin/cli.test.mjs` - CLI 测试
-- `docs/CLEANUP_SUPERPOWERS.md` - 用户文档