superpowers-zh 1.3.0 → 1.6.0

package/skills/requesting-code-review/SKILL.md

@@ -1,11 +1,16 @@
 ---
 name: requesting-code-review
 description: 完成任务、实现重要功能或合并前使用，用于验证工作成果是否符合要求
+version: "1.0.0"
+license: MIT
+metadata:
+  hermes:
+    tags: [code-review]
 ---
 
 # 请求代码审查
 
-派遣 superpowers:code-reviewer 子代理来在问题扩散之前发现它们。审查者获得的是精心组织的评估上下文——绝不是你的会话历史。这样可以让审查者专注于工作成果而非你的思考过程，同时保留你自己的上下文以便继续工作。
+派遣代码审查子代理，在问题扩散之前发现它们。审查者获得的是精心组织的评估上下文——绝不是你的会话历史。这样可以让审查者专注于工作成果而非你的思考过程，同时保留你自己的上下文以便继续工作。
 
 **核心原则：** 早审查，勤审查。
 
@@ -29,16 +34,15 @@ BASE_SHA=$(git rev-parse HEAD~1)  # 或 origin/main
 HEAD_SHA=$(git rev-parse HEAD)
 ```
 
-**2. 派遣 code-reviewer 子代理：**
+**2. 派遣代码审查子代理：**
 
-使用 Task 工具，指定 superpowers:code-reviewer 类型，填写 `code-reviewer.md` 中的模板
+使用 Task 工具，指定 `general-purpose` 类型，填写 `code-reviewer.md` 中的模板
 
 **占位符说明：**
-- `{WHAT_WAS_IMPLEMENTED}` - 你刚完成的内容
+- `{DESCRIPTION}` - 你刚完成的内容简要说明
 - `{PLAN_OR_REQUIREMENTS}` - 预期功能
 - `{BASE_SHA}` - 起始提交
 - `{HEAD_SHA}` - 结束提交
-- `{DESCRIPTION}` - 简要说明
 
 **3. 处理反馈：**
 - Critical 问题立即修复
@@ -56,12 +60,11 @@ HEAD_SHA=$(git rev-parse HEAD)
 BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
 HEAD_SHA=$(git rev-parse HEAD)
 
-[派遣 superpowers:code-reviewer 子代理]
-  WHAT_WAS_IMPLEMENTED: 会话索引的验证和修复功能
+[派遣代码审查子代理]
+  DESCRIPTION: 添加了 verifyIndex() 和 repairIndex()，支持 4 种问题类型
   PLAN_OR_REQUIREMENTS: docs/superpowers/plans/deployment-plan.md 中的任务 2
   BASE_SHA: a7981ec
   HEAD_SHA: 3df7661
-  DESCRIPTION: 添加了 verifyIndex() 和 repairIndex()，支持 4 种问题类型
 
 [子代理返回]:
   优点：架构清晰，测试真实
@@ -82,8 +85,8 @@ HEAD_SHA=$(git rev-parse HEAD)
 - 修复后再进入下一个任务
 
 **执行计划：**
-- 每批（3 个任务）后审查
-- 获取反馈，修复，继续
+- 每个任务完成后或在自然 checkpoint 审查
+- 获取反馈，应用，继续
 
 **临时开发：**
 - 合并前审查

package/skills/requesting-code-review/code-reviewer.md

@@ -1,146 +1,166 @@
-# 代码审查代理
+# 代码审查员提示模板
 
-你正在审查代码变更的生产就绪程度。
+派遣代码审查员子代理时使用此模板。
 
-**你的任务：**
-1. 审查 {WHAT_WAS_IMPLEMENTED}
-2. 对照 {PLAN_OR_REQUIREMENTS} 进行比较
-3. 检查代码质量、架构、测试
-4. 按严重程度分类问题
-5. 评估生产就绪程度
+**用途：** 在工作成果扩散到更多工作之前，对照需求和代码质量标准做一次审查。
 
-## 实现内容
+```
+Task tool（general-purpose）:
+  description: "审查代码改动"
+  prompt: |
+    你是一名资深代码审查员，精通软件架构、设计模式与最佳实践。
+    你的工作是对照计划或需求审查已完成的工作，在问题扩散之前发现它们。
 
-{DESCRIPTION}
+    ## 实现内容
 
-## 需求/计划
+    {DESCRIPTION}
 
-{PLAN_REFERENCE}
+    ## 需求 / 计划
 
-## 待审查的 Git 范围
+    {PLAN_OR_REQUIREMENTS}
 
