@kafka0102/onespec 0.1.14 → 0.2.2

package/assets/skills/onespec/SKILL.md

@@ -60,7 +60,7 @@ ONESPEC_ENV="${ONESPEC_ENV:-$(find . "$HOME"/.codex "$HOME"/.claude "$HOME"/.cur
 - OpenSpec 负责“要做什么”、formal artifacts、approval gate、spec delta 与归档语义。
 - Superpowers 负责高歧义需求澄清、实现计划、TDD、分任务 review 与工程执行质量。
 - 不要询问变更名称。根据任务自动生成简短短横线命名的 `change-id`，如冲突则追加数字。
-- 读取最少必要上下文：`openspec/config.yaml`、`openspec/project.md`、相关 `openspec/specs/**`、项目入口文档、当前分支和工作区状态。
+- 读取最少必要上下文：`openspec/config.yaml`、相关 `openspec/specs/**`、项目入口文档、当前分支和工作区状态。
 - 只问会改变 proposal、执行路径、分支处理或归档结果的问题。
 - 当共同规则与阶段规则冲突时，以当前阶段 reference 的停止条件为准。
 - 每个阶段 reference 定义了强制暂停 gate（如 `references/execute.md` 的“实现完成 Gate”、`references/design.md` 的“批准 Gate”）。路由进入下一阶段前，必须确认上一阶段的 gate 已完成。如果 gate 未完成就试图进入下一阶段，必须拒绝并指出缺失步骤。

package/assets/skills/onespec/references/archive.md

@@ -34,13 +34,26 @@ ONESPEC_ENV="${ONESPEC_ENV:-$(find . "$HOME"/.codex "$HOME"/.claude "$HOME"/.cur
 
 入口校验：如果 phase 已到 `review`，但 `.onespec.yaml` 里的 `handoff_purpose` 不是 `review`，或 `handoff_hash` 为空，说明 execute gate 可能未正常完成。此时必须告诉用户："执行阶段的 review handoff 状态未写回，建议先回到执行阶段补充汇报（回复 `补充汇报` 或重新触发 execute gate）。" 不允许静默跳过。
 
+### 1.1 用户确认请求规则
+
+当归档阶段需要用户确认归档、合并、废弃 worktree、继续修改或停留评审时，必须把“需要用户选择”作为独立块输出，标题固定为 `用户确认请求`。不要把当前状态、推荐收尾动作和等待用户确认混成同一段。
+
+确认块必须包含：
+
+- 一句明确指令：`请回复编号。`
+- 1-3 个编号选项，其中第 1 项通常是推荐项，并标注“推荐”
+- `其他：` 说明非编号内容如何处理，通常视为继续修改当前实现
+- 如果用户补充了新条件但还没有形成明确选择，继续给出新的编号选项，直到用户明确选择、终止或要求继续往下走
+
+如果平台提供结构化询问能力，例如 `ask user questions`、`request_user_input` 或等价 UI，优先用结构化询问承载这些编号选项；如果当前环境没有这类能力，则在普通消息中输出上述 `用户确认请求` 块。无论使用哪种形式，都不能只给一句“建议归档”或“下一步进入收尾”就结束。
+
 ## 2. 用户评审
 
 实现完成后让用户评审。若用户指出问题，继续修改并重新验证。
 
 开发完成后不需要再次让用户确认是否 review，也不需要展示常规“继续评审 / 保留分支”类选项。收尾应先处理临时 worktree 中的代码去向；如果用户回复任意非编号内容，默认视为“继续修改当前实现”，直接回到代码处理环节。
 
-不要让用户自己猜“下一步该输入什么”。如果用户是直接进入 archive phase，尚未做收尾选择，则必须给出可直接回复的编号选项。
+不要让用户自己猜“下一步该输入什么”。如果用户是直接进入 archive phase，尚未做收尾选择，则必须给出用户只需回复数字编号的选项。
 
 如果用户是从 execute phase 的完成汇报进入这里，并且已经回复了收尾编号，则把那次回复视为唯一有效授权，不得再次展示一轮相同菜单，也不得再追加“是否处理合并/归档”之类的中间确认。此时只需汇报必要状态检查，并按用户已选动作直接执行，不需要拆成两轮确认。
 
@@ -53,12 +66,22 @@ ONESPEC_ENV="${ONESPEC_ENV:-$(find . "$HOME"/.codex "$HOME"/.claude "$HOME"/.cur
 
 如果当前分支或工作区不同于 `origin_*`，必须明确说明“你当前看到的是临时实现分支或临时 worktree”。如果用户改为输入任意非编号内容，则表示当前功能还有问题，需要继续修改。
 
-可选收尾路径只有以下三种：
+可选收尾路径必须先按当前是否临时 worktree 差异化判断，不允许凭感觉直接给固定菜单。先执行：
+
+```bash
+"$ONESPEC_BASH" "$ONESPEC_CLOSEOUT" recommend-actions <change-id>
+```
+
+如果 `temporary_worktree: true`，可选收尾路径只有以下三种：
 
 - 归档当前 change，并合并分支到 base 分支
 - 直接归档，不合并到 base 分支
 - 删除当前临时 worktree并废弃代码
 
+如果 `temporary_worktree: false`，可选收尾路径只有一种：
+
+- 直接归档（不合并分支，不删除 worktree）
+
 合并、废弃、删除与归档都是有后果的操作；但只要用户已经在编号菜单里明确授权，就直接执行，不要再拆成二次确认。
 
 ## 2.1 Superpowers Worktree 优先规则
