The Claude skills I built, and why

Watch a Japanese bus driver pull away from a stop and you'll see something that looks, at first, a little theatrical. They point at the mirror and say it out loud. Point at the signal, say it out loud. Point at the speedometer, call the number. There is nobody else in the cab. They are not talking to anyone. It's called shisa kanko, pointing and calling, and it's standard practice on Japanese buses and trains because it works. Not because the driver has forgotten how to drive (they've done this route a thousand times) but because putting the eyes, the arm, the mouth and the ear on the same check catches the thing your brain would happily skim past at the end of a long shift. It's a way of taking knowledge that lives quietly in someone's head and forcing it out into the open, so it gets done the same way every single time.

I think about my Claude skills the same way. They are the pointing and the calling. More than that, they're the checks the assistant performs for me, naming each item out loud and confirming it while I keep my hands on the wheel.

Let me back up and say what a "skill" even is, because that word is doing a lot of heavy lifting.

What a skill actually is

When I work with Claude inside my codebase, I can type a normal sentence, and it does its best. That's fine for one-off questions. But a lot of what I do isn't one-off. It's the same multi-step chore, over and over, that I want done the same careful way each time. Adding a new database table. Reviewing my own changes before I commit them. Checking the whole project for security holes before a feature launch.

A skill is just a written-down version of that chore. It's a Markdown file (a set of instructions and a workflow) that lives in my project under a folder called .claude/skills/. Each one has a name and a short description at the top, then the body spells out, step by step, exactly what to do. When I type /review-code, Claude reads that file and follows it like a recipe.

The closest human analogy isn't some magic spell. It's teaching an apprentice your house rules. "In this shop, we always sand with the grain, we always dry-fit before glue, and we never skip the final coat." You write it down once. After that, the apprentice does it your way without being reminded, and a new apprentice can read the same notes and get up to speed. I hope that lands, because the rest of this article is just five flavors of that same idea.

I've built multiple so far, but I would share on five. Each one was born from a specific chore I was tired of doing by hand, or tired of doing inconsistently. Let me walk through them.

review-code: a gate, not a suggestion

The first and most-used skill reviews my code before it goes anywhere. But the interesting part is how it reviews.

Here's the problem with asking one AI assistant to "review this code." A single reader, looking at everything at once, gets tired in the same way a single human reviewer does. It notices the obvious naming issue and glosses right over the subtle missing database filter. Attention is finite, even for a machine.

So instead of one reviewer, this skill spawns seven reviewers (subagents), and each one is a specialist. One looks only at type safety. One looks only at error handling. One looks only at performance. One only at security. One checks whether the change actually does what it was meant to do. And they all look at the same change at the same time.

That phrase, "agents in parallel," sounds technical, but it's an everyday idea. Imagine handing a contract to seven lawyers and saying, "you check the liability clauses, you check the payment terms, you check the termination conditions," and they all read their slice at the same time in separate rooms. You get back seven focused reports in the time it takes to read the contract once, instead of waiting for one exhausted generalist to do seven passes. Each of my seven agents knows only its narrow job, so it does that job well.

When the seven come back, an eighth agent (a verifier) re-reads the lines they flagged and throws out the false alarms. AI reviewers, like nervous junior engineers, sometimes report problems that aren't really there, or cite a line number that's slightly off. The verifier checks their homework before I ever see it. I hope you are still with me 🙂.

Then the skill does something I lean on hard: it scores the change out of ten. It starts at a perfect 10 and subtracts points: two for a real security hole, one for each lint error, half a point for a style slip. A security vulnerability caps the whole thing at 5 no matter what.

