When Claude Spawns the Next Claude

My new workflow helps me automate, ship efficiently, keep Claude in context, and track the work.

Multi-session work itself isn’t new. Non-trivial features have been spreading across sessions for a while, and the plans for them live in the repo where any agent can read them. What changed for me recently is that the transitions between sessions now run themselves.

The previous Claude writes the handoff. It opens a new pane next to itself, launches another Claude in that pane, and points it at the doc. The new agent reads the doc and starts working, without me bridging the gap.

The workflow

We plan a feature that’s bigger than one session, and Claude starts working on it.

When the session has had enough, it writes a handoff doc and launches a new Claude in a new pane. The new one picks up where the last left off and keeps going.

When that one fills up, it does the same. The loop runs for as many legs as the feature takes — a relay of Claudes carrying the work across.

The handoff gives me four concrete advantages:

• Automate — the glue I used to do by hand (open a pane, type claude, paste a brief, wait for boot, type the first prompt) is now done by the previous agent.
• Ship efficiently — each leg of the relay runs on a clean context window at full speed, faster than one long session limping along under accumulated weight.
• Keep Claude in context — the window resets at every handoff, before the agent has time to start dragging.
• Track the work — every relay leaves a handoff doc and a stack of PRs that together tell the story of what shipped.

The pieces

This started as a paving job. I’d been using the handoff skill for a while, and a few times in a row I followed it with the same manual sequence: open a new pane, type claude, point it at the doc. After the third or fourth round of that I asked the obvious question — why isn’t this one command? — and Claude wrote the wiring.

Two pre-existing things make the workflow possible, plus the one I asked Claude to write on top:

• cmux — the terminal multiplexer the whole setup runs in, which lets a Claude in one pane programmatically spawn another pane and start another Claude in it.
• A handoff skill — the doc-writing primitive that compacts the current session into a one-page brief, adapted from the community-shared skill ecosystem (the one I draw from most often is Matt Pocock’s skills repo).
• A handoff-launch skill — the small thing Claude wrote to wire them together, which writes the doc, opens the new pane, sends the launch command, and fires the next Claude, all from one slash command in the previous session and with no typing from me.

The handoff is the context boundary

Before I get to the skill, I want to name something the workflow does that I underweighted at first: the relay is a context-management technique, not just a glue-removal technique.

A long-running Claude session fills up. The context window is finite, and the auto-compactor is always getting closer.

By the third or fourth hour, the model is dragging weight it doesn’t need: every dead end you walked through, every clarification you resolved, every test that failed before you fixed it. All of that context may be correct. That does not mean it is still useful.

The handoff doc carries only what survived:

• The wrong paths are gone.
• The corrected misunderstandings show up as decisions, not arguments.
• The fresh agent doesn’t have to learn what not to do — it just has the plan.

That’s a structural advantage no amount of clever prompting inside the old session can replicate. The handoff is the lever. The skill makes pulling it cost nothing.

What the skill actually does

The skill is called handoff-launch. It runs in the current session, near the end of it, when a clean unit of work has landed — a PR is up, a checkpoint is reached, the next phase is well-defined.

One slash command kicks it off. Then, without any further input from me, the current Claude does four things:

1. Writes a handoff document. Short, opinionated, no transcript. The doc names what was done, what to do next, which files matter, which decisions are settled and which are open. It references the plan and the PRs that just landed, rather than restating them.

2. Opens a new pane in the terminal multiplexer, to the right of the current one, focused.

3. Sends a claude command into the new pane with the handoff path as the argument: read this doc and begin work.

4. Flashes the new pane so my eye goes there.

That’s the entire interaction from my side. Six seconds, one slash command, no typing, no terminal navigation.

The fresh Claude boots, reads the doc, and starts the next PR. I switch panes when I’m ready to watch.

Two details that matter

A couple of small choices in the underlying primitives carry more weight than they look like they do.

Cmux treats panes as addressable surfaces. An agent inside one pane can deterministically spawn another, send keystrokes into it, read its screen back. Without that, there’s no way for a Claude to programmatically start another Claude in its own neighborhood. The whole workflow rests on this.

The handoff doc lives in $TMPDIR, not the repo. Handoffs are ephemeral. They don’t deserve a git commit. They exist for one job — bootstrap the next session — and then they’re gone. Keeping them out of the repo prevents handoff-rot: stale docs in the project tree that look authoritative but describe a state of the world from three loops ago.

Why “autonomous start” is the part that matters

The most important part of the whole thing: I don’t open the new Claude, and the new Claude doesn’t wait for me.

I tell the old Claude to do the handoff and walk away. It writes the doc, opens a new pane, launches Claude there, and points it at the doc. The new Claude doesn’t read the doc and stop to ask “what should I do?” — the doc already said. It just starts on the next PR.

This sounds like a tweak. It’s not.

If either side needed me — opening the new Claude, or prompting it after boot — I’d have to be at the keyboard at the exact moment of handoff. With autonomy on both ends, the relay keeps moving whether I’m watching or not. I can be in another window, in another project, away from my desk. The feature keeps moving.

Interactive mode is still there as a flag for the rare case I want to drive manually. It’s the exception, not the default.

Choosing autonomy as the default is what makes the relay a relay, rather than a chain of human-supervised handovers.

The autonomy is bounded. The plan is in the repo, the work is PR-shaped, and nothing ships without review. The agent can keep the branch moving; it cannot merge its own judgment into production. That boundary is what makes the autonomy useful instead of sloppy.

What I actually do now

Between PRs, three things:

• Read the diff.
• Comment if something’s off.
• Merge.

What I don’t do:

• I don’t write prompts.
• I don’t open terminals.
• I don’t summarize the previous session for the next one — the previous session already did.
• I don’t re-explain the plan — the plan is in the repo and both Claudes can read it.

The amount of glue work I’ve removed from my day is striking once I started counting. Not in dramatic hours saved, but in the number of small switches I no longer have to perform. Each switch was cheap. The aggregate was a tax.

My role has compressed toward the shape of a reviewer. That’s the right shape. Reviewing diffs is high-leverage human work. Pasting boilerplate into terminal panes is not.

What’s load-bearing

Three things make this loop work.

The plan lives in the repo, not in the conversation. If the plan only exists as scrollback in the current session, the handoff doc has to carry it, which means the doc gets bloated and the next session re-litigates decisions. With the plan checked in, the handoff doc just points to it.

The handoff doc is opinionated about omission. A handoff that tries to summarize the whole conversation is just a worse version of the conversation. The doc’s job is to be the next agent’s prompt, not its transcript.

• References over duplication.
• Decisions over deliberation.
• Open questions over resolved ones.

The skill is autonomous by default. The relay only feels like a relay if the new agent runs without me. Otherwise it’s a chain of supervised restarts, and the manual work creeps back in a different shape.

What this changes

The downstream effect is obvious — relays advance whether I’m there or not, so features land faster.

The upstream effect on how I spend my own attention is the one I notice more.

The bottleneck has moved back to where it belongs: the quality of the plan, the quality of the review.

The boring middle — the part where a human shuttles context between agents — has been deleted. What’s left is the part that’s actually worth my judgment.