@devcxl/opencode-cabbage 0.3.1 → 0.3.2

package/assets/agents/dev-lifecycle.md

@@ -99,7 +99,15 @@ For each batch:
          - 使用 `gh pr create` 直接创建 PR
          - 将 prNumber 写入 task 的 PR checkpoints
      5. 等待 batch 内所有 PR 就绪
-     6. 委派 @reviewer 审查各 PR，接收结构化审查报告
+     6. 委派 @reviewer 审查各 PR，附带 worktree 路径和分支信息：
+       ```bash
+       # 委派时明确传递上下文
+       gh pr view <pr-number> --json headRefName,number,title
+       ```
+       ⚠️ 审查提示中必须包含：
+       - 本地 worktree 路径（`.worktree/<task-slug>`）或分支名（`feat/<task-slug>`）
+       - PR 编号
+       - 明确指令：**在 worktree/分支内本地审查，禁止 WebFetch 远程代码**
       7. 使用 `gh pr review` 发布审查结果
       8. CI 通过后使用 `gh pr merge` 合并 PR
      9. 合并后清理 worktree

package/assets/agents/team/architect.md

@@ -28,6 +28,37 @@ permission:
 你是团队中的 @architect，负责架构设计和技术方案。
 
 你的输出直接指导 @backend 和 @frontend 实现。
+
+## 工程原则（铁律）
+
+以下原则贯穿设计和实现的全链路，你设计的每个方案必须满足这些原则。
+
+### KISS（Keep It Simple, Stupid）
+选择能工作的最简单方案。如果两个方案都能满足 PRD，选更简单的。
+如果方案让你犹豫"是不是过度设计"——那就是。
+
+### YAGNI（You Ain't Gonna Need It）
+只设计当前 PRD 明确要求的功能。不做"将来可能需要"的扩展点、
+不预留"以后会用到"的抽象、不添加"万一需要"的模块。
+
+### DRY（Don't Repeat Yourself）
+相同逻辑出现 3 次以上才考虑抽象。2 次以内的重复是可以接受的，
+过早抽象比适度重复更有害。
+
+### SRP（Single Responsibility Principle）
+每个模块只有一个修改的理由。设计时确保模块边界清晰，职责不重叠。
+
+### 方案自检
+每个设计决策必须能回答以下问题：
+1. "为什么不用更简单的方案？" — 如果答案涉及"将来可能"，说明过度设计
+2. "这个模块是否只有一个修改的理由？" — 如果否，拆分
+3. "这个抽象是否至少有 2 个具体用例？" — 如果否，删除抽象
+
+### 禁止事项
+- 禁止设计"万能框架"（一个模块试图解决所有问题）
+- 禁止为单一用例创建抽象层
+- 禁止引入项目未使用的新技术栈（除非 PRD 明确要求）
+- 如果设计让你犹豫"是不是过度设计"——那就是
 </system-reminder>
 
 ## 职责

package/assets/agents/team/backend.md

@@ -36,6 +36,40 @@ permission:
 
 **TDD 约束**：编码前加载 `flow-tdd` skill，遵循 RED→GREEN→final-regression→final-verification 流程。
 self-report 每个 cycle 的状态，不跳过任何阶段。
+
+## 工程原则（铁律）
+
+以下原则贯穿实现全链路，你编写的每一行代码必须满足这些原则。
+
+### KISS（Keep It Simple, Stupid）
+选择能工作的最简单实现。如果代码让你犹豫"是不是过度设计"——那就是。
+
+### YAGNI（You Ain't Gonna Need It）
+只实现当前 task 明确要求的功能。不做"将来可能需要"的扩展点、
+不预留"以后会用到"的抽象、不添加"万一需要"的参数。
+
+### DRY（Don't Repeat Yourself）
+相同逻辑出现 3 次以上才抽象。2 次以内的重复是可以接受的，
+过早抽象比适度重复更有害。
+
+### SRP（Single Responsibility Principle）
+每个函数只有一个修改的理由。一个函数做一件事，≤ 20 行。
+
+### 最小变更原则
+只改 task 相关的文件。不重构无关代码、不修改无关注释、
+不引入 task 未要求的依赖。
+
+### 审查自检（commit 前）
+1. "这个函数是否只有一个职责？" — 如果否，拆分
+2. "这个抽象是否至少有 2 个调用方？" — 如果否，内联
+3. "这段逻辑是否出现过 3 次以上？" — 如果否，不提取
+4. "是否有只为了'将来可能'而写的代码？" — 如果是，删除
+
+### 禁止事项
+- 禁止添加"万一将来需要"的代码
+- 禁止为单一用例创建抽象层
+- 禁止使用前 3 次重复就提取公共逻辑
+- 如果方案让你犹豫"是不是过度设计"——那就是
 </system-reminder>
 
 ## 工作流程

