Git工作树使用技能：为每个功能任务一键开出独立、干净的开发空间
- 一句话定位：这是一个把「git worktree 隔离工作区」流程标准化的技能，自动完成目录选择、
.gitignore安全校验、依赖安装与基线测试，让你在不动当前工作区的前提下开工新功能。 - 核心原则：目录优先级（已有目录 >
CLAUDE.md约定 > 询问用户）+ 安全验证（项目本地目录必须先进.gitignore）= 可靠隔离。 - 能省掉什么：不用手动切分支、不用 stash 未完成的改动、不用每次重装依赖、不用猜「这个测试失败是不是我引入的」。
- 适合谁用：需要并行处理多个分支的开发者、使用 AI 编码助手执行实现计划的团队、希望在动代码前先拿到「干净基线」的工程师。
- 关键约束：项目本地工作树若不在
.gitignore中，技能会先补上并提交；基线测试失败时会先报告再询问是否继续。
该技能叫什么？如何一键安装 AI 技能提升开发效率？
这个技能的中文名是 Git工作树使用技能Skill，英文名 using-git-worktrees，技能 ID 为 11886。
它解决的是一个非常具体的痛点：当你正准备开始一个新功能或执行一份实现计划时，当前工作区往往还留着半成品改动。传统做法是 git stash 或直接切分支，前者容易忘、后者容易把未完成代码带进新分支。Git 本身提供了 git worktree 来创建共享同一仓库的隔离目录，但手工操作细节多：目录放哪、要不要写进 .gitignore、依赖要不要重装、测试基线干不干净——每一步都可能出错。这个技能就是把这些步骤固化成一套可复用的流程。
一键安装的思路与步骤：
- 确认前提：本机已安装 Git，且当前处于一个 Git 仓库中；同时你的 AI 编码助手 / 技能运行环境支持加载技能（具体入口与命名以官方说明为准）。
- 安装技能：通过你所使用平台的技能市场或技能管理入口，按技能 ID 11886 或英文名 using-git-worktrees 查找并安装；也可以按平台支持的方式导入技能定义文件（以官方说明为准）。
- 验证是否生效：在会话中触发一次「准备开始新功能」的请求，观察技能是否按约定先输出声明——技能要求在使用时明确宣布「我正在使用使用-git-worktrees技能来设置一个隔离的工作空间」。若能看到这句声明，并随后执行目录检查（如
ls -d .worktrees），说明已生效。 - 首次使用建议：先在一个小仓库里跑一遍，确认目录位置与
.gitignore处理符合你的团队习惯，再用于正式项目。
需要说明的是，该技能本身不依赖额外付费服务，其能力完全建立在 Git 原生 git worktree 之上；关于安装渠道、是否需要账号等，请以官方说明为准。
该技能的主要功能和特点
- 智能目录选择（三级优先级）：先检查是否已存在
.worktrees（首选、隐藏），其次worktrees；若两者都存在，.worktrees胜出。接着读取CLAUDE.md中关于工作树目录的偏好设置，一旦指定就直接采用、不再询问。两者都没有时，才向用户给出两个选项：项目内.worktrees/或全局位置~/.config/superpowers/worktrees/<项目名称>/。 - 强制安全校验：对项目本地目录，创建前必须验证该目录已写入
.gitignore（通过grep -q "^\.worktrees/$" .gitignore之类的检查）；若缺失，立即补上并提交。这一步直接避免工作树内容被误提交、污染仓库状态——这是手工操作最容易翻车的地方。 - 自动检测并运行项目设置：根据仓库特征文件自动判断技术栈并安装依赖，支持 Node.js（
package.json→npm install）、Rust（Cargo.toml→cargo build）、Python（requirements.txt→pip install -r、pyproject.toml→poetry install）、Go（go.mod→go mod download）。没有匹配文件就跳过，不硬编码命令。 - 干净基线验证：创建工作树后运行项目测试（如
npm test、cargo test、pytest、go test ./...），确认从零错误状态起步。这样后续出现的失败一定是新代码导致的，而不是环境遗留问题。 - 规范化的完成播报：输出完整路径、测试通过数量与失败数、以及即将实现的功能名，让「现在该在哪个目录干活」这件事一目了然。
- 与工作流上下游打通：可由头脑风暴/设计确认环节调用，与「收尾开发分支」技能配对做清理，并与「执行计划」「子代理驱动开发」类技能配合，把实际编码放进隔离工作树中进行。
和普通做法的差别在哪：普通做法是「记得就 stash，忘了就乱」；这个技能把「目录一致性、忽略规则、依赖、基线」四件事变成有顺序、有校验、有失败处理的固定流程，并且把「不确定就问」写进了规则里，而不是靠猜。
如何使用该技能？
以下按技能定义的实际流程给出分步指南。
步骤 1：触发并声明 在开始新功能或执行实现计划前发起请求，例如：「我要开始做 auth 功能，先给我一个隔离工作区。」技能会先声明正在使用该技能，然后进入目录检查。
步骤 2：目录决策（自动或一次询问） 技能依次执行：
ls -d .worktrees 2>/dev/null # 首选（隐藏）
ls -d worktrees 2>/dev/null # 替代
grep -i "worktree.*director" CLAUDE.md 2>/dev/null
若都没有结果，你会收到类似提问：「未找到工作树目录。我应该在何处创建工作树？1. .worktrees/（项目本地，隐藏）2. ~/.config/superpowers/worktrees/<项目名称>/（全局位置）」。选一个即可，后续同项目会沿用。
步骤 3：安全验证
若选择项目本地目录，技能会检查 .gitignore 是否包含对应条目；不包含则自动添加并提交。若选择全局目录，则跳过该校验——因为它完全位于项目之外。
步骤 4：创建工作树
project=$(basename "$(git rev-parse --show-toplevel)")
git worktree add "$path" -b "$BRANCH_NAME"
cd "$path"
实际效果等价于：git worktree add .worktrees/auth -b feature/auth。
步骤 5：安装依赖 技能按特征文件自动执行对应命令，无需你指定包管理器。
步骤 6：跑基线测试 运行项目测试命令。若失败，技能会报告失败并询问「是否继续或先排查」，不会擅自推进；若通过，则播报结果。
步骤 7：读取完成报告 输出形如：
工作树准备就绪于 /Users/xxx/myproject/.worktrees/auth
测试通过 (47 测试，0 失败)
准备实现 auth 功能
此后所有编码都在该目录进行，原工作区的未完成改动保持原样、不受影响。
输入输出示例（对话视角）
- 输入：「按计划实现登录模块，先在隔离环境里开工。」
- 输出：目录检查结果 →
.gitignore校验通过 → 创建工作树feature/login→ 安装依赖 → 测试 47 通过 0 失败 → 报告路径与就绪状态。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| Git工作树使用技能（using-git-worktrees） | 隔离工作区的流程化技能 | 目录优先级选择、.gitignore 安全校验、依赖自动安装、基线测试、完成播报 |
需支持技能加载的运行环境；依赖 Git | 并行开发多分支、AI 助手执行实现计划 | 优势：安全校验与基线验证到位，减少污染与误判；不足：依赖运行环境支持，纯手工场景需自行照流程执行 |
手动 git worktree 命令 |
Git 原生能力 | 创建/列出/删除工作树 | 仅需 Git，零安装 | 熟悉 Git 的开发者临时隔离 | 优势：无额外依赖、最灵活；不足：目录规范、忽略规则、依赖与测试全靠自觉，易漏步骤 |
git stash + 切分支 |
传统上下文切换 | 暂存改动后切分支 | 极低 | 改动少、切换频繁的短任务 | 优势：上手最快；不足：不提供真正隔离，stash 堆积易丢失上下文，无依赖与基线保障 |
| 完整仓库再克隆一份 | 物理隔离的笨办法 | 独立目录、独立仓库 | 需重复克隆与配置 | 长期并行的大功能 | 优势：隔离最彻底；不足：磁盘与同步成本高，与主仓库共享历史不便，无法共享同一仓库对象 |
从对比可见，该技能的差异化不在于「能不能创建隔离目录」，而在于把安全校验和基线验证做成不可跳过的步骤，并把目录选择变成有优先级、可询问的决策，而不是靠个人记忆。
该技能的典型应用场景与实际体验情况
场景一：多分支并行开发的后端工程师 痛点：手上功能 A 改到一半，产品插队要求先修 B 的线上问题，切分支容易把 A 的半成品带上线。使用方式：让技能为 B 创建独立工作树，原目录原封不动。实际体验：上手几乎零学习成本，技能会先声明再执行，路径与测试结果都会明确播报；注意点是第一次使用需要回答一次目录选择问题。
场景二：用 AI 助手执行实现计划的团队 痛点：AI 直接在主干工作区改代码，一旦出错难以回滚，且新老错误混在一起。使用方式：在计划执行前调用本技能，让后续「执行计划」「子代理驱动开发」类工作发生在隔离工作树内。实际体验：效果取决于基线测试是否可靠——技能会先跑一遍测试，这让「AI 引入的错误」与「项目原有问题」能被清楚区分。
场景三：接手陌生仓库的新成员
痛点：不清楚项目依赖怎么装、测试怎么跑。使用方式：交给技能自动检测 package.json、Cargo.toml、requirements.txt、pyproject.toml、go.mod 并执行对应命令。实际体验：省去查文档的时间；注意若项目使用非常规构建方式（无上述特征文件），技能会跳过安装，需要你手动处理。
场景四：团队规范统一
痛点：每个人工作树目录五花八门，有人放在仓库里还忘了加忽略规则，导致提交里混入工作树文件。使用方式：在 CLAUDE.md 中写明目录偏好，技能读到后不再询问并直接采用，同时对项目本地目录强制校验 .gitignore。实际体验：这是该技能长期价值最大的一环；注意 CLAUDE.md 中的关键词需能被 worktree.*director 这类匹配命中，写法上要贴近该模式。
该技能能为用户带来的价值
- 效率提升：把「查目录、改忽略规则、装依赖、跑测试」四段零散操作压缩成一次调用，切换功能上下文的准备时间从数分钟级降到接近「说一句话」。
- 风险下降：
.gitignore强制校验直接消除「工作树内容被误提交」这类污染仓库的事故；基线测试验证让你永远知道失败是不是自己造成的。 - 门槛降低：不熟悉
git worktree的开发者也能获得正确用法，命令由技能按规范生成，避免手写路径出错。 - 协作一致性：目录优先级与
CLAUDE.md约定让团队内的工作区布局统一，减少「你的工作树在哪」这类沟通成本。 - 长期价值：与「收尾开发分支」「执行计划」等技能配对后，形成「开隔离环境 → 实现 → 清理」的闭环，让并行开发成为默认习惯而非临时技巧。
常见问题 FAQ
Q1：怎么安装这个技能？ 在支持技能的平台中，按技能 ID 11886 或英文名 using-git-worktrees 查找并安装，或按平台方式导入技能定义；安装入口与权限要求以官方说明为准。安装后建议先在一个小仓库验证：触发新功能请求时，是否出现「我正在使用使用-git-worktrees技能来设置一个隔离的工作空间」的声明。
Q2：收费吗？
技能本身基于 Git 原生 git worktree 能力编排流程，不涉及额外付费服务；是否存在平台侧费用，以官方说明为准。
Q3：适合谁用？
适合需要并行处理多个分支的开发者、使用 AI 编码助手执行实现计划的团队，以及希望统一工作区规范的工程团队。若你只是偶尔切一次分支、改动很少，直接用 git stash 也许更轻。
Q4：和直接手动 git worktree 有什么区别？
手动方式只负责创建目录；本技能额外覆盖三件事：按优先级决定目录位置（必要时询问你）、对项目本地目录强制校验并补全 .gitignore、自动安装依赖并跑基线测试。它的价值在流程约束，而非新增 Git 功能。
Q5：测试失败了会怎样？
技能不会擅自继续。按技能定义，若基线测试失败，会报告失败并询问是继续还是先排查；这样能避免把「原本就存在的问题」误判成新代码引入的错误。另外，如果仓库里没有 package.json、Cargo.toml 等特征文件，依赖安装会被跳过，这属于正常行为。