Compare commits

..

3 Commits

Author SHA1 Message Date
Drew Ritter
b8bced40a5 fix: restore auto-worktree triggering; remove consent ask (PRI-1147)
PR #1121's Step 0 consent prompt was intended as a bridge to
EnterWorktree's built-in "ONLY when user explicitly asks" guardrail, but
in context-diluted real-world sessions agents rationalize their way out
of asking AND fail to create a worktree — falling back to a plain feature
branch with reasoning like "EnterWorktree is restricted to explicit
worktree requests only, which this isn't."

Changes:
- Delete Step 0 consent ask paragraph; replace with "skill invocation IS
  the request for isolation" bridge language
- Restore imperative Step 1a framing ("STOP HERE if available", "No
  exceptions") that 998c40b softened during PR #1121 review
- Add Red Flag entries naming the specific anti-patterns: stopping to ask
  when skill is already invoked; falling back to a plain feature branch
  because the native tool feels "restricted to explicit requests"

Preserves the valuable parts of PRI-974: Step 0 detection
(GIT_DIR != GIT_COMMON), submodule guard, native-tool preference, cleanup
fixes. Only walks back the consent-ask construct.

Drill companion changes ship in a separate PR in the drill repo under
the same ticket.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-14 18:21:50 -07:00
Jesse Vincent
1e8000a4d4 Merge pull request #1121 from obra/worktree-worktree-rototill
adjust worktree handling and defer to harness tools when avail (PRI-974)
2026-04-13 16:57:07 -07:00
Jesse Vincent
c61f75030f Merge pull request #1122 from obra/fix-replace-hardcoded-users
fix: replace hardcoded /Users/jesse with generic placeholders (#858)
2026-04-13 16:48:28 -07:00
4 changed files with 39 additions and 83 deletions

View File

@@ -65,6 +65,6 @@ After all tasks complete and verified:
## Integration ## Integration
**Required workflow skills:** **Required workflow skills:**
- **superpowers:using-git-worktrees** - Detects workspace environment and offers worktree isolation on request - **superpowers:using-git-worktrees** - Ensures isolated workspace (creates one or verifies existing)
- **superpowers:writing-plans** - Creates the plan this skill executes - **superpowers:writing-plans** - Creates the plan this skill executes
- **superpowers:finishing-a-development-branch** - Complete development after all tasks - **superpowers:finishing-a-development-branch** - Complete development after all tasks

View File

@@ -265,7 +265,7 @@ Done!
## Integration ## Integration
**Required workflow skills:** **Required workflow skills:**
- **superpowers:using-git-worktrees** - Detects workspace environment and offers worktree isolation on request - **superpowers:using-git-worktrees** - Ensures isolated workspace (creates one or verifies existing)
- **superpowers:writing-plans** - Creates the plan this skill executes - **superpowers:writing-plans** - Creates the plan this skill executes
- **superpowers:requesting-code-review** - Code review template for reviewer subagents - **superpowers:requesting-code-review** - Code review template for reviewer subagents
- **superpowers:finishing-a-development-branch** - Complete development after all tasks - **superpowers:finishing-a-development-branch** - Complete development after all tasks

View File

@@ -1,21 +1,21 @@
--- ---
name: using-git-worktrees name: using-git-worktrees
description: Use when starting feature work that needs isolation from current workspace or before executing implementation plans - detects environment, offers worktree isolation when appropriate description: Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback
--- ---
# Using Git Worktrees # Using Git Worktrees
## Overview ## Overview
Detect the workspace environment. Work in place by default. Offer worktree isolation when the user would benefit, but only create one when they explicitly ask. Ensure work happens in an isolated workspace. Prefer your platform's native worktree tools. Fall back to manual git worktrees only when no native tool is available.
**Core principle:** Detect first. Default to working in place. Create worktrees only on explicit user request. Never fight the harness. **Core principle:** Detect existing isolation first. Then use native tools. Then fall back to git. Never fight the harness.
**Announce at start:** "I'm using the using-git-worktrees skill to check the workspace." **Announce at start:** "I'm using the using-git-worktrees skill to set up an isolated workspace."
## Step 1: Detect Existing Isolation ## Step 0: Detect Existing Isolation
**Before anything else, check if you are already in an isolated workspace.** **Before creating anything, check if you are already in an isolated workspace.**
```bash ```bash
GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P) GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P)
@@ -30,59 +30,33 @@ BRANCH=$(git branch --show-current)
git rev-parse --show-superproject-working-tree 2>/dev/null 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. The current workspace is your working environment — use it for whatever the user is asking about. Skip to Step 4 (Project Setup). **If `GIT_DIR != GIT_COMMON` (and not a submodule):** You are already in a linked worktree. Skip to Step 3 (Project Setup). Do NOT create another worktree.
**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: Report with branch state:
- On a branch: "Already in isolated workspace at `<path>` on branch `<name>`." - 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." - 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. Proceed to Step 2. **If `GIT_DIR == GIT_COMMON` (or in a submodule):** You are in a normal repo checkout. Proceed to Step 1 to create an isolated workspace.
## Step 2: Offer Workspace Options **Do not stop to ask the user whether they want a worktree.** Invoking this skill IS the request for isolation — your authorization to create one comes from that invocation, not from a separate "yes" reply. If the user has already declared in their instructions that they prefer to work in place, honor that and skip to Step 3. Otherwise, create the worktree.
**The default path is to work in place on your current branch.** Do NOT create a worktree unless the user explicitly asks for one. ## Step 1: Create Isolated Workspace
```bash **You have two mechanisms. Try them in this order.**
# Report current state to the user
echo "Current branch: $BRANCH"
echo "Repository: $(basename "$(git rev-parse --show-toplevel)")"
```
**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. ### 1a. Native Worktree Tools (preferred — STOP HERE if available)
Otherwise, tell the user their options and **wait for a reply**: Do you have a tool with a name like `EnterWorktree`, `WorktreeCreate`, a `/worktree` command, or a `--worktree` flag? **If YES: use it now and skip to Step 3.** Skill invocation is your authorization — you do not need a separate user reply.
> "You're on `<branch>` in `<repo>`. I can set up an isolated worktree, or we can work directly here. What do you prefer?" Native tools handle directory placement, branch creation, and cleanup automatically. Using `git worktree add` when you have a native tool creates phantom state your harness can't see or manage — cleanup becomes impossible.
**Routing:** **Even if `.worktrees/` already exists, even under time pressure, even if `git worktree add` feels faster — use your native tool.** No exceptions.
- **User explicitly asks for a worktree** → proceed to Step 3
- **User says work in place** → skip to Step 4
- **User gives no clear worktree preference** → skip to Step 4 (default is in-place)
- **Silence or unrelated reply** → ask once more, then skip to Step 4 if still unclear
The default is always Step 4. Step 3 requires an explicit "yes, create a worktree" from the user. Only proceed to Step 1b if you have confirmed you have NO native worktree tool available.
## Step 3: Create Worktree ### 1b. Git Worktree Fallback
**You only reach this step because the user explicitly asked for a worktree in Step 2.** **Only use this if Step 1a does not apply** — you have no native worktree tool available. Create a worktree manually using git.
You have two mechanisms. Try them in this order.
### 3a. Native Worktree Tools (preferred)
Do you already have a way to create a worktree? It might be a tool with a name like `EnterWorktree`, `WorktreeCreate`, a `/worktree` command, or a `--worktree` flag. If you do, use it and skip to Step 4.
Native tools handle directory placement, branch creation, and cleanup automatically. Using `git worktree add` when you have a native tool creates phantom state your harness can't see or manage.
Only proceed to Step 3b if you have no native worktree tool available.
### 3b. Git Worktree Fallback
**Only use this if Step 3a does not apply** — you have no native worktree tool available. Create a worktree manually using git.
#### Directory Selection #### Directory Selection
@@ -135,7 +109,7 @@ 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. **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 4: Project Setup ## Step 3: Project Setup
Auto-detect and run appropriate setup: Auto-detect and run appropriate setup:
@@ -154,7 +128,7 @@ if [ -f pyproject.toml ]; then poetry install; fi
if [ -f go.mod ]; then go mod download; fi if [ -f go.mod ]; then go mod download; fi
``` ```
## Step 5: Verify Clean Baseline ## Step 4: Verify Clean Baseline
Run tests to ensure workspace starts clean: Run tests to ensure workspace starts clean:
@@ -169,30 +143,20 @@ npm test / cargo test / pytest / go test ./...
### Report ### Report
If working in a worktree:
``` ```
Worktree ready at <full-path> Worktree ready at <full-path>
Tests passing (<N> tests, 0 failures) Tests passing (<N> tests, 0 failures)
Ready to implement <feature-name> Ready to implement <feature-name>
``` ```
If working in place:
```
Working in place on <branch> at <path>
Tests passing (<N> tests, 0 failures)
Ready to implement <feature-name>
```
## Quick Reference ## Quick Reference
| Situation | Action | | Situation | Action |
|-----------|--------| |-----------|--------|
| Already in linked worktree | Skip creation, go to Step 4 (Step 1) | | Already in linked worktree | Skip creation (Step 0) |
| In a submodule | Treat as normal repo (Step 1 guard) | | In a submodule | Treat as normal repo (Step 0 guard) |
| Normal repo, user wants in-place | Work in place, go to Step 4 (Step 2 default) | | Native worktree tool available | Use it (Step 1a) |
| Normal repo, user asks for worktree | Create worktree (Step 3) | | No native tool | Git worktree fallback (Step 1b) |
| Native worktree tool available | Use it (Step 3a) |
| No native tool | Git worktree fallback (Step 3b) |
| `.worktrees/` exists | Use it (verify ignored) | | `.worktrees/` exists | Use it (verify ignored) |
| `worktrees/` exists | Use it (verify ignored) | | `worktrees/` exists | Use it (verify ignored) |
| Both exist | Use `.worktrees/` | | Both exist | Use `.worktrees/` |
@@ -202,25 +166,18 @@ Ready to implement <feature-name>
| Permission error on create | Sandbox fallback, work in place | | Permission error on create | Sandbox fallback, work in place |
| Tests fail during baseline | Report failures + ask | | Tests fail during baseline | Report failures + ask |
| No package.json/Cargo.toml | Skip dependency install | | No package.json/Cargo.toml | Skip dependency install |
| User gives no worktree preference | Work in place (Step 2 default) |
| Plan touches multiple repos | Offer a matching worktree per repo, same branch name |
## Common Mistakes ## Common Mistakes
### Creating a worktree without being asked
- **Problem:** Agent creates a worktree because the skill was invoked, without the user requesting one
- **Fix:** Step 2 defaults to working in place. Only Step 3 creates, and only after explicit user request.
### Fighting the harness ### Fighting the harness
- **Problem:** Using `git worktree add` when the platform already provides isolation - **Problem:** Using `git worktree add` when the platform already provides isolation
- **Fix:** Step 1 detects existing isolation. Step 3a defers to native tools. - **Fix:** Step 0 detects existing isolation. Step 1a defers to native tools.
### Skipping detection ### Skipping detection
- **Problem:** Creating a nested worktree inside an existing one - **Problem:** Creating a nested worktree inside an existing one
- **Fix:** Always run Step 1 before creating anything - **Fix:** Always run Step 0 before creating anything
### Skipping ignore verification ### Skipping ignore verification
@@ -240,19 +197,18 @@ Ready to implement <feature-name>
## Red Flags ## Red Flags
**Never:** **Never:**
- Create a worktree without the user explicitly asking for one - Stop to ask the user for consent when the skill has already been invoked. Invoking the skill IS the request — treat it as your authorization to proceed.
- Create a worktree when Step 1 detects existing isolation - Fall back to a plain feature branch because a native worktree tool feels "restricted to explicit user requests." Skill invocation is the explicit request the tool requires.
- Create a worktree when Step 0 detects existing isolation
- Use `git worktree add` when you have a native worktree tool (e.g., `EnterWorktree`). This is the #1 mistake — if you have it, use it. - Use `git worktree add` when you have a native worktree tool (e.g., `EnterWorktree`). This is the #1 mistake — if you have it, use it.
- Skip Step 3a by jumping straight to Step 3b's git commands - Skip Step 1a by jumping straight to Step 1b's git commands
- Create worktree without verifying it's ignored (project-local) - Create worktree without verifying it's ignored (project-local)
- Skip baseline test verification - Skip baseline test verification
- Proceed with failing tests without asking - Proceed with failing tests without asking
- Infer worktree consent from the task description or plan — only an explicit user request counts
**Always:** **Always:**
- Run Step 1 detection first - Treat skill invocation as implicit authorization to create a worktree
- Default to working in place (Step 2 → Step 4) - Run Step 0 detection first
- Only create a worktree after explicit user request
- Prefer native tools over git fallback - Prefer native tools over git fallback
- Follow directory priority: existing > global legacy > instruction file > default - Follow directory priority: existing > global legacy > instruction file > default
- Verify directory is ignored for project-local - Verify directory is ignored for project-local
@@ -262,9 +218,9 @@ Ready to implement <feature-name>
## Integration ## Integration
**Called by:** **Called by:**
- **subagent-driven-development** - Calls this to detect the workspace and optionally set up worktree isolation on request - **subagent-driven-development** - Ensures isolated workspace (creates one or verifies existing)
- **executing-plans** - Calls this to detect the workspace and optionally set up worktree isolation on request - **executing-plans** - Ensures isolated workspace (creates one or verifies existing)
- Any skill that may use worktree isolation - Any skill needing isolated workspace
**Pairs with:** **Pairs with:**
- **finishing-a-development-branch** - REQUIRED for cleanup after work complete - **finishing-a-development-branch** - REQUIRED for cleanup after work complete

View File

@@ -84,8 +84,8 @@ BRANCH=$(git branch --show-current)
- `GIT_DIR != GIT_COMMON` → already in a linked worktree (skip creation) - `GIT_DIR != GIT_COMMON` → already in a linked worktree (skip creation)
- `BRANCH` empty → detached HEAD (cannot branch/push/PR from sandbox) - `BRANCH` empty → detached HEAD (cannot branch/push/PR from sandbox)
See `using-git-worktrees` Step 1 and `finishing-a-development-branch` See `using-git-worktrees` Step 0 and `finishing-a-development-branch`
Step 2 for how each skill uses these signals. Step 1 for how each skill uses these signals.
## Codex App Finishing ## Codex App Finishing