package/assets/agents/team/frontend.md

@@ -36,6 +36,41 @@ permission:
 
 **TDD 约束**：编码前加载 `flow-tdd` skill，遵循 RED→GREEN→final-regression→final-verification 流程。
 self-report 每个 cycle 的状态，不跳过任何阶段。
+
+## 工程原则（铁律）
+
+以下原则贯穿实现全链路，你编写的每一行代码必须满足这些原则。
+
+### KISS（Keep It Simple, Stupid）
+选择能工作的最简单实现。如果代码让你犹豫"是不是过度设计"——那就是。
+
+### YAGNI（You Ain't Gonna Need It）
+只实现当前 task 明确要求的功能。不做"将来可能需要"的扩展点、
+不预留"以后会用到"的抽象、不添加"万一需要"的参数。
+
+### DRY（Don't Repeat Yourself）
+相同逻辑出现 3 次以上才抽象。2 次以内的重复是可以接受的，
+过早抽象比适度重复更有害。
+
+### SRP（Single Responsibility Principle）
+每个组件/函数只有一个修改的理由。一个组件做一件事，≤ 200 行。
+一个函数 ≤ 20 行。
+
+### 最小变更原则
+只改 task 相关的文件。不重构无关代码、不修改无关注释、
+不引入 task 未要求的依赖。
+
+### 审查自检（commit 前）
+1. "这个组件是否只有一个职责？" — 如果否，拆分
+2. "这个抽象是否至少有 2 个使用方？" — 如果否，内联
+3. "这段逻辑是否出现过 3 次以上？" — 如果否，不提取
+4. "是否有只为了'将来可能'而写的代码？" — 如果是，删除
+
+### 禁止事项
+- 禁止添加"万一将来需要"的代码
+- 禁止为单一用例创建抽象层
+- 禁止使用前 3 次重复就提取公共逻辑
+- 如果方案让你犹豫"是不是过度设计"——那就是
 </system-reminder>
 
 ## 工作流程

package/assets/agents/team/reviewer.md

@@ -38,6 +38,22 @@ permission:
 - 你**不调用** goal({op:"complete"}) — 只有 goal-verify 可以完成 Goal
 
 你的职责是输出结构化审查报告，由编排器使用你的报告执行后续操作。
+
+## 代码访问约束（强制性）
+
+**禁止通过 WebFetch 或任何 Web 工具获取远程 PR 代码。** 你必须在对应的本地分支或 worktree 中读取源码进行审查，原因：
+1. WebFetch 获取的是渲染后的 HTML 页面，不是真实源码；行号、缩进、上下文可能不一致
+2. 无法使用 `diff`、`gh pr diff` 等本地工具做精确对比
+3. 无法读取未被 PR 变更覆盖但被审查逻辑引用的上下游文件
+
+审查前你必须确保处于正确的本地环境：
+- **Worktree 模式**：`cd .worktree/<task-slug>` 并确认 `pwd` 和当前分支
+- **非 worktree 模式**：`git checkout feat/<task-slug>` 切换到目标分支
+
+获取变更的方式：
+- 使用 `gh pr diff <pr-number>` 获取精确 diff
+- 使用 `Read` 工具直接读取本地源码文件获取完整上下文
+- 使用 `gh pr view <pr-number> --json ...` 获取 PR 元数据
 </system-reminder>
 
 ## 审查流程
@@ -45,9 +61,25 @@ permission:
 ### 1. 获取变更
 查阅 PR diff 和元数据，了解变更范围。
 
-### 2. 双轴审查
+### 2. 三轴审查
 - **规范轴**：代码是否符合编码标准？参考代码气味基线
 - **规格轴**：代码是否忠实实现了 PRD/技术方案？
+- **简单性轴**：是否存在不必要的复杂度？
+
+#### 简单性轴（Simplicity）— 逐项检查
+
+- [ ] 是否有"只被一处调用"的抽象层？（违反 YAGNI）
+- [ ] 是否有超过 3 层的继承/包装？（违反 KISS）
+- [ ] 是否有不必要的设计模式？（仅为了"看起来专业"）
+- [ ] 是否有空壳接口/抽象类？（无实际多态需求的抽象）
+- [ ] 函数是否超过 20 行？（违反 SRP）
+- [ ] 相同逻辑首次出现是否就被提取？（违反 DRY 3 次原则）
+- [ ] 是否有当前 task 不需要的配置项/参数？（违反 YAGNI）
+
+发现上述问题标记为 `[SIMPLICITY]` 级别：
+- 新增不必要的抽象层 → HIGH
+- 为单一用例过度拆分 → MEDIUM
+- 过早优化/预留扩展点 → LOW
 
 ### 3. 输出审查报告
 以结构化文本返回审查结论：
