Problem
The improve execute <plan> workflow requires an isolated disposable git worktree for execution and verification, but the skill does not appear to specify where that worktree should be created.
In VS Code-style agent environments, if the worktree is created as a sibling of the workspace root, for example:
/path/project-exec-002/path/project-js-store-exec-002
then subsequent file reads, edits, builds, tests, and git commands operate outside the opened workspace. Some agents treat that as outside-workspace access and trigger repeated approval prompts, even though the worktree is disposable and belongs to the same repo/task.
Current Behavior
The skill requires an isolated worktree, but leaves the filesystem location to the host agent/model. This can lead agents to create sibling folders outside the workspace root.
Expected Behavior
By default, disposable execution worktrees should be created under a repo-local, ignored directory inside the current workspace, so agent tools still operate within the approved workspace boundary.
For example:
plans/
README.md
002-some-plan.md
.worktrees/
002-some-plan/
or:
plans/
.improve/
worktrees/
002-some-plan/
For nested repositories, the same workspace-local location could include the repo name:
plans/.worktrees/js-store-002-selected-period-low-utilisation/
Potential Solution
Update the execute instructions to recommend a deterministic, workspace-local disposable worktree path, such as:
plans/.worktrees/<plan-id>-<slug>/
and have the skill create or maintain an ignore rule for that directory, for example:
or:
plans/.improve/worktrees/
The skill should still preserve the current safety properties:
- executor edits happen only in the isolated git worktree
- advisor never edits source directly
- worktree path and branch are reported in the verdict
- nested repos are supported by including the nested repo name in the worktree folder name
- disposable worktree folders are ignored by the parent repo so they do not pollute git status
Why This Helps
Keeping disposable worktrees inside the workspace root reduces approval friction in agents that distinguish between workspace and outside-workspace filesystem access, while preserving the isolation benefits of git worktree.
It also makes cleanup and reconciliation easier because all improve-generated artifacts live under the existing plans folder.
Problem
The
improve execute <plan>workflow requires an isolated disposable git worktree for execution and verification, but the skill does not appear to specify where that worktree should be created.In VS Code-style agent environments, if the worktree is created as a sibling of the workspace root, for example:
/path/project-exec-002/path/project-js-store-exec-002then subsequent file reads, edits, builds, tests, and git commands operate outside the opened workspace. Some agents treat that as outside-workspace access and trigger repeated approval prompts, even though the worktree is disposable and belongs to the same repo/task.
Current Behavior
The skill requires an isolated worktree, but leaves the filesystem location to the host agent/model. This can lead agents to create sibling folders outside the workspace root.
Expected Behavior
By default, disposable execution worktrees should be created under a repo-local, ignored directory inside the current workspace, so agent tools still operate within the approved workspace boundary.
For example:
or:
For nested repositories, the same workspace-local location could include the repo name:
plans/.worktrees/js-store-002-selected-period-low-utilisation/Potential Solution
Update the execute instructions to recommend a deterministic, workspace-local disposable worktree path, such as:
plans/.worktrees/<plan-id>-<slug>/and have the skill create or maintain an ignore rule for that directory, for example:
plans/.worktrees/or:
plans/.improve/worktrees/The skill should still preserve the current safety properties:
Why This Helps
Keeping disposable worktrees inside the workspace root reduces approval friction in agents that distinguish between workspace and outside-workspace filesystem access, while preserving the isolation benefits of git worktree.
It also makes cleanup and reconciliation easier because all improve-generated artifacts live under the existing plans folder.