chore(skills): 同步上游 v5.1.0 worktree 安全修复（issue #19 第一批）

[jnMetaCode]

你要解决什么问题？

上游 obra/superpowers v5.1.0 对 using-git-worktrees 和 finishing-a-development-branch 两个 skill 做了行为安全修复（参见 obra/superpowers#991），本 fork 当前 SKILL.md 内容仍停留在 v4.x/v5.0.5 之前的结构，导致：

• 子代理嵌套 worktree：subagent-driven-development 在已经在 worktree 内的情况下不检测，会再次创建 worktree（obra#991 报告的根因）
• 清理误删 harness-managed 工作区：旧 Step 5 清理逻辑没有 "by-provenance" 检查，可能移除由 IDE/harness 创建的工作区（造成 phantom state）
• submodule 误判：单看 GIT_DIR != GIT_COMMON 在 submodule 内也为真，旧版无守卫
• 分离 HEAD 默认走 merge 菜单：v5.1.0 已收敛为 3 选项（无 merge），旧版仍提供 4 选项导致下游错误
• /Users/jesse/myproject/ 硬编码：旧"示例工作流"段含上游作者的本地路径，issue tracking: 同步上游 superpowers v5.0.6 / v5.1.0 关键 skill 变更 #19 列入清理项

本 PR 是 issue #19 追踪清单里 v5.1.0 worktree 安全部分的第一批同步。

这个 PR 做了什么改变？

把上游 v5.1.0 在两个 worktree skill 上的所有行为变更逐字翻译同步：

using-git-worktrees/SKILL.md：

• 🆕 Step 0 检测现有隔离（GIT_DIR/GIT_COMMON + submodule 守卫 + 同意流程）
• 🔄 Step 1 重组为 1a Native Tools（首选）+ 1b Git Worktree Fallback（含目录选择/安全验证/创建/沙盒回退）
• ❌ 删除旧"示例工作流"段（含 /Users/jesse/myproject/ 硬编码）
• ✅ 章节编号保留上游"Step 1→3 跳过 Step 2"的怪癖，不擅自"修正"
• ✅ 我们独有的 `## 集成` 段（指向 brainstorming/subagent 等）保留

finishing-a-development-branch/SKILL.md：

• 🆕 Step 2 检测环境（三态表：normal repo / named-branch worktree / detached HEAD 决定菜单形态和清理逻辑）
• 🔄 旧 Step 2/3/4/5 重编号为 Step 3/4/5/6
• 🆕 Step 4 分离 HEAD 3 选项变体（去掉 merge 选项，防止误用）
• 🔄 Step 5 Option 1 重写：`MAIN_ROOT` cwd safety + 严格的 merge→verify→cleanup→delete 排序
• 🔄 Step 5 Option 2 增加 "不要清理 worktree" 提示（PR 反馈迭代需要）
• 🆕 Step 6 清理范围限定：只清 `.worktrees/` / `worktrees/` / `~/.config/superpowers/worktrees/` 之内的工作区；外部 harness-managed 一律不动（核心安全修复）
• 🔄 红线 + 常见错误段按上游对应扩展（新增 4 条 mistakes）

翻译原则：

• 章节标题翻译；章节编号严格 1:1 对应上游（Step 0/1/3/4/5/6）
• 代码块完全保留，不翻译变量名/命令
• 散文逐句翻译，不简化不扩写
• 不"改进"上游精心调优的措辞（红旗表/合理化描述等）

这个改变适合放在核心库中吗？

适合。这是上游 core skill 的行为安全修复同步，对所有中文用户都生效，不针对任何具体项目/工具/工作流。

你考虑了哪些替代方案？

1. 跳过 worktree 重构、只补 Step 0 检测——不够，Step 6 清理范围限定才是核心安全修复（误删 harness workspace 风险最高），且 Step 0 和 Step 6 共用 GIT_DIR/GIT_COMMON 探测，半同步会留下不一致。
2. 拆成两个 PR（一个 skill 一个 PR）——两个文件的 worktree 行为是联动的（Step 0 检测 ↔ Step 6 清理），分开同步留 review 缺口。
3. 保留旧结构、只补 v5.1.0 增量段——会破坏 SKILL 内部章节编号连续性（Step 1→2→3→4 中间插一段会让旧 Step 编号全部错位），不如整体重写干净。
4. 现方案：一个 PR 同步两个 skill，结构完全对齐上游——diff 大但语义最干净。✓

这个 PR 是否包含多个不相关的改变？

否。两个 skill 同属 worktree 子系统，行为联动（Step 0 检测 ↔ Step 6 清理）。本 PR 严格限定在 worktree 安全修复 scope 内。

明确不在本 PR 范围（issue #19 后续批次）：

• review loop 简化（v5.0.6 brainstorming/writing-plans）
• code-reviewer 整合（v5.1.0 requesting-code-review）
• subagent 节奏调整（v5.1.0 subagent-driven-development）
• brainstorm server.cjs 脚本结构同步（v5.0.6 CONTENT_DIR/STATE_DIR 拆分）

已有的 PR

• 我已查看所有已开放和已关闭的 PR，确认没有重复或先前的类似工作
• 相关 PR：未找到处理 v5.1.0 worktree 同步的 PR；issue tracking: 同步上游 superpowers v5.0.6 / v5.1.0 关键 skill 变更 #19 是相关 tracking issue

测试环境

工具	工具版本	模型	模型版本/ID
Claude Code	latest	Claude Opus	claude-opus-4-7

说明： 本 PR 是 SKILL.md 文档同步，不涉及代码执行路径。

结构对齐验证（本地）：

• grep -nE '^#{1,4} ' 比对：我方与 upstream/main 在 Step 0/1a/1b/3/4 + Step 2-6 章节结构 1:1 对齐
• GIT_DIR 出现 10 处（v5.1.0 标志）、MAIN_ROOT 6 处（cwd safety）、submodule 守卫 1 处、/Users/jesse 硬编码 0 处

评估

本 PR 是翻译同步性质，不是 skill 行为设计变更，所以无需对抗式 eval。措辞按上游逐句翻译，不改语义、不优化、不简化。

人类伙伴应做的下游 eval（合并后或本地试用本分支）：

• 在已有 .worktrees/<existing-branch> 内 cd 进去，触发任何调用 using-git-worktrees 的 skill，确认 Step 0 检测到并跳过创建
• 在 submodule 内触发，确认守卫生效（按普通仓库处理）
• 在分离 HEAD 工作区里走 finishing-a-development-branch，确认菜单是 3 选项（无 merge）
• 在 harness 创建的非 .worktrees/ 路径工作区里走 Option 1 / Option 4，确认 Step 6 不会移除（提示由 harness 管理）

严格性

• 这是 skill 改变，但翻译同步性质——上游已做过 eval（v5.1.0 release）、本 fork 只是把同样的措辞翻译成中文。不需要重做对抗式压力测试。
• 没有在未经评估的情况下"改进"上游精心调优的内容（红旗表、合理化描述、"人类伙伴"用语等都按上游对应翻译）
• 章节编号、变量命名、code block 内容、表格结构都与上游 1:1 对应

人工审核

• 提交前已有人工审核过 diff 范围（章节骨架对齐 + 关键标志统计）
• 完整文本 review 待你在 GitHub PR diff 视图 inline 评论