Worktree Isolation
Protect concurrent and unrelated repository work by assessing isolation before mutation.
Read linked worktree model when the decision depends on shared repository state, submodules, pruning, locking, or repair.
Workflow
- Inspect the current branch, revision, status, existing worktrees, and target files without changing them.
- Identify ownership overlap, uncommitted work, branch conflicts, shared generated output, and commands that can affect all worktrees.
- Decide whether the work can proceed in place, needs a linked worktree, or must wait for coordination.
- Propose the exact branch, base revision, worktree path, ownership boundaries, validation, and cleanup conditions.
- Require explicit authority before creating, moving, locking, repairing, pruning, or removing a worktree.
- Recheck the shared repository state before cleanup. Preserve worktrees with uncommitted or unintegrated work.
Boundaries
- Linked worktrees share repository-level state, including refs and some configuration; they are not independent clones.
- Do not assign the same branch to multiple worktrees.
- Treat submodule-heavy repositories cautiously because linked-worktree support can be incomplete.
- Never remove a worktree or branch merely because another change is complete.
Output
Report Current state, Collision risks, Isolation decision, Proposed layout, Required authority, Validation, and Cleanup conditions.
1---2name: worktree-isolation3description: Assess whether dirty or concurrent repository work needs Git worktree isolation and design a safe isolation approach. Use when work may overlap existing changes; require explicit authority before creating, moving, locking, repairing, or removing a worktree.4license: MIT5---67# Worktree Isolation89Protect concurrent and unrelated repository work by assessing isolation before mutation.1011Read [linked worktree model](references/linked-worktree-model.md) when the decision depends on shared repository state, submodules, pruning, locking, or repair.1213## Workflow14151. Inspect the current branch, revision, status, existing worktrees, and target files without changing them.162. Identify ownership overlap, uncommitted work, branch conflicts, shared generated output, and commands that can affect all worktrees.173. Decide whether the work can proceed in place, needs a linked worktree, or must wait for coordination.184. Propose the exact branch, base revision, worktree path, ownership boundaries, validation, and cleanup conditions.195. Require explicit authority before creating, moving, locking, repairing, pruning, or removing a worktree.206. Recheck the shared repository state before cleanup. Preserve worktrees with uncommitted or unintegrated work.2122## Boundaries2324- Linked worktrees share repository-level state, including refs and some configuration; they are not independent clones.25- Do not assign the same branch to multiple worktrees.26- Treat submodule-heavy repositories cautiously because linked-worktree support can be incomplete.27- Never remove a worktree or branch merely because another change is complete.2829## Output3031Report `Current state`, `Collision risks`, `Isolation decision`, `Proposed layout`, `Required authority`, `Validation`, and `Cleanup conditions`.
JovaniPink