← ClaudeAtlas

isolating-executionlisted

Use before executing a plan — puts the work in an isolated, gated workspace. At minimum a feature branch (so the review gate applies, since the hooks skip protected branches), or a dedicated worktree for heavier isolation. Run it first, before executing-handoff-plans or orchestrating-execution.
Expeed-Software/exloom · ★ 0 · Code & Development · score 72
Install: claude install-skill Expeed-Software/exloom
# Isolating Execution ## Overview Execution has to happen somewhere. If it happens on the branch you were already standing on — often `main`, `dev`, or a shared branch — two things go wrong. First, the review gate does not fire: the hooks deliberately skip protected branches (`main`, `master`, `dev`, `develop`), so work committed there ships with no enforced review. Second, the plan's commits interleave with whatever else that branch was carrying, and the 1:1 mapping between plan tasks and commits that `exloom:auditing-plan-fidelity` depends on is polluted from the first commit. Isolating execution fixes both before a single line is written. It puts the work in its own workspace so the gate *can* apply to it (once the repo's gate marker is enabled — see "Gated, or just isolated?" below) and the base branch is never touched by half-finished work. This is the setup step for `exloom:executing-handoff-plans` — run it first, once, and the rest of the loop inherits a clean, gated place to build. Isolation here is not about a tidy branch for its own sake. It makes two guarantees mechanical: the work is **reviewable** (it is on a gated branch) and **auditable** (its commits stand alone). ## The three levels Scale the isolation to the work. Detect first, then pick the lightest level that makes both guarantees hold. ### Level 0 — Detect existing isolation Before creating anything, check where you already are: ```bash git rev-parse --is-inside-work-tree # a git repo at a