Anthropic's official guide to turning manual code checks into Skills that verify and fix themselves
- After the AI changes code, it can see compile errors, type errors, failing tests, and linter warnings on its own. The checks only you know about still require you to click through them every single time.
- The Claude Code team's approach: write down the steps you keep doing by hand in plain language, save them as a Skill, and the AI can run and fix them itself. The smallest example is just over a dozen lines.
- Writing the check is only half the battle. The other half is where it lives: called only when you remember, embedded in the Skill that generates code, chained so one Skill automatically triggers the next, or attached to every PR. The further along you go, the less you have to think about it — but the harder it is to change.
- Anthropic's own Claude Code team runs a four-skill relay daily:
/code-reviewfinds bugs,/simplifycleans up the diff,/verifyactually runs the app to see the results, and if the change touches the UI, a custom/designcheck runs against DESIGN.md. - The cost is spelled out too: once a Skill is loaded, it stays in the context until the session ends, so the longer the chain, the more tokens you burn. Also, since v2.1.215,
/verifyand/code-reviewonly run when you explicitly invoke them — they don't fire on their own.
After the AI changes code, which checks does it run on its own — and which still need you?
Anthropic's official team shared how they build a verification loop in Claude Code: turning the checks you'd normally do by hand into automated Skills, so the AI can correct itself. The author is Delba de Oliveira from the Claude Code team, published July 22.
In short, a verification loop means Claude checks its own work after writing code, finds problems, and fixes them — without you hovering over your screen like a supervisor.
Here's what you probably do now: you ask the AI to change a feature, it says it's done, then you open the page and click through it, skim the logs, and drag the browser window down to phone width. Every single time, those steps fall to you. These are the ones you want to hand off.
First, let's look at the full picture of how the AI works.
There's a detail in this diagram the post doesn't mention: when verification fails, the arrow points back to "Gather context," not "Take action." In other words, it doesn't just retry with the same information — it goes back, reassesses the situation, and then decides what to do.
The verification step already partly happens on its own. A codebase is full of machine-readable signals: compiler errors, type-check failures, failing tests, linter warnings. When any of these appear, the AI sees them and knows to turn back.
The trouble is the other half — the half with no error text to look at.
- Compiler errors
- Type-check failures
- Failing tests
- Linter warnings
- Whether that button gets hidden at phone width
- Whether that error log writes the user's request body into it
- Whether the data from a dropped column in this migration was backfilled into the new structure
- Whether this change matches the team's design specs
Nothing on the right side of that list will ever raise a machine alert for you. So they always land back on your desk, as the things you click by hand. The next step is turning those right-side checks into signals the AI can read too.
Six built-in checks in Claude Code, and what each one does
Before you build from scratch, look at what's already installed. Claude Code ships with six, each sitting at a different spot — some need you to call them, some run on their own.
