Where the
check lives
After writing code, Claude already watches types, lint, tests, and runtime errors on its own. The manual checks that remain are the ones to encode. The harder question comes after: where that check hangs once written, and how it grows from a personal habit into a gate for the whole team.
Not "what kinds of loops exist," but where this check hangs
This blog post is by Delba de Oliveira of the Claude Code team, published 2026-07-22. It follows "Getting started with loops": that piece defines loops, sorts them into four types, and maps each to a primitive — it answers "what kinds of loops exist." This one does not repeat the taxonomy. It asks a later question: once you've decided to hand a check to Claude to run on its own, where does that check hang, and how does it grow from a personal habit into a gate for the whole team?
The post's one-line definition of a verification loop:
In Claude Code, a verification loop is an iterative process where Claude checks and attempts to fix the work.
After writing code, Claude already watches the codebase's deterministic signals — the pass/fail evidence that requires no judgment: type checkers, linters, tests, and runtime errors. What it cannot infer, especially the checks developers still run manually, is exactly what should be encoded into a verification loop.
Which types of loops exist, which primitive each uses (Turn-based / Goal-based / Time-based / Proactive), and how to choose among /goal, /loop, and /schedule — that is the other piece's subject. This one picks up after "which kind of loop to build" and only covers where a check hangs once it lands. For the taxonomy first, read "An official definition of loops: four layers and their primitives."
Before building your own, see what's already built in
Before creating a custom loop, the report suggests knowing what Claude already supports so you don't rebuild it. There are six built-in verification mechanisms, ranging from local self-checks to managed grading.
| Built-in | What it does | Status |
|---|---|---|
/verify | Builds, runs, and observes the changes in your application | built-in |
| Toolchain | Catches and acts on error codes/warnings from any tool you provide such as a linter; list your exact build and test commands in CLAUDE.md so Claude doesn't have to infer them | built-in |
| Code Review | Managed multi-agent service that runs an automated review pass on PRs in enabled repos; fix the finding and push, or comment @claude on it to close the loop | research preview |
| GitHub Actions | Define a job that invokes Claude with a verification skill; the same local checks fire on every push or PR | built-in |
| Spec validation | A skill that verifies each change against a markdown spec in the repo and looks to fix violations | built-in |
| Managed Agents rubrics | Verify outcomes against a rubric with a separate grader agent; failures loop back for rework automatically | beta |
A rubric is the scoring standard; the grader agent scores outcomes against it. Both live in Claude Managed Agents.
The corrections you keep making are what to encode
The trigger is repetition: when Claude implements a feature and the same small corrections follow each time, it's time to turn those steps into your own custom verification loop. The first step is to write down everything you find yourself doing every time.
A new project is the same: describe the best-practices version in plain English, the way you'd hand it to a new teammate on day one. When the check itself is hard to articulate, ask Claude for best practices first and edit from there — your version differs on a few specific points, and those differences are exactly what you want to capture.
"Reject any migration that drops a column without a backfill step" is a deterministic rule no generic linter will catch, though a project-specific one will. The report's one-line close: Anything you keep having to enforce by hand as a manual check qualifies for capture as a loop.
The common implementation is a skill. The fastest route is installing the skill-creator plugin and letting Claude interview you about your workflow:
/skill-creator Create a skill for verifying frontend changes end-to-end. Interview me about my workflow.
Or hand-write one: drop a markdown file under .claude/skills/. The simplest verification skill is a few lines of frontmatter plus a body:
---
name: verify-log-hygiene
description: Check that error logs include the request ID and never
include the request body. Use when the diff touches error handling
or logging.
allowed-tools: [Read, Edit, Grep]
---
Read the error-handling paths in the current diff.
For each log call on an error path, confirm it includes the request ID
and does not pass the request body, headers, or any user-supplied payload.
Report each violation with file:line, then fix it: add the request ID
where it's missing and strip the payload from the log call.
Where it runs: four patterns, one maturity ladder
The next thing to determine is how the loop kicks off. The report gives four ways — standalone, embedded, chained, on every PR. They aren't parallel options but a ladder from manual to automatic, from personal practice to team infrastructure, and each rung has a clear "you've outgrown this" signal.
| Pattern | Kicks off | Suits | Graduation signal / boundary |
|---|---|---|---|
| standalone deliberate | invoked by hand after the artifact exists | cross-cutting checks not run every time (security scan / accessibility audit / license header) | running it after every change → embed or chain it |
| embedded in the producer | fires as part of the producing skill | a check that belongs to one workflow | only for skills you can edit; chain the ones you can't |
| chained a sequence | one skill calls the next when it ends | several verified handoffs, end-to-end | skip when steps are independent; can raise token spend — test first |
| on every PR team gate | runs on every PR once the chain is stable | a team standard not reliant on the author's diligence | hold off while the chain is in flux; every change is team-visible |
Standalone · invoked by hand
You invoke it deliberately, after the artifact exists. It suits cross-cutting checks that don't apply every time — a pre-commit security scan, a pre-PR accessibility audit, repository-wide license-header verification — anything you want available across many workflows but don't want firing on every code change. The cost is that each invocation is still a turn you have to remember to take. The graduation signal is precise:
The signal that you've outgrown standalone is when you're running it after every change.
At that point the check has earned a permanent home: embed it or chain it.
Embedded · inside the producing skill
It fires automatically as part of the skill that produces the work. The check belongs to one workflow, and that workflow now runs it without you asking. The simplest form is a one-line append to the producing skill's body — the scaffold-component example below adds "after creating the component file, run eslint and address any errors before reporting completion":
---
name: scaffold-component
description: Scaffold a new React component under src/components/, including the component file, its co-located test, and an index export. Use when the user asks to create a new component.
allowed-tools: [Read, Write, Edit, Bash, Glob]
---
# Scaffold a new React component
Given a component name (PascalCase), create the following under `src/components//`:
1. `.tsx`: function component with a typed props interface and a default export.
2. `.test.tsx`: React Testing Library test that renders the component and asserts it mounts without throwing.
3. `index.ts`: re-export the default and any named exports.
Follow the patterns in `src/components/Button/` as the reference. Match the import alias style (`@/components/...`) used throughout the codebase.
# code continues...
After creating the component file, run eslint on it and
address any errors before reporting completion.
Verify the embed by invoking the skill on a fresh task and confirming the new step appears in the output; if it doesn't, the description or earlier instructions aren't pulling the appended check in. Embedding only works on skills you can edit — ones you wrote, or project-level ones whose SKILL.md is under your control. Built-in skills and plugin-managed skills (the kind overwritten on update) are off-limits; chain those instead. And skip embedded for checks that span workflows — those want standalone, so you can invoke them from any context.
Chained · turning a habit into a contract
One skill calls another at its end, and several verified handoffs run end-to-end. Members of Anthropic's Claude Code team use this in their day-to-day — a real chain:
The source line, verbatim: /code-review hunts for bugs, /simplify cleans up the diff, a /verify skill confirms end-to-end behavior, and a custom /design skill checks against guidelines in a DESIGN.md file if the change touched UI. Here DESIGN.md is the markdown file holding the team's design guidelines.
Chaining is also how you add verification around a skill you can't modify: a wrapper skill that invokes the original, then your verification skill:
Run /simplify on the current diff first.
When /simplify finishes, invoke /verify-no-public-api-changes.
The point of this step is that a personal habit becomes a contract:
What started as a habit ("I always run /verify after /simplify") becomes a contract ("/simplify always runs /verify when it finishes").
The chain runs the whole dev cycle on its own; you only step in when something escalates back. The boundary: independent steps may still need to run alone, chaining trades flexibility for automation, and chained loops can increase token spend — so test before deploying broadly.
On every PR · from personal to team infrastructure
Once the chain is solid for your own changes, the same procedure can run on every PR. A teammate's change passes the same gates whether or not they remembered to invoke the chain — the same skills, rubrics, and standards, no longer depending on the author's diligence. The report's one-line summary of the shift:
This is where verification stops being personal infrastructure and becomes team infrastructure.
The check you wrote to save yourself "two minutes a week" now saves everyone two minutes a week, on every change. The boundary: hold off on PR-wide gates while the chain is still in flux, because every adjustment becomes a team-visible event.
Whatever you automate, the creation process is the same
Once you have it down, you can expand your loop engineering — and the creation process is consistent, no matter what you're automating or in what environment:
Pick the most frequent one
Pick the manual follow-up you did most often this week.
Try built-in /verify first
Try out the built-in /verify skill first and see if it helps your process.
Write it in plain English
Write the procedure in plain English, the way you'd hand it to a new teammate on day one.
skill-creator or hand-write
Hand it to skill-creator, or drop the markdown file in .claude/skills/ yourself.
Confirm on a new task
Invoke it on a new task and confirm the check runs as part of the output, iterate if needed.
Chain it
Experiment with skill chaining to create an end-to-end verification flow.
The more you can encode for Claude to follow, the more often Claude's response will land closer to what you want on the very first try. The corrections you no longer have to fiddle with now free up your attention for the individual and exclusive work that no skill can write down for you.