It is a Thursday afternoon in our Sydney office and there are four windows open on the screen in front of me.
A terminal with Claude Code running inside our own code. A browser with the business app open on our demo account, because I am checking a figure against what the screen says rather than against a spreadsheet. A diff, which is the list of what changed since this morning. And a file called AGENTS.md, 150 lines long, which is why the other three windows are worth anything.
I am Petboost's CTO, and building software with Claude Code is now most of my job. I write less code by hand than I did two years ago. What I write instead is rules.
The direct answer. Building software with Claude Code, the way we genuinely do it, is not mostly about prompting. It is three things written down and one thing refused. One rules file that loads at the start of every session. A folder of jobs described once each, so nobody explains those jobs again. A review loop that decides what is allowed to ship. And a short list of actions it is never permitted to take, which for us includes committing, deploying, and anything that moves money. The whole apparatus is one file of about 3,800 words, 121 written-down jobs, nine commands, and seven reviewers.
This series has spent 29 posts telling you to try this. This one shows you ours, because the argument only holds if it is specific.
Building software with Claude Code starts with one file
The rules live in one file at the top of our code, called AGENTS.md: build commands, conventions, the things we have banned, and the gate that decides what counts as finished. It is the only place any of that is written.
Claude Code reads a file called CLAUDE.md, so ours is a few lines long and one of them is @AGENTS.md. That is an import. Anthropic's documentation says what it does: an imported file is expanded and loaded into context when the session launches, and imports chain up to four hops deep. One source of truth, one thin door into it, rather than two files that slowly disagree.
This is exactly the idea in post 21, the CLAUDE.md for your own business, running at a larger scale. Same file, same purpose, same failure mode if you neglect it.
Here is the honest part. Post 21 tells you to keep yours to about two pages. Ours is closer to eight, and that's not a badge. A rules file that has drifted out of date is worse than none, because it is confidently wrong.
Rules closest to the work win
There are two more of these files, one for the back end and one for the front end. Each holds the build and test commands for its area, and overrides the root file where they conflict.
The mechanism is the same one you would use. These files load from the top of the disk downwards, so the file nearest the job is read last, and last wins. Not a hierarchy anyone maintains. Just position.
You already run your salon this way: house rules everyone knows, and a laminated note above the bath that contradicts one of them for good reason. For you that means one page for the business, and a second page inside the bookkeeping folder only once the first is not enough.
The shelf: 121 jobs written down once
Alongside the rules sit 121 skills: one folder named after a job, with one plain text file inside describing how that job is done.
They are not glamorous. Of the 121, 22 are variations on one shape: taking a pet business's client book out of whatever software they are leaving, cleaning the breed names and the addresses, checking the phone numbers for duplicates, and bringing it into Petboost without losing a dog.
Others are one-offs that earned their place: one produces a co-branded proposal for a prospect. One reviews a change purely for over-engineering and reports only what should be cut. One builds an Instagram tile. One reads a business's real numbers before a call with the owner.
Almost none were planned. They were written the second or third time somebody did the job and got annoyed. I would trust that trigger over any planning exercise: if you have explained something twice, write it down on the second telling, while you still remember what tripped you up.
There is also a technical reason to prefer a skill over the rules file. The rules file loads every session, so it costs you context whether or not today's job needs it. A skill loads only when invoked, so long instructions cost nothing until the job comes up. Building one is a post of its own, and 12 already written are written out in full there.
Nine more are commands rather than skills, meaning we type them deliberately instead of letting the job be recognised. Seven are reviewers we hand a finished draft to before it goes near publication.
The rules that exist because we broke something
This is the section I would most want you to read, because it's the least impressive and the most useful.
Our rules file is not a style guide. Several of its rules carry a sentence explaining the mistake that produced them, and two of those carry a date and the word incident. They read less like policy and more like a scar. Here are five.
The first is about finishing:
Never say done, complete, green, or passing on CI numbers, editor tooltips, a green build, or "it's trivial". Only on tests and a build you ran and saw pass this session.
The second is about touching anything live. Gentle by default: a handful of records at a time, a pause between batches, and an abort on the first error rather than pushing through. Run one, then about 10 while you watch what happens, then the rest.
We did not write that in advance. We wrote it after a bulk job we were confident about set off far more downstream work than the job itself, on a system real businesses were using at the time. The rule has four clauses because all four were missing that day.
The third is the shortest: never state one of our prices from memory. Look it up, live, in the system that holds the real ones. That exists because of a mistake we made once, and why it invents a confident wrong number tells that story properly.
The fourth is about alarms. You may only raise one if a human must actually do something; "nothing, it retries and fixes itself" gets recorded quietly instead. An alarm that goes off all day teaches everyone to ignore the one that matters.
The fifth has nothing technical in it. No personal mobile number goes into anything we send a client or a prospect. Not an email, not a PDF, not a pitch pack. A printed leave-behind cannot be recalled, which is why it is an absolute rather than a judgement call.
What it is never allowed to do
Just as plainly:
- It never commits and never pushes. It stages the change; a person commits it. No branches, no pull requests, no rewriting history.
- It never deploys. Shipping to production is a person's decision, and for the back end that person is me.
- It never sends, charges, or moves money without a human reading the thing first. Drafting is fine. Sending is not.
- It treats the back end as read-only unless the job is explicitly a back-end job, so a front-end task cannot quietly reach somewhere consequential.
There is a setting on Claude Code governing how much of this it may do without asking, and which settings exist, and which to start on. Our two most important lines are not settings at all, though. They are sentences: it stages, we commit, and nothing irreversible happens without a person in the loop.
If your version of "irreversible" involves client records, read what must never be pasted into an AI chat before writing your own list. Yours is about people's pets and their contact details, and it should be shorter and stricter than ours.
It gets things wrong here too
It does. Anthropic says so in its own documentation: Claude Code makes mistakes with unfamiliar code patterns, can misread what a poorly documented old system was meant to do, and may propose a fix that introduces a new bug. Confident-sounding wrong answers remain possible. It also cannot see live system state, or what a change will set off, until it runs.
Our two most common failures are more specific, and neither is a wrong line of code.
The first is a premature "done". Not a lie, exactly. It's the same optimism a human has when the build goes green and the tests were never run. That is why our rule about finishing names the specific excuses.
The second is building a new thing beside the thing that already did the job: a second service where one would do, a hand-rolled badge where a shared one exists. Left alone, that habit turns a tidy codebase into four ways of doing everything.
Our answer to both is a hook: a deterministic shell command that runs at fixed points in the session regardless of what the model decides, which makes it different in kind from a rules file, because a rules file is advice. Ours re-states the do-not-over-engineer rule and the finished checklist at the start of every turn. The reason sits in a comment at the top of the script: a rule loaded once at session start loses its edge against the task in front of you.
The part of building software with Claude Code that nobody advertises
The review loop is the actual product, and the part nobody selling an AI coding tool talks about.
"Tests are green" is not "ready". Our file has a gate with six items on it, and the rule attached says you must state your conclusion on each one out loud, because silence is not assessment.
Did you reuse a pattern that exists in at least two places, or invent a new one. Did you run the tests and watch them pass in this session. Did you cover the awkward cases, the empty case, and the repeat run. Did you re-read the whole change end to end, not just the last file you touched.
Then the clause that makes it a loop rather than a checklist: a fix applied after the last clean pass makes that pass stale, so you run the gate again. It is possible to go round three times. That is not a failure of the process, it is the process.
Everything else in this post is arrangement. This is the bit that decides whether the arrangement produces software worth paying for. Take the shape of it if you take nothing else: two lines at the bottom of every job you write down, saying how you check the output and what this must never do.
If you would like to see the thing on the other end of all this, book a demo and we will walk you through the product rather than the process.
The thing we have not built
Honesty is cheap in a post like this unless it costs something, so here is the bit that costs.
You cannot connect your own AI to your Petboost account. There is no public API, no connector, and no key for you to generate. We use the plug-socket standard internally, which is how our in-app assistant Grazi AI reads live business data instead of guessing at it, but none of that points outward at you. It is our plumbing, not your integration point.
Grazi AI is on every plan, Calendar Lite included, at no extra cost, and it runs on Claude Sonnet 5. It is read-only, formally designated experimental, and it will not book, cancel, charge, or send anything on your behalf. The longer version carries the route that does work today: export the CSV, then analyse it on your own machine.
We would like to build the outward-facing door. I will not promise it, because a date I invent is exactly the failure this series keeps warning you about.
Three things worth copying
Not the 121 skills. Three habits, in this order.
- Write the rules file first. One page. Your prices, your policies, how you talk, and the things that must never happen. The line-by-line version already exists.
- Write down the next job you catch yourself explaining twice. Not the biggest one. The second-most-annoying one, on the day it annoys you. A complete worked example exists.
- Write your own finished line. How you check the output, and what it must never do. If other people work for you, that belongs on a page they can all read.
Then, and only then, worry about making any of it run on a schedule. Making it repeat itself covers that honestly, including the part where the right answer is to open it yourself on a Monday and type one thing.
What this actually reclaims for you
I will not give you a productivity multiple, because we have not measured one and an invented figure would be the exact thing this series tells you to distrust.
What I can give you is our count, and it is ours rather than a study. There are 121 job files in our code. Hardly any of them started as a plan. They exist because somebody did the job twice and refused to do it a third time from memory.
So here is that scaled to you, as a worked example. Say two of your jobs look like ours: 20 minutes of explaining, twice a month, each. Writing each one down costs about half an hour, once. That is 40 minutes a month back per job, roughly 16 hours across the pair in a year, against the one hour you spent writing them.
The 16 hours are not really the point. The point is that the second time you sit down to explain your own overdue-client list to a machine, you'll notice you're doing it, and you'll stop. That noticing is the whole level.
And if you'd rather the boring half of your back office came already built, that is the software we make. Book a demo and bring your worst spreadsheet.