Worktrees and isolated changes
Use separate Git checkouts for parallel or risky changes.
A separate checkout, shared history
Section titled “A separate checkout, shared history”A Git worktree gives a task its own working directory and branch. It is useful for parallel changes or experiments that should not touch your current checkout.
Subagents alone do not provide this isolation. Workers can edit the same files unless their tasks and workspaces are explicitly separated.
Ask for an isolated task
Section titled “Ask for an isolated task”Inspect git status and existing worktrees. Create a separate worktree for this fix, keep the current checkout untouched, and report the branch and commit after testing. Do not merge, push, or remove anything without asking.
Choose names and locations that make sense for the repository. A fresh worktree may not contain ignored dependencies or generated files; account for those before testing.
Review and bring the change back
Section titled “Review and bring the change back”Check the diff and test results in the worktree, then deliberately merge or cherry-pick the approved change. Keep unrelated user work intact. Report the exact branch and commit so the handoff can be verified.
Cleanup is a separate action
Section titled “Cleanup is a separate action”The native repository hygiene tool can plan cleanup and perform targeted push, remove, or prune actions behind terminal approval. Review its plan first. Do not remove a checkout with uncommitted or unpreserved work.
Worktrees isolate files; they are not security sandboxes and do not isolate all external services or credentials.