Worktree workflow

forge/scripts/forge_worktree.sh new <branch> creates a sibling folder at /home/justinwieb/forge-wt/<branch>/ that is its own checkout of the same .git repo. Two Claude Code sessions can edit code at the same time without stomping each other.

When to reach for it

• Risky refactor in a long-lived branch. Pure Phoenix Phase 3 wipe, big rename pass, dependency upgrade. Main stays usable for daily ops.
• Hot interrupt. You're mid-task and a brand emergency comes in. Don't lose your active conversation, just spawn a worktree on hotfix/<thing>, do the fix, merge back.
• Comparing two approaches. Cut two worktrees, prototype both, keep whichever wins.

When NOT to reach for it

• One-shot research or read-only work, just use the main repo.
• A change that fits in a single conversation, branch in place is fine.

Commands

forge_worktree.sh new <branch>       create on a new branch
forge_worktree.sh from <branch>      create on an existing branch
forge_worktree.sh ls                 list worktrees
forge_worktree.sh rm <branch>        remove worktree, keep branch
forge_worktree.sh purge <branch>     remove worktree + delete branch

After new: cd /home/justinwieb/forge-wt/<branch> && claude opens a fresh Claude Code session there. Auto-context, MEMORY.md, all skills work normally.

Mental model

• Worktrees are 100% local. They do not push, pull, or touch GitHub by themselves.
• Same .git directory backing both folders. Disk usage is just the working files.
• Branches behave the same as any other branch. git merge from main back to feature, normal flow.

Wired in

• Quick Commands row in forge/CLAUDE.md
• This memory file
• Helper script at forge/scripts/forge_worktree.sh