← ClaudeAtlas

worktreelisted

Git worktree strategy for branch-isolated development. Use for planned-feature package work, isolated bugfixes, hotfixes, spikes, feature-branch management, or worktree cleanup. Do not use for direct implementation without an approved worktree action.
leninkhaidem/super-developer · ★ 0 · Code & Development · score 62
Install: claude install-skill leninkhaidem/super-developer
# Git Worktree Strategy Protect the user-owned root worktree while using branch-isolated `.worktrees/` checkouts for package, bugfix, hotfix, spike, integration, target-merge, and artifact-sidecar work. ## Always - Root files/index are user-owned: never switch, edit, merge, or deliver there. Commands may run from `$PROJECT_ROOT` to create/remove approved non-root worktrees/refs. - Resolve the primary root with the NUL-safe common-directory procedure below; `--show-toplevel` alone may be a linked worktree and must not anchor nested `.worktrees/`. - Keep agent-managed checkouts under `$PROJECT_ROOT/.worktrees/`; ensure `.worktrees/` is ignored. - Feature branches are refs, not root checkouts. Create `feature/<feature>` from an explicit `<base-ref>`. - Use `.worktrees/<feature>/merge` as the only checkout of `feature/<feature>` for integration. - Planned-package branches use `wp/<feature>/<WP-ID>` with worktrees at `.worktrees/<feature>/wp-<WP-ID>`. Normal feature work integrates into `feature/<feature>`; a planned production hotfix integrates into the exact non-root `hotfix/<name>` worktree/ref from its explicit production base and creates no feature ref. - Artifact sidecars use orphan ref `artifacts/<feature>` at `.worktrees/<feature>/artifacts`; they are not source checkouts or deliverable refs. - Package agents never create worktrees, branches, merges, target pushes, or cleanup operations. - An auto-resolve Execution Contract may authorize matching probes and focused