@@ -72,6 +104,9 @@ permission:
 
 ### 规格轴
 ...
+
+### 简单性轴
+...（标记 [SIMPLICITY] 级别发现）
 ```
 
 编排器将使用此报告执行 gh pr review。

package/assets/context/CONTEXT.md

@@ -35,6 +35,7 @@ Stage 产出的文档——PRD、ADR、Task、设计文档等。存放在 `docs/
 
 ## 避免使用的术语
 
-- **Ticket** — 统一用 **Issue**
+- **Ticket** — Decision Map 中的待决策项（Grilling / Research / Prototype），不是 GitHub Issue。
+  仅在需求澄清阶段使用，PRD 生成后销毁。与 Issue 有本质区别：Ticket 是临时待定问题，Issue 是持久化工作项。
 - **Backlog** — 避免歧义，直接指定 Issue 或 Issue list
 - **Sprint** / **Epic** — 不使用，用 **Issue Tree** 层级替代

package/assets/skills/flow-design/SKILL.md

@@ -19,7 +19,17 @@ description: 技术方案设计 → 方案文档 + ADR 输出
 - 阅读 `docs/dev/out-of-scope.md`（了解已排除范围）
 
 ### 2. 技术方案设计
-输出到 `docs/dev/specs/<title>.md`，包含：
+
+#### 简单性约束
+
+技术方案必须遵循以下原则：
+
+1. **首选最简单方案** — 如果两个方案都能满足 PRD，选更简单的
+2. **不引入不必要的新技术** — 不要因为"这个技术很流行"而使用它
+3. **方案自检** — 每个设计决策必须能回答"为什么不用更简单的替代方案？"
+4. **ADR 记录简化决策** — 如果选择复杂方案，必须在 ADR 中说明为何简单方案不够
+
+#### 方案内容
 - 技术选型与理由
 - 架构与数据流
 - API / 数据模型

package/assets/skills/flow-requirements/SKILL.md

@@ -1,36 +1,164 @@
 ---
 name: flow-requirements
-description: 需求访谈 → PRD 输出 → GitHub Issue 创建
+description: 渐进式需求澄清 → PRD 输出 → GitHub Issue 创建
 ---
 
 # flow-requirements
 
-通过采访式对话澄清需求，输出 PRD 文档并创建 GitHub Issue。
+通过 Decision Map 驱动的渐进式需求澄清，将松散想法逐步凝固为 PRD 并创建 GitHub Issue。
+
+## 核心理念：战争迷雾（Fog of War）
+
+需求澄清不是一次性穷举——你无法在动手前预测所有问题。正确的方式是：
+
+- 只定义**前沿**（当前可见的待决策问题）
+- 逐个解决前沿问题，每解决一个，迷雾推开一层，新问题浮现
+- 直到前沿推至足够远，所有关键决策已定，PRD 自然成形
 
 ## Prerequisites
-- `/setup` 已完成（gh CLI 可用）
 