-**Base:** {BASE_SHA}
-**Head:** {HEAD_SHA}
+    ## 待审查的 Git 范围
 
-```bash
-git diff --stat {BASE_SHA}..{HEAD_SHA}
-git diff {BASE_SHA}..{HEAD_SHA}
-```
+    **Base：** {BASE_SHA}
+    **Head：** {HEAD_SHA}
 
-## 审查清单
-
-**代码质量：**
-- 关注点分离是否清晰？
-- 错误处理是否恰当？
-- 类型安全（如适用）？
-- 是否遵循 DRY 原则？
-- 边界情况是否已处理？
-
-**架构：**
-- 设计决策是否合理？
-- 是否考虑了可扩展性？
-- 性能影响如何？
-- 安全方面有无隐患？
-
-**测试：**
-- 测试是否真正测试了逻辑（而不只是 mock）？
-- 边界情况是否覆盖？
-- 需要的地方是否有集成测试？
-- 所有测试是否通过？
-
-**需求：**
-- 是否满足了计划中的所有需求？
-- 实现是否与规格一致？
-- 有无范围蔓延？
-- 破坏性变更是否已记录？
-
-**生产就绪：**
-- 迁移策略（如有 schema 变更）？
-- 是否考虑了向后兼容性？
-- 文档是否完备？
-- 有无明显 bug？
-
-## 输出格式
+    ```bash
+    git diff --stat {BASE_SHA}..{HEAD_SHA}
+    git diff {BASE_SHA}..{HEAD_SHA}
+    ```
 
-### 优点
-[做得好的地方？要具体。]
+    ## 检查内容
 
-### 问题
+    **计划对齐：**
+    - 实现是否匹配计划 / 需求？
+    - 偏差是有道理的改进，还是有问题的偏离？
+    - 计划中的所有功能都到位了吗？
 
-#### Critical（必须修复）
-[Bug、安全问题、数据丢失风险、功能异常]
+    **代码质量：**
+    - 关注点分离清晰吗？
+    - 错误处理到位吗？
+    - 该有类型安全的地方有吗？
+    - DRY 但没有过早抽象？
+    - 边界情况处理了吗？
 
-#### Important（应该修复）
-[架构问题、缺失功能、错误处理不足、测试缺口]
+    **架构：**
+    - 设计决策合理吗？
+    - 可扩展性和性能合理吗？
+    - 有没有安全隐患？
+    - 与周围代码集成是否干净？
 
-#### Minor（可以改进）
-[代码风格、优化机会、文档改进]
+    **测试：**
+    - 测试验证的是真实行为，不是 mock？
+    - 边界情况覆盖了吗？
+    - 该有集成测试的地方有吗？
+    - 所有测试都通过吗？
 
-**每个问题需包含：**
-- 文件:行号引用
-- 什么有问题
-- 为什么重要
-- 如何修复（如果不明显的话）
+    **生产就绪：**
+    - 如果改了 schema，有迁移策略吗？
+    - 考虑了向后兼容吗？
+    - 文档完整吗？
+    - 没有明显 bug？
 
-### 建议
-[对代码质量、架构或流程的改进建议]
+    ## 校准标准
 
-### 评估
+    按实际严重程度分类。不是所有问题都是 Critical。
+    在列出问题之前先认可做得好的地方——准确的肯定能让实现者
+    更愿意接受后续的反馈。
+
+    如果发现与计划有重大偏差，明确标出，让实现者确认这个偏差
+    是不是有意为之。如果问题出在计划本身而不是实现，也要说清楚。
+
+    ## 输出格式
+
+    ### 优点
+    [哪些地方做得好？具体一点。]
+
+    ### 问题
 
-**可以合并吗？** [是/否/修复后可以]
+    #### Critical（必须修复）
+    [bug、安全问题、数据丢失风险、功能损坏]
 
-**理由：** [1-2 句话的技术评估]
+    #### Important（应该修复）
+    [架构问题、缺失功能、错误处理不到位、测试漏洞]
 
