fix: close sibling-worktree loophole in already-inside path

Drill scenario worktree-already-inside-spec-aware revealed a latent
skill loophole: agents detecting existing isolation would correctly
refuse to nest a worktree, but then offer options — including exiting
to the main repo and creating a sibling worktree from there — and
execute the sibling option when the actor accepted.

The prior wording "Do NOT create another worktree" got read as
"don't NEST another worktree," leaving sibling creation as an
apparently-legal workaround that satisfied the agent's interpretation
of the directive while violating the skill's actual intent (use the
current workspace, period).

Fix: tighten the already-inside block to be explicit:
- Current workspace is the working environment, use it
- No alternatives, no creation — not nested, not sibling, not anywhere
- If the user genuinely needs different isolation for unrelated work,
  they have to exit the current workspace themselves

Validation pending via drill reruns of worktree-already-inside and
worktree-already-inside-spec-aware on this branch state.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

docs/superpowers/plans/2026-04-06-worktree-rototill.md

@@ -251,7 +251,7 @@ Report with branch state:
 
 **If `GIT_DIR == GIT_COMMON` (or in a submodule):** You are in a normal repo checkout.
 
-If the user has not already made their preferences about worktree isolation clear — check global and project agent instruction files (`CLAUDE.md`, `AGENTS.md`, `GEMINI.md`, `.cursorrules`, or equivalent) — ask for consent before creating a worktree:
+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."
 
@@ -289,7 +289,7 @@ Follow this priority order:
    ```
    If found, use it (backward compatibility with legacy global path).
 
-3. **Check your project's agent instruction file** (CLAUDE.md, GEMINI.md, AGENTS.md, .cursorrules, or equivalent) for a worktree directory preference. If specified, use it without asking.
+3. **Check your instructions for a worktree directory preference.** If specified, use it without asking.
 
 4. **Default to `.worktrees/`.**
 

skills/using-git-worktrees/SKILL.md

@@ -30,7 +30,11 @@ BRANCH=$(git branch --show-current)
 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 4 (Project Setup). Do NOT create another worktree.
+**If `GIT_DIR != GIT_COMMON` (and not a submodule):** You are already in a linked worktree. The current workspace is your working environment — use it for whatever the user is asking about. Skip to Step 4 (Project Setup).
+
+**Do not offer alternatives, and do not create another worktree — not here as a nested one, not as a sibling from the main repo, and not anywhere else.** If the user's request mentions "isolation" or "a worktree" explicitly, the current worktree already satisfies that need. Explain this and work in place.
+
+**If the user insists on different isolation for unrelated work:** stop and ask them to exit this workspace and re-invoke the skill from the main repo. Do not create siblings on their behalf.
 
 Report with branch state:
 - On a branch: "Already in isolated workspace at `<path>` on branch `<name>`."
@@ -48,7 +52,9 @@ echo "Current branch: $BRANCH"
 echo "Repository: $(basename "$(git rev-parse --show-toplevel)")"
 ```
 
-Tell the user their options, then **wait for a reply**:
+**Check the user's most recent message first.** If they already asked for a worktree, named the worktree skill, or asked for an isolated workspace in the message that invoked you, that IS the explicit ask — proceed directly to Step 3 without re-prompting.
+
+Otherwise, tell the user their options and **wait for a reply**:
 
 > "You're on `<branch>` in `<repo>`. I can set up an isolated worktree, or we can work directly here. What do you prefer?"
 
@@ -82,7 +88,7 @@ Only proceed to Step 3b if you have no native worktree tool available.
 
 Follow this priority order. Explicit user preference always beats observed filesystem state.
 
-1. **Check global and project agent instruction files** (`~/.claude/CLAUDE.md`, `~/.config/gemini/AGENTS.md`, project-level `CLAUDE.md`, `AGENTS.md`, `GEMINI.md`, `.cursorrules`, or equivalent) for a declared worktree directory preference. If specified, use it without asking.
+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
@@ -241,7 +247,7 @@ Ready to implement <feature-name>
 - Create worktree without verifying it's ignored (project-local)
 - Skip baseline test verification
 - Proceed with failing tests without asking
-- Infer worktree consent from the task description, plan, or skill invocation — only an explicit user reply counts
+- Infer worktree consent from the task description or plan — only an explicit user request counts
 
 **Always:**
 - Run Step 1 detection first
@@ -256,9 +262,9 @@ Ready to implement <feature-name>
 ## Integration
 
 **Called by:**
-- **subagent-driven-development** - Ensures isolated workspace (creates one or verifies existing)
-- **executing-plans** - Ensures isolated workspace (creates one or verifies existing)
-- Any skill needing isolated workspace
+- **subagent-driven-development** - Calls this to detect the workspace and optionally set up worktree isolation on request
+- **executing-plans** - Calls this to detect the workspace and optionally set up worktree isolation on request
+- Any skill that may use worktree isolation
 
 **Pairs with:**
 - **finishing-a-development-branch** - REQUIRED for cleanup after work complete