Most working sessions start the same way for me now. The ideas come faster than I can act on them. Fix this, refactor that, try the other thing, and don't forget the edge case from yesterday. The reflex used to be one of three moves, and all of them were bad. I could start doing one of them and lose the rest. I could dump everything into a single long prompt and hope the AI sorted it out. Or I could do the responsible-sounding thing and stash the future prompts in Apple Notes to get to later. The first let good ideas evaporate. The second buried the AI under a pile of unrelated work and got me mediocre results on all of it. The third felt organized for about a day, until the notes sprawled across a dozen files, out of order and disconnected from the projects they belonged to, which made them about as useful as not writing them down at all.
So I built a place to put the work down the moment I think of it, and a way to feed it to Claude one job at a time. I've been calling it Claude Code Command. It has quietly become the most useful thing on my screen.
What it actually is
Start with what it isn't. It is not a chatbot, and it is not a smarter prompt. It is a queue.
Each project gets a board with three columns. Backlog is where ideas land. Working is the run queue, the jobs being handed to Claude right now. Done is everything that finished, with the result attached. When I drag a card from Backlog into Working, it gets dispatched into a live Claude Code session running in my terminal. Claude does the work, reports back, and the card moves to Done with its result captured. I can be in the app on my laptop or my phone, and the work is happening in a terminal somewhere else.
The board is the obvious part. The things that changed how I work are less obvious: how fast I can capture, how the queue runs one job at a time, and how the context stays with the project instead of disappearing when a session ends.
Getting it out of my head
The capture has to be frictionless or it doesn't happen. In the middle of a session, when five things occur to me at once, I can type each one into the backlog as a sentence and keep moving. They stack at the top, newest first, and I deal with them later. I'm not holding them in my head anymore, and I'm not breaking my own focus to act on each one the instant it arrives. The point of capture is to stop paying attention to the list so I can pay attention to the work.
The working column is a queue, not a list
Here is the part I'd defend hardest. The work in the Working column executes in sequence. One prompt runs, finishes, and the next one starts. I can stack five jobs and walk away, and Claude works through them in order. I can reorder them while they wait, so the thing that should run next actually runs next.
This is the opposite of the long one-shot prompt, and that's the point. When you hand an AI a list of ten unrelated tasks in a single prompt, it splits its attention across all of them and does each one a little worse. When you hand it one job, it concentrates, and the output is better because the context stays clean. This is the same lesson we keep coming back to with clients: managing context is the job now, and the fastest way to ruin context is to cram unrelated things into the same window. The queue enforces that discipline for me. Each job gets its own focused turn.
Context that survives the session
The other problem the queue solves is memory across time. A single Claude session forgets when it ends. A project doesn't.
Because the board belongs to the project, not to any one terminal window, I can connect a new Claude session to it tomorrow, or three sessions over a week, and the history travels with it. Every prompt I've sent, every result that came back, what's still queued, and what's running right now. I can open a project cold after a few days away and pick it back up without reconstructing it from memory or scrolling back through a terminal.
The parts I didn't plan
I built this for capture and sequencing. The longer I used it, a few things I never designed up front turned out to matter just as much, and they all serve the same purpose: moving across a lot of projects without losing the thread.
The one I reach for most is the recap. With a click, the app reads the last twenty finished cards on a project and writes a couple of plain sentences about where things stand, then keeps that summary attached to the project. When I come back to something after a few days on other work, I read those two sentences and I'm oriented in seconds instead of minutes. Across a dozen projects, that fast re-entry is the difference between moving between them easily and dreading every switch.
There's a global activity feed alongside it that records every send, every completion, and every time Claude stopped to ask me something, across all projects at once. I can filter it to one project or search it, so when I want to know what actually happened, there's one place to look. A dashboard sits on top of all of it and shows the state of everything: what's queued, what's running, what finished, which sessions are live this minute, and how much has moved in the last couple of weeks. When I sit down to work, I can see where everything stands in about five seconds.
The smallest of them is a snippet library, for the bits of instruction I type over and over. I describe the same UI component the same way every time, so I save the description once and pull it into any prompt with an @-mention. Minor on its own, but it removes a little friction every day.
Why this maps to the real skill
We wrote a while back that the old focus-versus-multitasking debate is breaking down. On a small team, everyone is already doing a lot, and the work is spread across more projects than any one person can hold in their head at once. For a long time the limit was execution. There were only so many hours to actually do the work, so splitting your attention across it made the output worse. That limit is lifting. The model handles more of the execution every month, which means we can run more in parallel across a much broader surface than we could before.
That change exposes a different bottleneck. The hard part is no longer doing each task. It's moving between them: holding the plan for a dozen efforts at once, knowing which one needs you next, and bringing judgment, taste, and clear direction to each without losing the thread. That is the real new skill. You set direction, you spin up the work, and you judge what comes back. The work only you can do gets your full attention, and everything else runs in parallel.
This app is the scaffolding for that. The queue holds the work so my head doesn't have to. The sequential execution keeps each job focused so the model does its best work. The recaps and the activity feed keep the context so I can move between efforts without paying the full reload cost every time. My attention goes where it should, on framing the work and judging the output, which are still the parts the AI can't do for me.
How it's wired, briefly
The pieces are simple, and most of the credit goes to the harness rather than to me. I run Claude in a project with a small wrapper called cq instead of the usual command. It launches the same Claude Code session inside a pseudo-terminal, and in the background it polls the queue over an ordinary outbound web connection. There's no tunnel into my machine and no open ports. When I send a prompt, cq pulls it on its next poll and types it into the session the way I would, holding it as type-ahead if Claude is mid-task.
The queue itself is a small web app on Vercel with a database behind it, and it only ever hands cq the next job once the current one has finished. That is what keeps the execution sequential instead of dumping five prompts into the terminal at once. Information flows back the other way through Claude Code's hooks. As each turn ends, a hook grabs the final reply and posts it to the app, which is how a card moves itself to Done with its result attached, and how the board knows whether Claude is working, idle, or waiting on me for a decision.
Two things make it usable day to day. The first is that I can drive the whole thing from the Claude app on my phone through a connector, so I can queue work, reorder it, and check where things stand while I'm away from the desk. The second is quieter. The work runs against my own code projects, but a result can still pick up something I'd rather not keep, so before anything is saved, the app scrubs out what looks like a secret or personal data and stores only a count of what it pulled. It's a safety net rather than a guarantee, but it means a stray key or token doesn't end up sitting in the database. None of this is exotic. It's the kind of thing the current tooling makes possible to assemble in a few evenings.
Why I'm sharing this
I built this for myself, and I use it every day. It's a single-user tool, shaped around exactly how I work, and I'm not trying to turn it into a product. What I am doing is working out how to put the same scaffolding in front of the rest of the team, because the pattern underneath it travels further than the app.
The pattern is this. As more of the execution moves to AI, the advantage shifts to three things: how quickly you can capture the work, how cleanly you can sequence it, and how well you can hold context as you move across it. Put a little structure around those three, and the same model you were already using gets noticeably more useful, because you are no longer the slow step between a good idea and a finished result.
This space is moving fast, and we can take on more than we could a year ago. What has been holding us back has less to do with the model and more to do with the cost of switching between a growing number of efforts and keeping the plan straight across all of them. This tool took most of that cost off my plate. I move between projects faster, I lose far less context in the handoffs, and the work we deliver to clients is better for it.