-## 关键规则
+    #### Minor（锦上添花）
+    [代码风格、优化机会、文档润色]
+
+    每个问题包含：
+    - File:line 引用
+    - 哪里有问题
+    - 为什么重要
+    - 怎么修（如果不明显）
+
+    ### 建议
+    [关于代码质量、架构或流程的改进建议]
+
+    ### 评估
+
+    **可以合并吗？** [是 | 否 | 修完再合]
+
+    **理由：** [1-2 句技术评估]
+
+    ## 关键规则
+
+    **要做：**
+    - 按实际严重程度分类
+    - 具体（file:line，别含糊）
+    - 解释为什么这个问题重要
+    - 认可优点
+    - 给出明确判断
+
+    **不要：**
+    - 没检查就说"看起来 OK"
+    - 把小事标成 Critical
+    - 对没真看过的代码给反馈
+    - 含糊其辞（"改进错误处理"）
+    - 回避给出明确判断
+```
 
-**应该做的：**
-- 按实际严重程度分类（不是所有问题都是 Critical）
-- 要具体（文件:行号，不要含糊）
-- 解释问题为什么重要
-- 肯定做得好的地方
-- 给出明确结论
+**占位符说明：**
+- `{DESCRIPTION}` —— 已构建内容的简要说明
+- `{PLAN_OR_REQUIREMENTS}` —— 预期功能（计划文件路径、任务文本或需求）
+- `{BASE_SHA}` —— 起始 commit
+- `{HEAD_SHA}` —— 结束 commit
 
-**不该做的：**
-- 没仔细看就说"看起来不错"
-- 把小问题标为 Critical
-- 对没有审查的代码给反馈
-- 含糊其辞（"改善错误处理"）
-- 回避给出明确结论
+**审查员返回：** 优点、问题（Critical / Important / Minor）、建议、评估
 
 ## 输出示例
 
 ```
 ### 优点
-- 数据库 schema 清晰，迁移规范（db.ts:15-42）
-- 测试覆盖全面（18 个测试，覆盖所有边界情况）
-- 错误处理良好，有降级方案（summarizer.ts:85-92）
+- 数据库 schema 干净，迁移规范（db.ts:15-42）
+- 测试覆盖全面（18 个测试，所有边界情况都覆盖）
+- 错误处理有 fallback，做得很好（summarizer.ts:85-92）
 
 ### 问题
 
 #### Important
-1. **CLI 包装器缺少帮助文本**
-   - 文件：index-conversations:1-31
-   - 问题：没有 --help 选项，用户无法发现 --concurrency
-   - 修复：添加 --help 分支，附带使用示例
+1. **CLI wrapper 缺少帮助文本**
+   - File: index-conversations:1-31
+   - 问题：没有 --help flag，用户不会发现 --concurrency
+   - 修复：加 --help case 含使用示例
 
-2. **日期校验缺失**
-   - 文件：search.ts:25-27
-   - 问题：无效日期静默返回空结果
-   - 修复：校验 ISO 格式，抛出带示例的错误
+2. **缺少日期校验**
+   - File: search.ts:25-27
+   - 问题：无效日期会静默返回空结果
+   - 修复：校验 ISO 格式，抛错并附示例
 
 #### Minor
-1. **进度指示器**
-   - 文件：indexer.ts:130
-   - 问题：长时间操作没有"X / Y"计数器
-   - 影响：用户不知道还要等多久
+1. **进度指示**
+   - File: indexer.ts:130
+   - 问题：长操作没有 "X of Y" 计数
+   - 影响：用户不知道要等多久
 
 ### 建议
-- 添加进度报告以改善用户体验
-- 考虑用配置文件管理排除的项目（提高可移植性）
+- 加进度上报改善用户体验
+- 考虑用配置文件管理排除项目（提升可移植性）
 
 ### 评估
 
-**可以合并：修复后可以**
+**可以合并吗：修完再合**
 
