As we delegate more ambitious tasks to Claude, it becomes increasingly important that it can verify its own work.
The more Claude can self-verify:
• the more independently it can work on long-running tasks
• the better the quality of the final result
• the fewer back and forths it takes to get there
VIDEO
The good news is that Claude already self-verifies against deterministic signals like type errors, lint errors, failing tests, and runtime errors. And as models improve, this will only get better.
What Claude can’t always infer are the manual checks you run after it responds, and later on, before you merge code into production.
The more of those checks you can encode, the closer Claude’s first response gets to the final result you had in mind.
The more of those checks you can encode, the closer Claude’s first response gets to the final result you had in mind.
You spend less time babysitting, and Claude can keep going while you work on something else.
## Write down your processes
A good place to start is to write down the best-practices version of what you or your team already do.
For frontend, that's usually: run the dev server, open the browser, check the console for errors, click around as the user would and look out for things like layout shift or slow navigations.
Every domain has its own version. For each of those steps, there's likely a tool Claude can use for verification:
## Encode your process as a skill
Once the process is clear, encode as much of it as possible as a skill. Install the `skill-creator` plugin, then ask Claude to interview you:
/skill-creator Create a skill for verifying frontend changes end-to-end. Interview me about my workflow.If you're struggling to put your process into words, ask Claude for the domain best practices first and let it show you what an end-to-end verification flow might look like.
Taste and judgment are difficult to codify, but many checks have criteria Claude measure against: a performance budget, an accessibility checklist, design system rules, good vs bad examples.
Taste and judgment are difficult to codify, but many checks have criteria Claude measure against: a performance budget, an accessibility checklist, design system rules, good vs bad examples.
For example, a frontend skill might include instructions to capture a performance trace through the Chrome DevTools MCP or Agent browser.
---
name: frontend-verify
description: Verify frontend changes in a browser. Run whenever
a UI (page, component, typography, CSS style) change is made.
---
# Frontend verify
- Run a two-step verification pass in a real browser.
- Fix issues and re-verify before responding to the user.
## Step 1 — Verify the change behaves as expected
1. Open the URL in a browser:
- In the Claude Code desktop app, use the embedded preview.
- In the CLI, use the Chrome DevTools MCP.
2. Interact with the new element and confirm it renders and
behaves as expected.
## Step 2 — Verify the change passes a mobile audit
1. Open the URL in a new page via the Chrome DevTools MCP
2. Run a performance trace and audit Core Web VitalsOther checks are more qualitative than pass/fail, like comparing data against historical norms. For these, you can work with Claude to set a rubric for evaluating output.
Generated by Thread Navigator
Press ⌘ + S to quick-export