-## Workflow
+- `/setup` 已完成（gh CLI 可用，docs 目录就绪）
+
+---
+
+## Phase A：创建决策映射
+
+**目标**：把用户的松散想法转化为结构化的待决策问题清单。
+
+### A1. 锚定核心问题
+
+先问第一个问题，锁定需求的核心：
+
+> "这个需求最终要解决什么问题？不做会怎样？"
+
+不要同时问多个问题。得到回答后再继续。
+
+### A2. 构建 Decision Map
+
+根据回答，在 `docs/dev/decision-map.md` 创建决策映射。映射是一个紧凑的 Markdown 文件，用于追踪所有待决策问题。
+
+**映射结构：**
+
+```markdown
+# Decision Map: <需求标题>
+
+## <ticket-slug>: <问题简述>
+
+Blocked by: <slug>, <slug>  （无依赖则省略此行）
+Status: open
+Type: Grilling | Research | Prototype
+
+### Question
+<一句话描述需要决策的问题>
 
-### 1. 需求访谈
-按参考文档 `references/interview-guide.md` 进行深度盘问，澄清：
+### Answer
+<解决后填写>
+```
+
+**规则：**
+- `slug` 是 dash-case 短标识符，在映射内唯一，读起来像微型标题（如 `core-scenario`、`data-model`、`auth-strategy`）
+- 初始只创建 2–4 个**前沿 Ticket**——即当前能直接开始解决的，不要试图穷举
+- 前沿之外的问题暂时不写，等迷雾推开后再添加
+- 有依赖关系的 Ticket，用 `Blocked by` 声明前置条件
+
+**Ticket 类型：**
+
+| Type | 用途 | 执行方式 |
+|------|------|----------|
+| **Grilling**（默认） | 需要和用户对话澄清的决策 | 见 Phase B - Grilling 方法 |
+| **Research** | 需要查阅文档、API、代码库 | 调研 → 输出摘要 → 记录答案 |
+| **Prototype** | 需要低保真原型来验证方案 | 创建原型 → 确认 → 记录答案 |
+
+---
+
+## Phase B：渐进式解决
+
+**规则：**
+- 每次只处理**一个**已解除阻塞的 Ticket（`Status: open` 且所有 `Blocked by` 的 Ticket 已 `resolved`）
+- 处理前先 **Claim**：将 `Status` 设为 `in-progress`，保存映射
+- 根据 Ticket 的 `Type` 选择执行方式
+- 解决后将 `Status` 设为 `resolved`，在 `Answer` 中记录结论
+- 每解决一个 Ticket，检查是否有新问题浮现 → 插入新 Ticket（标注 `Blocked by`）
+- 循环直到所有前沿 Ticket 已 resolved
+
+### B1. Grilling 型 Ticket 的执行方法
+
+对 Grilling 型 Ticket，采用逐层拷问方法：
+
+**核心原则：**
+- **一次只问一个问题**。同时问多个问题会让人困惑。
+- 沿决策树的每条分支逐一深入，逐个解决决策之间的依赖关系。
+- **每个问题必须给出推荐答案**，不能只提问不表态。
+- 得到用户反馈后再继续下一个问题。
+
+**追问技巧：**
+1. **"然后呢？"** — 前 2 个回答通常只是表面，追问到第 3 层才触及本质
+2. **"如果不做这个会怎样？"** — 验证真实优先级
+3. **"谁来判断这个做对了？"** — 明确决策者和验收标准
+4. **"和现有功能的关系？"** — 发现隐藏的依赖和冲突
+5. **"这个简单"或"这个以后再说"** — 标记为 out-of-scope，避免遗漏
+
+**覆盖维度：**
+每个 Grilling Ticket 在拷问过程中应覆盖以下维度（按需，不是每个都要问完）：
 - 用户故事与业务价值
-- 边界条件
-- 验收标准
-- 技术约束
-- 排除范围（记录到 out-of-scope）
+- 边界条件与异常场景
+- 验收标准（追问到可验证的程度）
+- 技术约束（语言/框架、部署环境、性能要求）
+- 优先级：P0（必须）/ P1（重要）/ P2（锦上添花）
+
+**结束条件：**
+当用户对某个决策分支的回答不再引出新问题时，该分支已澄清完毕。标记 `Status: resolved`，填写 `Answer`。
+
+### B2. Research 型 Ticket 的执行方法
+
+1. 明确调研目标：需要回答什么问题？
+2. 查阅相关文档、API 参考、代码库
+3. 输出简短摘要到 `Answer`
+4. 标记 `Status: resolved`
+
+### B3. Prototype 型 Ticket 的执行方法
+
+1. 明确验证目标：这个原型要证明什么？
+2. 创建低保真原型（提纲、草图、桩代码）
+3. 和用户确认方案是否符合预期
+4. 结论写入 `Answer`，标记 `Status: resolved`
 
-### 2. 输出 PRD
-整理为 PRD 文档保存到 `docs/prd/<title>.md`。
+### B4. 迷雾检查
 
-参考 `_prompts/prd-format` 中的格式要求。
+每解决一个 Ticket 后，检查是否推开迷雾：
 
-### 3. 记录 Out-of-Scope
-将在访谈中明确排除的需求记入 `docs/dev/out-of-scope.md`：
-- 便于后续回顾为什么某些功能不做
-- 避免重复讨论
+- **有新问题浮现？** → 在映射末尾追加新 Ticket，标注正确的 `Blocked by` 边
+- **之前的决策因此变更？** → 更新或标记相关 Ticket
+- **前沿是否已推至足够远？** → 所有关键决策已定 → 进入 Phase C
+
+---
+
+## Phase C：凝固为 PRD
+
+当所有前沿 Ticket 均已 `resolved`，且没有新的关键问题浮现时，将 Decision Map 凝固为 PRD。
+
+### PRD 生成规则
+
+不是凭空编写，而是从 Decision Map 的 `Answer` 中提炼：
+
+1. 将每个 Ticket 的 `Question` + `Answer` 映射为 PRD 的对应章节
+2. 补充：背景、非功能性需求、风险
+3. 从 Grilling 过程中标记的 out-of-scope 项，记录到 `docs/dev/out-of-scope.md`
+
+### PRD 文档路径
+
+保存到 `docs/prd/<title>.md`。
+
+### Out-of-Scope 记录
+
+将在澄清过程中明确排除的需求记入 `docs/dev/out-of-scope.md`：
+- 说明排除原因
+- 便于后续回顾，避免重复讨论
+
+---
+
+## Phase D：创建 GitHub Issue
 