-**理由：** 核心实现扎实，架构合理，测试充分。Important 问题（帮助文本、日期校验）容易修复，不影响核心功能。
+**理由：** 核心实现扎实，架构和测试都很好。Important 问题（帮助文本、
+日期校验）很容易修，且不影响核心功能。
 ```

package/skills/subagent-driven-development/SKILL.md

@@ -1,6 +1,11 @@
 ---
 name: subagent-driven-development
 description: 当在当前会话中执行包含独立任务的实现计划时使用
+version: "1.0.0"
+license: MIT
+metadata:
+  hermes:
+    tags: [agents, development]
 ---
 
 # 子智能体驱动开发

package/skills/systematic-debugging/SKILL.md

@@ -1,6 +1,11 @@
 ---
 name: systematic-debugging
 description: 遇到任何 bug、测试失败或异常行为时使用，在提出修复方案之前执行
+version: "1.0.0"
+license: MIT
+metadata:
+  hermes:
+    tags: [debugging]
 ---
 
 # 系统化调试

package/skills/test-driven-development/SKILL.md

@@ -1,6 +1,11 @@
 ---
 name: test-driven-development
 description: 在实现任何功能或修复 bug 时使用，在编写实现代码之前
+version: "1.0.0"
+license: MIT
+metadata:
+  hermes:
+    tags: [testing, development]
 ---
 
 # 测试驱动开发（TDD）

package/skills/using-git-worktrees/SKILL.md

@@ -1,104 +1,113 @@
 ---
 name: using-git-worktrees
-description: 当需要开始与当前工作区隔离的功能开发或执行实现计划之前使用——创建具有智能目录选择和安全验证的隔离 git 工作树
+description: 当需要开始与当前工作区隔离的功能开发，或在执行实现计划之前使用——通过原生工具或 git worktree 回退机制确保隔离工作区存在
+version: "1.0.0"
+license: MIT
+metadata:
+  hermes:
+    tags: [git, workflow]
 ---
 
 # 使用 Git 工作树
 
 ## 概述
 
-Git 工作树创建共享同一仓库的隔离工作区，允许同时在多个分支上工作而无需切换。
+确保工作发生在隔离的工作区中。优先使用你的平台的原生 worktree 工具。仅在没有原生工具可用时，再回退到手动 git worktree。
 
-**核心原则：** 系统化的目录选择 + 安全验证 = 可靠的隔离。
+**核心原则：** 先检测现有隔离。然后用原生工具。再回退到 git。绝不与 harness 对抗。
 
 **开始时宣布：** "我正在使用 using-git-worktrees 技能来建立一个隔离的工作区。"
 
-## 目录选择流程
+## 步骤 0：检测现有隔离
 
-按以下优先顺序执行：
-
-### 1. 检查现有目录
+**创建任何东西之前，先检查你是否已经在一个隔离的工作区里。**
 
 ```bash
-# 按优先顺序检查
-ls -d .worktrees 2>/dev/null     # 首选（隐藏目录）
-ls -d worktrees 2>/dev/null      # 备选
+GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P)
+GIT_COMMON=$(cd "$(git rev-parse --git-common-dir)" 2>/dev/null && pwd -P)
+BRANCH=$(git branch --show-current)
 ```
 
-**如果找到：** 使用该目录。如果两者都存在，`.worktrees` 优先。
-
-### 2. 检查 CLAUDE.md
+**Submodule 守卫：** 在 git submodule 内 `GIT_DIR != GIT_COMMON` 也为真。在判定"已经在 worktree 内"之前，先确认你不在 submodule 里：
 
 ```bash
-grep -i "worktree.*director" CLAUDE.md 2>/dev/null
+# 如果这条命令返回路径，说明你在 submodule 里，不是 worktree —— 按普通仓库处理
+git rev-parse --show-superproject-working-tree 2>/dev/null
 ```
 
-**如果指定了偏好：** 直接使用，无需询问。
+**如果 `GIT_DIR != GIT_COMMON`（且不是 submodule）：** 你已经在一个 linked worktree 内。跳到步骤 2（项目设置）。**不要**再创建一个 worktree。
 
-### 3. 询问用户
+按分支状态报告：
 
-如果没有现有目录且 CLAUDE.md 中无偏好设置：
+- 在某个分支上："已经在隔离工作区 `<path>`，分支 `<name>`。"
+- 分离 HEAD："已经在隔离工作区 `<path>`（分离 HEAD，由外部管理）。完成时需要创建分支。"
 
-```
-未找到工作树目录。我应该在哪里创建工作树？
+**如果 `GIT_DIR == GIT_COMMON`（或在 submodule 内）：** 你在一个普通的仓库检出里。
 
-1. .worktrees/（项目本地，隐藏目录）
-2. ~/.config/superpowers/worktrees/<project-name>/（全局位置）
+用户是否已经在你的 instructions 里表明过 worktree 偏好？如果没有，创建 worktree 之前先征求同意：
 
