Browse Source

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>
Drew Ritter 4 months ago
parent
commit
b8d9f06cfb
1 changed files with 5 additions and 1 deletions
  1. 5 1
      skills/using-git-worktrees/SKILL.md

+ 5 - 1
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>`."