How I actually use Claude Code: an agency's flow from brief to live

Claude Code isn't run here as a chatbot, it's run as an execution arm. The order never changes: read the brief and settle scope in a conversation first, cut a single, narrow task out of that scope and hand it to Claude Code, run a real build and typecheck command when the work is done, open a pull request only if both pass. The decision always sits with a person, the execution goes to the agent, and a verification command draws the line between the two.

TL;DR

Five steps: brief, plan, task, verify, deploy. The plan happens in a conversation, and a person approves the scope. The part that becomes a task goes to Claude Code once, narrowly defined, never as a broad "handle this" instruction. Every task starts by reading a CLAUDE.md file, which carries the project's fixed rules. Nothing merges without a passing build and typecheck, no exceptions. Hard-to-reverse work like payments, migrations, and secret handling never goes to the agent unsupervised. This article went through the same flow, with a real example below.

Every project starts with the same three steps: brief, plan, task

A client brief almost never turns straight into an agent task. It becomes a plan in conversation first: which page, which integration, which constraint, which stack. A person owns that call, not Claude Code. Once the plan is clear, one narrow task comes out of it: "add this payment provider to checkout, make these two tests pass," something concrete with a clear edge. Keeping scope wide doesn't help the agent, it costs control: a vague task like "fix the checkout flow" opens the door to the agent expanding scope on its own judgment. A narrow task means a narrow diff, and a narrow diff means an easy review.

CLAUDE.md: the one file Claude Code reads every session

Every client project has a CLAUDE.md at the repo root, and Claude Code reads it before doing anything else in a session. Three things live in it: the stack's fixed facts (which framework, which database, which deploy target), the bans (libraries not to use on this project, steps not to skip), and the verification rule (which command has to pass before anything merges). If a line reads "stay on Next.js, don't suggest WooCommerce without a client request," that one line stops the agent from carrying a habit over from the previous project before the first PR even opens. The file stays short on purpose: not a long list of generic rules nobody reads, a handful of lines specific to that project that actually change an outcome.

Which decision stays with a person, which task goes to the agent

The split is plain: anything easy to reverse goes to the agent, anything hard to reverse or directly client-facing stays with a person.

This table isn't fixed, it shifts with the project. On a new repo with thin test coverage, what gets handed to the agent narrows; on a mature repo with strong tests, it widens. Three rows never move though: payments, migrations, and secret handling stay with a person no matter how mature the repo is.

Nothing merges without verification: the build and typecheck gate

A task isn't "done" until a real command runs: the framework's own build command and a typecheck command. Both have to pass before a PR opens, "should work" is never the bar. The rule exists because the agent doesn't get to trust its own output; after Claude Code writes code, it tests that code with a real command, exactly the way a human developer would be expected to. The same discipline applies before risky commands too: before a hard-to-reverse git operation like a delete, a reset, or a branch switch, the working tree's state gets checked first, and anything that could get overwritten gets set aside. Skipping verification looks like it saves time, but the time it saves gets paid back later, digging through the next session to find out why something broke.

This article went through the same flow

So this doesn't stay theoretical: this article is itself an example of the flow above. An idea waiting in an approval queue got picked up, with its scope and title already settled; from there an outline got drafted and run through a check before a word of prose got written. The panel below shows what that check actually returned in this session, not a made-up example, run against this article's own outline.

Had the result failed, the heading order and opening would have changed before a draft ever got written; it passed, so drafting went ahead. The same check runs once more against the finished article, right before it ships. That's a small, concrete example of the difference between "generating a post with AI" and "running AI under a verification discipline."

Where this flow doesn't apply

This discipline isn't worth setting up for every job. For a small, one-off script nobody else will touch, building the whole brief-plan-task-verify chain is wasted time; write the script, run it, done. The chain earns its keep the moment a client depends on the output, a teammate has to read the code, or a system runs it unattended. It also weakens without a CLAUDE.md in the repo: without written project rules, the agent can carry over a habit from the last project, a process failure that should get caught in the first PR, not a design flaw in the agent itself. And no verification command can make a scope call for a person; a passing build only means the code runs, never that it's the right feature to ship.

Frequently asked questions

Do you hand every task to Claude Code?
No. Scope decisions, design decisions, and hard-to-reverse work like payments or migrations stay with a person. What gets handed off is work with a settled decision, a clear edge, and a way to verify it.

Does it still work without a CLAUDE.md file?
It works, just weaker. Without the file, the agent doesn't know that project's specific bans and preferences, so the same reminder has to be repeated in chat every time. The file is a way to write that reminder once and have it read automatically every session.

What happens if build or typecheck fails?
No PR opens. The error goes back to the agent, the agent fixes its own code against that error, the command runs again. That loop continues until the command genuinely passes.

Does this flow matter to someone who doesn't code?
The flow itself is technical, but its output is visible to a non-technical reader too: every PR has a description, every task has a verification record. A project handed over with no such record at all is usually the first sign nothing was tested while it was being built.

Is this discipline slow to set up?
Writing a CLAUDE.md and settling on build/typecheck commands is an afternoon's work. Most of the time goes into clarifying the rules over the first few tasks; after that it's a repeating pattern.

This is usually the exact gap in projects we take over: the code runs, but there's no trace of how any task was verified. We compared the tools themselves in Cursor vs Claude Code vs Windsurf, and covered what to check when inheriting a project with none of this trail in our guide to hiring a developer to fix a vibe-coded app; without the flow described here, a handed-over project usually gets rebuilt in the first week of our AI project completion work.