The Claude Code team published its internally used "verification loop" practice on 2026-07-22: instead of handing over code the moment Claude finishes writing it, have Claude run four checks on itself first. This article focuses on the verification layer — 4 built-in self-check skills, how to write a verification skill of your own, and 4 levels of automation. If you're already familiar with the general agentic loops pattern (loop, feedback, tool calls), this piece is the "verification layer" you stack on top of your existing loop.

Official sources:

• Building Verification Loops in Claude Code with Skills
• Getting Started with Loops

What the Verification Loop Changes

The official definition: an iterative process in which Claude checks and attempts to fix its own work.

The traditional agentic loop closes with "gather context → take action → human review," and that last step bottlenecks on a person. The verification loop changes it to:

gather context → take action → automated verification → fix → verify again

Checking and fixing get pushed back into the loop, and the AI evolves from "can write code" to "can check the code it writes."

Two kinds of checks need to be distinguished:

• Deterministic signals: type checker, linter, test runs, runtime errors — Claude already reads these and fixes them in passing.
• Project-specific judgment: whether the UI looks right, whether the flow feels smooth, whether this change planted a landmine — historically only a human could watch for these. Anthropic's answer is to wrap each manual check into a Skill so Claude executes it automatically in every task.

The 4 Built-in Self-Check Skills

The four steps the Claude Code team runs every day:

• /code-review: reviews code changes specifically, flushes out potential bugs, and produces a review write-up — effectively a tireless reviewer.
• /simplify: cleans up the current change's diff, cutting out the twisty complex implementations so the structure gets simpler. Adds no features — only subtracts, keeping maintenance cost down.
• /verify: performs end-to-end verification, actually running things to confirm the feature is truly done rather than "looks done." Write the build/test commands clearly in CLAUDE.md and it will follow them.
• /design: only steps in when the UI was touched; it checks the visual implementation line by line against the repo's DESIGN.md to see whether anything has drifted.

Only after all four run is the work delivered. These 4 Skills add one more pass on top of Claude Code's general foundation (built-in /verify, PR multi-agent review, GitHub Actions auto-triggers).

How to Write Your Own Verification Skill

Step 1: Write the Manual Check in Plain Language

Write down the step you do manually every time, as if briefing a new colleague on their first day.

If you get stuck just describing what the check should be, have Claude produce a generic best-practices version first, then edit it. The points where your version differs from the generic one are exactly the ones most worth writing down.

Step 2: Turn Vague Judgment into Hard Rules

A check cannot stay at the level of fuzzy judgment like "does it feel right."

💡 Tip: A typical project-specific red line — "any change that drops a database field without a matching data migration step gets sent back, no exceptions." This is a homegrown rule a generic linter will never catch, yet it is specific to your project. Any red line you can only hold by manually staring at it all the time is worth turning into a loop.

Step 3: Hand It to skill-creator or Just Write the Markdown

Pick one of two ways:

• Invoke skill-creator and let it interview you for a few minutes before generating one automatically.
• Drop a Markdown file into the .claude/skills/ directory yourself.

The simplest verification Skill is a few lines of description plus a body.

Step 4: Invoke It Once to Confirm It Actually Runs

Invoke it once on a new task and confirm the check really executes alongside.

💡 Pitfall to avoid: When you hit a Skill you can't modify (built-in ones, plugin-hosted ones), write a wrapper Skill that first calls the original and then calls your verification — the check still gets embedded.

Verification Isn't One-Size-Fits-All: 4 Levels of Automation

Four levels, loose to tight:

The official name for that middle transition is "from habit to contract": what used to be the personal habit of "I always remember to run /verify after /simplify" becomes, once chained, the fixed contract of "/simplify automatically calls /verify when it finishes."

⚠️ Important: Chained verification genuinely burns tokens. Don't set every check as a PR gate that blocks every submission right out of the gate. The right approach is to first see whether it holds steady, then step up gradually.

Verification Results

All four levels switched on is the destination, not the starting point. The suggested minimal verification chain:

/code-review → /verify → /simplify

Run this chain at the Chained level for a week, watch token consumption and the bug interception rate, then decide whether to pull it up to On-every-PR.

FAQ

• Are Skills and Markdown prompts the same thing? No. A Skill is a capability module holding instructions, file structures, scripts, tool calls, configuration, and a whole workflow — a way to distill a team's checklists, design standards, and hard-won lessons into an on-call package.
• Will this lock me into Claude Code? Skills are turning from a Claude Code feature into a cross-vendor open standard: GitHub Copilot, Cursor, OpenAI Codex, and Gemini CLI have all adopted the same format, so the Skills a team builds are portable.
• Model gaps keep shrinking — what actually differentiates? Agent capability = model + tools + verification mechanism + workflow. The model item is converging across vendors; what truly differentiates is the other three, all of which sit in your hands.
• Does this mean AI can write software independently? No. This is process optimization for AI-assisted development; it still depends on engineers and cannot deliver production-grade work without people.

Who This Fits

• Running medium-to-long tasks with Claude Code (>5 rounds of interaction) and already having a basic agentic loop in place.
• Teams with a fixed code review checklist, design standards, or migration rules that they want to distill into automated steps.
• Being willing to bear extra token cost in exchange for higher first-pass delivery quality.