| name | recursive-worktree |
| description | Use when starting any recursive-mode requirement to set up an isolated git worktree. Required before implementation phases: create an isolated workspace, verify a clean baseline, and keep main/master clean. |
recursive-worktree
Purpose
Use this skill at the start of a recursive-mode run to set up an isolated worktree before Phase 1+ work begins.
The canonical overall workflow still lives in /.recursive/RECURSIVE.md. This skill covers only the worktree-isolation discipline for 00-worktree.md.
Hard Rule
Do not proceed with recursive-mode phase work until:
- A feature-branch worktree exists.
- The worktree directory is git-ignored if it lives inside the repo.
- Project setup has completed.
- A clean or explicitly acknowledged baseline test state has been recorded.
Default Location Order
Use this priority:
- Existing
.worktrees/
- Existing
worktrees/
- A preference documented in repo instructions
- Ask the user
- Default to
.worktrees/
Global fallback location:
~/.config/recursive-mode/worktrees/<project-name>/
Main Branch Protection
If the current branch is main or master, default to creating a worktree on a feature branch:
git worktree add .worktrees/<run-id> -b recursive/<run-id>
cd .worktrees/<run-id>
If the user explicitly insists on main-branch work, record that exception in 00-worktree.md.
Minimum Phase 0 Checklist
00-worktree.md must cover:
- selected worktree location
- git-ignore verification
- branch name and worktree path
- setup commands executed
- baseline test command and result
- normalized diff basis fields including
Baseline type, Baseline reference, Comparison reference, Normalized baseline, Normalized comparison, and Normalized diff command
- explicit note that subsequent phases run from the worktree
- the required
## TODO heading from the scaffold
Suggested Commands
Check branch:
git branch --show-current
Check ignore status:
git check-ignore -q .worktrees || git check-ignore -q worktrees
Create worktree:
git worktree add .worktrees/<run-id> -b recursive/<run-id>
Setup Guidance
Run the setup command that matches the repo:
- Node.js:
npm install
- Rust:
cargo build
- Python:
pip install -r requirements.txt or project-specific install
- Go:
go mod download
- Maven:
mvn compile -q
- Gradle:
./gradlew compileJava
- .NET:
dotnet restore
Then run the baseline test command appropriate to the project and record the result in 00-worktree.md.
Router State In Worktrees
Before delegated or routed work runs from an isolated worktree, verify the router files inside that same worktree:
test -f .recursive/config/recursive-router.json
test -f .recursive/config/recursive-router-discovered.json
Test-Path .recursive/config/recursive-router.json
Test-Path .recursive/config/recursive-router-discovered.json
If the controller/source repo has a configured router policy or discovery inventory and the worktree lacks it, sync both files into the worktree before resolving or invoking routed roles. Preserve user edits to the worktree policy; when changing bindings, prefer recursive-router-configure over hand edits.
recursive-router-discovered.json is local discovery state and may be untracked. Its absence in a fresh worktree is expected, but it is still not safe to resolve an external role from stale assumptions. Refresh it with python ./scripts/recursive-router-probe.py --repo-root . --json from the worktree, or copy the current inventory from the controller/source repo when that is the intended policy basis.
Record the router policy path, discovery path, validation/probe command, and resulting route decision in 00-worktree.md or in the delegated action record before accepting routed work.
Output Contract
Write the artifact to:
/.recursive/run/<run-id>/00-worktree.md
Use feature branches named:
Routing Awareness
If this skill uses delegated review or any other routed external model to validate worktree setup, baseline verification, or branch safety, re-read:
/.recursive/config/recursive-router.json
/.recursive/config/recursive-router-discovered.json
immediately before choosing that CLI/model, and honor the routed policy or explicit fallback instead of hardcoding a reviewer model.
Integration
- Invoke this skill before AS-IS analysis and planning.
- After Phase 0 is lock-valid, continue the run from the worktree context.
- Keep later phases, including
STATE.md, DECISIONS.md, and memory updates, on the same feature branch until merge time.