@@ -79,9 +102,9 @@ ONESPEC_ENV="${ONESPEC_ENV:-$(find . "$HOME"/.codex "$HOME"/.claude "$HOME"/.cur
 3. 如果用户只需要保留归档记录而不合并代码，则允许“仅归档”。
 4. 如果用户要废弃代码，则删除 worktree 并丢弃本地临时分支。
 
-## 2.2 worktree 收尾规则
+## 2.2 差异化收尾规则
 
-如果当前是临时 worktree，必须展示以下编号菜单：
+如果脚本探测到 `temporary_worktree: true`，必须展示以下编号菜单：
 
 ```text
 1. 归档当前 change，并合并分支到 base 分支
@@ -99,14 +122,14 @@ ONESPEC_ENV="${ONESPEC_ENV:-$(find . "$HOME"/.codex "$HOME"/.claude "$HOME"/.cur
 
 如果当前不是临时 worktree，且代码已经真正位于目标分支，也允许执行 `archive-only`。
 
-如果当前不在临时 worktree，且当前分支就是 `origin_branch`，并且该分支是 `main` 或 `master`，则不要再展示“归档后合并”或“删除当前临时 worktree”两个选项。此时收尾菜单只保留一个编号：
+如果脚本探测到 `temporary_worktree: false`，说明代码已经真正位于目标分支/目标工作区。无论当前目标分支是否为 `main`/`master`，都不要再展示“归档后合并”或“删除当前临时 worktree”两个选项。此时收尾菜单只保留一个编号：
 
 ```text
