implement-spec: isolated implementer worktrees branch from the default branch and trip Claude Code's isolation checks

### Skill `implement-spec` ### Harness and version Claude Code 2.1.310, the `mattpocock-skills` plugin from `claude-plugins-official`, skills 1.3.1 ### Model and effort The orchestrator ran on Opus 5.5 at high effort. Each implementer was a fresh Sonnet 5.5 subagent, also at high effort, so its context was nearly empty when the refusals began. ### What happened I ran a 23-ticket spec with up to four implementers at once. Step 4 started each one in a worktree-isolated subagent (`isolation: "worktree"`). Claude Code's [worktree isolation checks](https://code.claude.com/docs/en/worktrees#how-claude-code-enforces-isolation) then refused ordinary shell commands throughout the run: - **Coverage:** all 26 isolated subagents hit at least one refusal. - **Rate:** 174 of their 1,560 Bash calls were refused. - **Cost:** each refusal cost a turn to rewrite the command, and some subagents gave up on a technique entirely. For example, they stopped writing files with heredocs. - **Control:** the merger subagents worked in the main checkout without isolation and ran git freely. None of their commands was refused. What the refused commands were doing: | What the implementer was doing | Refused | |---|---| | Writing a file, or feeding a script to an interpreter, via heredoc | 61 | | Looping over files (`for`, `xargs`) with `sed`/`yq`/git | 47 | | Step 4's base check, reset, and merging the integration tip (`git merge-base --is-ancestor HEAD; echo $?`) | 28 | | Reading `$?` after a command, with git elsewhere in the line | 18 | | Other | 20 | A typical refusal: ```text This agent is isolated in the worktree …/.claude/worktrees/agent-a0adf7fbe8a782508, but this command names git in a form too complex to verify that it stays inside the worktree. Refusing to run it — a worktree-isolated agent's git operations must target its own worktree. Split it into plain, separate commands and run them from …/.claude/worktrees/agent-a0adf7fbe8a782508. ``` The base check failed almost every time it ran, as the agents phrased it. A command with `$?` and git anywhere in it was refused 41 times out of 43, and the same command without git 0 times out of 25. At least two worktrees really did start off the integration branch and needed the reset. Both problems come from step 4 using isolated worktrees for work on an existing branch. The Claude Code docs say that combination doesn't work: - Subagent worktrees branch from the default branch unless `worktree.baseRef` is `"head"`, and `baseRef` [can't name a branch](https://code.claude.com/docs/en/worktrees#choose-the-base-branch): "To start a worktree from a specific existing branch, create it with git directly." - The isolation checks apply only to sessions Claude Code isolated itself, and the command-shape check "can't be turned off". So the skill makes each implementer fix up its own base with git, inside a session whose checks refuse that kind of command and most ordinary shell besides. `implement` is not affected. It works in the current session on the current branch. ### What you expected Step 4 should do what the docs say to do for a specific existing branch: the orchestrator creates each implementer's worktree with git, on the integration branch, and starts the implementer in it without worktree isolation. Then: - every worktree starts at the integration tip; - implementers have no base check or reset to do; - none of the isolation checks apply. Proposed wording: ```text 4. Use **implementer subagents** to implement each ticket, each in its own worktree on its own branch. Create the worktree yourself, outside the repo, at the integration tip: `git worktree add -b `. Start the implementer without worktree isolation, and tell it to work only in ` `. Each implementer subagent: - calls the Skill tool with `tdd` to build the ticket; - merges the integration branch tip into its own branch before reporting done 9. Clean up all **implementer subagent** worktrees with `git worktree remove `. Claude Code's periodic sweep never removes worktrees created with git. ``` The trade-off is that nothing mechanical stops an implementer from editing the main checkout. The brief's "work only in ` `" carries that. Since #943 already argues that isolation can't be unconditional, a brief that pins the working directory seems the better default. Related: #943 (worktrees lack gitignored material) and #1251 (step 9 cleanup). This is a third way the isolated-worktree assumption in step 4 breaks.