Git 工作树自动引导

问题在哪

git worktree add 能同时开多个分支目录，但每个新 worktree 往往还是手工活：从主仓库拷 .env、再装一遍 node_modules、改 dev 端口、对齐 docker-compose 项目名。仓库一复杂（monorepo、Python venv、Wrangler 本地 state），重复步骤多且容易漏。

本技能不是每次创建 worktree 时自动跑的那层逻辑——那是 hook 和 scripts/setup-worktree.sh。技能只在你说「帮我配 worktree 自动引导」「项目结构变了，更新 init 脚本」这类明确需求时运行，产出针对当前仓库的脚本与 Agent 配置。

它怎么工作

核心是 先审计、再交草案、少问废话、最后落地，四步流程：

1. Step 1 — 自行审计：读 package.json / pyproject.toml / .gitignore / .env.example、Makefile、CI、是否已有 scripts/setup-worktree.sh 等，推断 monorepo、包管理器、哪些目录该 Share（symlink）、Copy（密钥与可能并发写的 state）、Generate（端口、COMPOSEPROJECTNAME）。
2. Step 2 — 带具体资源清单进场：给出推荐配置，只对审计无法判定的项（例如 .wrangler/state 是否跨 worktree 共享、是否多 Agent 工具）标「需确认」。
3. Step 3 — 根据回答收紧：最多 1～2 轮跟进，不堆问卷。
4. Step 4 — 生成并验证：写入 scripts/setup-worktree.sh、合并 .claude/settings.json 等 hook 配置；跑两遍验证幂等；在新 worktree 里实际 dev/测试；保留 bash scripts/setup-worktree.sh 手动入口。

Agent 触发方式因工具而异：Claude Code 可用 SessionStart / WorktreeCreate；Codex、Cursor 等若无等价 hook，会退到 post-checkout + 同一脚本。不熟悉的工具不会瞎编 hook，会向你索要文档。

边界与注意

• 有状态目录（Postgres data、SQLite WAL）：多 worktree 并发 dev 时默认倾向 Copy，共享 symlink 可能损坏数据；是否共享必须由你确认，技能不会替你做并发策略决定。
• Monorepo：只链根目录 node_modules 不够，workspace 子包（apps/*、packages/*）的本地 node_modules 也要纳入 Share，否则会出现子路径 export 找不到模块。
• 更新已有脚本：只改脚本底部「资源声明」块，一般不碰 helper；.env 必须 Copy，不能 symlink（否则改 secret 会串 worktree）。