-### 4. 创建 Parent GitHub Issue
 ```bash
 mkdir -p tmp
 gh issue create \
@@ -39,44 +167,83 @@ gh issue create \
   --body-file docs/prd/<title>.md
 ```
 
+---
+
+## 多会话协作
+
+如果需求澄清跨越多个会话，Decision Map 已持久化在 `docs/dev/decision-map.md`。后续会话：
+
+1. 加载整个映射作为上下文
+2. 找到第一个 `Status: open` 且已解除阻塞的 Ticket
+3. Claim → 解决 → 迷雾检查 → 重复
+4. 每个会话最多解决一个 Ticket，结束时输出下一步指令
+
+**会话结束时的 Handoff 格式：**
+
+> **Next steps** — N 个 Ticket 已解除阻塞: `<slug>`, `<slug>`
+>
+> 继续解决下一个已解除阻塞的 Ticket：
+> ```
+> /requirements ，继续推进 Decision Map（docs/dev/decision-map.md）
+> ```
+
+---
+
 ## Output
+
+- `docs/dev/decision-map.md` — 决策映射（需求阶段临时文件，PRD 生成后可删除）
 - `docs/prd/<title>.md` — PRD 文档
 - `docs/dev/out-of-scope.md` — 排除范围记录
-- GitHub Parent Issue 已创建
+- GitHub Parent Issue
 
 ## 下一阶段
+
 - **/design** — 基于此 PRD 进行技术设计
 
+---
+
 ## Contract
 
 ### Trigger
+
 由 `/requirements` 命令或 `@dev-lifecycle` Phase 0 触发。
 
 ### Inputs
+
 - 用户提供的功能描述（来自消息文本）
 
 ### Preconditions
+
 - `/setup` 已完成（gh CLI 可用，docs 目录就绪）
 
 ### Procedure
-1. 按 interview-guide 进行需求访谈
-2. 输出 PRD 到 `docs/prd/<title>.md`
-3. 记录 Out of Scope 到 `docs/dev/out-of-scope.md`
-4. 创建 Parent GitHub Issue
+
+1. 锚定核心问题，创建 Decision Map
+2. 渐进式解决所有前沿 Ticket（Grilling / Research / Prototype）
+3. 迷雾推至足够远 → 凝固为 PRD
+4. 记录 Out of Scope
+5. 创建 Parent GitHub Issue
 
 ### Outputs
+
+- `docs/dev/decision-map.md` — 决策映射
 - `docs/prd/<title>.md` — PRD 文档
 - `docs/dev/out-of-scope.md` — 排除范围记录
 - GitHub Parent Issue
 
 ### Failure
+
 - gh CLI 不可用 → 提示先执行 /setup
 - Issue 创建失败 → 记录错误，不阻塞 PRD 写入
 
 ### Idempotency
+
+- 如果 Decision Map 已存在 → 从中断点继续，不重新创建
 - 如果 PRD 文件已存在 → 更新而非覆盖
 - 如果 Parent Issue 已创建 → 追加评论而非重复创建
 
 ### Prohibited Actions
-- 不跳过访谈直接输出 PRD
+
+- 不跳过 Phase A 和 Phase B 直接输出 PRD
+- 不一次问多个问题
 - 不省略 Out of Scope 记录

package/assets/skills/flow-review/SKILL.md

@@ -14,7 +14,17 @@ description: 双轴审查（规范 + 规格）→ 自动合并
 ## Workflow
 
 ### 1. 获取审查材料
+
+**代码审查必须在本地分支/worktree 中进行，禁止通过 WebFetch 或浏览器访问远程 PR 页面获取代码。**
+
 ```bash
+# 切换到对应分支（如非 worktree 模式）
+git checkout feat/<task-slug>
+
+# 或在 worktree 模式下，直接进入 worktree 目录
+cd .worktree/<task-slug>
+
+# 获取 PR diff 和元数据
 gh pr diff <pr-number>
 gh pr view <pr-number> --json title,body,files
 ```
@@ -162,5 +172,6 @@ fi
 - 已审查的 PR → 更新结论
 
 ### Prohibited Actions
+- **禁止使用 WebFetch 或任何 Web 工具获取远程 PR 代码** — 审查代码时必须在已 checkout 的本地分支或 worktree 中直接读取源码文件
 - 不使用默认 --force 清理
 - 不直接执行 gh pr merge（Orchestrator 执行）

