using-worktrees — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited using-worktrees (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Git worktrees create isolated workspaces sharing the same repository, allowing work on multiple branches simultaneously without switching.
Core principle: Systematic directory selection + safety verification = reliable isolation.
This skill covers git worktree setup, lifecycle, and known limitations for rageatc-code-oss workflows. It does NOT cover process-level isolation (Docker sandboxes), CI/CD pipeline isolation, or worktree usage outside of chunk-based development.
The orchestrator creates and manages worktrees manually using git worktree add, then points developer-agents to the worktree directory.
Why manual, not automated: Claude Code's isolation: "worktree" option creates a fresh worktree per agent spawn with an opaque branch name. The manual approach keeps the lifecycle with the orchestrator — setup (baseline tests, .gitignore checks) runs in the worktree before the agent launches, review iterations reuse the same worktree across developer invocations, and branches are named after chunks. The Feb 2026 bugs that originally forced this choice were re-verified fixed on 2026-07-04; see Known Limitations.
Orchestrator:
1. git worktree add <path> -b <branch>
2. Run setup in worktree
3. Launch developer-agent pointed at worktree path
4. After review + accept: merge branch, remove worktreeFollow this priority order:
ls -d .worktrees 2>/dev/null # Preferred (hidden)
ls -d worktrees 2>/dev/null # AlternativeIf found: Use that directory. If both exist, .worktrees wins.
grep -i "worktree.*director" CLAUDE.md 2>/dev/nullIf preference specified: Use it.
If no directory exists and no CLAUDE.md preference:
No worktree directory found. Where should I create worktrees?
Recommended: .worktrees/ (project-local, hidden)MUST verify before creating any project-local worktree:
git check-ignore -q .worktrees 2>/dev/nullIf NOT ignored:
.worktrees/ to .gitignoreWhy critical: Prevents accidentally committing worktree contents to repository.
# Name branch after chunk for traceability
git worktree add .worktrees/chunk-003 -b chunk-003/recipe-serviceAuto-detect and run appropriate setup:
# Node.js
if [ -f package.json ]; then npm install; fi
# Rust
if [ -f Cargo.toml ]; then cargo build; fi
# Python
if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
if [ -f pyproject.toml ]; then poetry install; fi
# Go
if [ -f go.mod ]; then go mod download; fiRun tests to ensure worktree starts clean:
# Use project-appropriate command
npm testIf tests fail: Report failures, ask whether to proceed or investigate.
If tests pass: Worktree is ready for the developer-agent.
Orchestrator launches developer-agent with the worktree path as the working directory.
# Merge the chunk branch back to main
git checkout main
git merge chunk-003/recipe-service
# Clean up
git worktree remove .worktrees/chunk-003
git branch -d chunk-003/recipe-service# Discard the worktree — main is untouched
git worktree remove --force .worktrees/chunk-003
git branch -D chunk-003/recipe-serviceClaude Code's isolation: "worktree" option, re-verified empirically 2026-07-04 (original reports Feb 2026, GitHub #29110):
git commit without permission failures. (Original bug: permissionMode: "bypassPermissions" was ineffective.)worktree-agent-{hash}); manual creation names branches after chunks.Automated isolation is now viable for one-shot parallel tasks. This skill keeps the manual approach for chunk builds because the review loop needs an orchestrator-controlled lifecycle: pre-launch setup, one worktree shared across developer iterations, and chunk-named branches.
| Scenario | Recommendation |
|---|---|
| Quick workflow (1-3 files) | Branch — simpler, no setup overhead |
| Standard workflow (sequential chunks) | Worktree per chunk — isolation without switching |
| Thorough workflow (parallel chunks) | Worktree per chunk — enables true parallelism |
| Single developer, small project | Branch may suffice — worktree overhead not always justified |
Never:
isolation: "worktree" with permissionMode: "bypassPermissions" (broken)isolation: "worktree" with background: true (ignored)Always:
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.