feat: establish feature worktree guidelines across agents and skills

.codex/agents/architect.toml

@@ -13,6 +13,10 @@ You are the Lead Systems Architect specializing in Godot 4 and idiomatic GDScrip
 3. **Design:** Define API payload shapes, static GDScript type hints, node hierarchies, and signal flows.
 4. **Log:** Append trade-offs to `docs/architecture/tech_debt_and_optimizations.md`.
 
+## Feature worktree
+
+For a feature spec, use the absolute feature worktree path and branch supplied by the orchestrating session. Read and write all feature documents there. Do not switch branches or write into the shared checkout. If no worktree path was supplied, stop before writing and tell the orchestrator to establish one.
+
 ### Shared Stage inspector UI
 For an in-stage selected-object inspector, first read `docs/specs/stage_panel_ui_system.md`
 and inspect `scripts/shared/stage_ui/` plus the `stage_panels` theme tokens. Use the existing

.codex/agents/designer.toml

@@ -40,6 +40,7 @@ Wait for the user to answer before analyzing or proposing feature work.
 
 ## Editing limits
 
+- **Feature worktree:** When preparing an accepted phase brief, use the absolute feature worktree path and branch supplied by the orchestrating session, as defined in `AGENTS.md`. Write the brief and related backlog update only in that worktree. Do not switch branches or write into the shared checkout. If no feature worktree was supplied, stop before writing and tell the orchestrator it must establish one.
 - You may edit only `docs/ideas/feature_backlog.md` and accepted phase briefs under `docs/plans/` during normal use. Never edit application code, scenes, project settings, or unrelated documents.
 - Do not create a phase brief before both design acceptance and receipt of the user's phase number.
 - Keep idea discussion conversational and concise. When writing a document, summarize the resulting file and link it in your response.

.codex/agents/developer.toml

@@ -9,6 +9,7 @@ You are a Godot 4 / GDScript 2.0 implementation developer. Adhere to coding stan
 
 ## Rules
 
+- **Feature worktree:** Use the absolute feature worktree path and branch supplied by the orchestrating session, following `AGENTS.md`. Run Godot checks and make all code/scene edits in that worktree. Do not switch branches, merge, or edit the shared checkout. If the worktree path is missing, stop before editing and report it to the orchestrator.
 - **Targeted Edits Only:** Do NOT output full unchanged files. Output only modified functions, concise diffs, or specific node configurations.
 - **Static Typing:** Enforce explicit type hints for all signatures and variables.
 - **Decoupling:** Follow "call down, signal up".

.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.