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.

How to write down the checks you do every time

The first step is writing. Write out those little corrections you make every time, one by one.

Describe the "best practice" version in plain language, as if you're handing it to a new teammate on day one. No need for documentation-speak — just the tone you'd use when delegating a task.

If you find you can't articulate what a check is actually looking for, there's a reverse approach: ask Claude what the common practice is for this kind of thing, use that as a draft, then adapt it to yours. The points where your way differs from the common practice are exactly what deserve to be written down — because those are the parts nobody else will remember for you.

A verification Skill you can copy directly — just over a dozen lines

The easiest approach is to have Claude interview you in reverse. Install the skill-creator plugin, then type this:

/skill-creator Create a skill for verifying frontend changes end-to-end. Interview me about my workflow.

Writing it by hand isn't hard either. Drop a markdown file into your project's .claude/skills/ folder and that's a Skill. The smallest example is just over a dozen lines, and it checks whether error logs include the request ID and whether the request body ever gets written into them:

---
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.

The last sentence is the whole point of the Skill: reporting isn't enough — after reporting, fix it. It first gives you a list with line numbers, then adds the missing request ID and strips whatever shouldn't be in the log from the call. Without that second half, it's just an alarm — it beeps and waits for you to act.

Where the check runs: four positions

Once the check is written, the next question is when it fires. Four positions, from "you remember to call it" all the way to "attached to every PR." Change the position and the same check becomes a different thing.

Standalone: it runs when you remember

This is the level where the thing already exists, and it only runs when you actively trigger it.

It suits checks that span many workflows but don't need to run every time you change code. Three typical cases: a security scan before committing, an accessibility review before opening a PR, and a license-header check across the whole repo. These are checks you want to be able to call from anywhere, but you don't want them jumping out after every line of code you touch.

The cost is real: every invocation is an action you have to remember to take. Forget, and it didn't happen.

The signal for moving up a level is this: when you find yourself running it after every single change, it's time to stop relying on your memory. At that point, the workflow has earned a permanent home — move it to one of the next two levels: embed it, or chain it.

Embedded: add one line to the end of the Skill that generates code

This level lets the check ride along with the workflow that produces it, without you saying a word.

It's simpler than it sounds: just append a sentence to the end of that Skill's body. Take a Skill that scaffolds React components — everything before is its original content, and the only addition is those last two lines:

---
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/<Name>/`:

1. `<Name>.tsx`: function component with a typed props interface and a default export.
2. `<Name>.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.

How do you verify it actually works? Call the Skill with a brand-new task and watch whether the new step shows up in the output. If it doesn't, the Skill's description or its earlier instructions failed to pull that step in — go back and fix it.

This level has a clear boundary: it only works on Skills you can edit. Your own Skills qualify, and so do project-level ones where the SKILL.md file is in your hands. Built-in Skills and plugin-managed ones don't — the latter get overwritten entirely on update, so your additions would be lost. For those two categories, you'll need the chaining approach from the next level.

And one rule in reverse: don't embed cross-workflow checks. Those you want to be able to call from any context — leave them at the standalone level.

Chained: the four-Skill relay inside Anthropic

When one Skill calls the next at its own end, several verified handoffs join into a chain that runs end-to-end.

Anthropic's Claude Code team uses this pattern daily, and their chain has four links:

Chaining has another use: adding verification to Skills you can't edit. Make a wrapper Skill that calls the original one first, then runs your check when it's done:

Run /simplify on the current diff first.
When /simplify finishes, invoke /verify-no-public-api-changes.

Here's where the nature of the thing shifts: before, it was a habit — "every time I run /simplify, I run /verify after." Now it's a contract — when /simplify finishes, /verify will run. The chain walks the whole development loop by itself, and only the decisions that need your call get escalated to you.

The cost is spelled out too. If the steps are independent enough that you sometimes want to run just one, don't chain them — chaining trades flexibility for automation. Also, chains burn noticeably more tokens, so test on a small scale before rolling it out wide.

On every PR: your teammates' changes go through the same gates

Once the chain runs smoothly on your own changes, the same flow can move onto every PR.

Nothing changes underneath: same Skills, same rubric, same standards. What changes is whose work it applies to.

At this point, verification stops being your personal infrastructure and becomes the team's infrastructure. The check you wrote to save yourself two minutes now saves everyone two minutes on every single change.

But there's a warning: while the chain is still being iterated on, don't roll it out to the whole team yet. Once it's live, every adjustment you make becomes an event the entire team can see.

Why chaining burns more tokens, and two switches that save them

Chaining costs more tokens, and the official docs spell out exactly where that money goes.

When you or Claude invoke a Skill, the rendered SKILL.md content enters the conversation as a message and stays there for the rest of the session. It doesn't leave when it's done.

So every line of a Skill's body is a recurring cost: with four Skills chained, those four bodies sit there permanently, and every subsequent turn has to carry them again. That's also why the official docs stress keeping Skill bodies short — write "what to do," not "how and why."

Two switches that save tokens

Two numbers worth knowing before you start writing Skills:

The six-step playbook

Whatever you're automating and wherever you're doing it, the order of these six steps is the same.

The more you can write down what you want and hand it to Claude to follow, the closer its first attempt gets to what you had in mind. And the fewer things you have to correct over and over, the more attention you free up for the things no Skill can write down for you.

Delba de Oliveira, closing words of the original post

A Skill is just a markdown file (a plain-text format, editable in Notepad) under .claude/skills/ in your project. Write the steps you do every time in plain language, like handing them to a new teammate on day one. The smallest one in the post is just over a dozen lines — it checks whether error logs include the request ID and whether user-submitted content gets written into them.

To have it run automatically without you asking, append a sentence to the end of the Skill that generates code. In the component-scaffolding Skill below, the only change is the last few lines.

The added line says: after creating the component file, run the code linter on it, fix any errors, then report completion. From then on, every generated component automatically carries this step. Three templates you can copy wholesale are in the full article.

Once the check is written, the next question is when it fires. The same check at a different position becomes a different thing.

Chaining costs noticeably more, and the Claude Code docs spell out where it goes: when a Skill is invoked, its body enters the conversation as a message and stays there for the rest of the session. With four Skills on the chain, those four bodies sit there permanently, and every turn after that has to carry them again.

Two switches that save: add a line with context: fork to run it in a separate subagent, keeping its body out of your main context; and keep Skill bodies to "what to do," not "how and why."

These three numbers come from the official Claude Code docs — hard limits worth knowing before you start.