using-git-worktrees: $LOCATION and $BRANCH_NAME used in Step 1 code block without prior assignment

[specterslient95-lgtm]

skills/using-git-worktrees/SKILL.md Step 1 includes a "Create the Worktree" code block that uses $LOCATION and $BRANCH_NAME shell variables without either documenting them as agent-supplied placeholders or showing assignment lines:

# Determine path based on chosen location
path="$LOCATION/$BRANCH_NAME"

git worktree add "$path" -b "$BRANCH_NAME"
cd "$path"

Neither variable is assigned earlier in the SKILL.md, and there is no preceding line of the form LOCATION=... / BRANCH_NAME=.... An agent reading the workflow and executing the block verbatim ends up running git worktree add "/" -b "" (both vars empty), which fails with an empty-branch-name error.

The earlier prose (lines 60–76) does discuss how to pick a location and the implicit branch name, but the variables in the code block are presented as if already in scope.

Suggested fix

Prepend explicit assignment lines so the block is runnable:

# Use the LOCATION you chose above (e.g., ".worktrees" or a project-specific path)
LOCATION="<chosen-location>"
# Use BRANCH_NAME based on the task (e.g., "feat-add-login")
BRANCH_NAME="<chosen-branch-name>"

# Determine path based on chosen location
path="$LOCATION/$BRANCH_NAME"

git worktree add "$path" -b "$BRANCH_NAME"
cd "$path"

Or, if the intent is for the agent to fill the variables before pasting the block, document that explicitly above the code fence (e.g., "Agent fills: LOCATION = …, BRANCH_NAME = …").

[specterslient95-lgtm]

Pull request: #1801

[obra]

@specterslient95-lgtm - Did you hit this in the field or did you find it by inspection?

[specterslient95-lgtm]

By inspection. Here's a clean trigger so it's grounded — three scenarios, run against a fresh git repo with env -i to keep the env hermetic.

1. Both vars unset (loudest mode, but still leaves the agent in /)

$ env -i HOME=$HOME PATH=$PATH bash -c '
    path="$LOCATION/$BRANCH_NAME"
    git worktree add "$path" -b "$BRANCH_NAME"
    cd "$path"
    echo "ended_up_at: $(pwd)"
  '
Preparing worktree (new branch '')
fatal: '' is not a valid branch name
ended_up_at: /

git worktree add fails, but the block has no set -e, so cd "$path" (which expands to cd "/") still runs. The agent's shell is now at filesystem root, and every subsequent step (npm install, cargo build, git status) executes there.

2. One var inherited from a parent shell / prior skill / .envrc

$ env -i HOME=$HOME PATH=$PATH LOCATION=".worktrees" bash -c '<block>'
Preparing worktree (new branch '')
fatal: '' is not a valid branch name
bash: line 6: cd: .worktrees/: No such file or directory

Loud, but git's bookkeeping was already touched with an invalid branch name.

3. Both vars carry stale values from a prior step — silent corruption

$ env -i HOME=$HOME PATH=$PATH \
    LOCATION="/tmp/stale-loc" BRANCH_NAME="stale-branch" bash -c '<block>'
Preparing worktree (new branch 'stale-branch')
HEAD is now at d89bb8d init
ended_up_at: /tmp/stale-loc/stale-branch
on branch:   stale-branch

Zero errors. The agent silently lands in an unrelated worktree on an unrelated branch and starts editing files there, convinced it set up a fresh workspace for the current task. This is the mode that worries me — there's no way for the agent to notice.

The two-line fix in #1801 (explicit LOCATION= / BRANCH_NAME= assignment before the block) closes all three.

[obra]

I'm pretty sure this is agentic spam. This is a first-principles argument without proof that it has ever failed in the field. Can anyone provide an example of a time the agent couldn't get this right?