What problem does it solve? When multiple agents or long-running tasks modify the same source checkout, they collide, leave dirty state, or destroy each other's work. This Skill defines when isolated git worktrees are mandatory and how to use them correctly so the source checkout stays stable and interrupted work remains recoverable. ## Core Features & Use Cases - Trigger checklist (T1-T6): Concrete conditions (parallel writers, tasks over 30 minutes, irreversible changes, multi-agent experiments) that mandate worktree isolation instead of editing the source tree directly. - Three usage patterns: hermes --worktree subprocesses, delegate_task with an explicit workdir, or direct git worktree add plus cd, matched to task duration and monitoring needs. - Hard rules R1-R6: Source checkout is never switched or cleaned, every task gets its own branch and directory, dirty or interrupted worktrees are retained 24 hours, and cleanup goes through trash-cli instead of rm -rf. - Use Case: You delegate two feature branches to sub-agents in parallel. Each runs in ../worktrees/<task-id> on branch task/<id>-<desc>, hands back branch name and commit hash, and the main agent verifies nothing leaked into the source root before cleanup. ## Quick Start Ask the agent to set up an isolated worktree for a delegated coding task using the worktree-setup.sh template and verify the source checkout stays clean afterward.
