)
1a. Native Worktree Tools (preferred)【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowersIf your platform provides a worktree or workspace-isolation tool, use it. You know your own toolkit — the skill does not need to name specific tools. Native tools handle directory placement, branch creation, and cleanup automatically.After using a native tool, skip to Step 3 (Project Setup).1b. Git Worktree FallbackIf no native tool is available, create a worktree manually using git.**但要注意这正是 TDD 中被推翻的初稿。** 设计规格的 Step 1a 设计笔记完整记录了这次迭代初稿故意写得抽象你知道自己的工具箱但 RED/GREEN 验证证明 Agent 会锚定在 Step 1b 的具体 git 命令上而忽略抽象指引——**通过率仅 2/6**。三处修改把通过率拉到 50/50 1. **显式列举工具名**——列出 EnterWorktree、WorktreeCreate、/worktree 命令、--worktree 标志把我有没有原生工具从语义解释题变成事实查表题工具列表里有没有这些名字无这些工具的平台查不到自然落到 Step 1b未观察到误报 2. **同意桥接consent bridge**——用户同意创建 worktree 就是你使用原生工具的授权直接对齐 EnterWorktree 工具描述层面的护栏ONLY when user explicitly asks。因为工具描述会覆盖技能指令技能必须把用户同意翻译成工具要求的授权形式 3. **Red Flag 条目**——把反模式点名写进红旗区有原生 worktree 工具时还用 git worktree add 是第一大错误。 当前 [skills/using-git-worktrees/SKILL.md](https://link.gitcode.com/i/367a54f39b6537c0a04df4217e4ef71a) 的 Step 1a 正是修改后的形态It might be a tool with a name like EnterWorktree, WorktreeCreate, a /worktree command, or a --worktree flag.并补了一句后果说明Using git worktree add when you have a native tool creates phantom state your harness cant see or manage. 规格还专门测试过把 Step 1b 拆到另一个文件的方案——**没有必要**锚定问题靠 Step 1a 文本质量解决而不是靠物理隔离 git 命令完整 240 行技能所有 git 命令可见的对照测试 20/20 通过。 ### Step 1bgit 兜底的目录策略与安全校验 无原生工具时的手动创建路径有一套优先级明确的目录选择策略 1. **查用户指令中声明的 worktree 目录偏好**——声明了就直接用不再询问 2. **查项目内已有目录**ls -d .worktrees优先隐藏式与 ls -d worktrees备选两者并存时 .worktrees 胜出 3. **默认 .worktrees/**项目根下。 规格特别说明不做交互式目录选择提示也不再检测/提供旧的用户全局 Superpowers worktree 路径——新手动 worktree 一律项目内本地化除非用户显式指定别处。这一点有专门的回归测试 [test-worktree-path-policy.sh](https://link.gitcode.com/i/7fba78e5f633cab3fcb53f3c577d6ab6) 守护它断言两个技能与规格/计划文档中都不再出现 ~/.config/superpowers/worktrees 旧全局路径且 using 技能包含 default to \.worktrees/\ at the project root 措辞、finishing 技能保留 .worktrees/ or worktrees/ 的清理归属判断。 创建前还有一道**忽略校验**仅限项目内本地目录 bash git check-ignore -q .worktrees 2/dev/null || git check-ignore -q worktrees 2/dev/null若目录未被 git 忽略先写入.gitignore并提交再创建——否则整个 worktree 目录树会被误提交进仓库。创建命令与沙箱兜底path$LOCATION/$BRANCH_NAME git worktree add $path -b $BRANCH_NAME cd $path若git worktree add因权限错误失败沙箱拒绝按受限环境处理告知用户、就地工作并继续执行初始化与基线测试。当前技能文件还保留了计划中的Hooks Awareness要点git worktree 不继承主仓库 hooks 目录1b 创建后应符号链接 hooks防止 pre-commit、linter 等在迁入 worktree 后静默失效。Step 2/3项目初始化与基线验证无论工作区来自哪条路径Step 0 检测到已有、Step 1a 原生工具、Step 1b git 兜底或用户拒绝创建流程都收敛到同一段按package.json/Cargo.toml/requirements.txt/pyproject.toml/go.mod自动探测并执行npm install、cargo build、pip install -r、poetry install、go mod download然后跑测试套件确认基线干净。基线失败则报告并请求指示不得带病开工。最终报告格式固定为三行Worktree ready at full-path/Tests passing (N tests, 0 failures)/Ready to implement feature-name。当前技能文件末尾的 Quick Reference 表覆盖了 13 种情况已在 worktree、在子模块、有原生工具、目录并存、目录未忽略、权限错误、基线失败等其后的 Common Rationalizations 表则针对 Agent 的典型借口逐条反驳如我看出来不在 worktree 里不用检测——harness 创建的隔离与子模块都会骗过肉眼检测命令才有定论git worktree add更快——绕过原生工具是第一大错误。Task 3重写 finishing-a-development-branch —— 环境感知收尾与三个 bug 修复skills/finishing-a-development-branch/SKILL.md 的重写遵循Verify tests → Detect environment → Present options → Execute choice → Clean up主链。计划要求的核心变化是在展示选项之前先重跑一次环境检测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)检测结果决定菜单与清理策略状态菜单清理GIT_DIR GIT_COMMON普通仓库标准选项无 worktree 可清理GIT_DIR ! GIT_COMMON命名分支标准选项基于来源归属provenance清理GIT_DIR ! GIT_COMMONdetached HEAD缩减菜单无本地合并项外部管理保持原样detached HEAD 无法在不先建分支的情况下合并所以本地合并选项必须从菜单中拿掉——这正是 Codex App 沙箱模型平台托管、detached HEAD、无 Agent 工具需要的行为。三个收尾 bug 的修复规格 Bug Fixes 表Bug问题修复位置#940Option 2建 PR的正文写Then: Cleanup worktree与 Quick Reference保留 worktree自相矛盾Step 5 又说Options 1, 2, 4Common Mistakes 又说仅 1 和 4Option 2 不再清理 worktree——用户要在该 worktree 里迭代 PR 反馈清理仅适用于 Options 1 和 4finishing SKILL.md#999Option 1 先删分支再删 worktree而 worktree 仍引用该分支导致git branch -d失败顺序改为merge → 验证测试 → 删 worktree → 删分支且合并未成功前不得删除任何东西finishing SKILL.md#238在被删除的 worktree 内部执行git worktree remove会静默失败加 CWD 守卫移除前cd到主仓库根finishing SKILL.md#999 的修复还解释了为什么先删 worktree的朴素修法也是错的——若随后 merge 失败工作目录已经消失、变更丢失。本地合并的完整执行序列当前 finishing 技能 Step 5 可对照# 先取主仓库根保证 CWD 安全Bug #238 修复 MAIN_ROOT$(git -C $(git rev-parse --git-common-dir)/.. rev-parse --show-toplevel) cd $MAIN_ROOT # 先合并成功验证前不删除任何东西 git checkout base-branch git pull git merge feature-branch test command # 在合并结果上验证测试 # 合并成功后先清理 worktree再删分支Bug #999 修复 git branch -d feature-branch若合并后测试失败停止保留 worktree 与分支去排查——尚未 push本地合并可恢复。基于来源归属provenance的清理清理只由 Option 1本地合并与确认后的 discard 触发Option 2PR和 Option 3保留永远保留 worktree。清理逻辑本身就是来源归属原则的落点if GIT_DIR GIT_COMMON: 普通仓库无 worktree 可清理 elif WORKTREE_PATH 在 .worktrees/ 或 worktrees/ 之下: 主仓库根下执行 git worktree remove $WORKTREE_PATH git worktree prune # 自愈清理过期注册 else: 宿主环境拥有该工作区 —— 不动它若平台提供 workspace-exit 工具则用它【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 1a. Native Worktree Tools (preferred)
1a. Native Worktree Tools (preferred)【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowersIf your platform provides a worktree or workspace-isolation tool, use it. You know your own toolkit — the skill does not need to name specific tools. Native tools handle directory placement, branch creation, and cleanup automatically.After using a native tool, skip to Step 3 (Project Setup).1b. Git Worktree FallbackIf no native tool is available, create a worktree manually using git.**但要注意这正是 TDD 中被推翻的初稿。** 设计规格的 Step 1a 设计笔记完整记录了这次迭代初稿故意写得抽象你知道自己的工具箱但 RED/GREEN 验证证明 Agent 会锚定在 Step 1b 的具体 git 命令上而忽略抽象指引——**通过率仅 2/6**。三处修改把通过率拉到 50/50 1. **显式列举工具名**——列出 EnterWorktree、WorktreeCreate、/worktree 命令、--worktree 标志把我有没有原生工具从语义解释题变成事实查表题工具列表里有没有这些名字无这些工具的平台查不到自然落到 Step 1b未观察到误报 2. **同意桥接consent bridge**——用户同意创建 worktree 就是你使用原生工具的授权直接对齐 EnterWorktree 工具描述层面的护栏ONLY when user explicitly asks。因为工具描述会覆盖技能指令技能必须把用户同意翻译成工具要求的授权形式 3. **Red Flag 条目**——把反模式点名写进红旗区有原生 worktree 工具时还用 git worktree add 是第一大错误。 当前 [skills/using-git-worktrees/SKILL.md](https://link.gitcode.com/i/367a54f39b6537c0a04df4217e4ef71a) 的 Step 1a 正是修改后的形态It might be a tool with a name like EnterWorktree, WorktreeCreate, a /worktree command, or a --worktree flag.并补了一句后果说明Using git worktree add when you have a native tool creates phantom state your harness cant see or manage. 规格还专门测试过把 Step 1b 拆到另一个文件的方案——**没有必要**锚定问题靠 Step 1a 文本质量解决而不是靠物理隔离 git 命令完整 240 行技能所有 git 命令可见的对照测试 20/20 通过。 ### Step 1bgit 兜底的目录策略与安全校验 无原生工具时的手动创建路径有一套优先级明确的目录选择策略 1. **查用户指令中声明的 worktree 目录偏好**——声明了就直接用不再询问 2. **查项目内已有目录**ls -d .worktrees优先隐藏式与 ls -d worktrees备选两者并存时 .worktrees 胜出 3. **默认 .worktrees/**项目根下。 规格特别说明不做交互式目录选择提示也不再检测/提供旧的用户全局 Superpowers worktree 路径——新手动 worktree 一律项目内本地化除非用户显式指定别处。这一点有专门的回归测试 [test-worktree-path-policy.sh](https://link.gitcode.com/i/7fba78e5f633cab3fcb53f3c577d6ab6) 守护它断言两个技能与规格/计划文档中都不再出现 ~/.config/superpowers/worktrees 旧全局路径且 using 技能包含 default to \.worktrees/\ at the project root 措辞、finishing 技能保留 .worktrees/ or worktrees/ 的清理归属判断。 创建前还有一道**忽略校验**仅限项目内本地目录 bash git check-ignore -q .worktrees 2/dev/null || git check-ignore -q worktrees 2/dev/null若目录未被 git 忽略先写入.gitignore并提交再创建——否则整个 worktree 目录树会被误提交进仓库。创建命令与沙箱兜底path$LOCATION/$BRANCH_NAME git worktree add $path -b $BRANCH_NAME cd $path若git worktree add因权限错误失败沙箱拒绝按受限环境处理告知用户、就地工作并继续执行初始化与基线测试。当前技能文件还保留了计划中的Hooks Awareness要点git worktree 不继承主仓库 hooks 目录1b 创建后应符号链接 hooks防止 pre-commit、linter 等在迁入 worktree 后静默失效。Step 2/3项目初始化与基线验证无论工作区来自哪条路径Step 0 检测到已有、Step 1a 原生工具、Step 1b git 兜底或用户拒绝创建流程都收敛到同一段按package.json/Cargo.toml/requirements.txt/pyproject.toml/go.mod自动探测并执行npm install、cargo build、pip install -r、poetry install、go mod download然后跑测试套件确认基线干净。基线失败则报告并请求指示不得带病开工。最终报告格式固定为三行Worktree ready at full-path/Tests passing (N tests, 0 failures)/Ready to implement feature-name。当前技能文件末尾的 Quick Reference 表覆盖了 13 种情况已在 worktree、在子模块、有原生工具、目录并存、目录未忽略、权限错误、基线失败等其后的 Common Rationalizations 表则针对 Agent 的典型借口逐条反驳如我看出来不在 worktree 里不用检测——harness 创建的隔离与子模块都会骗过肉眼检测命令才有定论git worktree add更快——绕过原生工具是第一大错误。Task 3重写 finishing-a-development-branch —— 环境感知收尾与三个 bug 修复skills/finishing-a-development-branch/SKILL.md 的重写遵循Verify tests → Detect environment → Present options → Execute choice → Clean up主链。计划要求的核心变化是在展示选项之前先重跑一次环境检测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)检测结果决定菜单与清理策略状态菜单清理GIT_DIR GIT_COMMON普通仓库标准选项无 worktree 可清理GIT_DIR ! GIT_COMMON命名分支标准选项基于来源归属provenance清理GIT_DIR ! GIT_COMMONdetached HEAD缩减菜单无本地合并项外部管理保持原样detached HEAD 无法在不先建分支的情况下合并所以本地合并选项必须从菜单中拿掉——这正是 Codex App 沙箱模型平台托管、detached HEAD、无 Agent 工具需要的行为。三个收尾 bug 的修复规格 Bug Fixes 表Bug问题修复位置#940Option 2建 PR的正文写Then: Cleanup worktree与 Quick Reference保留 worktree自相矛盾Step 5 又说Options 1, 2, 4Common Mistakes 又说仅 1 和 4Option 2 不再清理 worktree——用户要在该 worktree 里迭代 PR 反馈清理仅适用于 Options 1 和 4finishing SKILL.md#999Option 1 先删分支再删 worktree而 worktree 仍引用该分支导致git branch -d失败顺序改为merge → 验证测试 → 删 worktree → 删分支且合并未成功前不得删除任何东西finishing SKILL.md#238在被删除的 worktree 内部执行git worktree remove会静默失败加 CWD 守卫移除前cd到主仓库根finishing SKILL.md#999 的修复还解释了为什么先删 worktree的朴素修法也是错的——若随后 merge 失败工作目录已经消失、变更丢失。本地合并的完整执行序列当前 finishing 技能 Step 5 可对照# 先取主仓库根保证 CWD 安全Bug #238 修复 MAIN_ROOT$(git -C $(git rev-parse --git-common-dir)/.. rev-parse --show-toplevel) cd $MAIN_ROOT # 先合并成功验证前不删除任何东西 git checkout base-branch git pull git merge feature-branch test command # 在合并结果上验证测试 # 合并成功后先清理 worktree再删分支Bug #999 修复 git branch -d feature-branch若合并后测试失败停止保留 worktree 与分支去排查——尚未 push本地合并可恢复。基于来源归属provenance的清理清理只由 Option 1本地合并与确认后的 discard 触发Option 2PR和 Option 3保留永远保留 worktree。清理逻辑本身就是来源归属原则的落点if GIT_DIR GIT_COMMON: 普通仓库无 worktree 可清理 elif WORKTREE_PATH 在 .worktrees/ 或 worktrees/ 之下: 主仓库根下执行 git worktree remove $WORKTREE_PATH git worktree prune # 自愈清理过期注册 else: 宿主环境拥有该工作区 —— 不动它若平台提供 workspace-exit 工具则用它【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考