A Claude Code workflow you can run all day

Not principles, a routine. The exact loop I run Claude Code in for a full workday: how a task starts, what happens during the turn, what happens when it ends, how parallel lanes work, and the fifteen minutes of maintenance that keep the whole thing from decaying.

We wrote up the principles behind our Claude Code setup already. This post is the other half: the actual loop, hour by hour, with the commands. Principles tell you why; a workflow is what your hands do. Mine has stabilized into something I can run all day without it decaying into chaos by 4pm, and it has five parts: how a task starts, what happens during a turn, what happens when a turn ends, how parallel lanes work, and the maintenance that keeps it alive.

The unit of work is a task, not a conversation

The biggest structural decision: one session per task, and the task is written down before the session starts. Not a paragraph in the chat box, a file. For small fixes that is three lines in a scratch note; for features it is a spec in specs/ that says what done means. The session's first message points at the file.

This sounds like ceremony until you hit the alternative. A session that drifts across three loosely related tasks accumulates context that makes every subsequent answer a little worse, and when the context gets compacted, decisions that only lived in scrollback quietly vanish. A file survives compaction, survives tomorrow, and survives being handed to a different session. Chat is for steering; files are for state.

Starting a task, concretely:

cd ~/work/myapp
claude
# first message: "Read specs/rate-limit.md. Plan first, don't edit anything yet."

That last sentence is the whole planning step. Read the plan it comes back with, fix the wrong assumption (there is usually one), then say go.

During the turn: the wait is part of the workflow

Once the agent is working, a turn runs minutes, not seconds. What you do with that gap is a workflow decision most people never make on purpose, and the default (hover and watch tokens stream, or tab to something bottomless) is the worst part of most people's agent setup.

What works for me is giving the gap a fixed menu, so there is no decision to make in the moment:

• Steer another lane. If a second task is running in another worktree (below), check whether it needs input.
• Review the previous diff. The last turn's changes are sitting there uncommitted; the wait is exactly long enough to actually read them.
• Take the flashcard. This is the itch Unwait was built to scratch: it notices the turn started, shows one card from whatever you are memorizing, and disappears when the agent needs you. One card fits inside one turn almost perfectly.

What does not work: starting anything with its own momentum. The turn will end and you will not come back, and now the agent is waiting on you, which inverts the entire point.

When the turn ends: verify, then checkpoint

Turn end is a gate, and I run the same three moves every time:

1. Read the diff, not the summary. The agent's prose description of what it did is a press release. git diff is the news.
2. Run the proof. Whatever counts as evidence for this task: the test suite, the build, hitting the endpoint. If you find yourself skipping this when tired, make a Stop hook do it for you; recipe four in our hooks post refuses to end the turn while tests fail.
3. Commit the checkpoint. Working state gets committed immediately, message written by the agent, one keystroke from me. Small commits are what make agent mistakes cheap: rolling back a focused diff is a shrug.

Then either the next instruction in the same session, or if the task is done, the session ends. Sessions do not outlive their task. Context is a consumable, and stale context is worse than none: /compact buys you room, but what it cannot preserve is what you never wrote to a file.

Parallel lanes without chaos

One agent working means you have minutes of wait per turn; two or three lanes soak that up. But parallelism is where workflows usually collapse, so the rules are strict:

• One worktree per lane. git worktree add ../myapp-ratelimit gives each session its own checkout; two agents in one directory will trample each other's files.
• Two lanes of real work, max. A third lane can exist if it is mechanical (a rename, a dependency bump, doc updates), because mechanical lanes need almost no steering. Three lanes of thinking work means dropped context in at least one, every time.
• Signals, not polling. The reason lanes fail silently is that "agent finished" and "agent is stuck waiting for permission" look identical in a background terminal. Claude Code fires distinct hook events for both; wiring them into notifications with the project name takes five minutes and is the single piece of setup that makes multi-lane work viable at all. Blocked is the expensive one: an unnoticed permission prompt eats twenty minutes and produces nothing.
• Remote lanes live in tmux. Anything running on a server goes through the tmux setup so a dropped connection does not kill a half-finished turn.

The maintenance loop

The parts above run hourly. Two things run on a slower cycle, and skipping them is how the workflow rots:

End of task: reconcile the spec. If reality diverged from the spec (it did), the file gets updated before the session closes, while the divergence is still fresh. A spec that no longer matches the code is worse than no spec, because the next session will trust it.

Weekly: prune CLAUDE.md and the permission list. CLAUDE.md only grows when a real failure earns a new rule, and rules that stopped earning their place get deleted; every line is a tax on every future session. The permission allowlist grows the opposite way, from real prompts: each prompt that interrupts a turn either gets its command allowlisted or stays a deliberate speed bump. After a few weeks the prompts you still see are exactly the ones you want to see.

The loop, compressed

1. Task in a file, session per task, plan before code.
2. During the turn: steer another lane, review the last diff, or take the flashcard. Nothing with momentum.
3. Turn end: read the diff, run the proof, commit the checkpoint.
4. Lanes: one worktree each, two real lanes max, notifications for finished and blocked, tmux for remote.
5. Reconcile specs at task end; prune CLAUDE.md and permissions weekly.

None of it is clever, which is the point. A workflow you can describe in five lines is one you will still be running in six months, and the compounding wins in agent work come from the boring loop, not the brilliant prompt.