7.2
Finding And Vetting Skills
Why this exists
Thousands of skills exist, written by strangers, free to install. Most are fine. Some are thin. A few would do something you didn't intend on a machine that can reach your files and your systems.
You now have exactly the access that makes this worth thinking about — which is why this lesson sits here and not back in Level 1.
The idea
A skill is instructions your AI will follow on your machine. Read it before you run it.
That sentence is the whole lesson. It sounds obvious and almost nobody does it, because installing feels like installing an app — a transaction with a vendor — when it's actually closer to letting a stranger write your procedures.
Popularity is not safety. A repo with a lot of stars is more likely to be reputable and it is not a guarantee. Star counts can be manufactured, and plenty of well-starred repos contain skills nobody has read carefully. Popularity tells you something about attention, not about what the file does.
What to actually check, in about two minutes:
| Check | What you're looking for |
|---|---|
| Read the body | Do the instructions match the description? |
| What does it touch? | Files, network, credentials, anything that sends |
| Does it delete or send? | Irreversible or outward-facing actions |
| Is it specific? | Vague skills produce vague output |
| When was it updated? | Two years old may assume a world that's gone |
The mismatch check is the one that matters. A skill described as "formats your notes" whose body reaches out to a network is not necessarily malicious — but the gap between what it says and what it does is the single best signal that something's wrong, and you can spot it by reading.
Ask Claude to review it for you, and be specific: "Read this skill file. What does it actually do? Does anything in it touch the network, credentials, or delete files? Does the body match the description?" That's a genuinely good use of it — reading a file and reporting structure. Then verify anything alarming yourself, per 2.1.
The honest framing: rejecting is cheap and normal. You are not obliged to use something because you found it. Most skills you look at won't be right — too vague, too specific to someone else's setup, doing something you'd rather do yourself. Passing on six and keeping one is a good afternoon.
And the alternative is always available: write your own. That's 7.4, and for anything specific to how you work it'll be better than anything you'd find.
Do
- Find where skills are shared — ask Claude for the main sources.
- Pick six that sound useful for something you actually do.
- For each, open the file and read the body. Not the README. The skill.
- For each, ask Claude: "What does this skill actually do? Does it touch the network, credentials, or delete anything? Does the body match the description?"
- Verify anything concerning yourself by reading the relevant lines.
- Keep three. Reject three. Write
vetted.mdwith a line per skill: what it claimed · what it does · keep or reject · why. - For each rejection, say which check failed.
- Note any that were rejected only because they're vague — those are candidates to write yourself.
Step 6's ratio is deliberate. If you kept all six you weren't reading carefully; if you rejected all six you may be looking in the wrong place.
Done when
Never do
Never install a skill you haven't read. It's instructions your AI will follow on a machine that can reach your files and systems. Reading takes two minutes.
Never treat popularity as vetting. It means people looked. It doesn't mean people read.
Never install something that touches credentials without understanding exactly why it needs them. Almost nothing legitimately does.