← ClaudeAtlas

using-git-worktreeslisted

Use when work needs isolation from the current branch — long-running feature, risky refactor, parallel attempt. Creates and tracks a worktree without touching unrelated state.
felipemelendez/llm-orchestrator · ★ 3 · Code & Development · score 69
Install: claude install-skill felipemelendez/llm-orchestrator
# Using git worktrees Isolation by directory, not by stash. ## When to use - The current branch has uncommitted work you don't want to lose. - You want to compare two approaches side by side. - A subagent will edit code while you keep working. Skip for tiny edits on a clean tree — just commit. ## Delegation Do not hand the checkout to the harness's per-agent worktree isolation (`isolation: worktree` on dispatch) — it was evaluated and rejected, and the reasons apply to the interactive single-writer case as much as to batch fan-out (the evaluation is a dated brief under `docs/llm-orchestrator/research/`, a local working directory that is not distributed; the operative reasons are all inline here): the harness branches from the default branch, not your current `HEAD`, so the subagent edits against the wrong base; the `worktree.baseRef: head` mitigation is a user setting a plugin cannot ship; the harness never reports the worktree path, so the registry claim, provenance marker, and green-baseline capture below have nowhere to land; and native cleanup keeps changed worktrees in a location the reaper never scans. Create the worktree yourself with the steps below (for parallel writers, the materialize engine per `dispatching-parallel-agents`) and pass the path into the dispatch envelope. ## Steps 1. **Check for existing isolation.** If you're already inside a worktree, don't nest. ``` git rev-parse --git-dir git rev-parse --git-common-dir ``` If they differ,