using-git-worktrees（使用Git工作树）Skill 是什么？如何下载安装使用？

使用Git工作树Skill：为每个功能分支建立安全、可验证的隔离开发空间

核心结论速览

它解决什么问题：当你要开发一个与当前工作空间互不干扰的新功能时，直接在当前目录切换分支会打乱未提交的改动、污染构建产物。该技能通过创建独立的 Git 工作树（worktree），让多个分支在同一仓库下“并行开工”。
它的核心方法论：把“目录选择”和“安全验证”做成标准化流程——先按优先级选目录（已存在 > CLAUDE.md 约定 > 询问用户），再强制校验 .gitignore，最后跑一遍基线测试确认环境干净。
它的差异点：不只是一条 git worktree add 命令，而是把“目录约定 + 忽略规则 + 依赖安装 + 基线测试 + 结果报告”打包成一条可复用的操作链，减少人为遗漏。
它适合谁：需要并行处理多个分支的开发者、使用 AI 编程助手执行实施计划的用户、以及希望团队统一工作树规范的工程团队。
安装与使用成本：以技能形式接入你常用的 AI 编程助手即可，具体安装入口与命令请以官方说明为准；日常使用只需一句自然语言指令触发。

一、该技能叫什么？如何下载安装 AI 技能提升开发效率？

技能基本信息

项目	内容
技能中文名	使用Git工作树
技能英文名	using-git-worktrees
技能ID	13642
一句话定位	创建与当前工作空间隔离的 Git 工作树，具备智能目录选择与安全验证能力
触发时机	开始需要与当前工作空间隔离的功能开发时，或在执行实施计划之前

它到底解决什么问题

传统做法里，你想开发一个新功能，通常要在当前目录执行分支切换。这会带来三个高频麻烦：

未提交改动无处安放：切分支前得先 stash 或临时提交，切回来再恢复，容易出错。
构建产物互相污染：同一份 node_modules、target、dist 在不同分支间反复重建，既慢又容易出诡异的编译错误。
AI 助手“跑偏”：当你让 AI 助手执行一份实施计划时，它在你的主工作目录里改文件，一旦中途发现方向不对，回滚成本很高。

Git 工作树天然能解决前两个问题，但它是一条需要“手工输入路径、记得加 .gitignore、记得装依赖、记得验证基线”的命令。该技能的价值，就是把这套容易漏步骤的操作固化成流程：系统化目录选择 + 安全验证 = 可靠隔离。

“一键安装”AI 技能提升开发效率的思路

安装 AI 技能的本质，是把一段结构化的操作规范“挂载”到你的 AI 编程助手上，让它在你下达指令时能够自动读懂并执行这套流程。通用步骤大致如下（具体命令、下载地址、客户端入口请以官方说明为准）：

第一步：确认安装前提

你的 AI 编程助手已支持“技能（Skill）”机制，并能读取本地技能目录或技能市场中的条目。
本地已安装 Git，且当前目录是一个可正常执行 git rev-parse --show-toplevel 的 Git 仓库。
若你希望使用全局工作树目录，需确认 ~/.config/superpowers/worktrees 这类路径在你的系统中可写（路径以技能实际输出为准）。

第二步：添加技能

在助手的技能管理界面中搜索技能名 using-git-worktrees（或技能ID 13642）并添加；也可按官方文档给出的方式将技能放入本地技能目录。
具体安装命令、是否需要登录或授权，请以官方说明为准。

第三步：验证是否生效

安装后不要急着用，先做一次“生效性验证”：

在对话中提出类似请求：“我要开发一个独立的新功能，请帮我创建隔离的工作空间。”
观察助手是否主动声明：“我正在使用 using-git-worktrees 技能来设置一个隔离的工作空间。” 这句开场白是该技能的标准触发信号。
观察它是否按顺序执行了：检查 .worktrees / worktrees 目录 → 检查 CLAUDE.md 约定 → 校验 .gitignore → 创建并进入工作树 → 运行依赖安装 → 运行基线测试 → 报告路径与测试结果。
最后确认工作树目录确实被创建、且未被 Git 跟踪（git status 中不出现工作树内容）。