-你倾向哪个？
-```
+> "你希望我搭一个隔离的 worktree 吗？它能保护你当前分支不被改动。"
 
-## 安全验证
+如果用户已声明过偏好，直接遵循，不再询问。如果用户拒绝同意，原地工作并跳到步骤 2。
 
-### 项目本地目录（.worktrees 或 worktrees）
+## 步骤 1：创建隔离工作区
 
-**创建工作树前必须验证目录已被忽略：**
+**你有两种机制。按这个顺序尝试。**
 
-```bash
-# 检查目录是否被忽略（遵循本地、全局和系统 gitignore）
-git check-ignore -q .worktrees 2>/dev/null || git check-ignore -q worktrees 2>/dev/null
-```
+### 1a. 原生 Worktree 工具（首选）
+
+用户已经请求隔离工作区（步骤 0 已获同意）。你是否已经有创建 worktree 的方法？可能是名为 `EnterWorktree`、`WorktreeCreate` 的工具、`/worktree` 命令，或 `--worktree` 标志。如果有，用它，然后跳到步骤 2。
+
+原生工具自动处理目录放置、分支创建和清理。在你已经有原生工具的情况下使用 `git worktree add`，会创建你的 harness 看不到也无法管理的"幻影状态"。
 
-**如果未被忽略：**
+只有在没有原生 worktree 工具可用时，才进入步骤 1b。
 
-根据 Jesse 的规则"立即修复坏掉的东西"：
-1. 在 .gitignore 中添加相应条目
-2. 提交更改
-3. 继续创建工作树
+### 1b. Git Worktree 回退
 
-**为什么这很关键：** 防止意外将工作树内容提交到仓库。
+**只在步骤 1a 不适用时使用** —— 你没有可用的原生 worktree 工具。手动用 git 创建 worktree。
 
-### 全局目录（~/.config/superpowers/worktrees）
+#### 目录选择
 
-无需 .gitignore 验证——完全在项目之外。
+按以下优先级。明确的用户偏好始终优先于观察到的文件系统状态。
 
-## 创建步骤
+1. **检查你的 instructions 里是否声明过 worktree 目录偏好。** 如果用户已指定，不再询问直接用。
 
-### 1. 检测项目名称
+2. **检查是否存在项目本地的 worktree 目录：**
+
+   ```bash
+   ls -d .worktrees 2>/dev/null     # 首选（隐藏目录）
+   ls -d worktrees 2>/dev/null      # 备选
+   ```
+
+   找到就用。如果两者都存在，`.worktrees` 优先。
+
+3. **如果没有其他可参考的信息**，默认用项目根目录下的 `.worktrees/`。
+
+#### 安全验证（仅项目本地目录）
+
+**创建 worktree 前必须验证目录已被忽略：**
 
 ```bash
-project=$(basename "$(git rev-parse --show-toplevel)")
+git check-ignore -q .worktrees 2>/dev/null || git check-ignore -q worktrees 2>/dev/null
 ```
 
-### 2. 创建工作树
+**如果未被忽略：** 添加到 .gitignore，提交该改动，然后继续。
+
+**为什么关键：** 防止 worktree 内容被意外提交到仓库。
+
+#### 创建工作树
 
 ```bash