-1. 直接归档（当前已在 `main/master`，无需额外合并分支）
+1. 直接归档（当前不在临时 worktree，无需额外合并分支或删除 worktree）
 其他：任意非编号内容视为继续修改当前实现；用户未输入时默认停留在当前评审阶段
 ```
 
-也就是说，`master/main` 分支就不要提示合并分支/删除 worktree。
+也就是说，不在临时 worktree 时，不管当前目标分支叫 `main`、`master`、`develop`、`feature/*` 还是其他名称，都不要提示合并分支/删除 worktree。
 
 如果用户之前已经在 execute phase 的完成菜单里选了收尾编号，则这里不再重复相同菜单，而是结合实际工作区状态直接执行对应动作。
 
@@ -141,8 +164,8 @@ ONESPEC_ENV="${ONESPEC_ENV:-$(find . "$HOME"/.codex "$HOME"/.claude "$HOME"/.cur
   1. closeout 前先自动提交当前工作区里与本次 change 相关的脏文件。
   2. 如果 archive 产生了新的归档工件或删除了 `.onespec.yaml`，archive 之后再自动补一笔归档提交。
   3. 如果用户选择“先归档再合并”，则必须在 archive 提交完成后，再把当前实现分支合并回 base 分支。
-- 如果用户选择 `archive-then-merge-worktree`，必须先归档，再合并到目标分支，并将状态设为 `archived`。
-- 如果用户选择 `archive-only`，直接执行 OpenSpec archive，并将状态设为 `archived`；不自动合并，不自动删除当前 worktree。
+- 如果用户选择 `archive-then-merge-worktree`，必须仅在 `temporary_worktree: true` 时执行；先归档，再合并到目标分支，最后删除临时 worktree，并将状态设为 `archived`。
+- 如果用户选择 `archive-only`，直接执行 OpenSpec archive，并将状态设为 `archived`；不自动合并。若 `temporary_worktree: false`，也不得删除工作区或 worktree。
 - 如果用户选择 `discard-worktree`，不执行归档，不把废弃分支代码合入 base 分支。
 - 只有真正执行 archive 后，才删除运行时状态文件：
 

package/assets/skills/onespec/references/design.md

@@ -22,7 +22,7 @@ ONESPEC_ENV="${ONESPEC_ENV:-$(find . "$HOME"/.codex "$HOME"/.claude "$HOME"/.cur
 
 读取最少必要上下文：
 
-- `openspec/config.yaml`、`openspec/project.md`、`openspec/specs/**` 中与任务相关的部分
+- `openspec/config.yaml`、`openspec/specs/**` 中与任务相关的部分
 - 项目入口文档，如 `AGENTS.md`、`README.md`、`docs/**` 中与任务相关的部分
 - 当前分支和工作区状态
 
@@ -138,11 +138,24 @@ OpenSpec artifacts 写完后，不要只汇报“proposal 已生成”。必须
   - `Superpowers + subagent + current worktree/current branch`
 - 用户可覆盖推荐
 
+### 3.1 用户确认请求规则
+
+当输出结果后需要用户决定是否批准、是否进入实现、是否改路径或是否继续停留时，必须把“需要用户选择”作为独立块输出，标题固定为 `用户确认请求`。不要把结论、推荐意见和等待用户确认混成同一段。
+
+确认块必须包含：
+
+- 一句明确指令：`请回复编号。`
+- 2-4 个编号选项，其中第 1 项通常是推荐项，并标注“推荐”
+- `其他：` 说明用户可以补充条件或提出不在菜单中的操作
+- 如果用户补充了新条件但还没有形成明确选择，继续给出新的编号选项，直到用户明确选择、终止或要求继续往下走
+
+如果平台提供结构化询问能力，例如 `ask user questions`、`request_user_input` 或等价 UI，优先用结构化询问承载这些编号选项；如果当前环境没有这类能力，则在普通消息中输出上述 `用户确认请求` 块。无论使用哪种形式，都不能只给一句“推荐使用某路径”就结束。
+
 ## 4. Proposal 批准 Gate 与路径选择
 
 默认意图映射、issue workflow 路由或实现路径推荐，不等于 proposal 已获批。
 
-只有用户明确批准 proposal / design / spec 后，才允许进入实现计划。设计阶段结束时，不要只给一句自由文本，也不要只要求用户输入 `批准`、`yes`、`continue` 等完整词；必须给出“显式选项 + 推荐项 + 可直接回复的口令”菜单。用户可以回复数字，也可以直接回复对应口令。沉默、“看起来还行”、最初的“开始实现”、“执行这个 change”或“make plan”都不算对 proposal 产物的批准。
+只有用户明确批准 proposal / design / spec 后，才允许进入实现计划。设计阶段结束时，不要只给一句自由文本，也不要要求用户输入 `批准`、`yes`、`continue` 等完整词；必须给出“显式编号选项 + 推荐项”菜单。用户只需回复数字编号。沉默、“看起来还行”、最初的“开始实现”、“执行这个 change”或“make plan”都不算对 proposal 产物的批准。
 
 生成批准菜单前先确定推荐组合：
 
@@ -155,42 +168,31 @@ OpenSpec artifacts 写完后，不要只汇报“proposal 已生成”。必须
 默认使用下面这组批准菜单，并把推荐组合写进第 1 项。菜单必须解释组合由三部分构成：实现路径 + 执行方式 + 工作区策略。
 
 1. 批准当前 proposal / design / spec，并按推荐组合继续实现：`<recommended-combination>`（推荐）
-   可直接回复：`批准，按推荐路径继续`
 2. 批准当前 proposal / design / spec，但我要改实现路径、执行方式或工作区
-   可直接回复：`批准，但我要改实现路径`
 3. 先修改 proposal / design / tasks / spec；我会补充要改的点
-   可直接回复：`先修改 proposal`
 4. 先停在设计阶段，暂不进入实现
-   可直接回复：`先停在设计阶段`
 其他：如果意图不在以上选项里，允许用户直接补充说明其他操作
 
 菜单解释规则：
 
-- 用户回复 `1` 或 `批准，按推荐路径继续`：视为批准当前 artifacts，并接受当前推荐组合；不要再二次询问 `subagent/local` 或 `worktree/current-branch`，直接记录该组合对应的 `implementation_path`、`execution_method` 与 `workspace`。
-- 用户回复 `2` 或 `批准，但我要改实现路径`：视为批准当前 artifacts，但要覆盖推荐组合；此时继续给出组合菜单，不要把 `subagent/local` 与 `worktree/current-branch` 拆成两轮问题。
-- 用户回复 `3` 或 `先修改 proposal`：继续留在 design phase，根据用户反馈修改 artifacts，不进入实现。
-- 用户回复 `4` 或 `先停在设计阶段`：暂停在设计阶段，等待用户后续指令。
+- 用户回复 `1`：视为批准当前 artifacts，并接受当前推荐组合；不要再二次询问 `subagent/local` 或 `worktree/current-branch`，直接记录该组合对应的 `implementation_path`、`execution_method` 与 `workspace`。
+- 用户回复 `2`：视为批准当前 artifacts，但要覆盖推荐组合；此时继续给出组合菜单，不要把 `subagent/local` 与 `worktree/current-branch` 拆成两轮问题。
+- 用户回复 `3`：继续留在 design phase，根据用户反馈修改 artifacts，不进入实现。
+- 用户回复 `4`：暂停在设计阶段，等待用户后续指令。
 - 用户输入其他自由文本：如果意图清晰，按用户自定义意图处理；如果仍有歧义，只追问一个最短的澄清问题。
 
-当用户选择第 2 项，后续确认也使用“显式组合选项 + 推荐项 + 可直接回复口令”菜单，不要只给数字或只给一句自由文本。根据当前是否已经在附加 worktree 中生成菜单：
+当用户选择第 2 项，后续确认也使用“显式编号组合选项 + 推荐项”菜单；用户只需回复数字编号。不要只给一句自由文本，也不要在每个选项下附加口令提示。根据当前是否已经在附加 worktree 中生成菜单：
 
 - 如果当前不在附加 worktree 中，默认菜单：
   1. `Superpowers + subagent + new worktree`（推荐）
-     可直接回复：`使用 Superpowers subagent worktree`
   2. `Superpowers + local + new worktree`
-     可直接回复：`使用 Superpowers local worktree`
   3. `Superpowers + local + current branch`
-     可直接回复：`使用 Superpowers local current-branch`
   4. `OpenSpec apply + native + current branch`
-     可直接回复：`使用 OpenSpec apply`
   其他：允许用户补充说明特殊组合；例如明确要求 `Superpowers + subagent + current branch`
 - 如果当前已经在附加 worktree 中，默认菜单：
   1. `Superpowers + subagent + current worktree/current branch`（推荐）
-     可直接回复：`使用 Superpowers subagent 当前 worktree`
   2. `Superpowers + local + current worktree/current branch`
-     可直接回复：`使用 Superpowers local 当前 worktree`
   3. `OpenSpec apply + native + current worktree/current branch`
-     可直接回复：`使用 OpenSpec apply`
   其他：允许用户补充说明特殊组合；不要推荐再创建新的 worktree
 
 `main`/`master` 规则：

package/assets/skills/onespec/references/execute.md

@@ -36,6 +36,19 @@ apply 前至少读取：
 
 如果 proposal 尚未批准，直接停止，不要开始实现。
 
+### 1.1 用户确认请求规则
+
+当执行阶段需要用户确认实现路径、工作区策略、继续实现、回到设计修订或完成后的收尾动作时，必须把“需要用户选择”作为独立块输出，标题固定为 `用户确认请求`。不要把结论、验证结果、推荐意见和等待用户确认混成同一段。
+
+确认块必须包含：
+
+- 一句明确指令：`请回复编号。`
+- 2-6 个编号选项，其中第 1 项通常是推荐项，并标注“推荐”
+- `其他：` 说明非编号内容如何处理，通常视为继续修改当前实现或补充特殊条件
+- 如果用户补充了新条件但还没有形成明确选择，继续给出新的编号选项，直到用户明确选择、终止或要求继续往下走
+
+如果平台提供结构化询问能力，例如 `ask user questions`、`request_user_input` 或等价 UI，优先用结构化询问承载这些编号选项；如果当前环境没有这类能力，则在普通消息中输出上述 `用户确认请求` 块。无论使用哪种形式，都不能只给一句“下一步应进入某阶段”或“推荐使用某路径”就结束。
+
 如果 proposal 阶段已经确认实现路径：
 
 - 用户确认 `Superpowers`：继续 Superpowers Make Plan。
@@ -210,11 +223,19 @@ git -C "$implementation_workspace_path" status --short
 7. 是否更新了 `proposal.md`、`design.md` 或 spec delta
 8. 测试结果
 9. `openspec validate <change-id> --strict` 结果
-10. 下一步编号选项（必须给出可直接回复的数字菜单，并明确任意非编号内容视为继续修改当前实现）
+10. 下一步编号选项（必须给出只需回复数字编号的菜单，并明确任意非编号内容视为继续修改当前实现）
 
 ### 5.3 下一步编号菜单模板
 
-汇报结尾必须包含以下格式的编号提示（可微调措辞，但结构和编号语义不可省略）：
+生成下一步菜单前，必须先用脚本探测当前收尾状态；不要凭分支名、路径命名或主观判断推断是否需要合并/删除 worktree：
+
+```bash
+"$ONESPEC_BASH" "$ONESPEC_CLOSEOUT" recommend-actions <change-id>
+```
+
+菜单必须按探测结果差异化生成：
+
+- 如果 `temporary_worktree: true`，说明当前实现位于临时 worktree。汇报结尾必须包含以下格式的编号提示（可微调措辞，但结构和编号语义不可省略）：
 
 ```
 ---
@@ -231,7 +252,7 @@ git -C "$implementation_workspace_path" status --short
 ---
 ```
 
-如果当前不在临时 worktree，且当前分支就是 `origin_branch`，并且该分支是 `main` 或 `master`，则不要提示“合并分支到 base 分支”或“删除当前临时 worktree”。此时收尾菜单必须收缩为仅归档一个选项：
+- 如果 `temporary_worktree: false`，说明当前实现已经在目标分支/目标工作区，不存在可合并回收的临时 worktree。无论该分支是否为 `main`/`master`，都不要提示“合并分支到 base 分支”或“删除当前临时 worktree”。此时收尾菜单必须收缩为仅归档一个选项：
 
 ```
 ---
@@ -241,20 +262,21 @@ git -C "$implementation_workspace_path" status --short
 📍 当前工作区: `<path>`
 📍 origin: `<origin_branch>` @ `<origin_workspace_path>`
 
-1. 直接归档（当前已在 `main/master`，无需额外合并分支）
+1. 直接归档（当前不在临时 worktree，无需额外合并分支或删除 worktree）
 其他：任意非编号内容视为继续修改当前实现；用户未输入时默认停留在当前评审阶段
 ---
 ```
 
-也就是说，`master/main` 分支就不要提示合并分支/删除 worktree。
+也就是说，不在临时 worktree 时，不管当前目标分支叫 `main`、`master`、`develop`、`feature/*` 还是其他名称，都不要提示合并分支/删除 worktree。
 
-如果当前分支或工作区不同于 `origin_*`，还必须额外说明："当前实现位于临时分支或临时 worktree；若你直接回复非编号内容，我会按继续修改处理。"
+如果脚本探测到当前分支或工作区不同于 `origin_*`，还必须额外说明："当前实现位于临时分支或临时 worktree；若你直接回复非编号内容，我会按继续修改处理。"
 
-- 选择 `1` 时，archive phase 必须按“先归档，再合并分支到 base 分支”的固定顺序执行。
-- 选择 `2` 时，archive phase 只做归档，不合并分支，也不自动删除当前 worktree。
-- 选择 `3` 时，archive phase 删除当前临时 worktree 并废弃代码，不执行归档。
+- `temporary_worktree: true` 且选择 `1` 时，archive phase 必须按“先归档，再合并分支到 base 分支，最后删除临时 worktree”的固定顺序执行。
+- `temporary_worktree: true` 且选择 `2` 时，archive phase 只做归档，不合并分支，也不自动删除当前 worktree。
+- `temporary_worktree: true` 且选择 `3` 时，archive phase 删除当前临时 worktree 并废弃代码，不执行归档。
+- `temporary_worktree: false` 且选择 `1` 时，archive phase 只做归档；不得合并分支，不得删除工作区或 worktree。
 
-不要只停在“下一步应进入 archive phase”这种抽象提示，也不要只说“做 `review-closeout`”。必须同时给出用户可直接回复的编号选项。
+不要只停在“下一步应进入 archive phase”这种抽象提示，也不要只说“做 `review-closeout`”。必须同时给出用户只需回复数字编号的选项。
 
 ### 5.4 反模式（NEVER）
 

package/assets/skills/onespec/references/fast.md

@@ -24,7 +24,7 @@ ONESPEC_ENV="${ONESPEC_ENV:-$(find . "$HOME"/.codex "$HOME"/.claude "$HOME"/.cur
 
 - 仅在用户明确要求 `onespec-fast`、快速路径、fast apply、OpenSpec 自动 proposal/开发/归档或自动贯通时使用。
 - 不要询问 change 名称。根据任务自动生成简短短横线命名的 `change-id`，如冲突则追加数字。
-- 读取最少必要上下文：`openspec/config.yaml`、`openspec/project.md`、相关 `openspec/specs/**`、项目入口文档、当前分支和工作区状态。
+- 读取最少必要上下文：`openspec/config.yaml`、相关 `openspec/specs/**`、项目入口文档、当前分支和工作区状态。
 - 只有 OpenSpec 必需上下文缺失到无法写出有效 proposal、或项目文档明确禁止自动修改当前分支时才暂停。
 
 ## 2. 直接 Proposal

package/assets/skills/onespec/scripts/onespec-closeout.sh

@@ -271,8 +271,8 @@ cmd_validate_actions() {
   elif [ "$has_discard_worktree" = "true" ]; then
     message="允许删除临时 worktree 并废弃对应本地分支代码；废弃后不归档。"
   elif [ "$has_archive_only" = "true" ]; then
-    if [ "$temporary" != "true" ] && [ "$current_head" = "$origin_branch" ] && { [ "$current_head" = "main" ] || [ "$current_head" = "master" ]; }; then
-      message="允许直接归档当前 change；当前已经在 ${current_head}，无需额外合并分支，也不自动删除当前工作区。"
+    if [ "$temporary" != "true" ]; then
+      message="允许直接归档当前 change；当前不在临时 worktree，当前分支 ${current_head} 已是目标分支，无需额外合并分支，也不会删除工作区。"
     else
       message="允许直接归档当前 change，不合并到 base 分支，也不自动删除当前 worktree。"
     fi

package/assets/skills-en/onespec/SKILL.md

@@ -60,7 +60,7 @@ Default intent mapping:
 - OpenSpec owns scope, formal artifacts, approval gates, spec deltas, and archive semantics.
 - Superpowers owns high-ambiguity clarification, implementation planning, TDD, per-task review, and execution quality.
 - Do not ask the user to name the change. Generate a short kebab-case `change-id` from the task and append a suffix if needed.
-- Read the minimum necessary context: `openspec/config.yaml`, `openspec/project.md`, relevant `openspec/specs/**`, project entry docs, and current branch/worktree state.
+- Read the minimum necessary context: `openspec/config.yaml`, relevant `openspec/specs/**`, project entry docs, and current branch/worktree state.
 - Only ask questions that can change the proposal, execution path, branch handling, or archive result.
 - If shared and phase-specific rules conflict, the current phase reference wins.
 - Each phase reference defines mandatory pause gates, such as the approval gate in `references/design.md` and the implementation-complete gate in `references/execute.md`. Before routing to the next phase, confirm the previous gate is complete; if it is not, refuse to continue and name the missing gate.

package/assets/skills-en/onespec/references/archive.md

@@ -34,6 +34,19 @@ If state has not reached `review`, explain what is still missing: implementation
 
 Entry validation: if phase is already `review` but `.onespec.yaml` does not show `handoff_purpose: review` or does not have a `handoff_hash`, treat that as an incomplete execute gate. Tell the user the review handoff state was not written back and send them to re-run the execute report instead of silently continuing.
 
+### 1.1 User Confirmation Request Rules
+
+When archive phase requires the user to confirm archive, merge, discard-worktree, continued implementation, or staying in review, render "user choice required" as a standalone block titled `User Confirmation Request`. Do not mix current state, recommended closeout action, and pending confirmation into one paragraph.
+
+The confirmation block must include:
+
+- one explicit instruction: `Reply with a number.`
+- 1-3 numbered options, with item 1 usually marked as `Recommended`
+- `Other:` explaining how non-numbered content will be handled, usually as continued implementation work
+- if the user adds constraints but still has not made a clear choice, continue presenting updated numbered options until the user chooses, stops, or explicitly tells you to continue
+
+If the platform provides structured question UI such as `ask user questions`, `request_user_input`, or an equivalent mechanism, prefer that for these numbered options. If no such mechanism is available, render the `User Confirmation Request` block in the normal message. In either form, do not end with only a sentence like "archive is recommended" or "the next step is closeout."
+
 ## 2. User Review
 
 Let the user review the implementation. If they raise issues, continue editing and re-verify.
@@ -53,12 +66,22 @@ Before offering closeout choices, explicitly tell the user:
 
 If the current branch or workspace differs from the recorded `origin_*` fields, explicitly say that the implementation is now living in a temporary branch or temporary worktree. If the user switches to free-form text, treat it as a request for more code changes.
 
-Supported closeout paths are limited to these three outcomes:
+Supported closeout paths must first be selected from the actual temporary-worktree state. Do not show a fixed menu by intuition. First run:
+
+```bash
+"$ONESPEC_BASH" "$ONESPEC_CLOSEOUT" recommend-actions <change-id>
+```
+
+If `temporary_worktree: true`, supported closeout paths are limited to these three outcomes:
 
 - Archive the current change, then merge the branch into the base branch
 - Archive only, without merging
 - Delete the current temporary worktree and discard the code
 
+If `temporary_worktree: false`, the only supported closeout path is:
+
+- Archive only, without merging or deleting a worktree
+
 Merge, discard, deletion, and archive are consequential actions, but once the user has explicitly selected them in the numbered menu, execute them directly without another confirmation round.
 
 ## 2.1 Superpowers Worktree Priority
@@ -79,9 +102,9 @@ Default recommended order:
 3. if the user only wants to preserve the archive record without merging code, allow archive-only
 4. if the user wants to discard the code, delete the worktree and drop the local temporary branch
 
-## 2.2 Worktree Closeout Rules
+## 2.2 State-Specific Closeout Rules
 
-If the current workspace is a temporary worktree, show this menu:
+If the script reports `temporary_worktree: true`, show this menu:
 
 ```text
 1. Archive the current change, then merge the branch into the base branch
@@ -99,14 +122,14 @@ Menu interpretation:
 
 If the current workspace is not a temporary worktree and the code is already truly on the target branch, `archive-only` is allowed.
 
-If the current checkout is not a temporary worktree, the current branch already equals `origin_branch`, and that branch is `main` or `master`, do not show the "archive then merge" or "delete the current temporary worktree" options. In that case the closeout menu must contain only:
+If the script reports `temporary_worktree: false`, the code is already truly on the target branch/workspace. Regardless of whether the target branch is `main`, `master`, `develop`, `feature/*`, or any other name, do not show the "archive then merge" or "delete the current temporary worktree" options. In that case the closeout menu must contain only:
 
 ```text
-1. Archive only, without merging
+1. Archive only (current checkout is not a temporary worktree; no branch merge or worktree deletion is needed)
 Other: any non-numbered content means continue modifying the current implementation; if the user gives no input, remain paused in the current review stage
 ```
 
-In other words, on `master/main`, do not prompt for branch merge or worktree deletion.
+In other words, when `temporary_worktree: false`, do not prompt for branch merge or worktree deletion on any target branch.
 
 If the user already selected a closeout number in the execute phase completion menu, do not repeat the same menu here; combine that reply with the actual workspace state and execute the matching action directly.
 
@@ -141,8 +164,8 @@ Before merge, discard, delete, or archive is finalized, always check whether the
   1. auto-commit current-workspace dirty files related to the change before closeout continues
   2. if archive creates new archive artifacts or removes `.onespec.yaml`, auto-commit the archive result after archive finishes
   3. if the user chooses archive-then-merge, merge the implementation branch back into the base branch only after the archive commit is complete
-- If the user selects `archive-then-merge-worktree`, archive first, then merge into the target branch, and set state to `archived`.
-- If the user selects `archive-only`, run OpenSpec archive and set state to `archived`; do not auto-merge and do not auto-delete the current worktree.
+- If the user selects `archive-then-merge-worktree`, run it only when `temporary_worktree: true`; archive first, then merge into the target branch, then delete the temporary worktree, and set state to `archived`.
+- If the user selects `archive-only`, run OpenSpec archive and set state to `archived`; do not auto-merge. When `temporary_worktree: false`, also do not delete any workspace or worktree.
 - If the user discards the worktree, do not archive and do not merge discarded branch code into the base branch.
 - Only after archive actually runs should the runtime state file be removed:
 

package/assets/skills-en/onespec/references/design.md

@@ -22,7 +22,7 @@ Treat `recover` output as the current phase contract, not as reference informati
 
 Read the minimum necessary context:
 
-- Relevant parts of `openspec/config.yaml`, `openspec/project.md`, and `openspec/specs/**`
+- Relevant parts of `openspec/config.yaml` and `openspec/specs/**`
 - Relevant project entry docs such as `AGENTS.md`, `README.md`, or `docs/**`
 - Current branch and workspace state
 
@@ -138,6 +138,19 @@ Always state:
   - `Superpowers + subagent + current worktree/current branch`
 - that the user may override the recommendation
 
+### 3.1 User Confirmation Request Rules
+
+When the result requires the user to decide whether to approve, start implementation, change the path, or stay in design, render "user choice required" as a standalone block titled `User Confirmation Request`. Do not mix the conclusion, recommendation, and pending confirmation into one paragraph.
+
+The confirmation block must include:
+
+- one explicit instruction: `Reply with a number.`
+- 2-4 numbered options, with item 1 usually marked as `Recommended`
+- `Other:` explaining that the user may add constraints or request an operation not listed
+- if the user adds constraints but still has not made a clear choice, continue presenting updated numbered options until the user chooses, stops, or explicitly tells you to continue
+
+If the platform provides structured question UI such as `ask user questions`, `request_user_input`, or an equivalent mechanism, prefer that for these numbered options. If no such mechanism is available, render the `User Confirmation Request` block in the normal message. In either form, do not end with only a sentence like "I recommend this path."
+
 ## 4. Proposal Approval Gate and Path Selection
 
 Default intent mapping, issue-workflow routing, or implementation recommendations do not count as proposal approval.

package/assets/skills-en/onespec/references/execute.md

@@ -36,6 +36,19 @@ Default intent mapping:
 
 If the proposal is not approved yet, stop immediately.
 
+### 1.1 User Confirmation Request Rules
+
+When execution requires the user to confirm the implementation path, workspace policy, continued implementation, return to design revision, or post-completion closeout action, render "user choice required" as a standalone block titled `User Confirmation Request`. Do not mix conclusions, verification results, recommendations, and pending confirmation into one paragraph.
+
+The confirmation block must include:
+
+- one explicit instruction: `Reply with a number.`
+- 2-6 numbered options, with item 1 usually marked as `Recommended`
+- `Other:` explaining how non-numbered content will be handled, usually as continued implementation work or extra constraints
+- if the user adds constraints but still has not made a clear choice, continue presenting updated numbered options until the user chooses, stops, or explicitly tells you to continue
+
+If the platform provides structured question UI such as `ask user questions`, `request_user_input`, or an equivalent mechanism, prefer that for these numbered options. If no such mechanism is available, render the `User Confirmation Request` block in the normal message. In either form, do not end with only a sentence like "the next step is that phase" or "I recommend this path."
+
 If the proposal phase already confirmed the implementation path:
 
 - user chose `Superpowers`: continue into Superpowers Make Plan.
@@ -214,7 +227,15 @@ After running those commands, the user-facing report must include all of the fol
 
 ### 5.3 Numbered Next-Step Menu Template
 
-The report must end with a menu equivalent to:
+Before generating the next-step menu, inspect the current closeout state with the script. Do not infer whether merge/worktree deletion is needed from branch names, path names, or intuition:
+
+```bash
+"$ONESPEC_BASH" "$ONESPEC_CLOSEOUT" recommend-actions <change-id>
+```
+
+Generate the menu from the inspected state:
+
+- If `temporary_worktree: true`, the current implementation lives in a temporary worktree. The report must end with a menu equivalent to:
 
 ```text
 ---
@@ -231,7 +252,7 @@ Other: any non-numbered content means continue modifying the current implementat
 ---
 ```
 
-If the current checkout is not a temporary worktree, the current branch already equals `origin_branch`, and that branch is `main` or `master`, do not show "merge the branch into the base branch" or "delete the current temporary worktree". In that case the closeout menu must collapse to a single archive-only option:
+- If `temporary_worktree: false`, the current implementation is already on the target branch/workspace and there is no temporary worktree to merge back or delete. Regardless of whether that branch is `main`, `master`, `develop`, `feature/*`, or any other name, do not show "merge the branch into the base branch" or "delete the current temporary worktree". In that case the closeout menu must collapse to a single archive-only option:
 
 ```text
 ---
@@ -241,18 +262,19 @@ Current branch: <branch>
 Current workspace: <path>
 Origin: <origin_branch> @ <origin_workspace_path>
 
-1. Archive only, without merging
+1. Archive only (current checkout is not a temporary worktree; no branch merge or worktree deletion is needed)
 Other: any non-numbered content means continue modifying the current implementation; if the user gives no input, remain paused in the current review stage
 ---
 ```
 
-In other words, on `master/main`, do not prompt for branch merge or worktree deletion.
+In other words, when `temporary_worktree: false`, do not prompt for branch merge or worktree deletion on any target branch.
 
-If the current branch or workspace differs from `origin_*`, add an explicit note that implementation currently lives in a temporary branch or temporary worktree and that any non-numbered reply will be treated as a request for more implementation work.
+If the script reports that the current branch or workspace differs from `origin_*`, add an explicit note that implementation currently lives in a temporary branch or temporary worktree and that any non-numbered reply will be treated as a request for more implementation work.
 
-- If the user chooses `1`, archive phase must archive first, then merge the branch into the base branch.
-- If the user chooses `2`, archive phase must archive only, without merging and without auto-deleting the current worktree.
-- If the user chooses `3`, archive phase must delete the temporary worktree and discard the code without archiving.
+- If `temporary_worktree: true` and the user chooses `1`, archive phase must archive first, then merge the branch into the base branch, then delete the temporary worktree.
+- If `temporary_worktree: true` and the user chooses `2`, archive phase must archive only, without merging and without auto-deleting the current worktree.
+- If `temporary_worktree: true` and the user chooses `3`, archive phase must delete the temporary worktree and discard the code without archiving.
+- If `temporary_worktree: false` and the user chooses `1`, archive phase must archive only; it must not merge a branch or delete any workspace/worktree.
 
 Do not stop at an abstract note such as "the next step is archive phase" or just "do review-closeout". You must also give the user a concrete numbered menu.
 

package/assets/skills-en/onespec/references/fast.md

@@ -24,7 +24,7 @@ Use rules:
 
 - Use only when the user explicitly asks for `onespec-fast`, the fast path, fast apply, automatic OpenSpec proposal/implementation/archive, or automatic end-to-end execution.
 - Do not ask the user to name the change. Generate a short kebab-case `change-id`; append a numeric suffix if needed.
-- Read the minimum needed context: `openspec/config.yaml`, `openspec/project.md`, relevant `openspec/specs/**`, project entry docs, current branch, and workspace state.
+- Read the minimum needed context: `openspec/config.yaml`, relevant `openspec/specs/**`, project entry docs, current branch, and workspace state.
 - Pause only when required OpenSpec context is too incomplete to produce a valid proposal, or project docs explicitly forbid automatic edits on the current branch.
 
 ## 2. Direct Proposal

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kafka0102/onespec",
-  "version": "0.1.14",
+  "version": "0.2.2",
   "description": "OpenSpec + Superpowers workflow skill installer for mainstream SKILL.md agents",
   "repository": {
     "type": "git",
@@ -38,5 +38,8 @@
   "engines": {
     "node": ">=20"
   },
-  "license": "MIT"
+  "license": "MIT",
+  "dependencies": {
+    "@inquirer/prompts": "^8.4.3"
+  }
 }

package/src/cli.js

@@ -1,11 +1,10 @@
 import path from 'node:path';
-import readline from 'node:readline/promises';
-import { stdin as input, stdout as output } from 'node:process';
 import { readFile } from 'node:fs/promises';
+import { checkbox, select, confirm } from '@inquirer/prompts';
 
 import { doctorProject } from './doctor.js';
 import { SUPPORTED_LANGUAGES } from './init.js';
-import { getPlatform } from './platforms.js';
+import { getPlatform, PLATFORMS } from './platforms.js';
 import {
   detectExistingOneSpecPlatforms,
   detectPlatforms,
@@ -62,8 +61,57 @@ function parseArgs(argv) {
   return { command, options };
 }
 
-function normalizeYesNo(value) {
-  return ['y', 'yes', '是', '覆盖'].includes(value.trim().toLowerCase());
+async function selectScope(options) {
+  if (options.scope) return options.scope;
+  if (options.yes) return 'project';
+
+  return select({
+    message: 'Install scope:',
+    choices: [
+      { name: 'Project (current directory)', value: 'project' },
+      { name: 'Global (home directory)', value: 'global' },
+    ],
+  });
+}
+
+async function selectLanguage(options) {
+  if (options.yes) return 'zh';
+
+  const langId = await select({
+    message: 'Language for OneSpec skills:',
+    choices: Object.entries(SUPPORTED_LANGUAGES).map(([id, lang]) => ({ name: lang.name, value: id })),
+  });
+
+  return langId;
+}
+
+async function selectPlatforms(detected, options) {
+  const choices = SUPPORTED_PLATFORM_IDS.map((platformId) => {
+    const platform = getPlatform(platformId);
+    return {
+      name: `${platform.name}${detected.has(platformId) ? ' (detected)' : ''}`,
+      value: platformId,
+      checked: detected.has(platformId),
+    };
+  });
+
+  if (options.yes) {
+    const selected = [...detected];
+    return selected.length > 0 ? selected : ['codex'];
+  }
+
+  return checkbox({ message: 'Select platforms to set up:', choices, required: true });
+}
+
+async function askOverwrite(existingPlatforms, options) {
+  if (options.overwrite || existingPlatforms.length === 0) {
+    return options.overwrite;
+  }
+
+  return confirm({
+    message: `OneSpec skills already exist for ${existingPlatforms.join(', ')}. Overwrite existing items?`,
+    default: false,
+  });
 }
 
 async function askInitOptions(options) {
@@ -80,79 +128,24 @@ async function askInitOptions(options) {
     };
   }
 
-  const rl = readline.createInterface({ input, output });
-  try {
-    if (explicitPlatforms.length === 0) {
-      console.log('可选 AI 平台：');
-      for (const [index, platformId] of SUPPORTED_PLATFORM_IDS.entries()) {
-        const platform = getPlatform(platformId);
-        const detectedSuffix = detectedPlatforms.includes(platformId) ? ' [detected]' : '';
-        console.log(`  ${index + 1}. ${platform.name} (${platform.id})${detectedSuffix}`);
-      }
-      console.log('');
-    }
-
-    const platformAnswer =
-      explicitPlatforms.length > 0
-        ? explicitPlatforms.join(',')
-        : await rl.question(
-            `安装到哪些 AI 平台？输入编号或 id，逗号分隔（默认 ${defaultPlatforms.join(',')}）：`,
-          );
-    const selectedPlatforms = resolvePlatformSelection(platformAnswer, defaultPlatforms);
-    const scopeAnswer =
-      options.scope ??
-      (await rl.question('安装范围？输入 project 或 global（默认 project）：'));
-    const resolvedScope = scopeAnswer.trim() || 'project';
-    const languageAnswer =
-      options.language ??
-      (await rl.question('Skill 语言？输入 zh 或 en（默认 zh）：'));
-    const existingPlatforms = await detectExistingOneSpecPlatforms(
-      options.targetPath,
-      resolvedScope,
-      selectedPlatforms,
-    );
-    const overwriteAnswer =
-      options.overwrite || existingPlatforms.length === 0
-        ? 'no'
-        : await rl.question(
-            `检测到这些平台已存在 OneSpec skill：${existingPlatforms.join(', ')}。是否覆盖已存在项？输入 yes 或 no（默认 no）：`,
-          );
-
-    return {
-      ...options,
-      platforms: selectedPlatforms,
-      scope: resolvedScope,
-      language: languageAnswer.trim() || 'zh',
-      overwrite: options.overwrite || normalizeYesNo(overwriteAnswer),
-    };
-  } finally {
-    rl.close();
-  }
-}
-
-function resolvePlatformSelection(answer, defaultPlatforms) {
-  const trimmed = answer.trim();
-  if (!trimmed) {
-    return defaultPlatforms;
-  }
-
-  const numbered = trimmed
-    .split(',')
-    .map((value) => value.trim())
-    .filter(Boolean)
-    .map((value) => {
-      if (!/^\d+$/.test(value)) {
-        return value;
-      }
-
-      const index = Number.parseInt(value, 10) - 1;
-      if (index < 0 || index >= SUPPORTED_PLATFORM_IDS.length) {
-        throw new Error(`Unsupported platform selection: ${value}`);
-      }
-      return SUPPORTED_PLATFORM_IDS[index];
-    });
-
-  return parsePlatformList(numbered);
+  const detectedSet = new Set(detectedPlatforms);
+  const selectedPlatforms = explicitPlatforms.length > 0 ? explicitPlatforms : await selectPlatforms(detectedSet, options);
+  const resolvedScope = await selectScope(options);
+  const language = await selectLanguage(options);
+  const existingPlatforms = await detectExistingOneSpecPlatforms(
+    options.targetPath,
+    resolvedScope,
+    selectedPlatforms,
+  );
+  const overwrite = await askOverwrite(existingPlatforms, options);
+
+  return {
+    ...options,
+    platforms: selectedPlatforms,
+    scope: resolvedScope,
+    language,
+    overwrite,
+  };
 }
 
 function printHelp() {

package/src/platforms.js

@@ -21,7 +21,7 @@ export const PLATFORMS = {
     projectSkillsDir: path.join('.claude', 'skills'),
     globalSkillsDir: path.join(claudeHome, 'skills'),
     discoveryRoots: [],
-    openspecToolId: 'claude-code',
+    openspecToolId: 'claude',
   },
   cursor: {
     id: 'cursor',
@@ -37,7 +37,7 @@ export const PLATFORMS = {
     projectSkillsDir: path.join('.agents', 'skills'),
     globalSkillsDir: path.join(home, '.gemini', 'skills'),
     discoveryRoots: [path.join(home, '.agents', 'skills')],
-    openspecToolId: 'gemini-cli',
+    openspecToolId: 'gemini',
   },
   'github-copilot': {
     id: 'github-copilot',