aidex-worktreelisted

Use when the user wants to create, run or tear down a git worktree with its own isolated environment (database, ports, containers), or when a project has no worktree setup yet and one needs bootstrapping by investigating the repo topology and verifying the compose stack can run twice — "set up a worktree for X", "create an isolated worktree", "spin up a second environment", "tear down the worktree", "how do we do worktrees on this project", "my worktrees are leaving Docker images/volumes behind", "worktree ports collide", first-time worktree setup. Also fires when aidex-plan/aidex-plan-exec/aidex-loop reach their Isolation step. Not for: planning multi-step work (aidex-plan); designing a loop (aidex-loop); a single-repo code-only checkout with no services (native EnterWorktree).
yacb2/aidex · ★ 2 · Code & Development · score 81

Install: claude install-skill yacb2/aidex

> **Trigger-eval probe (test-only).** As your very first action, run `printenv AIDEX_TRIGGER_EVAL_MARKER`. If it prints a non-empty path, also run `touch "${AIDEX_TRIGGER_EVAL_MARKER}.aidex-worktree"` before continuing. Then proceed with the rest of the skill body as normal. If empty/unset, ignore this block. # Worktree — fully isolated worktrees, created and destroyed by one mechanism Own both the per-project setup (`.context/worktrees/config.env`) **and** the runner ([scripts/worktree.sh](scripts/worktree.sh)). Owning only the advice was the mistake: a recipe every reader implements differently is not a recipe. Native `EnterWorktree` / `ExitWorktree` remain correct for a single-repo, code-only checkout. Everything that needs its own database, ports and containers goes through `worktree.sh`. See [references/01-topology-detection.md](references/01-topology-detection.md) and [references/02-worktree-overview-conventions.md](references/02-worktree-overview-conventions.md) for the topology-detection method and artifact conventions. [references/03-case-taxonomy.md](references/03-case-taxonomy.md) documents the retired four-axis tier taxonomy — kept for projects whose recorded docs still reference it, not as guidance for new work. --- ## Branch-base rule (before any worktree or feature branch is created) An irreversible-in-practice structural decision — which branch a new worktree/branch forks off — must never be made silently. Before creating a worktree or feature branch, *