feat: update worktree guidelines for agents and skills to confirm user preferences before creating worktrees

AGENTS.md

@@ -8,12 +8,12 @@
 
 ## Feature branches and worktrees
 
-- Start each new feature or phase that will create project files in a dedicated Git branch and worktree. Use the same branch from its design brief and specs through implementation and verification, so parallel features stay isolated.
-- Read-only discussion and proposals do not need a worktree. Before the first persistent feature change, inspect `git status --short`, `git branch --show-current`, and `git worktree list`.
-- If the current checkout is already the matching feature worktree, continue there. Otherwise, create a new worktree at `.worktrees/<feature-slug>` with branch `feature/<feature-slug>`, based on the integration branch (usually `main`). Include the phase number in the slug when known, such as `phase-20-stage-search`.
-- Example from the repository root: `git worktree add .worktrees/phase-20-stage-search -b feature/phase-20-stage-search main`. Confirm the resulting path and branch with `git worktree list` and `git branch --show-current`.
-- Reuse an existing worktree for the same feature. Do not switch branches in the user's current checkout, overwrite an existing path/branch, stash, reset, clean, or move uncommitted work. If relevant uncommitted changes need to be carried into the feature worktree, ask how to handle them before proceeding.
-- Pass the absolute worktree path and branch name to every subagent. All project reads, writes, Godot commands, and visual checks for the feature must target that worktree. If no worktree path was supplied, do not write feature files in the shared checkout; tell the orchestrator what is missing.
+- Before creating a Git worktree for a task, ask the user whether they want this task to use one. Do not create a worktree until they answer. For small, self-contained fixes and documentation changes, offer the current checkout as the default; for larger feature phases, explain why a worktree may help and let the user choose.
+- Read-only discussion and proposals do not need a worktree. Before the first persistent change, inspect `git status --short`, `git branch --show-current`, and `git worktree list`.
+- If the user chooses the current checkout, keep working on its current branch. Do not switch branches, stash, reset, clean, move, or overwrite unrelated work.
+- If the user chooses a worktree, reuse a matching one when present. Otherwise, create `.worktrees/<feature-slug>` with branch `feature/<feature-slug>`, based on the integration branch (usually `main`). Include the phase number in the slug when known, such as `phase-20-stage-search`. Example: `git worktree add .worktrees/phase-20-stage-search -b feature/phase-20-stage-search main`. Confirm the path and branch with `git worktree list` and `git branch --show-current`.
+- If relevant uncommitted changes need to be carried into a chosen worktree, ask how to handle them before proceeding.
+- Pass every subagent the absolute path and branch the user chose, whether that is a worktree or the current checkout. All project reads, writes, Godot commands, and visual checks must target that path. Do not require a worktree when the user chose the current checkout.
 - Do not merge feature branches automatically. Keep each feature branch available for review and merge only when the user asks or the active workflow explicitly authorizes it.
 - `.worktrees/` is a local worktree container and must remain gitignored.