Why a number? Because a number can be a gate. I wired this skill into a husky "pre-commit hook," which is a little script that runs automatically the moment I try to commit my code (save my work into the project's history). The hook runs the review, finds the line that says FINAL SCORE: 7 / 10, and decides: below 5, it blocks the commit outright; 5 to 8, it stops and asks me; above 8, it waves me through. That single contract, one line of plain text in an exact format, is the reason the rest of the skill is allowed to be elaborate. The hook doesn't need to understand the review. It just needs to read the score. So, in the skill's instructions, that final block is sacred: get everything else right but never break that one line.

That's the skill that catches my mistakes before they become history. And of course, I can then go on to address any issues raised from the code review.

add-crud: the same four operations, every time

Most of what a web app does, underneath, is embarrassingly repetitive. You store a kind of thing (a customer, a prompt, an invoice) and you need to Create it, Read it, Update it, and Delete it. We call this CRUD, and you build it again for every new kind of thing.

The frustrating part isn't that it's hard. It's that it's long. For one new resource I have to touch the database schema, the validation rules, the service that talks to the database, the list of web addresses the server answers, the request handlers, the frontend code that calls the server, and the actual screen with its table and its create-and-edit pop-ups. Eight layers. Miss one and the feature is half-built.

So, I wrote down the whole assembly line. The add-crud skill asks me a few questions first (what fields does this thing have, does it need special permissions, any unusual rules) and then walks every layer in order. It even reads an existing, finished resource first and copies its patterns exactly, the way a careful apprentice studies one well-made chair before building the next. The database schema is the source of truth, and everything else derives from it, so the types can't quietly drift out of sync. By the end I have a working feature instead of a pile of TODOs.

This is automation in its plainest, most honest form: not cleverness, just refusing to type the same eight-step dance by hand ever again!

new-project: scaffolding a whole new house

My code lives in a "monorepo," which is one big repository holding several separate sub-projects side by side. Starting a brand-new one is a special kind of tedious. There's a backend, a frontend, a shared library, and a thick layer of plumbing that connects them: the workspace config that tells the tooling these folders belong together, the build settings, the deployment manifests.

The new-project skill scaffolds all of it. Its trick is that it doesn't generate from nothing. It copies an existing small project as a template, then strips out that project's specific business logic to leave a clean, working "Hello World" skeleton. I copy the house that already stands, then take down the interior walls, rather than pouring a new foundation from scratch.

The part I'm proudest of is the very last step, and it's almost invisible. The skill registers the new project in a little file that all my other skills read to learn which projects exist. So, the moment scaffolding finishes, add-crud, review-code, and the rest already know about the new project and can work on it, with no extra wiring. The skills know about each other through one shared registry. Teach the system once, and the whole system learns.

security-audit and fix-audit: find, then fix

The last two are a pair, and the split is deliberate. Finding problems is one job and fixing it is another job. If you ask a person to find issues and fix them at the same time, issues have a way of getting smaller. A person will find fewer problems every time, so they have less things to fix. It turns out AI is not that different.

security-audit is the finder. Like the code reviewer, it works as a fan-out of parallel specialist agents (six of them this time) but aimed at a whole project instead of one change. Each agent owns a slice of a long checklist I keep in a file: authentication holes, database query bugs, leaked secrets, missing rate limits, insecure deployment settings, and more. To stay fast on a big codebase, the agents don't read every file. They grep first, meaning they search for risky patterns, like a building inspector who knows the three places water damage loves to hide and checks those before crawling the whole attic, and they only read closely where the search points. Then verification agents double-check the serious findings, and the whole thing gets written to a dated report on disk, ranked by severity. Crucially, the auditor never fixes anything. Its only job is to tell the truth about the current state.

fix-audit is the fixer, and it reads that report. This is the most careful skill I've built, because applying fixes is where you can do real damage. It sorts each finding into a bucket: a tidy one-or-two-line change, a more involved targeted fix, a sweeping cross-cutting refactor, or something that needs me to make a judgment call. The easy mechanical fixes get batched together. The targeted ones run in parallel, but only in groups where no two of them touch the same file, so they can't trip over each other. The big sweeping refactors run one at a time and ask my permission before each. Every fix is supposed to come with a test proving it actually worked. And the whole skill is forbidden from ever committing anything. It leaves all its changes sitting right in front of me, uncommitted, so I review the diff and decide what's real.

The reason I split finding from fixing is the same reason a doctor who diagnoses you isn't rushed into surgery in the same breath. Diagnosis should be honest and complete. Treatment should be deliberate, reversible, and consented to. Two skills, two mindsets.

Why bother writing any of this down

I could do all five of these chores by hand. I used to. What I was really losing wasn't time, it was consistency. On a good day I'd remember to scope the database query to the right account and to leave the password field out of the response. On a tired day I might not, and that's exactly the day a bug ships.

A skill takes my best day and makes it the only kind of day I have. It's the bus driver's pointing finger again: the point isn't that I've forgotten how to drive. It's that I've written down how I want it done, so it gets done that way whether I'm sharp or exhausted, and so the next person who reads these files inherits the same standards without me having to stand over their shoulder.

That, in the end, is all a skill really is. A house rule, written down, that the assistant follows so I don't have to remember to. (Maybe more on how I chain these skills together in another article 🤔.)

Whatsoever thy hand findeth to do, do it with thy might. - Ecclesiastes 9:10