com um clique
using-git-worktrees
Isolates each task in its own git worktree off main.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Menu
Isolates each task in its own git worktree off main.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Flags risky shell commands and unsafe tree ops.
Detects high-confidence security risks in code.
Surfaces the dojo's non-negotiable prime directives.
Activates the dojo framework at the start of a session.
Plans multi-step work before writing code.
Captures lessons and promotes recurring patterns.
| name | using-git-worktrees |
| description | Isolates each task in its own git worktree off main. |
| tier | practical |
| category | workflow |
| created_by | human |
| platforms | ["windows","macos","linux"] |
| tags | ["git","worktree","isolation"] |
| author | Andreas Wasita (@andreaswasita) |
Creates an isolated git worktree on a dedicated feature branch for every development task, so main is never touched until finishing-a-development-branch says so. Does NOT replace feature branches when worktrees are impractical (CI, single-file fix) — the isolation principle is what matters.
main.brainstorming produces an approved design.git ≥ 2.5 with worktree support.powershell Copilot tool to run git.feature/*, fix/*, experiment/*.npm install, pip install -r requirements.txt, etc.).1. From the main repo root, create the worktree with a new branch.
2. Change into the worktree directory.
3. Install dependencies inside it.
4. Confirm a green test baseline.
5. Work only inside the worktree — never touch the main worktree.
| Operation | Command |
|---|---|
| Create | git worktree add ../<dirname> -b <branch> |
| List | git worktree list |
| Remove | git worktree remove ../<dirname> |
| Prune stale | git worktree prune |
| Branch prefix | Use |
|---|---|
feature/<slug> | New features |
fix/<slug> | Bug fixes |
experiment/<slug> | Spikes / throwaway |
| Dependency bootstrap | Detect signal |
|---|---|
npm install | package.json |
pip install -r requirements.txt | requirements.txt |
go mod download | go.mod |
mvn dependency:resolve | pom.xml |
dotnet restore | *.csproj |
From the main repo root, run via the powershell tool:
git worktree add ../project-feature-name -b feature/feature-name
cd ../project-feature-name
Use a directory name that is obviously not the main repo so you cannot edit the wrong one by accident.
Detect the stack from the table above and run the matching install command. A worktree shares .git, not node_modules / .venv / build artifacts.
Run the project's test command via the powershell tool. Capture pass/fail counts before changing any code. If the baseline is red, fix it first or explicitly acknowledge the broken tests in tasks/todo.md.
git status --porcelain # must be empty
git branch --show-current # must be the new feature branch
<project test command> # must exit 0 for a clean baseline
All commits go to the feature branch. The main repo's working tree is read-only for the duration. Open files and run commands only from inside the worktree directory.
For CI environments, single-file fixes, or systems without worktree support:
git checkout -b feature/<slug>
The isolation principle still applies: never commit to main.
Worktree teardown is owned by finishing-a-development-branch. Do not remove the worktree mid-task.
main. Not even once. That is how production breaks.git worktree list to audit; cleanup belongs to the finishing skill.git worktree list shows the new worktree.tasks/todo.md).git status --porcelain was empty before the first code change.