只要这条链路能完整跑通，说明技能已正确挂载。

二、该技能的主要功能和特点

1. 智能目录选择，遵循固定优先级 技能不会随意挑一个路径，而是严格按“已存在目录优先 → 读取项目约定 → 询问用户”的顺序决策：先看 .worktrees（首选，隐藏目录），再看 worktrees（备选），两者都存在时 .worktrees 胜出；再读 CLAUDE.md 中是否有 worktree 相关目录偏好；都没有才向用户提问，并给出“项目本地隐藏目录”与“全局配置目录”两个选项。这条设计避免了“每次创建位置都不一样”的混乱。

2. 强制安全验证，杜绝污染仓库 对项目本地目录，技能在创建工作树之前必须先验证 .gitignore。若目录模式不在忽略规则中，它会遵循“立即修复损坏的事物”的原则：先把对应规则写入 .gitignore 并提交，再继续创建。原因是显而易见的——如果工作树内容被 Git 跟踪，你的 git status 会被几十上百个无关文件淹没。对全局目录则无需此验证，因为它完全在项目之外。

3. 自动检测项目类型并安装依赖 创建工作树后，技能会按项目文件自动判断并执行设置：存在 package.json 跑 npm install，存在 Cargo.toml 跑 cargo build，存在 requirements.txt 跑 pip install -r，存在 pyproject.toml 跑 poetry install，存在 go.mod 跑 go mod download；没有任何匹配文件则跳过。相比硬编码某一条安装命令，这种自动检测能适配多技术栈项目。

4. 基线测试验证，保证“干净起点” 技能会在新工作树中运行项目测试（如 npm test、cargo test、pytest、go test ./...）。测试通过则报告就绪；测试失败则停下报告并询问是否继续或调查，绝不在失败状态下默默推进。这一步是判断“后续新错误是不是我引入的”的关键分水岭。

5. 结构化收尾报告 完成后输出标准格式：工作树完整路径、测试通过数量与失败数、准备实现的功能名称。让“我到底在哪个目录、环境是否健康”一目了然。

6. 与其它技能联动 该技能被 brainstorming（第 4 阶段，设计获批需要实施时）等技能调用；与 finishing-a-development-branch 配对用于工作完成后的清理；创建出的工作树可作为 executing-plans、subagent-driven-development 的执行场地。

和普通做法的差别在哪：普通做法是“我记得要跑一条命令”；这个技能是“一套带检查点、带失败处理、带报告的操作协议”。

三、如何使用该技能？

下面按真实使用顺序给出操作步骤。

步骤 1：用自然语言提出隔离需求

你可以直接说：“我要开发 auth 功能，请给我一个隔离的工作空间，不要影响当前目录。”助手会先宣布使用该技能。

步骤 2：技能自动执行目录优先级检查

它内部会依次执行：

ls -d .worktrees 2>/dev/null   # 首选（隐藏）
ls -d worktrees 2>/dev/null    # 备选
grep -i "worktree.*director" CLAUDE.md 2>/dev/null

若两者都没有、CLAUDE.md 也无约定，你会看到提问：

未找到工作树目录。我应该在哪里创建工作树？
1. .worktrees/（项目本地，隐藏）
2. ~/.config/superpowers/worktrees/<项目名称>/（全局位置）
您更喜欢哪个？

此时直接回答 1 或 2 即可。

步骤 3：确认安全验证结果

若选项目本地目录，技能会检查忽略规则：

grep -q "^\.worktrees/$" .gitignore || grep -q "^worktrees/$" .gitignore

若未命中，它会自动补上规则并提交，然后继续。你无需手动干预，但建议在提交信息里留意这条“为工作树添加忽略规则”的变更。

