The architecture of a Claude Code consulting workflow is four files, committed before any feature work.

What ends up in the client repo

A scoping PR for a typical SMB engagement (a single repo, one founder writing, a pre-commit formatter, an auto-commit cron) lands in this shape. The src/ tree is the existing client code, untouched. The four new top-level entries are the architecture.

Engagement IDs follow the pattern <year>-<month>-eng-<n> so a single client with multiple engagements has a separate plan and scratch space per engagement. plan/ and scratch/ are committed; this is a feature, not a leak. The next session in the next engagement should be able to read why the earlier engagement made the calls it made.

File 1: CLAUDE.md as a writers manifest, not a code-conventions doc

The most common self-rolled CLAUDE.md is 80 percent “here is what the codebase is” and 20 percent everything else. That ratio is backward. The codebase part the agent figures out from reading files. The part the agent cannot infer is who else is allowed to write, when, and what those writes look like.

Below is a stripped CLAUDE.md from a recent SMB engagement. Five sections, in this order: writers, tool contract, plan-pin policy, commit policy, escalation. Code conventions are intentionally absent; those live in the existing src/ files where the agent will find them naturally. The whole file is under 200 lines.

Section 1 is the load-bearing one. The agent cannot infer that an auto-commit cron is going to push every 60 seconds, or that the founder edits files in a separate editor while a Claude session is running. If those facts are not in CLAUDE.md, every session re-discovers them as surprises. With them in writing, every session starts already knowing.

Files 2 and 3: plan/ and scratch/, the parts compaction cannot eat

On Claude Code, conversation history is summarized into a <summary> block when input tokens approach the window. That is fine for transcript shape, lossy for facts that lived only inside a tool output 40 turns ago. plan/ and scratch/ are the disk-backed mirror.

plan/<id>.md is the scope, locked at consult time. It carries the named deliverables, the price tier this engagement maps to (one of the published tiers on c0nsl.com), the hours-saved estimate I quoted on the call, and the explicit out-of-scope list. The agent refers to it instead of re-deriving scope from a 400-turn transcript. A plan-mode resume three days later starts by reading the plan, not by asking the founder what we agreed on.

scratch/<id>/ is for everything else that has to survive a compaction. When I read the support-ticket schema out of the Shopify admin, the row count of the orders table, the actual shape of the pricing tiers in JSON, those land in scratch/<id>/<topic>.md as soon as I read them. The pattern is mechanical: every load-bearing fact gets pinned within the same turn it was first observed. The durable copy is then safe through compaction, session restart, and handoff to a parallel agent.

File 4: .claude/settings.json, committed not local

The default move with settings.json is to keep it on your laptop. For a consulting engagement that is wrong. If I ship the work and the founder opens Claude Code in the same repo three months later without my settings.json, they get default permissions, no hooks, and the contract I priced for stops firing. Every parallel agent and every teammate session also needs the same contract, so the file lives in the repo.

Two pieces are doing real work here. The deny list under permissions blocks the irreversible operations that cause the worst incidents (force-push, hard-reset, recursive rm). The PreToolUse hook on Edit and Write runs a tiny node script that confirms the file the agent is about to write to has a corresponding entry in plan/<id>.md; if it does not, the edit is paused and the agent is told to update the plan first. That is the difference between a session that quietly drifts off-scope and one that cannot.

Self-rolled vs. scoped: what the four files actually change

Two CLAUDE.md files from the same week, both for SMB founders using Claude Code on their own repos. The left is what the founder wrote before we worked together. The right is what we landed after the scoping engagement. The right is shorter and the agent behavior on top of it is more predictable.

# CLAUDE.md

## About this codebase
Next.js 15 app, App Router. Uses Drizzle ORM
on top of Postgres. Tailwind 4. shadcn/ui.

## Conventions
- Use server components when possible
- Use Tailwind utility classes only
- Don't use any
- Prefer named exports
- Components go in src/components
- API routes go in src/app/api
- Use zod for schema validation
- Tests go in __tests__ next to source
- Don't use console.log in committed code
- Use useEffect sparingly
- Don't use class components
- Use proper TypeScript types
- Don't ship secrets in client code
- Use env vars for config
- Don't push to main directly

## Style
- Two-space indent
- Single quotes for strings
- Trailing commas in arrays/objects
- Semi colons
- Prettier on save

## Workflow
- Run npm test before committing
- Open a PR for everything

The left has 22 lines of code conventions and 0 lines of writer information. The right has 0 lines of code conventions (those live in the source files) and 5 lines of explicit writer information, plus four sections of contract. The agent on the right does not re-discover the auto-commit cron every session as a surprise. It also does not amend pushed commits, because that line is in writing.

How a four-file engagement actually runs

The phase model still exists. It just runs on top of the architecture, not instead of it. Below is the public flow for a small-integration tier engagement, from the moment a founder books the consult to the handoff PR.

Agency-shaped engagement vs. single-engineer engagement

The agency-shaped four-phase template (audit, strategy, implementation, optimization) is what most pages on this topic describe. It is the right shape for a fifteen-person team selling into a Fortune 500 procurement process. It is the wrong shape for a five-person SMB on a $500 to $10K budget who needs the agent to stop shipping bad commits next Tuesday. Side by side:

Where the architecture is overkill

One-person hobby repo with no other writers, no formatter, no cron, no parallel sessions: you do not need this. The Edit tool's Read-before-Edit contract is enough on its own, and a five-line CLAUDE.md telling the agent the project is in TypeScript will cover the gap. The four-file architecture earns its weight the moment a second writer appears, which on a real client repo is day one.

It is also overkill if you only run Claude Code in short, supervised bursts. If your sessions are 10 minutes long and you watch every tool call, compaction is not a problem and scratch/ is overhead. For sessions that run for an hour or more, or that pass through a /compact, scratch/ pays for itself the first time the agent reaches for a fact that compaction would have summarized away.

What a c0nsl engagement looks like, by tier

Mapped to the published rates on c0nsl.com:

• $75 consult. 30 or 60 minutes. I read the existing repo, identify which of the four files are missing or wrong, and quote a fixed scope. You leave with three named automations and an hours-saved estimate written down. Refunded if I cannot.
• $500 to $2K small integration. The four files installed and tuned for one repo, with one to three named automations implemented on top. Typical timeline is half a day to three days, depending on how many writers the repo already has.
• $2K to $10K+ custom system. Multi-repo rollout, the same architecture committed to every repo in the client's stack, plus the cross-repo conventions that let a single agent move between them safely. Includes the custom hooks (the plan-pin enforcer, the writer-manifest auditor) and the eval harness that exercises the multi-writer cases.
• $1K to $5K mo retainer. I keep the architecture current as the model evolves and as new writers appear (a new agent, a new cron, a new teammate). The retainer is for clients running the architecture across enough repos that maintaining it is itself a part-time job.

The pricing is on the page, not on a sales call. If your repo and your writer set tell me the engagement should sit at a different tier than where you started, I tell you on the consult, in writing, with a refund of the $75 if my read on the scope is wrong.