My Context Engineering Workflow

I spend more time iterating with Claude on plans than actually writing code. From the blog posts and reddit threads I read, I don’t think I’m alone. We’re all living in markdown files, trying to set our agents up for success.

Here’s how it usually goes. I open a session, tell Claude the outcome I want, and let it map the code and come back with a rough plan. When one part needs more thought, I spawn another session to dig into just that piece. Claude Code does all of this natively — sessions, plan mode, checkpoints. But keeping it straight is on me. Every new session starts from zero, so I re-seed it with the outcome, the plan, and the slice I actually want to dig into. Pretty quickly I lose track of which session is doing what.

And when I lose the thread, Claude does too. That’s where the hallucinations creep in — confused architecture, made-up database tables, basics that are just wrong. So really my whole “workflow” is building a shared understanding of the code with Claude, and keeping it from rotting as I branch off into new sessions. I keep at it until I’m satisfied with the plan.

Tools like cmux are pretty good. But what I want is a way to manage branches and forks of my conversation with Claude. Claude Code does this natively, but managing all of this is a context switch by itself. Putting the branches into a UI makes it easy for me to reason about my conversation without having the clunky UI of Claude Code. Nothing like this seemed to exist.

So I wrote my own this weekend. I call it spwn.

Say I’m working on auth. I start a session, point Claude at the auth service, and let it dig around. When it comes back with something solid, I fork off to chase the token flow without losing the thread I was on — the branch shows up right there in the UI, so I’m never guessing which session is which. If the child finds something worth keeping, I pull its response back up to the parent and keep going. The stuff I really want to hold onto goes into a scratchpad, and I can spawn a fresh session seeded from it — grounded in what’s actually true instead of whatever the last thread drifted into. Everything’s grouped by project, and each session checkpoints the filesystem, so I can rewind and branch without ever committing to my changes.

How does this compare to memory systems? I’ve struggled to find a memory system that can separate 1) how the system works today and 2) the ideas that I’m working on. As I’m working with Claude, the memory systems I’ve used have confused past iterations as “truth” and only corrupt the work. It only gets worse when you’re working on multiple ideas and have multiple sessions.

How does this compare to spec driven development? Less hard coded plans and dense markdown files. Even as coding models advance, code will still be the source of truth, not specs. The code could be python, it could be english. Specs today are diffs. Once you have to enhance the spec, you’re better off starting from scratch. Why keep dense markdown files around then?

I’ve been using spwn every day since. It’s a proof of concept, really — built around the way I keep context straight, and I’m not sure it survives contact with anyone else’s workflow. But maybe that’s the point. The right answer probably isn’t one memory system or one spec format for all of us. It’s a way to branch, keep, and throw away context that bends to how you actually think.