步骤 4：创建工作树并进入

技能会先取项目名，再按目录类型拼出路径并创建分支：

project=$(basename "$(git rev-parse --show-toplevel)")
git worktree add .worktrees/auth -b feature/auth
cd .worktrees/auth

步骤 5：等待依赖安装与基线测试

技能自动执行项目设置（如 npm install）和测试（如 npm test）。这一步会花些时间，属于正常现象。

步骤 6：读取结果报告并开始干活

成功时的输出形如：

工作树准备就绪于 /Users/jesse/myproject/.worktrees/auth
测试通过（47个测试，0个失败）
准备实现auth功能

看到这份报告，你就可以在该目录内放心让助手执行实施计划了。若报告显示测试失败，请明确回复“先调查”或“继续”，技能会尊重你的决定而不是自行猜测。

输入输出小示例

输入：“帮我为 feature/payment 建一个隔离工作树，按项目已有约定选目录。”
预期输出：一句技能声明 + 目录决策说明 + 创建的完整路径 + 依赖安装摘要 + 测试通过数与失败数。

四、同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
使用Git工作树（using-git-worktrees）	AI 技能，把工作树创建流程标准化	目录优先级决策、`.gitignore` 强制校验、依赖自动安装、基线测试验证、结构化报告	需接入支持技能机制的 AI 助手；日常仅需自然语言指令，门槛低	多分支并行开发、AI 执行实施计划前的环境准备、团队统一工作树规范	优势：流程完整、安全兜底、可复用；不足：依赖助手生态，路径与客户端细节以官方说明为准
手动执行 `git worktree` 命令	Git 原生能力，手工操作	创建/列出/删除工作树	需熟记命令与路径参数，容易漏掉忽略规则与依赖安装	熟悉 Git 的高级用户、临时性隔离	优势：零依赖、最灵活；不足：全靠人记，`.gitignore` 漏配会污染仓库，基线测试常被跳过
分支切换 + `git stash`	在同一目录内切换上下文	暂存改动、切分支、恢复改动	门槛低但操作繁琐	改动量小、快速切回的场景	优势：无需新目录；不足：构建产物共享导致反复重建，恢复冲突时风险高，无法真正“并行”
多次 `git clone` 复制仓库	物理隔离的多份副本	各自独立的分支与工作区	需重复克隆与同步，磁盘占用高	需要完全独立环境的实验性开发	优势：隔离最彻底；不足：仓库历史重复占用空间，远端同步成本高，不适合频繁创建

五、该技能的典型应用场景与实际体验情况

场景一：后端工程师并行推进两个功能 角色：负责订单系统的后端工程师。痛点：手上 feature/refund 改到一半，产品突然要求先上 feature/coupon，切分支就得 stash，来回几次后连自己改了什么都要翻记录。使用方式：让助手为 feature/coupon 建一个工作树，原目录原封不动。实际体验：上手几乎零学习成本，唯一要注意的是第一次会多问一句目录选择；依赖安装阶段耗时取决于项目体积，建议在等待时先去处理别的沟通事项。

场景二：AI 助手执行实施计划前的环境准备 角色：使用 AI 编程助手执行多步骤计划的开发者。痛点：计划执行中途方向有误时，在主目录回滚成本高。使用方式：先触发该技能创建工作树，再让执行类技能在其中作业。实际体验：效果最明显的是“失败可抛弃”——整个工作树目录删掉即可，主工作区毫无痕迹。注意点是必须让它完成基线测试，否则后续分不清报错是新引入的还是原本就存在的。

场景三：紧急修 bug 不打断当前工作 角色：正在做重构的开发者，线上突然报错需要热修。痛点：重构代码大量未提交，切分支风险极高。使用方式：为 hotfix/xxx 创建工作树，在新目录里修复、测试、提交。实际体验：隔离感强，两边互不干扰；提醒一点，热修完成后记得按配对技能 finishing-a-development-branch 做清理，避免工作树目录长期堆积。

