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: - Resolving a merge conflict. Landing itself *is* part of `basicly worktree` (step 3 below), but a conflict is never settled here: it means the declared scopes missed a coupling, so the merge bounces the lane back to re-apply its intent on the new base. There is no hand-edited conflict marker and no merge-time AI resolution. - Creating or claiming the tracker record the work tracks (see `work-tracker`). - 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