Named by 11 of 26 clients, and increasingly tested by screen share
Four things the agent
got wrong building this.
Clients stopped asking whether you use Claude Code and started asking questions a portfolio cannot answer. Share the rules from your CLAUDE.md and what caused each. Tell me about a bug you fixed with it, including one thing the agent got wrong and how you caught it. Two of them now put you on a screen share with somebody who uses it daily.
Everything on this page came out of building the other pages on this site, over 33 commits in two days, against a CLAUDE.md of 280 lines and 51 skills. Those numbers were counted by a command rather than remembered, which is itself one of the rules.
What it got wrong, and what caught it
It marked six requirements as demonstrated while none of them were reachable in public.
A script, not a person. It fetches the live site and refuses to let a row say demonstrated unless the page answers and contains what it claims. Its first run reported 0 of 41 against my 6.
The agent had been reporting against a seven item list it wrote itself, while the research it was working from held 41. Every individual report was true and the impression was false.
It shipped a page reading a data file from a directory that is in .gitignore.
Checking git before deploying rather than after. The page would have rendered a "no data" fallback in production while looking perfect locally.
A runtime file read also is not traced by the bundler, so even a tracked file might not have shipped. Both are now static imports, which fail the build instead of the page.
It wrote a monitor that truncated a page to 4,000 characters and then searched it for something at 6,000.
The monitor immediately reported a healthy system as broken, which is the good outcome: the false alarm arrived on the first run rather than the fiftieth.
A monitor that cries wolf is worse than no monitor. The first alarm gets investigated, the third gets ignored, and the fourth is real.
It wrote a test that agreed with the code and therefore found nothing.
A reviewer, not the suite. The address guard asserted that one spelling of a loopback address was blocked and never tried the same address written in hex, and they walked through the gap to a local server.
Every table in the suite now includes an address that must still work, so a guard cannot pass by refusing everything.
Three of the four were caught by something written down rather than by somebody noticing. That is the argument for the rules below: an agent working fast produces mistakes faster than a person reviewing it can see them, so the review has to be a script wherever it can be.
Five rules from the file, and the behaviour that caused each
Nothing is reported unless it was proved.
The audit tool reported the Facebook links on two live client sites as dead. Both loaded perfectly in a browser: Facebook answers 400 to anything that is not a logged-in session, and so does facebook.com/nasa, which I used as a control. One wrong finding costs you the whole report, because the reader checks it, finds it working, and stops believing every other line.
Only 404, 410 and 5xx count as gone. Everything else is "could not check from here" and is left out.
Count it before you claim it.
A number went into a document from memory instead of from the system, twice in one day, and both times it was too low. The instruction now names where each number has to come from, and a recollection is not on the list.
This page says 51 skills because a command counted the files, and 33 commits because git counted them.
QC means opening it and clicking it.
A page was reported as working on the strength of a 200 response. A 200 tells you the server answered, not that a button does anything, and not that the layout survives at 320 pixels. The rule now names the widths and says to click every control one at a time.
Every page here was screenshotted at five widths and every interactive one was driven in a real browser.
A failed request is not proof of anything.
This started as a rule about other people’s links and turned out to be a rule about everything. It has since caught a menu page being called broken because a server rate limited us, a monitor calling an eval broken because it read the wrong half of the page, and me deciding a concurrent session had deleted my work because one command failed.
It is the most reused sentence in the file and it was written for a much smaller problem.
Never auto-commit.
Nothing dramatic. It exists because an agent that commits on its own removes the last place a person looks before something becomes permanent, and the cost of asking is one sentence.
Every commit in this work was made after being asked for.
The rest of the file is client specific and stays private. What is worth saying about it is the shape: almost every line exists because something went wrong once, and a rule with no incident behind it usually turns out to be a preference somebody is enforcing on everybody.
A twelve file diff arrives to fix one slow query. What I check
- Does the diff touch anything the goal did not mention? A fix for one query that edits a config file is two changes wearing one commit.
- Is there a test that fails before it and passes after? Without that the change is a claim.
- Did anything get deleted? Removing a check is the cheapest way to turn a suite green.
- Does it change behaviour on a path the goal did not name? A rename that touches a public export is an API change.
- Would I be able to explain each file to somebody who did not watch it happen? If not, it is too big and it gets split.
The one that rejects most often is the first. An agent asked to fix one thing will happily fix four, and a diff that does more than it was asked is harder to review than four diffs that each do one thing.
The part nobody puts on a portfolio
Working this way is faster and it fails differently. A person writing code by hand makes fewer mistakes per hour and catches most of them while typing. An agent makes them faster than anybody can read, and the dangerous ones are the plausible ones: a test that agrees with the code, a monitor looking at the wrong half of a page, a claim that is true in isolation and false in aggregate.
So the useful skill is not prompting. It is knowing which claims to distrust and building the check that distrusts them for you, before you need it.
Every defect on this page is written up in full, with the wrong diagnosis that was tried first, on what broke. The script that caught the first one is described on proof of work, and it still reports the gaps at the same size as the wins.