using-git-worktrees

<!-- Coacus adaptation of a Superpowers workflow (MIT). Upstream: https://github.com/obra/superpowers @ 5bf4e78011075bcfc0dc295f0724994cd123ee71 Process artifacts are written under docs/temp/. Conventions: ../using-coacus/references/coacus-process-conventions.md --> # Using Git Worktrees ## Overview Ensure work happens in an isolated workspace. Give preference to standard native git tooling (`git worktree add`) as the primary mechanism for workspace isolation, unless the current session is actively being supervised or managed by an integrated orchestrator. **Core principle:** Detect existing isolation first. If actively managed by an integrated orchestrator, use its integrated workspace mechanism; otherwise, use native git worktrees directly. Never hunt for or invoke external orchestrator CLIs from standalone terminal sessions. **Announce at start:** "I'm using the using-git-worktrees skill to set up an isolated workspace." ## Step 0: Detect Existing Isolation **Before creating anything, check if you are already in an isolated workspace.** ```bash GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P) GIT_COMMON=$(cd "$(git rev-parse --git-common-dir)" 2>/dev/null && pwd -P) BRANCH=$(git branch --show-current) ``` **Submodule guard:** `GIT_DIR != GIT_COMMON` is also true inside git submodules. Before concluding "already in a worktree," verify you are not in a submodule: ```bash # If this returns a path, you're in a submodule, not a worktree — treat as normal repo git rev-parse --show-superproject-working-tree 2>/dev/null ``` **If `GIT_DIR != GIT_COMMON` (and not a submodule):** You are already in a linked worktree. Skip to Step 2 (Project Setup). Do NOT create another worktree. Report with branch state: - On a branch: "Already in isolated workspace at `<path>` on branch `<name>`." - Detached HEAD: "Already in isolated workspace at `<path>` (detached HEAD, externally managed). Branch creation needed at finish time." **If `GIT_DIR == GIT_COMMON` (or in a submodule):** You are in a normal repo checkout. Has the user already indicated their worktree preference in your instructions? If not, ask for consent before creating a worktree: > "Would you like me to set up an isolated worktree? It protects your current branch from changes." Honor any existing declared preference without asking. If the user declines consent, work in place and skip to Step 2. ## Step 1: Create Isolated Workspace Choose the creation path based on whether the current session is actively managed by an orchestrator: ### 1a. Integrated Orchestrator Workspace (Conditional) **Condition:** Use this path **only** when your current session is actively running under and being supervised by an integrated orchestrator or platform that manages workspace lifecycles natively (e.g., a native tool like `EnterWorktree`, `WorktreeCreate`, or an environment-provided tool active in this session). - When running under an active orchestrator, using its integrated mechanism ensures the orchestrator can track placement, supervision, and cleanup automatically. - **Do not hunt for, probe, or invoke external orchestrator CLIs** when running in a standalone terminal or independent session. - If actively managed by an integrated orchestrator, use its native mechanism and skip to Step 2. Otherwise, proceed to Step 1b. ### 1b. Native Git Worktree (Primary / Default) **Default for all standard terminal and standalone sessions.** When no active orchestrator manages the session, create an isolated worktree directly using standard `git worktree add`. #### Directory Selection Follow this priority order. Explicit user preference always beats observed filesystem state. 1. **Check your instructions for a declared worktree directory preference.** If the user has already specified one, use it without asking. 2. **Check for an existing project-local worktree directory:** ```bash ls -d .worktrees 2>/dev/null # Preferred (hidden) ls -d worktrees 2>/dev/null # Alternative ``` If found, use it. If both exist, `.worktrees` wins. 3. **If there is no other guidance available**, default to `.worktrees/` at the project root. #### Safety Verification (project-local directories only) **MUST verify directory is ignored before creating worktree:** ```bash git check-ignore -q .worktrees 2>/dev/null || git check-ignore -q worktrees 2>/dev/null ``` **If NOT ignored:** Add to .gitignore, commit the change, then proceed. **Why critical:** Prevents accidentally committing worktree contents to repository. #### Create the Worktree ```bash # Determine path based on chosen location path="$LOCATION/$BRANCH_NAME" git worktree add "$path" -b "$BRANCH_NAME" cd "$path" ``` **Sandbox fallback:** If `git worktree add` fails with a permission error (sandbox denial), tell the user the sandbox blocked worktree creation and you're working in the current directory instead. Then run setup and baseline tests in place. ## Step 2: Project Setup Auto-detect and run appropriate setup: ```bash # Node.js if [ -f package.json ]; then npm install; fi # Rust if [ -f Cargo.toml ]; then cargo build; fi # Python if [ -f requirements.txt ]; then pip install -r requirements.txt; fi if [ -f pyproject.toml ]; then poetry install; fi # Go if [ -f go.mod ]; then go mod download; fi ``` ## Step 3: Verify Clean Baseline Run tests to ensure workspace starts clean: ```bash # Use project-appropriate command npm test / cargo test / pytest / go test ./... ``` **If tests fail:** Report failures, ask whether to proceed or investigate. **If tests pass:** Report ready. ### Report ``` Worktree ready at <full-path> Tests passing (<N> tests, 0 failures) Ready to implement <feature-name> ``` ## Quick Reference | Situation | Action | |-----------|--------| | Already in linked worktree | Skip creation (Step 0) | | In a submodule | Treat as normal repo (Step 0 guard) | | Actively managed by orchestrator | Use integrated mechanism (Step 1a) | | Standalone terminal / standard session | Native git worktree (Step 1b) | | `.worktrees/` exists | Use it (verify ignored) | | `worktrees/` exists | Use it (verify ignored) | | Both exist | Use `.worktrees/` | | Neither exists | Check instruction file, then default `.worktrees/` | | Directory not ignored | Add to .gitignore + commit | | Permission error on create | Sandbox fallback, work in place | | Tests fail during baseline | Report failures + ask | | No package.json/Cargo.toml | Skip dependency install | ## Common Rationalizations | Excuse | Reality | |--------|---------| | "I'm obviously not in a worktree — no need to check" | Run Step 0. Harness-created isolation and submodules both fool eyeballing; the detection commands settle it. | | "I should search for external orchestrator CLIs" | Hunting for external orchestrator CLIs outside an actively managed session creates detached, phantom state. In standard terminal sessions, native git worktrees are always the direct, reliable path. | | "The worktree directory is surely ignored already" | Run `git check-ignore`. An unignored worktree directory commits the whole tree into the repo. | | "Any directory name works" | Explicit instructions beat an existing project-local directory, which beats the `.worktrees/` default. | | "The workspace is fresh — baseline tests can wait" | A dirty baseline makes every later failure ambiguous. Run the tests now; proceeding past failures is your human partner's call. |