feat: establish feature worktree guidelines across agents and skills

.codex/skills/feature-ideation/SKILL.md

@@ -37,6 +37,8 @@ Treat the user's clear statement that they are ready to work on the discussed, s
 
 ## Stage 3: Write and hand off the brief
 
-Once the user is ready and the phase number is known, have Designer create the accepted product/design brief at `docs/plans/phase_<number>_<feature_slug>.md`, following `docs/plans/README.md`. The brief should cover the goal and audience, desired child outcome, behavior/flow and feedback, story or directing value where relevant, success criteria, included and excluded scope, known risks/dependencies, project references, and remaining questions for the spec-pipeline. Keep architecture/API decisions for the architect's later technical specification in `docs/specs/`.
+Once the user is ready and the phase number is known, establish or reuse a dedicated feature worktree before writing the brief, following the `Feature branches and worktrees` rules in `AGENTS.md`. Use that same branch for the brief, later specs, implementation, and verification. Pass the absolute worktree path and branch name to Designer and ensure the brief and backlog update are written there. Do not switch or write into the shared checkout to prepare the brief.
+
+Have Designer create the accepted product/design brief at `docs/plans/phase_<number>_<feature_slug>.md`, following `docs/plans/README.md`. The brief should cover the goal and audience, desired child outcome, behavior/flow and feedback, story or directing value where relevant, success criteria, included and excluded scope, known risks/dependencies, project references, and remaining questions for the spec-pipeline. Keep architecture/API decisions for the architect's later technical specification in `docs/specs/`.
 
 Do not overwrite an existing phase brief without the user's direction. Confirm the resulting file exists, update the matching backlog entry to `Planned` with a link to the brief, then tell the user where the plan is using a clickable local file link. Stop there; this skill creates the design handoff, not the technical spec or implementation.

.codex/skills/spec-pipeline/SKILL.md

@@ -5,6 +5,14 @@ description: "Stickman Studio feature workflow: UI/UX and architecture specs, im
 
 ## Execution Logic
 
+### Feature branch and worktree setup
+
+For every new feature or phase that will produce project files, use one dedicated feature branch and worktree from the first persistent artifact through implementation and verification. Read-only proposals can happen before the worktree is created; create or reuse it before the first UI spec, architecture spec, design brief, asset candidate, code change, or other feature file is written.
+
+Follow the `Feature branches and worktrees` rules in `AGENTS.md`: inspect the current branch and worktree list, reuse a matching feature worktree when present, otherwise create `.worktrees/<feature-slug>` on `feature/<feature-slug>` from the integration branch. Include the phase number in the slug when known. Do not switch the user's shared checkout, transfer uncommitted changes without direction, or merge automatically.
+
+Pass the absolute worktree path and branch name to every delegated agent, and tell each agent to use that path for all repository reads, writes, Godot runs, and visual checks. If a delegated agent cannot target the supplied worktree, stop its file-writing work and report the issue to the orchestrator.
+
 1. **Phase 0a: UI/UX Proposal & Alternative Ideas (User-Facing Features Only)**
    - `@uiux` analyzes the user's initial idea for cognitive friction, accessibility, and kid-friendliness.
    - Before proposing, mocking, reviewing, or suggesting UI/UX changes, `@uiux` reads `docs/guides/editor_visual_style_guide.md` and checks the relevant implemented controls/specs. Treat the guide as the current visual baseline; distinguish implemented behavior from recommendations and explain intentional departures. This also applies to direct `@uiux` requests outside the pipeline.