ce-worktree

Worktree Isolation handles the setup of isolated git worktrees so that work can proceed without disturbing the user's main checkout. Because most coding harnesses already create a worktree at session start, the skill's primary job is to detect existing isolation before creating anything redundant. It follows a strict order of operations: detect existing isolation, prefer a native worktree tool, then fall back to plain git only when neither applies.

Detection works by comparing the resolved absolute git directory against the resolved absolute common git directory. Because git mixes absolute and relative path forms depending on the current directory, the skill resolves each to an absolute path first rather than doing a raw string compare, which would otherwise yield a false "already isolated" result. When the two paths differ, it distinguishes a linked worktree from a submodule using the superproject working tree check, and works in place when it is already inside an isolated worktree. When a native worktree primitive exists (such as an EnterWorktree tool, a /worktree command, or a --worktree flag), it uses that and stops, because a behind-the-back git worktree add creates phantom state the harness cannot see or clean up.

The git fallback runs from the repo root, chooses a meaningful branch name derived from the work description, ensures .worktrees/ is gitignored (checking with a trailing slash so directory-only rules are honored), does a best-effort non-fatal fetch of the base branch, creates the worktree under .worktrees/<branch-name>, and switches into it. If creation fails with a sandbox or permission error, the skill treats it as a blocking decision and asks the user via the platform's question tool rather than silently working in the main checkout. It also documents other worktree operations (list, remove, switch) and integrates with the ce-work and ce-code-review flows, which offer it as a worktree option.