What I've learned from building 40 Claude Code skills

The third time you explain the same job to an AI, something has gone wrong.

You would never run a team this way. Imagine briefing a member of staff on the same job from scratch every single morning, and slightly differently each time. You would get the job done slightly differently each time too. Yet that is exactly how most people use AI: the same instructions, retyped from memory, every day. A business does not run on "roughly the same". It runs on repeatable process.

Claude Code has an answer to this, and it is almost embarrassingly simple. It is called a skill, and it is a folder containing a markdown file. That file holds the instructions for one job, written once, properly. Say the trigger words and Claude reads the file and follows it. Same process, every time.

I have now built 40 of them. They run my morning briefing, draft my email replies, log my time, scope my meetings, process voice notes I dictate while I am out, and produce these blog posts. This piece is the method that emerged, including the parts I got wrong.

What a skill actually is

The best way to think about a skill is a handover. Imagine handing a job to a new member of staff. You would sit down and write out how the job should be done: what it is, what good looks like, where everything lives, who to check with, and what must never happen. A skill is exactly that instruction manual. The only difference is that the new person is the AI, and it follows the manual to the letter, every time, without drifting from it after a month. If you can write a decent handover note, you can write a skill. No code for most of them.

The difference between a skill and just prompting well is permanence. A good prompt dies with the chat. A skill compounds, because every improvement you make is still there next week.

How I build them

Some skills are easy. A simple capture skill (jot an idea to a file, log a line to a list) can be built in ten minutes and will just work. The more complex ones, anything that touches email, a database, or runs while you are not watching, need thinking about more deeply. These tips are what that deeper thinking looks like in practice.

1. Build with your strongest model, run with whatever. A skill is written once and executed hundreds of times, so the quality of the instructions is where all the leverage is. I draft and refine every skill with the most capable model available, even though it costs more per session. Day to day, the skill then runs fine on faster, cheaper models, because the thinking has already been done and written down. Paying top rate for the architect and standard rate for the operator is a very old idea, and it applies perfectly here.

2. Start with the outcome, not the steps. My opening prompt describes the finished thing, not the procedure. "I want a ready to send reply sitting in my drafts for every client email that arrives" beats "first search the inbox, then look up the sender, then...". Describe the destination and let Claude propose the route. It will usually suggest steps you would not have thought of, and you correct the ones that are wrong. If you dictate the steps, you cap the skill at your own first idea.

3. Build it as a conversation, not one giant prompt. The temptation is to write everything you know into one enormous opening message. Resist it. Feed the context in stages, the way you would brief a person, and before anything gets written ask it to play back what it has understood and to ask you questions. The questions it comes back with are usually the holes in your spec, and they are far cheaper to fix in conversation than after three bad runs.

4. Tell it where you are. Context. What the business is, what already exists, what this skill sits alongside. A skill built in a vacuum will cheerfully reinvent something you already have. Mine all know they are part of one operation, so the email skill knows the task system exists and the briefing skill knows the voice notes skill exists, and they hand off to each other instead of overlapping.

5. Tell it where the data is. Name the files, the folders, the tables, the IDs. This is the difference between a skill that runs in seconds and one that spends half its time rediscovering things it knew yesterday. My skills carry the exact locations of everything they touch, so a run goes straight to work. Any time a skill has to go looking for something, that is a prompt to bake the answer into the file.

6. Do the job manually once, then say "turn what we just did into a skill". This is the single best trick I know. Work through the job in a normal conversation, correcting as you go. When the result is right, the transcript of that conversation is the best specification you will ever produce, because it contains every wrinkle you hit and every correction you made. One sentence converts it into a permanent process.

To be clear, this is a different run from the one that comes next. The manual run happens before the skill exists, and it produces the spec. Then, once the skill is drafted, do not go straight to live. Tell it you want a run-through, a dry run where it walks the whole process but writes no data and sends nothing. Nearly every skill I have built surfaced at least one problem on the dry run, and fixing it there costs minutes instead of a mess.

7. Put your trigger words in the description. Every skill has a short description, and that description is how Claude decides the skill applies. Write the exact phrases you would naturally say, not a formal summary. Mine include things like "wrap up the day" and "check my notes" because that is what I actually say. A perfectly written skill that never fires because the description is too polite is a filing cabinet, not an employee.

8. Make it safe to run unattended. The best skills run on a loop while you do something else, and that only works if the worst case is boring. My email drafting skill opens with a block of hard guardrails: it never sends, it only creates drafts, it never writes to the database, and where a reply needs a decision only I can make (a price, a date, a commitment) it leaves a marked gap in the draft instead of guessing. It also keeps a small state file recording what it has already handled, so a loop that fires every 30 minutes never drafts the same email twice. Drafts not sends, read not write, marked gaps not guesses. Get those in writing and you can let it run overnight.

9. Fix the skill, not the mistake. When a run goes wrong, correcting the output fixes today. The follow up that matters is "update the skill so that never happens again". My voice notes skill once processed the same note twice because it was matching on dates and the source list truncated. The fix went into the skill file: match on the note's unique ID, never on dates. That class of mistake is now extinct. Skills that get edited after every bad run stop having bad runs, and this is exactly how you would manage a person, except the person never forgets the feedback.

10. Review your skills when the models get stronger. This one took me longest to learn. A skill written a year ago was written for a weaker model, and it shows. Some instructions exist purely to babysit limitations that no longer exist, and those instructions now hold the stronger model back, like giving a senior hire the induction pack you wrote for a junior. Every few months I pick a skill and ask the current best model to critique it: what here is unnecessary, what is over specified, what would you do differently. The skills get shorter and better at the same time, which is usually the sign you are removing scaffolding rather than substance.

What you can take from this

You do not need my 40 skills. You need the realisation underneath them: your processes are an asset, and most businesses have never written them down. Writing a skill forces you to. It is the standard operating procedure you always meant to produce, with one difference, this one executes itself.

Start with the job you explain most often. Do it once, manually, with the AI. Then turn the transcript into a skill, add the guardrails, and put your trigger words in the description. One process, written properly, beats a hundred good prompts.

Where this is heading

The skills folder has quietly become the most valuable directory in my business, more than the code, because it is the business, written down. If you are curious what that would look like for your operation, that is the conversation AI-First exists for.