worktree-branchinglisted

# Worktree branching One job: give a work-item exactly one isolated git worktree on its own `feature/`, `fix/`, or `chore/` branch off the integration branch, so work runs in parallel without touching the primary checkout. Detect an existing one before making a new one; never make two. Native `git worktree` is the whole mechanism - no wrapper is added where git already does the job. ## Before anything: read the overrides A project may already have opinions here - a different branch prefix (`feat/` not `feature/`), a different integration branch (`develop` not `staging`), a different placement. Read them first and let them win: ```bash .better-dev/bin/bd-mem read overrides 2>/dev/null .better-dev/bin/bd-mem recall "branch prefix integration worktree" 2>/dev/null ``` Detect the layout, don't impose one. What the repo already does is the default. ## You are not the only actor here This repo runs parallel worktrees, and other agents or the operator may be working in it while you are. If you notice changes in the working tree or index you did not make, they are not yours to undo - do not revert, stash, or "clean up" after another actor. Keep going if the changes don't touch your files; if they do, or you cannot tell whose they are, surface exactly what you see and ask before proceeding. `git checkout --`, `git reset --hard`, and `git clean` aimed at work you didn't author are how a parallel model loses someone else's data. ## Step 0 - are you already isolated? Before cre