Separate the work before starting it
An account is a place to run Claude; a session is where I give it a particular job. I keep that job bounded so I can judge what came back. A separate git worktree gives parallel sessions separate working copies, rather than leaving them to edit the same files.
Separate Claude data folders keep logins apart, but they do not separate the project files. The repo records parallel sessions in .claude/worktrees. That is where the code gets its own working space.
I start with the boundary: what this job owns, what it depends on and what else is already moving. Those details belong in the brief. If a session needs to change work outside its boundary, the plan needs attention before the change spreads.
Use parallel work where it pays
My tech-lead skill says to build in the current session unless delegation clearly pays. A large, self-contained chunk can justify another builder; so can genuinely independent chunks. The useful question is whether the work can progress without both sessions needing the same decision.
The skill caps builders at two at once: one in the main checkout and another in a worktree. It gives them separate ports, test-database prefixes and cache namespaces as well. Separate files are only part of the separation; running applications can collide too.
The withseismic.com checkout had five worktrees on 18 October 2026.
Know which account is in front
Claude Notch gives me an immediate account check. ⌥⌘1, ⌥⌘2 and ⌥⌘3 bring the corresponding copy forward, starting it if necessary. The coloured outline tells me which account I am typing into, and the brief peek names it after the switch.
Those keys select accounts, so I do not treat the outline as a label for the job. The PRD holds the job’s identity and state. The Notch answers which Claude is in front; the repo answers what the session is meant to do.
I can also see which account has room left without opening Usage settings in each copy. That removes a separate check from a context switch. But moving to an account with capacity still needs a proper handover of the work itself.
Leave a handover that survives the chat
My brief names what to read by path, the reason for the job, its boundary and how to verify it on the real surface. Returning to the work therefore starts with the files that define it, rather than a search through conversations for the latest agreement.
Long sessions get their state written into the PRD’s notes and the backlog before a fresh session takes over. The tech-lead skill calls for that around 200 turns. The important part is recording what remains before the conversation becomes the only place that knows.
Some state must stay shared. The desk database deliberately lives in the main checkout and is shared across worktrees, so agents see the same people, holds and actions. Separate code copies should not create separate versions of who has already been contacted.
Bring the result back deliberately
A worktree keeps edits apart while they happen, but integration still needs judgement. My tech-lead session reads the diff, reruns the checks and inspects the result. The skill explicitly says never to take an all-green report on trust; the evidence has to survive outside the session.
The handover is complete when the repo tells the truth about the work. Record what shipped, what was checked and what remains open. That is how I can switch attention without asking a returning session, or another person, to reconstruct the job from memory.