The Problem
For the first weeks of building the Saiko group’s websites, I planned in one place and built in another. Most planning happened in a chat project with no access to the files; building happened in Claude Code, on the real files. I carried notes between the two by hand. Six handoff notes came out of that stretch, five of them from the chat side, and the sites shipped.
Then I ran an audit. On 2026-10-02 I had a read-only pass made over every Saiko site folder: code, release zips, rules files, the build log and every handoff. The code was fine; it matched itself everywhere. The documents around it were not:
- Four files gave theme versions that were already out of date.
- Two files gave opposite answers to “which document wins when they disagree”.
- Two handoff notes carried a name the client had asked to keep private, after the rest of the project had already been cleaned of it.
None of that had broken a page yet. But every one of those is the kind of thing that breaks a page later, and one of them was a broken promise to a client. The problem was not the code. It was that decisions lived in notes that nobody went back to.
The Rule I Started From
The same day, I rebuilt the rules files in layers: one for every build, one for the client group, one for each site. Every rule got exactly one home, and the lower files point up to it instead of repeating it.
When I set up a folder for Gambitworks itself, the business side, I gave it one rule above the others: write a page only after doing the thing once for real. Nothing goes in on theory. I have read a lot of process documents that describe a business that does not exist yet, and I did not want to write another one.
That rule shaped everything below. The playbook folder, where the manual is meant to live, is still empty. That is on purpose: it fills when a real project needs a page, not before.
Five Steps, Two Kinds of Session
The biggest change was splitting planning and building into separate sessions, both in Claude Code, so both read the same real files. Each step is a skill, a short slash command that carries its own instructions:
- Plan. A planning session reads the current rules and build log, talks the change through with me, and writes a handoff note. It changes no code. Because it reads the real files, it cannot plan from a stale picture.
- Build. A fresh session reads the handoff, does the first task, stops where the note says to stop, and writes a report back, including how each part was checked and what was not tested.
- Explain. Back in the planner, I ask what the builder just did. It explains the output in plain language, checks it against the plan, and writes my answers into a reply note the builder reads. No copying and pasting between windows.
- Report. Once the change is live, the client gets a short PDF: every change, a link to its page, a before and after picture.
- Close. The lasting decisions move into the project’s rules files, the build log gets its entry, and the handoff is marked merged. A merged handoff is history: it is kept, never edited again, and no longer a source of truth.
Each of those maps to something the audit found. The handoff template now forbids private names outright. Every handoff has a “Merged into” line, and an empty one means there is still merging to do. Only settled decisions go under Decisions; anything else is an open item with a name beside it saying who it waits on. And a report has to say how each part was checked, because a fix had once been reported as done with part of it untested.
Templates, Drafted From Real Work
The templates came from the same rule: each one was drafted from something that already existed, not invented.
- Client drive: the folder layout a client fills with content, drafted from the Saiko content folder.
- Project folder: drafted from a second client’s project folder.
- Handoff: the notes between sessions, drafted from the six Saiko handoffs, with the audit’s lessons built in.
- Proposal: split in two. First an overview and the questions I need answered; the quotation comes second, priced by deliverable with no hours shown. Clients judge the outcome, not the clock.
- Contract: a plain-language website agreement, including a clause for when content runs late: the project pauses, and after a long pause it can be closed and invoiced.
I want to be straight about where these stand. The proposal has not been sent to a client yet, and the contract has not been reviewed by a lawyer or seen by a client. They are drafts that came from real work, waiting for the real project that tests them. The folder’s own status table says exactly that, so I never mistake a draft for something proven.
The First Real Runs
The skills had their first real run on 2026-10-12, on a round of changes the Saiko Builders client sent. On that first run, the explain step caught two mistakes in the planner’s own handoff before they reached the build. That alone justified splitting the sessions.
Between 2026-10-12 and 2026-10-15, four rounds went through the full loop on that one site: two photo rounds and two theme releases. The handoff folder now holds 27 notes in date order, so it reads as one conversation between the planner and the builder. Each round ended with a client report.
The skills kept changing as the rounds went. Reply notes replaced pasted replies. Questions got numbered. The close step learned to tidy a round that had been merged by hand. A system you build from real work keeps learning from real work.
When the System Was Too Heavy
The process is built for client changes on live sites, where a mistake costs someone else. It turned out to be too much for my own blog. Publishing my previous Workshop post took five sessions and four long documents for one post.
So for blog posts I replaced the plan, build, explain and close loop with a single skill, /post: one session from idea to published, and I approve each step with a button. Client work keeps the full loop. This post went through /post.
That is the part I would underline: a system is not finished when it is written. It is finished when it fits the size of the job.
What I Would Tell Someone Else
- Write it down after, not before. A page written after doing the thing once is short and true. A page written before is long and hopeful.
- Give every rule one home. When the same fact lives in two files, one of them is already wrong.
- Close your notes. A note that is merged and marked closed cannot quietly disagree with your rules later.
- Check the work in a different session from the one that did it. The planner caught what the builder missed, and the other way round.
If you want client work that runs on a process you can see, tell me the problem, and we’ll work out the fix together.