Choosing good skills and reading them safely

Thousands of skills are now published in public repositories, and quality varies enormously. Some encode years of hard-won practice; others are a vague paragraph with a grand name. A few are actively harmful. Because a skill is instructions your agent will follow, and sometimes code it will run, choosing one deserves the same care as installing any software. This chapter covers how to spot a good skill and how to review it safely in a few minutes.

What a good skill looks like

The most useful skills tend to encode a discipline the model wouldn’t follow by default: writing a failing test before the fix, finding the root cause before changing code, checking contrast and spacing before calling a design done. If the instructions only restate common sense, the skill adds little beyond the context it costs.

Reading a skill safely

Reviewing a skill is mostly reading. You don’t need to be a security expert, but you should look at every file the agent might read or run.

1. Read SKILL.md top to bottom

• Does the description match what the body actually does?
• Does it tell the agent to ignore, override or hide anything from other instructions or from you? That’s a red flag.
• Does it ask the agent to send data anywhere: post to a URL, email a summary, upload files?
• Does it ask for credentials, tokens or environment variables, and if so, why?

2. Open every other file

Reference files are instructions too. A malicious instruction can hide in a long reference document the agent reads later, so skim them all, including any that look like data.

3. Read the scripts carefully

• Network calls: look for curl, wget, fetch, requests, sockets or anything that contacts a host. Is each one necessary and to a host you recognise?
• Downloads and execution: piping a download into a shell, or fetching code to run later, means the code you reviewed isn’t the code that runs.
• File access: does it read outside the project, such as your home folder, SSH keys, browser data or cloud credentials?
• Destructive actions: deleting, overwriting or force-pushing without asking.
• Obfuscation: base64 blobs, minified code or encoded strings in a small utility script are worth questioning.
• Dependencies: if it installs packages, are they well known and pinned?

A hit isn’t automatically bad. A skill for a web API will mention URLs. The point is to find each instance and understand it.

Keep a safety net while you learn to trust it

• Keep the agent’s permission prompts on for shell commands and file writes, at least the first few times you use a new skill.
• Try new skills in a throwaway branch, a copy of the project or a sandboxed environment.
• Watch the first run. Most agents show which files are read and which commands run.
• Don’t give the agent broader access than the skill needs: no production credentials for a writing skill.
• Re-review when a skill updates. A trusted skill can change after you installed it, so pin to a version or commit if you can.

A review checklist you can reuse

1. The source is a repository I can inspect, with a licence and a maintainer.
2. The description is specific and matches what the body does.
3. The body adds real know-how, not generic advice.
4. No instruction tells the agent to hide actions, ignore other instructions or bypass approvals.
5. Every script is readable and I understand what it does.
6. Network calls go only to expected hosts, for documented reasons.
7. No file outside the project is read without a clear reason, especially credentials.
8. Secrets come from environment variables I control and are never logged or sent elsewhere.
9. Destructive actions ask for confirmation.
10. I’ve tried it once with permission prompts on and watched what it did.

AAgent safety checklistPromptA printable checklist for reviewing agents and skills.Free promptSecurity Review ChecklistAgent skillA skill that walks an agent through a security review.Agent skill · MITOOpen-source license review checklistPromptCheck a skill’s licence before you use or share it.Free prompt

Where to look for good skills

Start with skills from teams that publish their work openly and maintain it: tool vendors documenting their own products, well-known engineers sharing their workflows, and curated collections that review what they list. Our directory shows each skill’s source repository, licence and the files inside it, so you can read before you download. The Claude Code starter skills list is a good first stop.

Key takeaways

• The best skills encode discipline and specifics the model wouldn’t apply by default.
• Read every file: SKILL.md, references and scripts.
• Look hard at network calls, credential access, downloads and destructive commands.
• Keep permissions tight and prompts on until a skill has earned your trust.