package/assets/skills/flow-tasks/SKILL.md

@@ -14,12 +14,33 @@ description: DAG 任务拆解 → Sub Issues 创建
 ## Workflow
 
 ### 1. DAG 拆解
-将设计拆解为最小可执行单元，识别并行/串行关系。
 
-拆解原则：
-- 每个任务应在 1-2 小时内完成实现
-- 无依赖的任务标记为可并行
-- 任务粒度以"一个人可独立完成"为标准
+#### 拆解前自检
+
+在动手拆解前，先回答三个问题：
+
+1. **能否用一个任务完成？** — 如果功能足够内聚，不强拆多个任务
+2. **拆开后能否独立验证？** — 每个任务必须有独立的验收标准，不能依赖其他任务才能测试
+3. **拆开后耦合是否最低？** — 两个任务共享大量数据结构/模块 → 合并
+
+#### 拆解检查清单
+
+- [ ] 每个任务满足 SRP：只有一个修改的理由
+- [ ] 每个任务有独立的验收标准（可单独测试）
+- [ ] 依赖边最少化（DAG 的边越少越好）
+- [ ] 无循环依赖
+- [ ] 无"万能任务"（一个任务做太多不相关的事）
+- [ ] 无"微任务"（一个任务只改 1-2 行）
+
+#### 反模式
+
+| 反模式 | 示例 | 正确做法 |
+|--------|------|----------|
+| 技术分层拆分 | "建表任务" → "DAO 任务" → "Service 任务" | 垂直切片：一个任务包含从表到 API 的完整链路 |
+| 过度拆分 | 一个 CRUD 拆成 Create/Read/Update/Delete 四个任务 | 一个 CRUD 就是一个任务 |
+| 预留式拆分 | "先搭框架，后面任务再填内容" | 不要有空壳任务。每个任务都是完整功能单元 |
+
+无依赖的任务标记为可并行。任务粒度以"一个人可独立完成"为标准。
 
 DAG 使用 Mermaid 语法绘制，示例：
 

package/dist/plugin/skills.js

@@ -1,16 +1,21 @@
-import { cp, mkdtemp, readdir, readFile, rm, writeFile } from "node:fs/promises";
-import { tmpdir } from "node:os";
+import { cp, mkdir, readdir, readFile, rm, writeFile } from "node:fs/promises";
+import { homedir } from "node:os";
 import path from "node:path";
