Claude Code Workflow Tips From 18 Months of Daily Use
In early 2025, I asked Claude to fix a WooCommerce tax calculation, and it rewrote the entire checkout class. Working code, wrong scope, forty minutes of diff review for a two-line fix.
The workflow was the problem, and it took me most of that first year to admit it. After 18 months of daily use on client WordPress projects and on WP-AutoInsight, the habits that survived are about controlling scope and context: a maintained CLAUDE.md, Plan mode before anything risky, small tasks, raw error output, and deliberate context management.
Here's what stuck, and why.
Why does CLAUDE.md matter more than your prompts?
CLAUDE.md is the file Claude Code reads at the start of every session in a project directory. Run /init and Claude scans the codebase and generates it: what the project does, how it's structured, which commands build and test it, and where the entry points are. It’s a glorified README, written for a machine that forgets everything between sessions.
That amnesia is the part people underestimate. Every new session starts from zero. Without CLAUDE.md, the model spends the first chunk of every conversation rediscovering that your plugin uses PSR-4 autoloading, that deploys go through a specific script, that there's a legacy table nobody is allowed to touch. All this rediscovery process is spent in tokens, or, worse, in wrong assumptions.
The generated file is a starting point. But the real value comes from refining it. Mine accumulates rules to fix problems I started noticing during use. "Never modify the subscriptions table directly." "phpcs must pass before any commit.” And so on.
If a rule matters, it goes in the file.
Some instructions deserve to graduate further, into reusable commands. I wrote about that decision in when a prompt becomes a Claude Code skill, so I won't repeat it here.
When is Plan mode worth it?
Plan mode makes Claude Code draft an approach and ask questions before writing a single line. My threshold: anything that touches more than a couple of files or modifies data, and absolutely anything connected to a client's production environment.
The WooCommerce subscription billing work I did for a Canadian e-commerce client is the clearest example. A confident refactor that changes when a renewal fires can cost real money before anyone notices. In Plan mode, Claude laid out its intended changes first, and I caught a wrong assumption about webhook ordering before any code existed.
Reviewing a plan takes two minutes. Reviewing a change that broke your site can cost hours. And money.
For a one-file CSS fix or a throwaway WP-CLI script? Skip it.
Why do small tasks beat big asks?
Asking Claude Code to "build the feature" produces something that runs and needs a week of corrections. Asking it to build the settings page, then the REST endpoint, then the cron handler, then the uninstall routine, produces four things you actually reviewed.
This is the same lesson agencies learn about human developers. At Green Hat, I ran architecture for 30+ concurrent client projects, and the projects that went sideways were the ones scoped as "make it work" instead of a sequence of verifiable steps. An AI agent with repository access fails the same way, just faster and with more confidence.
The practical version: break work into tasks where you can verify the result in under ten minutes. The prompt structure I use forces this by making the Action line specific enough to test.
Small scope also protects your context window, which brings us to the next habit.
Paste the raw error, skip your summary of it
When something breaks, the fastest path is copying the full error output into the session, meaning the complete stack trace and the exact PHP notice with file and line number. Your paraphrase of a bug removes the details the model needed most.
A client of mine liked to make assumptions and ask for fixes, instead of pasting the logs and error outputs so Claude could have better context. So "the payment step dies after the coupon is applied” made Claude work toward the coupon logic, when the error was in fact caused by a 3rd party plugin.
Same rule for logs. wp-content/debug.log excerpts, failed cron output, HTTP response bodies, database errors.
How do you manage the context window before it manages you?
Claude Code sessions degrade as the context window fills. In my experience, once a long session gets heavy with old diffs and dead ends, output quality drops well before you hit any hard limit. This is an observation from daily use; treat it as an estimate, but the pattern is consistent enough that I now manage context deliberately instead of waiting for the model to get dumb.
Three tools, three jobs. /context shows what's consuming the window. /compact compresses the conversation while preserving key details, which is right when you're mid-task and need to continue. /clear wipes it, which is right when you're switching to something unrelated. Dragging yesterday's refactor context into today's SEO task helps nobody and costs tokens.
For work that spans days, I end sessions by asking Claude to write a handoff file: current status, decisions made, open questions, next steps, saved as markdown in the project. The next session starts by reading it. It's the same discipline as a developer handoff document, except the developer on both sides is the same model with no memory.
Close the loop at the end of each session
The last message of my working sessions is usually a version of "what should I add to CLAUDE.md based on what we did today?"
On good days, the answer is nothing. Often it's one line: a convention we established or a gotcha we hit. Over months, the file becomes institutional knowledge for a team of one human and one model.
This is the cheapest habit on this list and the one with the longest payoff. Every rule captured is a mistake that doesn't repeat, in this project and in every future session.
So what does the workflow look like assembled?
New project: /init, then edit CLAUDE.md by hand. Complex or risky task: Plan mode first. Every task: scoped small enough to verify quickly. Every bug: raw output, never a summary. Long sessions: /compact or a handoff file. Every session: one question at the end about what's worth writing down.
None of this is clever. That's the point. The developers getting consistent results from Claude Code on real WordPress work are running a boring, repeatable process around a very capable tool.
If your team adopted Claude Code and the results are inconsistent, the gap is almost always in the workflow and the guardrails around the tool. Auditing that setup and making agent-assisted development safe for production is exactly the kind of consulting I do.