How I build this site: one task, one pull request
This site is built one small task at a time. Each task gets its own branch, its own tests and its own pull request, and nothing reaches the live site until it has been reviewed and every check has passed. Here is how that works, and why I work this way.
Most of the building and reviewing is done by AI agents in Claude Code, working inside rules written into the repository. They do the work; every decision about what gets built is still mine.
Start with what to build
Before any code, the project has three documents: the requirements (what the site must do, and for whom), the architecture (how it is put together, and why), and the design (how it looks and feels). Every decision in them is mine. When something is only a guess, it is marked as provisional until I approve it, so a guess never quietly turns into a requirement.
From those documents comes a plan, split into tasks small enough to review in one sitting. Each task names the requirement it serves and the result that proves it is done.
One task, one branch
Every task starts on a fresh branch in its own folder, cut from the staging branch. Two tasks never share a branch, so each one can be reviewed, tested and undone on its own.
A large task is never split into a second one halfway through. A bug found along the way is fixed on the same branch, as part of the same work.
Tests first
Each change begins with a test that fails, because the behaviour it describes does not exist yet. Then the code is written until the test passes. A test that has never failed proves nothing: it may be passing for the wrong reason.
Before anything is pushed, every check runs on my machine: unit tests, lint and type checks for the web app, the API and the deployment scripts.
Review until nothing is left
When a task is built, a separate reviewer agent reads the change against its requirement and the project's rules. The reviewer can only report, not edit, so it has no reason to go easy on its own work.
Every finding is fixed, small ones included, and the change is reviewed again. A task is clean only when a review comes back with zero findings. Some take one round; the Resume trim that cut it from four pages to three took four.
Then the pull request
Only a clean branch is pushed. Its pull request says what changed and why, which requirement it serves, every check that was run and every decision I made along the way.
Continuous integration runs the checks again on a clean machine, including browser tests and an accessibility scan of every page. When everything is green, the change merges into staging. Production is a separate step that I take myself, when I decide to release.
Why bother
Working this way is slower per task, but it removes the expensive kind of surprise. Every change on this site can be traced from the requirement that asked for it to the pull request that shipped it. That is the same discipline I bring to client work: small steps, proof at each one, and nothing shipped on hope.