Compare commits

...

7 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
Drew Ritter
e3dd3b4c5a fix: replace hardcoded /Users/jesse with generic placeholders (#858) 2026-04-13 16:29:59 -07:00
Drew Ritter
e4a15b6d52 docs: drop instruction file enumeration per PR #1121 review
Jesse flagged that the verbose CLAUDE.md/AGENTS.md/GEMINI.md/.cursorrules
enumeration (a) chews tokens, (b) confuses models that anchor on exact
strings, and (c) is repeated DRY-violatingly across 3+ locations.

Replace with abstract "your instructions" framing in four spots:
- skills/using-git-worktrees/SKILL.md Step 0 → Step 1 transition
- skills/using-git-worktrees/SKILL.md Step 1b Directory Selection
- docs/superpowers/plans/2026-04-06-worktree-rototill.md (both mirror locations)

Same intent, harness-agnostic phrasing, ~half the tokens.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-13 16:29:44 -07:00
Drew Ritter
998c40be29 docs: soften Step 1a native-tool framing per PR #1121 review
Address obra's comment on explicit step numbers / prescriptive tone.
Drops "STOP HERE if available", the "If YES:" gate, and the "even if /
even if / NO EXCEPTIONS" reinforcement paragraph. Keeps the specific
tool-name anchors (EnterWorktree, WorktreeCreate, /worktree, --worktree),
which the original TDD data showed are load-bearing.

A/B verified against drill harness on the 3 creation/consent scenarios
(consent-flow, creation-from-main, creation-from-main-spec-aware):
baseline explicit wording scored 12/12 criteria, softened wording also
scored 12/12. The "agent used the most appropriate tool" criterion
passed in all 3 softened runs — agents still picked EnterWorktree via
ToolSearch without the imperative framing.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-13 11:43:45 -07:00
Drew Ritter
98263ce179 docs: address PR #1121 review — respect user preference, drop y/n
- Consent prompt: drop "(y/n)" and add escape valve for users who
  have already declared their worktree preference in global or
  project agent instruction files.
- Directory selection: reorder to put declared user preference
  ahead of observed filesystem state, and reframe the default as
  "if no other guidance available".
- Sandbox fallback: require explicitly informing the user that
  the sandbox blocked creation, not just "report accordingly".
- writing-plans: fully qualify the superpowers:using-git-worktrees
  reference.
- Plan doc: mirror the consent-prompt change.

Step 1a native-tool framing and the helper-scripts suggestion are
still outstanding — the first needs a benchmark re-run before softer
phrasing can be adopted without regressing compliance; the second is
exploratory and will get a thread reply.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-13 09:53:08 -07:00
6 changed files with 28 additions and 25 deletions

View File

@@ -249,11 +249,13 @@ 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. Ask for consent before creating a workspace:
**If `GIT_DIR == GIT_COMMON` (or in a submodule):** You are in a normal repo checkout.
> "Would you like me to set up an isolated worktree? This protects your current branch from changes. (y/n)"
Has the user already indicated their worktree preference in your instructions? If not, ask for consent before creating a worktree:
If yes, proceed to Step 1. If no, work in place — skip to Step 3 with no 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 3.
## Step 1: Create Isolated Workspace
@@ -287,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/`.**

View File

@@ -149,8 +149,8 @@ python3 tests/claude-code/analyze-token-usage.py ~/.claude/projects/<project-dir
Session transcripts are stored in `~/.claude/projects/` with the working directory path encoded:
```bash
# Example for /Users/jesse/Documents/GitHub/superpowers/superpowers
SESSION_DIR="$HOME/.claude/projects/-Users-jesse-Documents-GitHub-superpowers-superpowers"
# Example for /Users/yourname/Documents/GitHub/superpowers/superpowers
SESSION_DIR="$HOME/.claude/projects/-Users-yourname-Documents-GitHub-superpowers-superpowers"
# Find recent sessions
ls -lt "$SESSION_DIR"/*.jsonl | head -5

View File

@@ -4,7 +4,7 @@ Reference example of extracting, structuring, and bulletproofing a critical skil
## Source Material
Extracted debugging framework from `/Users/jesse/.claude/CLAUDE.md`:
Extracted debugging framework from `~/.claude/CLAUDE.md`:
- 4-phase systematic process (Investigation → Pattern Analysis → Hypothesis → Implementation)
- Core mandate: ALWAYS find root cause, NEVER fix symptoms
- Rules designed to resist time pressure and rationalization

View File

@@ -33,7 +33,7 @@ digraph when_to_use {
### 1. Observe the Symptom
```
Error: git init failed in /Users/jesse/project/packages/core
Error: git init failed in ~/project/packages/core
```
### 2. Find Immediate Cause

View File

@@ -36,11 +36,9 @@ 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. Ask for consent before creating a workspace:
**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.
> "Would you like me to set up an isolated worktree? This protects your current branch from changes. (y/n)"
If yes, proceed to Step 1. If no, work in place — skip to Step 3 with no worktree.
**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.
## Step 1: Create Isolated Workspace
@@ -48,13 +46,13 @@ If yes, proceed to Step 1. If no, work in place — skip to Step 3 with no workt
### 1a. Native Worktree Tools (preferred — STOP HERE if available)
The user has asked for an isolated workspace (Step 0 consent). Check your available tools — do you have `EnterWorktree`, `WorktreeCreate`, a `/worktree` command, or a `--worktree` flag? **If YES: the user's consent to create a worktree is your authorization to use it. Use it now and skip to Step 3.**
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.
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 worktrees it didn't create, and cleanup becomes impossible.
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.
**Even if `.worktrees/` already exists, even under time pressure, even if `git worktree add` feels faster — use your native tool.** There are no exceptions.
**Even if `.worktrees/` already exists, even under time pressure, even if `git worktree add` feels faster — use your native tool.** No exceptions.
**Only proceed to Step 1b if you have confirmed you have NO native worktree/isolation tool.**
Only proceed to Step 1b if you have confirmed you have NO native worktree tool available.
### 1b. Git Worktree Fallback
@@ -62,25 +60,25 @@ Native tools handle directory placement, branch creation, and cleanup automatica
#### Directory Selection
Follow this priority order:
Follow this priority order. Explicit user preference always beats observed filesystem state.
1. **Check existing directories:**
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 that directory. If both exist, `.worktrees` wins.
If found, use it. If both exist, `.worktrees` wins.
2. **Check for existing global directory:**
3. **Check for an existing global directory:**
```bash
project=$(basename "$(git rev-parse --show-toplevel)")
ls -d ~/.config/superpowers/worktrees/$project 2>/dev/null
```
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.
4. **Default to `.worktrees/`.**
4. **If there is no other guidance available**, default to `.worktrees/` at the project root.
#### Safety Verification (project-local directories only)
@@ -109,7 +107,7 @@ git worktree add "$path" -b "$BRANCH_NAME"
cd "$path"
```
**Sandbox fallback:** If `git worktree add` fails with a permission error (sandbox denial), treat this as a restricted environment. Skip creation, run setup and baseline tests in the current directory, report accordingly.
**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 3: Project Setup
@@ -199,6 +197,8 @@ Ready to implement <feature-name>
## Red Flags
**Never:**
- 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.
- 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.
- Skip Step 1a by jumping straight to Step 1b's git commands
@@ -207,6 +207,7 @@ Ready to implement <feature-name>
- Proceed with failing tests without asking
**Always:**
- Treat skill invocation as implicit authorization to create a worktree
- Run Step 0 detection first
- Prefer native tools over git fallback
- Follow directory priority: existing > global legacy > instruction file > default

View File

@@ -13,7 +13,7 @@ Assume they are a skilled developer, but know almost nothing about our toolset o
**Announce at start:** "I'm using the writing-plans skill to create the implementation plan."
**Context:** If working in an isolated worktree, it should have been created via the using-git-worktrees skill at execution time.
**Context:** If working in an isolated worktree, it should have been created via the `superpowers:using-git-worktrees` skill at execution time.
**Save plans to:** `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md`
- (User preferences for plan location override this default)