Using Git Worktrees（隔离工作区管理）
开始新功能开发前，优先用平台原生隔离工具，没有的话再退回手动 git worktree
为需要隔离开发环境的编码代理提供了明确且有实际价值的工作流：先检测现有 worktree，再优先使用原生工具，最后回退到 git worktree。涵盖分支、子模块、目录选择、初始化和基线测试，目标受众和适用场景清楚。证据缺口是没有展示不同 harness 中的实际行为结果，也未明确处理非 Git 项目或复杂 monorepo 边界。
步骤顺序、子模块保护、原生工具优先、权限失败回退和基线测试要求有助于提高一致性与可复现性。但分支名生成未定义，项目初始化和测试命令仅以通用示例表示，npm install、poetry install 等可能不适合所有项目；git check-ignore 的组合命令也没有明确验证最终选定目录。没有该技能自身的行为测试或执行结果，故可靠性只能保守计分。
要求创建 worktree 前征得用户同意，检查项目本地目录是否被忽略，并避免在已有 worktree 中嵌套创建，这些措施降低了误改当前分支和污染仓库的风险。仍存在外部副作用：自动安装依赖、构建、运行测试，以及在目录未被忽略时添加 .gitignore 并提交，后者尤其缺少单独确认、提交内容说明和撤销路径。没有完整的清理、失败回滚、路径冲突或命令信任边界说明。
技能文本提供了具体命令、决策顺序、报告模板和常见错误，具备一定可追溯性。README 提到仓库存在评估和测试基础设施，但所给材料没有证明 using-git-worktrees 已被独立测试，也没有测试输出、覆盖范围、版本化行为规范或外部独立 corroboration。部分结论只能视为文档声明，事实与推断的分离证据不足。
内容按步骤组织，包含输入前置条件、状态报告、快速参考和故障提示，代理可较容易照做。缺少明确的工作流输入/输出契约、分支命名规则、依赖安装成本、测试命令发现策略、非交互环境处理、路径冲突处理和完成后的退出或清理说明；“npm test / cargo test / pytest / go test ./...”作为文字示例也可能被误执行。
仓库提供 MIT 许可证、版本号、修订信息、贡献流程、问题反馈和更新说明，存在基本维护信号。所选 SKILL.md 没有自身版本、变更记录、兼容性矩阵或责任人；README 表示更新依赖 coding agent，更新路径不够具体。发布者未通过 FollowSkills 企业注册表验证，因此不因身份获得额外治理分数。
- 在允许技能运行前，确认代理确实具有创建 worktree、修改 .gitignore、提交变更、安装依赖和运行构建/测试的权限。
- 不要直接执行文档中的通用测试占位符；应先识别项目实际的包管理器、测试命令和非交互要求。
- 要求用户明确确认自动修改并提交 .gitignore，并预先说明提交内容和撤销步骤。
- 补充确定性的分支命名、路径冲突、失败清理和 worktree 删除流程，避免残留状态。
它能做什么 & 适用场景
在动手写代码前确保工作发生在隔离环境里，但明确要求「先检测是否已经在隔离环境、再用平台原生工具、最后才退回手动 git worktree」这个优先级顺序，避免在已有原生隔离机制（比如某些 harness 自带的 worktree 管理）的情况下再手动嵌套创建一个，产生「幽灵状态」。也包含子模块场景的误判防护（`GIT_DIR != GIT_COMMON` 在子模块里也会成立，容易被误判为已在 worktree 中）。
Step 0：比较 GIT_DIR 和 GIT_COMMON 判断是否已在隔离工作区，并用 git rev-parse --show-superproject-working-tree 排除子模块的误判；已在隔离环境直接跳到项目初始化，不重复创建。Step 1：如果不在隔离环境，先看有没有平台原生的 worktree 工具（比如 EnterWorktree 之类），有就直接用；没有才退回手动 git worktree add，并且要先确认目录（.worktrees/ 优先于 worktrees/）在 .gitignore 里，避免误提交 worktree 内容。Step 2：自动识别项目类型（Node/Rust/Python/Go）跑对应的依赖安装命令。Step 3：跑一次测试确认起始基线是干净的，测试失败则报告并询问是否继续。
- 开始一个新功能开发，需要一个跟当前工作区隔离的环境，避免污染正在用的分支
- 已经在 harness 提供的原生隔离工作区里，跳过重复创建，直接进入依赖安装和测试基线检查
- 手动创建 worktree 前，先确认 `.worktrees/` 目录已经在 `.gitignore` 里，避免不小心把整个工作区内容提交进仓库
优缺点一览
- 「先检测已有隔离、再用原生工具、最后才手动 git worktree」的优先级顺序写得很清楚，避免在 harness 已提供隔离机制时画蛇添足
- 子模块误判的防护是个容易被忽略但确实存在的边界情况（GIT_DIR != GIT_COMMON 在子模块里同样成立），专门处理体现了对细节的把控
- 手动创建前强制检查 `.gitignore`，直接防住了「worktree 内容被误提交进仓库」这个常见事故
- 只在会自动读取和遵循 SKILL.md 指令的 harness 里可靠工作（Claude Code、Codex CLI 等）；纯聊天式界面里等于一份说明文档，需要人工照做。
- 如果所在环境的沙箱权限不允许创建 worktree（比如某些受限执行环境），流程会退回到直接在当前目录工作，隔离性保证随之消失
- 跟 finishing-a-development-branch 强绑定（谁创建的 worktree 谁负责清理），单独使用这个 skill 而不配合收尾流程，容易留下没人清理的孤立 worktree
如何安装
作为 obra/superpowers 插件的一部分安装，不能单独安装某一个 skill：
- Claude Code：官方市场
/plugin install superpowers@claude-plugins-official；或先注册 Superpowers 自建市场/plugin marketplace add obra/superpowers-marketplace，再/plugin install superpowers@superpowers-marketplace - 也支持 Antigravity、Codex App/CLI、Cursor、Factory Droid、GitHub Copilot CLI、Kimi Code、OpenCode、Pi 等 harness，具体命令见仓库 README
装好后这个 skill 会和其余 13 个 Superpowers skill 一起启用，由 using-superpowers 统一引导、按场景自动触发，无需单独调用。
如何使用
在开始需要隔离的功能开发前，或者 executing-plans/subagent-driven-development 流程要求隔离工作区时自动触发；也用于 finishing-a-development-branch 判断当前是否在 worktree 里、该展示哪种收尾菜单。
对比同类
跟直接手写 git worktree add 命令相比，这个 skill 补上了「检测是否已经隔离」「优先用原生工具」「校验 gitignore」这几步经常被跳过的安全检查；跟完全不隔离、直接在当前分支改动相比，隔离工作区能避免功能开发中途出问题时污染主分支状态。