场景四：团队统一工作树规范 角色：技术负责人。痛点：每个人建工作树的位置五花八门，有人在项目根目录，有人放桌面。使用方式：在 CLAUDE.md 中写明 worktree 目录偏好，技能检测到后直接采用、不再询问。实际体验：这是最能体现“团队级价值”的用法，一次约定、长期生效。注意事项是约定文案要能被 worktree 与目录关键词匹配到，否则技能仍会走询问分支。

整体来看，该技能的上手难度低（一个自然语言请求即可），效果稳定（因为关键步骤都被设成了强制检查点），最需要注意的是两点：不要绕过 .gitignore 校验，以及基线测试失败时认真对待提示。

六、该技能能为用户带来的价值

1. 把“易漏的手工流程”变成“不可跳过的检查点” 目录选择、忽略规则、依赖安装、基线测试这四件事，手工做时漏掉任何一件都可能埋雷。技能把它们变成顺序执行的强制环节，直接消灭了“工作树内容被提交进仓库”“依赖没装导致满屏报错”这两类高频事故。

2. 显著缩短上下文切换的恢复时间 不需要 stash、不需要等依赖重装、不需要回想“我改到哪了”。原来的工作目录保持原样，新功能在新目录里从干净基线起步。对于一天要切换两三次任务的开发者，这种“切回来即继续”的体验收益是持续的。

3. 降低 AI 协作的风险成本 当 AI 助手在隔离工作树中执行计划时，任何偏差都可以通过丢弃整个目录来止损，主分支与主工作区不受影响。这让“让 AI 大胆去试”变得可行。

4. 统一团队约定，减少沟通摩擦 通过 CLAUDE.md 固化工作树位置，新成员无需口头传授“我们这边习惯放哪”，技能会自己按约定执行。

5. 长期价值：可预测的工程习惯 “干净基线 + 隔离空间 + 明确收尾”这三件事一旦成为习惯，排查问题时的因果关系会清晰得多——新出现的失败大概率就是本次改动引入的，而不是环境的历史遗留。

七、常见问题 FAQ

Q1：这个技能怎么安装？装完怎么确认它真的生效了？ A：在支持技能机制的 AI 编程助手中添加 using-git-worktrees（技能ID 13642）即可，具体入口、命令与授权方式请以官方说明为准。验证方法很简单：提出一个“需要隔离工作空间”的请求，看助手是否主动说出“我正在使用 using-git-worktrees 技能来设置一个隔离的工作空间”，并完整走完目录检查 → .gitignore 校验 → 创建 → 装依赖 → 跑测试 → 报告这条链路。

Q2：它收费吗？ A：技能本身的能力描述中不涉及任何计费信息。是否需要付费取决于你使用的 AI 编程助手平台的计费策略，请以官方说明为准。

Q3：为什么它坚持要检查 .gitignore，甚至自动改我的文件？ A：因为项目本地的工作树目录（如 .worktrees/）如果不在忽略规则里，工作树内的所有文件都会被主仓库跟踪，git status 会被大量无关文件污染，甚至可能被误提交。技能遵循“立即修复损坏的事物”原则，先补规则并提交，再创建工作树。全局目录位于项目之外，因此无需此步骤。

Q4：基线测试失败了，它会自己继续吗？ A：不会。技能明确规定：测试失败时报告失败，并询问你是继续还是调查，绝不在未获许可的情况下推进。这是为了保住“干净基线”这个前提——否则后续无法区分新错误与预先存在的问题。

Q5：它和直接敲 git worktree add 有什么区别，我该选哪个？ A：如果你熟悉 Git、且只需临时建一个工作树，原生命令更快更直接。如果你希望每次创建都自动处理目录约定、忽略规则、依赖安装和基线验证，尤其是在 AI 助手参与执行计划的场景下，该技能的流程化优势更明显。二者并不冲突——技能底层调用的正是 git worktree add。