worktree-isolationlisted

<!-- Generated by `basicly skills-build` from skill.yaml. Do not edit; edit the source. --> # Worktree Isolation ## Scope Owns running a unit of work in an isolated **sibling** git worktree via the `basicly worktree` commands: where the worktree goes, how it is provisioned so its gates actually run, and how it is torn down without endangering the main checkout. It is not for: - Merging a finished worktree branch back or resolving conflicts (that is the merge orchestrator's job — not yet part of `basicly worktree`). - Creating or claiming the beads issue the work tracks (see `tool-br`). - Git staging, diffing, or commit-message formatting (see `tool-git`, `conventional-commits`). ## When to isolate - **Isolate** any non-trivial change: multi-file work, anything that runs the gates, or work that could run in parallel with another track. - **Skip** trivial mechanical edits (a typo, a one-line doc fix) — those go straight to the source branch. A worktree has a real setup cost; do not pay it for throwaway work. ## Placement rule (non-negotiable) A worktree lives at the **sibling** path `<repo>.worktrees/<name>` on branch `harness/<name>`, forked from the configured base branch (`[worktree].base_branch` in `basicly.toml`, or the current branch). Never create work worktrees **inside** the repo (e.g. in-repo `.claude/worktrees/`): an in-repo worktree pollutes the repo's own file walk and is not provisioned, so its git hooks fall back to a system toolchain and **run no