Short answer: my Claude Code workflow comes down to five habits. Write the spec before the first prompt. Keep CLAUDE.md short and specific. Give Claude a check it must pass for every change. Enforce the rules that can't have exceptions with hooks. Ship every change through its own branch and pull request. Anthropic's own guide says the same thing in three lines: tell Claude what it can't see, give it a check to run, and enforce the rules that can't have exceptions.
Why a workflow matters more than prompts
An AI agent writes code fast. What breaks is everything nobody wrote down: how the app is tested, how it gets released, what must never happen. I learned that over 15 years of shipping software with teams of people, and agents need it even more, because they forget everything between sessions.
This is the workflow I use for every app, this site included. It is also the order of work in my free MVP System Design playbook. With practice and this workflow, my build times fell from a month to two days.
1. Write the spec before the first prompt
Most bad sessions start with a vague request. Anthropic suggests brainstorming a spec with Claude first, then starting a fresh session to build from it. The build begins with a clean context and a written definition of done, and the same file is what the review checks against later.
My version is a one-page idea file: the screens, the features, the words your business uses. Then I let Claude grill me with questions until nothing is unclear. Here is how: turn your app idea into a spec.
2. Keep CLAUDE.md short: what Claude can't see
Claude reads your code well. What it can't read is everything outside the code: the exact test command, the decisions your team made, the trap that cost you a day last month. That is what goes into CLAUDE.md, and nothing else.
Anthropic puts it bluntly: if you keep adding "IMPORTANT" to a line and Claude still misses it, the line belongs in a hook, not in the file. Here is what to put in CLAUDE.md, with a template.
3. Give Claude a check to run
Claude stops when the work looks done. Without a check to run, "looks done" is all it has, and you become the test suite. So every change in my projects comes with a test, and the build fails if test coverage drops under 99%.
Anthropic lists several ways to give Claude that check:
- In the prompt: "run the auth tests after, and keep going until they pass".
- As a goal with
/goal, which a separate model checks after every turn. - As a Stop hook: a script that runs when Claude tries to finish and sends it back to work if the check fails.
- With
/code-review, which has a fresh reviewer, one that never saw your conversation, check the change.
Whichever you use, ask for evidence: the command Claude ran and its output. "All tests pass" on its own tells you very little.
4. Enforce the rules that can't have exceptions
Some rules are preferences. Others must hold every single time: never touch the secrets file, never push straight to the live branch. Anthropic separates the two clearly:
| Claude decides | Claude Code enforces | |
|---|---|---|
| What to do | your prompt, CLAUDE.md, skills | hooks, permission rules |
| When it's done | a request for evidence, /goal, /code-review | tests, a Stop hook, your build checks |
Put the must-nevers in the right column. Here are the hooks I'd add first.
5. One change, one branch, one pull request
Every change in my projects goes through its own branch and pull request, and I read the diff before it reaches the live app. It sounds slow. It is the opposite: when something breaks, you know exactly which change did it, and you can undo it in a minute.
When I run several Claude sessions at once, each works in its own copy of the repository (a git worktree), so they never overwrite each other's work.
6. Reuse what works: skills and plugins
Anything you explain twice should become a skill: a set of instructions Claude loads only when the task needs it. Anthropic recommends exactly that for team procedures like a release. Start small, and read every file of anything you install. More in Claude Code skills and Claude Code plugins. Using Codex instead? Read how Codex skills work.
7. Ship it like a team would
A working demo is not a working product. Before real users arrive, an app needs three copies (one on your computer, a rehearsal copy, and the live one), logs and alerts that tell you something broke, and backups that have been restored at least once in a test. My playbook requires all of it. Here is the production-ready checklist.
My workflow on one page
| Step | What I do | Read more |
|---|---|---|
| Spec | a one-page idea file, then a fresh session | idea to spec |
| Rules | a short CLAUDE.md | CLAUDE.md |
| Build | small changes, a test with each | the playbook |
| Check | tests, a review, evidence | hooks |
| Ship | branch, pull request, release, backups | checklist |
| Learn | the whole path, step by step | learn Claude Code |
The advice from Anthropic quoted here is from its best practices for Claude Code, checked on 7 November 2026.
New to all of this? Start with Claude Code for beginners. All guides: articles.