A CLI workflow that survives a real working day

Ask an engineer to describe their day and you get a clean story. Watch the screen and you see something else. A build fails. Someone pings about a customer bug. The branch they were on is now three commits behind. A CLI workflow that only works when you have ninety uninterrupted minutes is a demo, not a workflow.

So the design constraint is recovery. Every step should leave enough on disk that you can walk away for two hours and come back without reconstructing anything from memory or from scrollback.

The four moves that make a CLI workflow durable

• One agent, one worktree. git worktree add ../feature-x feature-x gives the agent its own directory. Two agents in one checkout will fight over the index and you will spend the afternoon reading a stash you did not create.
• Write the plan to a file before any code changes. Not a chat message. A file the next session can read.
• Commit at every green test run, even mid-task. Cheap checkpoints beat clever undo.
• Keep the long-running thing in its own terminal. Dev servers and watchers do not belong inside the agent's shell, where a killed process takes the session with it.

What the loop looks like

Concretely, for a change of any real size:

git worktree add ../wt-invoices invoices-fix
cd ../wt-invoices
# describe the task, ask for a plan, read it, correct it
# then let it work, reviewing each file as it lands

The step people skip is reading the plan. It takes two minutes and it is the only cheap moment to catch a wrong approach. Once the agent has edited eleven files, correcting the direction costs more than starting over. We have timed this in workshops. Teams who read the plan finish a medium task faster than teams who dive straight in, and their diffs are about a third smaller.

The second skipped step is the mid-task commit. Engineers treat the agent's work as one atomic thing and only commit at the end. Then the last instruction goes badly, the working tree is a mess, and the good work from an hour ago goes with it.

Where the CLI is worse than the editor

Honest limits. Reviewing a large diff in a terminal is worse than reviewing it in an editor with a proper side-by-side view. Anything visual, a layout bug or a chart that looks wrong, is faster to fix where you can see it. And a terminal session has no memory of yesterday unless you gave it one, which is the whole reason for writing plans and notes into the repo.

The common failure we see is a team going all-in on the CLI, then reviewing thousand-line diffs in a pager at 6pm. They merge things nobody read. That is not a tooling win.

What to do next

Pick your next task that will take more than an hour. Run it in a fresh worktree. Write the plan to a file first, commit whenever tests pass, and open the final diff in your editor rather than the terminal. Do that three times before you change anything else about how you work. If the recovery property holds when you get interrupted, keep it. If it does not, the missing piece is almost always the plan file.

If you want help putting this into practice, talk to us.