ISSUE 32 · ME+MACHINE
I was casually browsing X and came across a repo someone had posted. A repo is basically a shared folder of files that others can look through, and this one was full of descriptions of game mechanics. It was such an epiphany. Of course other people have solved all of my problems before! Why did I think I needed to solve these things myself?
I’d spent weeks explaining game logic to AI, like how to build a chicken farm where you hatch the chickens, take care of them, and they produce eggs. AI was actually pretty good at a lot of it. But I don’t know anything about game development, and a lot of very smart people had already worked this out.
So before you start a new project, look for what already exists. In school they called it copying homework. In real life, it’s just smart. If someone has already written down how to do it, the AI can start from what worked instead of from scratch. A lot of the time, that write-up is packaged as a skill.
What a skill is
A skill is a folder with a text file in it called SKILL.md. That file holds the instructions for one specific task, written in plain language. The folder can also hold extra files the instructions point to, like examples, or small programs called scripts that the AI can run.
Your AI tool doesn't read every skill in full at the start of a conversation. It only sees each skill's name and a short description. When what you ask for looks like a match, it opens that skill's full instructions and follows them, and it only pulls in the extra files if it needs them. When people say a skill "loads," that's what they mean.
Because the name and description are all the AI sees before it decides, the description needs to say what the skill does and when to use it. Here's the description of a skill I have installed in Claude for building slide presentations called frontend-slides by Zara Zhang.
Create stunning, animation-rich HTML presentations from scratch or by converting PowerPoint files. Use when the user wants to build a presentation, convert a PPT/PPTX to web, or create slides for a talk/pitch. Helps non-designers discover their aesthetic through visual exploration rather than abstract choices.
The first sentence says what it does. The part that starts with "Use when" tells the AI when to reach for it. Without that part, the AI has to guess.
Where to look, and what to check
A lot of skills are shared on GitHub, a website where people post repos so others can look through them and copy what they need. A good place to start is skills.sh, a site that lets you search skills from lots of different repos. Each listing shows which repo it came from, so you can read the files before you add anything to your own setup. Anthropic keeps its own collection of example skills on GitHub too.
A couple of places and a few searches will usually tell you whether something close already exists. If the results keep missing what you need in the same way, your problem might really be new.
When you do find one, check their homework before you copy it. Ask four questions first.
Does it fit what I'm doing? A skill written for a slightly different problem brings its author's assumptions with it. If you'd have to rewrite half of it, adapting it becomes its own project.
Can my AI tool use it? Not every tool supports skills, and the ones that do expect them in a particular place. Your tool's help pages should say.
Am I allowed to reuse it? Public doesn't automatically mean free to reuse. Look for the license, a file that says what you're allowed to do with it. Even Anthropic's own collection mixes skills anyone can reuse with ones you can only look at.
Do I trust where it came from? This is important! A skill can include scripts the AI can run, and instructions that tell it to connect to outside websites or send your files somewhere else. A bad one can open security holes or leak your data. Only install skills from sources you trust, and if you can't tell what something does, don't use it.
When nothing fits, write it down
If you're going to explain it more than once, save it. That way you don't have to explain it again, and you don't have to keep re-deciding things you've already decided.
A good skill gives reasons, not just rules. For each instruction, write down why it works, the way you'd explain it to someone new. Keep each skill to one topic. Use lists or tables so the AI doesn't have to guess, and be specific, giving exact values instead of leaving room for it to make up its own. Then try it on a real task and look at what comes back. (This approach is adapted from Emil Kowalski's essay "Agents with Taste".)
Anthropic also publishes a skill called skill-creator that helps you write one. I highly recommend running the same task with and without your skill to see whether it actually helps.
THE 30-SECOND VERSION
Before you start a new project, look for what already exists.
Check that a skill fits, that your tool can use it and that you're allowed to reuse it.
Most of all, make sure you trust where it came from.
If nothing fits, write your own, with reasons for every rule.
If you're going to explain it more than once, save it.
Don't count your chickens before they hatch. And definitely don't spend weeks teaching an AI how to hatch them before checking whether somebody already wrote down instructions.
me+machine.