Riding at Paceskills, and when not to use one
The twelve are the whole ride. This is the extra page for whoever got to the end, enjoyed it, and now wants the horse to already know the routine before they ask for it.
By the end of this one you will have installed a skill, run it on your own work, written one of your own out of a job you keep repeating — and you will know the three cases where a skill is the wrong tool and something simpler is right.
Presented by Emile du Toit
brainitconsulting.com
Nothing here is needed. Everything the twelve promised, you already have.
- You can steer it — and you know when it is guessing.
- It works in your own folder, and asks before it changes anything.
- You have an undo, and a copy that is not on your laptop.
- Something of yours is on the internet, at an address you can text to somebody.
- And you write down what you want before anything gets built.
This page is for the one thing after that: you have noticed you are explaining the same job over and over.
Contents
- Before you startShort, and one of the items is honesty.
- What a skill actually isA folder. That is the whole surprise.
- Installing one, and where they come fromOne line, and an open directory.
- The two of ours worth havingStarting an app, and checking one over.
- Writing your ownOut of a job you already do too often.
- When a skill is the wrong answerThree cases, and they are common.
Then the questions this always raises, the words, and the picture to photograph.
Before you start
- The twelve behind you, or at least #006 and #008. A skill is a written instruction, and if writing instructions for the assistant is still new, start there instead — it is the same muscle and a gentler lift.
- An agent on your own machine. Claude Code or Codex, working in a folder. Claude in the browser can take a skill too, uploaded as a zip, but the installer on this page needs a folder to put it in.
- Node.js. The installer is
npx, which comes with it. The setup page has it. - A job you keep repeating. Bring a real one. Chapter four turns it into a skill, and an invented example teaches nothing.
- About an hour.
Honestly: most people do not need this. The twelve stand on their own, and a folder with good standing instructions in it will carry a small business a very long way. Read this when you catch yourself explaining the same job for the fourth time.
What a skill actually is
The word sounds like magic. The thing is a folder.
A racehorse and a plough horse are the same animal. What separates them is not the animal — it is that somebody already worked out the routine, wrote it down, and drilled it until it happened without being asked for. That is all a skill is: a routine somebody worked out, written down, that your agent follows when the job comes up.
Open one and there is usually no program inside. There is a folder with a file called SKILL.md in it: a name, one line saying what it does and when it should be used, and then the instructions in plain English. Sometimes a few extra files it refers to, now and then a small script it can run. That is all there is to it.
Standing instructions are read every time. A skill is read only when its job comes up.
Which tells you what a skill is for. Your CLAUDE.md is the saddle: on the horse for every ride, so it has to stay short. A skill is a piece of gear hanging in the tack room, fetched only for the job it belongs to. It can be as long and as detailed as that job deserves, because it costs nothing until the day it is needed.
Lab 1 — Read one before you install one 10 min
Ten minutes reading somebody else’s skill teaches you more than any explanation of what a skill is. They are public, and they are plain English.
Go and look
- Open skills.sh — the open directory of agent skills.
- Find any skill and open its page. Every one shows its
SKILL.mdin full, before you install anything. - Read it as if you were the new apprentice being handed it.
What to notice
- It is written to somebody, not to a machine. Numbered steps, plain sentences, the odd warning.
- The description line is doing real work. It is how the agent decides whether this job is the one — so it names the situation, not the feature.
- Most of it is about what to do when things are odd. The happy path is short. The exceptions are the value, exactly as they are in your own trade.
If you can read one and think “I could have written that” — good. You could. That is chapter four, and it is the point of this page.
Installing one, and where they come from
One line at a command prompt, and it is in the folder.
Installing a skill copies that folder into your project so the agent can find it. There is no build, nothing to configure, and nothing left running in the background. If you later delete the folder, the skill is gone and nothing else changes.
The installer is npx skills add, and it belongs to skills.sh rather than to us. There are two forms, depending on where the skill lives:
A shorthand for a GitHub repository, or the full address. Both do the same thing.
Read a skill before you install it, the same way you would read a contract before signing it. It is a written instruction you are handing your agent, and it will be followed inside your own folder. Everything on skills.sh shows you its full text first, along with what three security audits made of it — pass, warn or fail. Use that.
Lab 2 — Install one and watch it not fire 10 min
The interesting part of a skill is not that it runs. It is that it stays out of the way until the job actually comes up.
Install it
Now ask for something unrelated
Nothing happens. The skill sits there. That is correct, and it is why you can install several without your agent getting confused or your standing instructions getting longer.
Then ask for the job it is for
Now it fires, and it works to a routine somebody else already thought through rather than to whatever occurs to it in the moment.
That gap — installed but quiet until needed — is the whole difference between a skill and a line in your standing instructions. Watch it happen once and the rest of this page follows on its own.
The two of ours worth having
One to start something properly. One to check it before anybody sees it.
We publish a handful at github.com/brainit-consulting/skills. Two of them earn their keep for almost everybody, and they sit at the two moments where people most often go wrong: the beginning, and the bit just before showing it to somebody.
start-an-app
The blank-page problem, solved the way #008 solves it — by asking what you actually want before anything gets built, then laying the project out sensibly instead of however it happened to come out.
security-scanner
The chore from #011, done properly. Keys that should not be in the folder, things left open that should not be, the small mistakes everybody makes once. It reports; you decide.
Lab 3 — Point the scanner at something you actually built 15 min
Run it on the real thing from #010, not a practice folder. A scanner on an empty project tells you nothing you did not already know.
Run it
Read the answer like a quote, not a verdict
- Anything about a key or a password in the folder — fix today. That is the one that costs real money.
- Anything about what is public that should not be — check it yourself in a private browser window, the way #010 Lab 4 does. Do not take its word for it.
- The rest — ask what it would cost to fix, and decide. A finding is not an instruction.
A scanner that finds nothing is not proof that nothing is wrong. It is proof that nothing on its list is wrong. Those are different sentences, and the second one is the true one.
Writing your own
Out of a job you already do, and already explain too often.
This is the part worth the hour. Everything above is somebody else’s routine. The one that changes your week is the routine currently in your head, explained again every time, slightly differently, with something forgotten about a third of the time.
You do not write it from a blank page. There is a skill whose whole job is writing skills, and it interviews you the way #008 interviews you about a brief:
Lab 4 — Turn the job you keep explaining into a skill 20 min
Pick the real one. Writing an estimate from an email. Turning the week’s jobs into an invoice run. Checking a page over before it goes live. Whatever you have explained more than three times.
Let it interview you
Answer as if to a new apprentice
Not as if to a computer. “If there is no phone number on the email, stop and ask me — do not guess from the signature.” That sentence is worth more than any amount of structure, and it is the sort of thing only you know.
Then test it on last week
Take a job you have already done, and let the skill do it. You know the right answer, so you can see exactly where the written routine is thin. Fix the skill, not the answer — the same habit as fixing brief.md rather than the build in #008.
The first version will be wrong in one or two places. That is the normal outcome, and it is why you test it on a job you already know. A skill you have corrected twice is worth more than one that was right by luck.
When a skill is the wrong answer
Three cases. All three are common, and all three get reached for too early.
Every tool in this series has a chapter where I tell you not to use it. This one needs it more than most, because a skill feels like progress in a way that makes people build them for jobs that never needed one.
The job comes up every single time
Gear you never take off does not belong in the tack room.
Then it is not a skill, it is standing instructions. If it applies to every conversation in that folder, it belongs in CLAUDE.md where it is read every time. Putting it in a skill means it fires only when the agent decides the job has come up, which is a coin toss you have introduced for no reason.
You have done the job twice
You do not drill a routine you have ridden twice.
Then you do not know the routine yet, and a skill written now teaches the agent your first guess. Do the job by hand a few more times, notice what you actually check and what you keep forgetting, and write it when you know it. Skills written too early are the ones people quietly stop using.
It must happen, every time, without fail
A written instruction is a request, not a fence.
Then a skill is the wrong shape entirely, and so are standing instructions. Both are text the agent reads and mostly follows. If something must be true before anything reaches a customer, that is a check that runs on its own — workshop #011 — and the difference matters most exactly when you least want to be thinking about it.
Sometimes, and long enough to be worth writing down properly.
That is the whole test. If the job comes up every time, it belongs in the saddle. If it is short, just ask for it. A skill is for the jobs in between — and there are fewer of those than people expect.
Questions people actually ask
Five that come up whenever this page gets read.
Is this the same as the standing instructions from #006?
The saddle, or a tool off the wall.
Same idea, different moment. Standing instructions are read at the start of every conversation, so they have to stay short. A skill is read only when its job comes up, so it can be as long as that job needs. Most people should have one good CLAUDE.md and no skills at all for quite a while.
Is it safe to install somebody else’s?
You would read a contract before signing it.
It is written instructions your agent will follow inside your folder, so treat it that way. Read the text first — skills.sh shows it in full, along with what the security audits made of it. Prefer ones you can read end to end. If you cannot be bothered to read it, that is a reason not to install it rather than a reason to hurry.
Do I need a paid plan for this?
The gear is free. The horse might not be.
The skills and the installer cost nothing. But the labs here need an agent running on your own machine, and that is the part that may need a paid plan — the same fork in the road as workshop #005. Claude in the browser takes skills on every plan, the free one included, uploaded as a zip. The installer cannot reach it.
What happens when I change my mind about how the job is done?
Rewrite the drill, not the horse.
Edit the file. It is plain text in your folder, under the same version control as everything else from #007, so you can see what changed and put it back. That is the quiet advantage of the whole thing being written down rather than configured somewhere.
Should I publish mine?
Somebody else has the same yard.
If it is about your trade rather than your business, it is probably useful to somebody. A skill for writing plumbing estimates helps every plumber. Take your own prices, your customers and anything private out of it first — and remember that publishing is a decision you cannot really take back.
Plain words
Four new ones. Each closes with what it is on the ranch.
- Skill Pro
- Written instructions the agent reads only when that job comes up. A folder, not a program. A drill it already knows.
- SKILL.md Pro
- The file inside it: a name, one line about what it does and when to use it, then the instructions in plain English. The routine, written on the wall.
- skills.sh Pro
- The open directory skills are published to and installed from. Shows every skill’s full text before you take it. The tack shop.
- skill-creator Pro
- A skill whose job is writing skills. It interviews you rather than making you face a blank page. The trainer.
Everything on one page
If you photograph one thing from this page, photograph this.
1 · A skill is a folder
A name, one line about what it does and when to use it, and the instructions in plain English. Usually no program in there.
2 · Read it, then install it
npx skills add. It is an instruction your agent will follow in your folder, so read it first.
3 · It stays quiet
Installed but idle until its job comes up. That is what makes it different from the saddle.
4 · Write yours from a real job
One you have done often enough to know the exceptions. Let skill-creator interview you.
5 · Know when not to
Every time → the saddle. Done twice → too early. Must never fail → a check, not text.
The only thing to do next: write down the job you have explained more than three times. That sentence is the skill, and everything else on this page is how to type it up.
I do this for a living, and love to help people.
Thirty-plus years in enterprise software and a computer science degree — which mostly means I have watched a great many horses bolt, and I can usually tell you which ones are worth saddling before you spend money on the saddle.
In person
Your team, your room, your actual work on the whiteboard instead of somebody else's examples.
Over video
The same session, at your desks, with fewer chairs to stack afterwards.
Built for real
When the idea survives the workshop and somebody has to go and build the thing — that part I do too.
Fun fact — I rode to school on horseback as a kid in South Africa. So the metaphor isn't borrowed. I've done the falling off in person.
Emile du Toit brainitconsulting.com
Pro riders · Riding at Pace
© 2026 Emile du Toit, BrainIT Consulting · Print it, share it, leave my name on it.