.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Claude Code has been my daily driver since early spring, on an Ubuntu 24.04 laptop and two servers, and the setup I run now looks nothing like the one I started with. Most of what changed wasn't configuration. It was judgment: when to plan, when to just type, what to automate and what to keep behind a prompt. This article is the workflow layer, the way the pieces combine across a normal week. Every deep topic below has its own guide in this series, so you get the position and the reasoning here, with a pointer to the long version.
None of it is official doctrine. It's what survived months of me quietly abandoning the habits that didn't work.
Start unfamiliar work in plan mode
My first call on any task is a rough estimate of what a wrong first move costs. A codebase I don't know, a schema migration, anything touching more than three files: those start in plan mode, because the written plan exposes the model's mental map of the code before anything changes, and correcting a bad map in prose costs two minutes while unwinding twelve half-edited files costs an afternoon. The plan also doubles as my own orientation in code I've never read, which is a benefit nobody advertises.
For one-liners I skip it without guilt. A missing import doesn't deserve a planning ceremony; typing the fix request and reviewing one diff is faster than reading a document about it. The skill worth building is switching modes per task instead of picking one and living there, and Shift+Tab makes the switch cheap enough that there's no excuse not to.
Keep CLAUDE.md lean and per-repo
Per word, CLAUDE.md is the most expensive file in your repository, since every line loads into every session forever. Mine run 30 to 60 lines: build commands, the conventions the model can't infer from the code and a blunt list of the mistakes it keeps repeating in this specific project. That last section pulls more weight than the other two combined. My user-level file at ~/.claude/CLAUDE.md is four lines, because almost nothing I want is true across all my projects, and a fat global file just taxes every session equally.
The pruning test I apply: would deleting this line change the model's behavior on a real task this week? Commands and known mistakes pass. "Write clean, maintainable code" does not. The full hierarchy, imports and path-scoped rules are covered in the guide to CLAUDE.md and /init.
Scope permissions with allow and deny rules
Prompt fatigue is real, and the lazy fix is flipping to bypass mode and hoping. The better fix takes ten minutes: write permissions.allow rules for the commands you approve every single day (your test runner, your linter, git diff and friends) and the prompts nearly disappear while everything unusual still asks. Pair that with deny rules for .env reads and git push, and you've built a session that moves fast exactly where speed is safe. The permission modes documentation lists the rule syntax, and deny rules have one property I lean on hard: they hold in every mode, including bypass.
I do run with checks off sometimes, but only inside containers that hold nothing I'd miss. What that flag really disables, and the two guardrails it can't disable, is written up in the piece on --dangerously-skip-permissions. On my actual machine, scoped rules beat the kill switch every time.
Clear context between unrelated tasks
One task per session. When the bug is fixed and the next thing is unrelated, I type /clear and start fresh, because a session dragging three finished tasks behind it gets slower, costlier and measurably dumber; stale context competes with the current problem for attention. The old transcript stays on disk anyway (resuming and branching are covered under Claude Code sessions), so clearing costs nothing but the muscle memory.
The companion habit is glancing at /context whenever a session starts feeling sluggish. It shows exactly what's filling the window, and the answer is often something dumb like an entire log file I pasted an hour ago and forgot about.
Match the model to the task
The single biggest lever on both quality and spend. My split: haiku for mechanical work like renames and boilerplate, sonnet as the default for most coding, the flagship models only when the problem has earned them, with /model to switch mid-session (aliases are in the model configuration docs). The opusplan alias is the clever compromise, spending the deep model on planning and the standard one on execution. Where the money goes when you get this wrong, and the meters that show it, are in the guide to Claude Code costs and usage limits.
Commit early and often
This one's pure git discipline, and it matters more with an agent than without one. I have Claude commit at every working checkpoint, sometimes four or five commits inside one feature, because small commits keep the diffs reviewable and review is the entire safety model here. A 40-file uncommitted diff at the end of a long session is where people stop reviewing and start skimming, and skimming an agent's output is how surprises reach production.
The commits also turn git into the undo button. When a direction turns out wrong, git reset --hard back to the last good checkpoint beats asking the model to remember what it changed. My working rule: the tree never holds more than one task's worth of agent changes at a time.
Paste error messages verbatim
When something breaks, resist summarizing. "The build fails with a type error" gives the model almost nothing; the pasted output gives it the exact string, the file path and the line number, and it will grep for that string immediately instead of guessing where to look. I keep the whole traceback in, noise included, because the model is better at ignoring irrelevant lines than at reconstructing missing ones. Same logic applies to flaky tests: paste the failing assertion, not your theory about it. Your theory might be wrong, and now it's anchoring the search.
Run long jobs on a machine that stays up
Anything that runs longer than my attention span moves off the laptop. A big refactor, an overnight test-and-fix loop, a dependency upgrade across a monorepo: those run inside tmux on a server, where a closed lid or flaky hotel Wi-Fi can't kill forty minutes of progress. Recovery exists (claude --continue does resurrect dropped sessions) but not needing it is better. I run mine on a small LumaDock box deployed from the one-click Claude Code template, which comes up with the CLI preinstalled, and the unmetered bandwidth means an agent pulling dependencies all night changes nothing on the bill.
Treat MCP servers and frameworks as dependencies
Every MCP server you add ships tool definitions into your context on every session and runs code with your permissions, which makes it a dependency in every sense that matters, just without a lockfile. Before enabling one I read what it exposes, check when it was last touched and remove it the week I stop using it; the audit habits are in the MCP configuration guide. Community frameworks deserve the same treatment with more suspicion, since something like the SuperClaude framework works by injecting a large body of behavioral instructions into your sessions. Some of that is genuinely useful. All of it is text you didn't write steering an agent that edits your code, so I read it first, same as I'd skim any dependency that runs at install time.
That's the whole system: plan when wrong moves are expensive, keep the standing context small, pre-approve the boring commands, commit in checkpoints and audit anything that injects itself into the loop. Nothing on this list took me longer than an evening to set up, and the permission rules alone paid that back within the week.