-# 确定完整路径
-case $LOCATION in
-  .worktrees|worktrees)
-    path="$LOCATION/$BRANCH_NAME"
-    ;;
-  ~/.config/superpowers/worktrees/*)
-    path="~/.config/superpowers/worktrees/$project/$BRANCH_NAME"
-    ;;
-esac
-
-# 创建带有新分支的工作树
+# 根据选定位置确定路径
+path="$LOCATION/$BRANCH_NAME"
+
 git worktree add "$path" -b "$BRANCH_NAME"
 cd "$path"
 ```
 
-### 3. 运行项目设置
+**沙盒回退：** 如果 `git worktree add` 因权限错误（沙盒拒绝）失败，告诉用户沙盒阻止了 worktree 创建，你将在当前目录原地工作。然后原地运行 setup 和基线测试。
+
+## 步骤 2：项目设置
 
 自动检测并运行相应的设置命令：
 
@@ -117,23 +126,20 @@ if [ -f pyproject.toml ]; then poetry install; fi
 if [ -f go.mod ]; then go mod download; fi
 ```
 
-### 4. 验证基线正常
+## 步骤 3：验证基线干净
 
-运行测试确保工作树初始状态干净：
+运行测试确保工作区初始状态干净：
 
 ```bash
-# 示例 - 使用项目对应的命令
-npm test
-cargo test
-pytest
-go test ./...
+# 使用项目对应的命令
+npm test / cargo test / pytest / go test ./...
 ```
 
-**如果测试失败：** 报告失败情况，询问是否继续或排查。
+**如果测试失败：** 报告失败，询问是继续还是排查。
 
 **如果测试通过：** 报告就绪。
 
-### 5. 报告位置
+### 报告
 
 ```
 工作树已就绪：<full-path>
@@ -145,74 +151,75 @@ go test ./...
 
 | 情况 | 操作 |
 |------|------|
-| `.worktrees/` 存在 | 使用它（验证已忽略） |
-| `worktrees/` 存在 | 使用它（验证已忽略） |
-| 两者都存在 | 使用 `.worktrees/` |
-| 都不存在 | 检查 CLAUDE.md → 询问用户 |
+| 已在 linked worktree 内 | 跳过创建（步骤 0） |
+| 在 submodule 内 | 按普通仓库处理（步骤 0 守卫） |
+| 有原生 worktree 工具 | 用它（步骤 1a） |
+| 没有原生工具 | git worktree 回退（步骤 1b） |
+| `.worktrees/` 存在 | 用它（验证已忽略） |
+| `worktrees/` 存在 | 用它（验证已忽略） |
+| 两者都存在 | 用 `.worktrees/` |
+| 都不存在 | 检查 instructions 文件，再默认 `.worktrees/` |
 | 目录未被忽略 | 添加到 .gitignore + 提交 |
+| 创建时权限错误 | 沙盒回退，原地工作 |
 | 基线测试失败 | 报告失败 + 询问 |
 | 无 package.json/Cargo.toml | 跳过依赖安装 |
 
 ## 常见错误
 
+### 与 harness 对抗
+
+- **问题：** 平台已经提供隔离的情况下还在用 `git worktree add`
+- **修复：** 步骤 0 检测现有隔离。步骤 1a 让位给原生工具。
+
+### 跳过检测
+
+- **问题：** 在已有的 worktree 内嵌套创建另一个 worktree
+- **修复：** 创建任何东西之前都先跑步骤 0
+
 ### 跳过忽略验证
 
-- **问题：** 工作树内容被跟踪，污染 git status
-- **修复：** 创建项目本地工作树前始终使用 `git check-ignore`
+- **问题：** worktree 内容被跟踪，污染 git status
+- **修复：** 创建项目本地 worktree 前始终使用 `git check-ignore`
 
 ### 假设目录位置
 
-- **问题：** 造成不一致，违反项目约定
-- **修复：** 遵循优先级：现有目录 > CLAUDE.md > 询问
+- **问题：** 造成不一致、违反项目约定
+- **修复：** 遵循优先级：明确 instructions > 现有项目本地目录 > 默认
 
 ### 带着失败的测试继续
 
 - **问题：** 无法区分新 bug 和已有问题
 - **修复：** 报告失败，获得明确许可后再继续
 
-### 硬编码设置命令
-
-- **问题：** 在使用不同工具的项目上会出错
-- **修复：** 从项目文件自动检测（package.json 等）
-
-## 示例工作流
-
-```
-你：我正在使用 using-git-worktrees 技能来建立一个隔离的工作区。
-
-[检查 .worktrees/ - 存在]
-[验证已忽略 - git check-ignore 确认 .worktrees/ 已被忽略]
-[创建工作树：git worktree add .worktrees/auth -b feature/auth]
-[运行 npm install]
-[运行 npm test - 47 个通过]
-
-工作树已就绪：/Users/jesse/myproject/.worktrees/auth
-测试通过（47 个测试，0 个失败）
-准备实现 auth 功能
-```
-
 ## 红线
 
 **绝不：**
-- 创建项目本地工作树时不验证是否已忽略
+
+- 步骤 0 已检测到现有隔离时还创建 worktree
+- 在已有原生 worktree 工具（如 `EnterWorktree`）的情况下还用 `git worktree add`。这是 #1 错误——有就用。
+- 跳过步骤 1a 直接跳到步骤 1b 的 git 命令
+- 不验证已忽略就创建项目本地 worktree
 - 跳过基线测试验证
 - 不询问就带着失败的测试继续
-- 在有歧义时假设目录位置
-- 跳过 CLAUDE.md 检查
 
 **始终：**
-- 遵循目录优先级：现有目录 > CLAUDE.md > 询问
-- 对项目本地目录验证是否已忽略
+
+- 先跑步骤 0 检测
+- 优先原生工具，其次 git 回退
+- 遵循目录优先级：明确 instructions > 现有项目本地目录 > 默认
+- 项目本地目录验证已忽略
 - 自动检测并运行项目设置
 - 验证测试基线干净
 
 ## 集成
 
 **被以下技能调用：**
+
 - **brainstorming**（阶段 4）- 设计通过且需要实现时必需
 - **subagent-driven-development** - 执行任何任务前必需
 - **executing-plans** - 执行任何任务前必需
 - 任何需要隔离工作区的技能
 
 **配合使用：**
+
 - **finishing-a-development-branch** - 工作完成后清理时必需