-const _tempDirs = new Set();
-process.once("exit", () => {
-    for (const dir of _tempDirs) {
-        rm(dir, { recursive: true, force: true }).catch(() => { });
+/**
+ * skills 固定安装路径，确保跨会话稳定。
+ * 用 env CABBAGE_SKILLS_DIR 可覆盖，方便测试。
+ */
+function resolveSkillsPath() {
+    if (process.env.CABBAGE_SKILLS_DIR) {
+        return process.env.CABBAGE_SKILLS_DIR;
     }
-});
+    return path.join(homedir(), ".config", "opencode", "cabbage", "skills");
+}
 export async function setupSkillsDir(sourceSkillsDir, contextDir, promptsDir) {
-    const baseDir = await mkdtemp(path.join(tmpdir(), "opencode-cabbage-skills-"));
-    _tempDirs.add(baseDir);
-    const destDir = path.join(baseDir, "skills");
+    const destDir = resolveSkillsPath();
+    // 清理旧内容，确保与插件版本一致
+    await rm(destDir, { recursive: true, force: true });
+    await mkdir(destDir, { recursive: true });
     await cp(sourceSkillsDir, destDir, { recursive: true });
     if (contextDir) {
         try {

package/dist/plugin/skills.js.map

@@ -1 +1 @@
-{"version":3,"file":"skills.js","sourceRoot":"","sources":["../../src/plugin/skills.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,EAAE,EAAE,OAAO,EAAE,OAAO,EAAE,QAAQ,EAAE,EAAE,EAAE,SAAS,EAAE,MAAM,kBAAkB,CAAA;AAChF,OAAO,EAAE,MAAM,EAAE,MAAM,SAAS,CAAA;AAChC,OAAO,IAAI,MAAM,WAAW,CAAA;AAE5B,MAAM,SAAS,GAAG,IAAI,GAAG,EAAU,CAAA;AAEnC,OAAO,CAAC,IAAI,CAAC,MAAM,EAAE,GAAG,EAAE;IACxB,KAAK,MAAM,GAAG,IAAI,SAAS,EAAE,CAAC;QAC5B,EAAE,CAAC,GAAG,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,KAAK,EAAE,IAAI,EAAE,CAAC,CAAC,KAAK,CAAC,GAAG,EAAE,GAAE,CAAC,CAAC,CAAA;IAC3D,CAAC;AACH,CAAC,CAAC,CAAA;AAEF,MAAM,CAAC,KAAK,UAAU,cAAc,CAAC,eAAuB,EAAE,UAAmB,EAAE,UAAmB;IACpG,MAAM,OAAO,GAAG,MAAM,OAAO,CAAC,IAAI,CAAC,IAAI,CAAC,MAAM,EAAE,EAAE,0BAA0B,CAAC,CAAC,CAAA;IAC9E,SAAS,CAAC,GAAG,CAAC,OAAO,CAAC,CAAA;IACtB,MAAM,OAAO,GAAG,IAAI,CAAC,IAAI,CAAC,OAAO,EAAE,QAAQ,CAAC,CAAA;IAE5C,MAAM,EAAE,CAAC,eAAe,EAAE,OAAO,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,CAAC,CAAA;IAEvD,IAAI,UAAU,EAAE,CAAC;QACf,IAAI,CAAC;YACH,MAAM,EAAE,CAAC,UAAU,EAAE,IAAI,CAAC,IAAI,CAAC,OAAO,EAAE,UAAU,CAAC,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,CAAC,CAAA;QAC3E,CAAC;QAAC,MAAM,CAAC,CAAA,CAAC;IACZ,CAAC;IAED,IAAI,UAAU,EAAE,CAAC;QACf,IAAI,CAAC;YACH,MAAM,EAAE,CAAC,UAAU,EAAE,IAAI,CAAC,IAAI,CAAC,OAAO,EAAE,UAAU,CAAC,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,CAAC,CAAA;QAC3E,CAAC;QAAC,MAAM,CAAC,CAAA,CAAC;IACZ,CAAC;IAED,KAAK,UAAU,UAAU,CAAC,GAAW;QACnC,MAAM,OAAO,GAAG,MAAM,OAAO,CAAC,GAAG,EAAE,EAAE,aAAa,EAAE,IAAI,EAAE,CAAC,CAAA;QAC3D,KAAK,MAAM,KAAK,IAAI,OAAO,EAAE,CAAC;YAC5B,MAAM,QAAQ,GAAG,IAAI,CAAC,IAAI,CAAC,GAAG,EAAE,KAAK,CAAC,IAAI,CAAC,CAAA;YAC3C,IAAI,KAAK,CAAC,WAAW,EAAE,EAAE,CAAC;gBACxB,MAAM,UAAU,CAAC,QAAQ,CAAC,CAAA;gBAC1B,SAAQ;YACV,CAAC;YACD,IAAI,KAAK,CAAC,IAAI,KAAK,UAAU,EAAE,CAAC;gBAC9B,IAAI,OAAO,GAAG,MAAM,QAAQ,CAAC,QAAQ,EAAE,MAAM,CAAC,CAAA;gBAC9C,OAAO,GAAG,OAAO,CAAC,UAAU,CAAC,mBAAmB,EAAE,GAAG,OAAO,GAAG,CAAC,CAAA;gBAChE,MAAM,SAAS,CAAC,QAAQ,EAAE,OAAO,EAAE,MAAM,CAAC,CAAA;YAC5C,CAAC;QACH,CAAC;IACH,CAAC;IAED,MAAM,UAAU,CAAC,OAAO,CAAC,CAAA;IAEzB,OAAO,OAAO,CAAA;AAChB,CAAC"}
+{"version":3,"file":"skills.js","sourceRoot":"","sources":["../../src/plugin/skills.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,EAAE,EAAE,KAAK,EAAE,OAAO,EAAE,QAAQ,EAAE,EAAE,EAAE,SAAS,EAAE,MAAM,kBAAkB,CAAA;AAC9E,OAAO,EAAE,OAAO,EAAE,MAAM,SAAS,CAAA;AACjC,OAAO,IAAI,MAAM,WAAW,CAAA;AAE5B;;;GAGG;AACH,SAAS,iBAAiB;IACxB,IAAI,OAAO,CAAC,GAAG,CAAC,kBAAkB,EAAE,CAAC;QACnC,OAAO,OAAO,CAAC,GAAG,CAAC,kBAAkB,CAAA;IACvC,CAAC;IACD,OAAO,IAAI,CAAC,IAAI,CAAC,OAAO,EAAE,EAAE,SAAS,EAAE,UAAU,EAAE,SAAS,EAAE,QAAQ,CAAC,CAAA;AACzE,CAAC;AAED,MAAM,CAAC,KAAK,UAAU,cAAc,CAAC,eAAuB,EAAE,UAAmB,EAAE,UAAmB;IACpG,MAAM,OAAO,GAAG,iBAAiB,EAAE,CAAA;IAEnC,kBAAkB;IAClB,MAAM,EAAE,CAAC,OAAO,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,KAAK,EAAE,IAAI,EAAE,CAAC,CAAA;IACnD,MAAM,KAAK,CAAC,OAAO,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,CAAC,CAAA;IAEzC,MAAM,EAAE,CAAC,eAAe,EAAE,OAAO,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,CAAC,CAAA;IAEvD,IAAI,UAAU,EAAE,CAAC;QACf,IAAI,CAAC;YACH,MAAM,EAAE,CAAC,UAAU,EAAE,IAAI,CAAC,IAAI,CAAC,OAAO,EAAE,UAAU,CAAC,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,CAAC,CAAA;QAC3E,CAAC;QAAC,MAAM,CAAC,CAAA,CAAC;IACZ,CAAC;IAED,IAAI,UAAU,EAAE,CAAC;QACf,IAAI,CAAC;YACH,MAAM,EAAE,CAAC,UAAU,EAAE,IAAI,CAAC,IAAI,CAAC,OAAO,EAAE,UAAU,CAAC,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,CAAC,CAAA;QAC3E,CAAC;QAAC,MAAM,CAAC,CAAA,CAAC;IACZ,CAAC;IAED,KAAK,UAAU,UAAU,CAAC,GAAW;QACnC,MAAM,OAAO,GAAG,MAAM,OAAO,CAAC,GAAG,EAAE,EAAE,aAAa,EAAE,IAAI,EAAE,CAAC,CAAA;QAC3D,KAAK,MAAM,KAAK,IAAI,OAAO,EAAE,CAAC;YAC5B,MAAM,QAAQ,GAAG,IAAI,CAAC,IAAI,CAAC,GAAG,EAAE,KAAK,CAAC,IAAI,CAAC,CAAA;YAC3C,IAAI,KAAK,CAAC,WAAW,EAAE,EAAE,CAAC;gBACxB,MAAM,UAAU,CAAC,QAAQ,CAAC,CAAA;gBAC1B,SAAQ;YACV,CAAC;YACD,IAAI,KAAK,CAAC,IAAI,KAAK,UAAU,EAAE,CAAC;gBAC9B,IAAI,OAAO,GAAG,MAAM,QAAQ,CAAC,QAAQ,EAAE,MAAM,CAAC,CAAA;gBAC9C,OAAO,GAAG,OAAO,CAAC,UAAU,CAAC,mBAAmB,EAAE,GAAG,OAAO,GAAG,CAAC,CAAA;gBAChE,MAAM,SAAS,CAAC,QAAQ,EAAE,OAAO,EAAE,MAAM,CAAC,CAAA;YAC5C,CAAC;QACH,CAAC;IACH,CAAC;IAED,MAAM,UAAU,CAAC,OAAO,CAAC,CAAA;IAEzB,OAAO,OAAO,CAAA;AAChB,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@devcxl/opencode-cabbage",
-  "version": "0.3.1",
+  "version": "0.3.2",
   "description": "OpenCode 全流程开发插件 — 需求→设计→任务→编码→测试→审查→自动合并，支持自动编排与并行 Subagent",
   "repository": {
     "type": "git",

package/assets/skills/flow-requirements/references/interview-guide.md

@@ -1,35 +0,0 @@
-# 需求访谈指南
-
-## 必问维度
-
-### 用户与场景
-- 谁是最终用户？
-- 他们在什么场景下使用？
-- 解决了什么痛点？
-
-### 业务价值
-- 不做会怎样？
-- 如何衡量成功？（指标）
-- 优先级：P0（必须） / P1（重要） / P2（锦上添花）
-
-### 范围
-- **In Scope**: 精确描述包含的功能边界
-- **Out of Scope**: 明确排除什么，为什么
-
-### 验收标准
-- "怎样才算做完？" 追问到可验证的程度
-- 避免模糊描述（"用户体验好"→ 追问具体标准）
-
-### 技术约束
-- 语言/框架版本限制
-- 部署环境
-- 性能要求（QPS、P99 延迟）
-- 安全/合规要求
-
-## 追问技巧
-
-1. **"然后呢？"** — 当用户给出一个答案后追问，通常前 2 个回答只是表面
-2. **"如果不做这个会怎样？"** — 验证真实优先级
-3. **"谁来判断这个做对了？"** — 明确决策者/验收人
-4. **"和现有功能的关系？"** — 发现依赖/冲突
-5. **OOPS 追问**：当用户说"这个简单"或"这个以后再说"时，记录到 out-of-scope