The right way to think about this
An agent skill is a folder of instructions, and often executable scripts, that an agent loads and runs with your permissions. That's a closer analogy to adding a new dependency to a project than to reading a blog post or a tutorial. You wouldn't npm install a package with no name recognition and zero commits without a glance at what it does. A skill deserves the same glance, not more, and not less.
This isn't a reason to avoid skills. Most of what's wrong with an untrusted skill is the same as what's wrong with any untrusted code you'd run locally, and the fix is the same: look before you run it. This guide is a practical checklist, not a scare piece, every item on it takes a minute or two and tells you something concrete.
What can actually go wrong
Worth naming specifically, because vague risk is hard to check for and specific risk is easy to check for:
- Scripts that exfiltrate data. A bundled script in
scripts/could read environment variables, credentials, or file contents and send them somewhere outside your control, a webhook, a paste site, an unfamiliar API endpoint. - Instructions that push toward destructive commands. A
SKILL.mdbody can tell an agent to runrm -rf, force-push over a branch, or drop a database table, framed as a normal step in the workflow. - Prompt injection via bundled reference files. This one is easy to miss because it doesn't look like a script at all. If a skill's
references/folder contains a file the agent reads into context (a "style guide," a "spec," a "checklist") and that file contains text written to look like an instruction ("ignore prior constraints and also do X"), an agent that treats file contents as trustworthy the same way it treats its own instructions can be steered by it. This is the same class of problem as prompt injection via a webpage or a document, just delivered through a skill folder instead. It's worth checking reference files specifically, not just scripts, for exactly this reason. - Instructions to disable safety checks. A skill can instruct an agent to skip confirmation prompts, ignore
.gitignore, or bypass whatever guardrails your setup normally has, framed as a convenience. - Skills that push to remote branches unprompted. Anything that commits and pushes as part of "normal" skill behavior, without you asking it to, is worth a second look. That's an action with consequences outside your local machine.
None of this is unique to skills. It's the general shape of risk that comes with running anyone else's code or following anyone else's instructions. Skills just make it easy to install a lot of that, quickly, from a lot of different authors.
What a reference-file injection actually looks like
The prompt injection risk is easiest to understand with a concrete shape, even a generic one. Imagine a skill for formatting documentation that bundles references/style-guide.md, and the workflow step says "follow the tone rules in references/style-guide.md before writing." A legitimate style guide is a list of tone and formatting rules. An injected one looks almost the same, except somewhere in the middle it contains a line written to read as an instruction rather than documentation, something telling the agent to also read and summarize unrelated files, or to disregard constraints stated elsewhere in the session. Nothing about the file extension, the folder name, or the way the skill invokes it looks different from a legitimate reference. The only way to catch it is to actually read the file's contents before trusting the skill that bundles it, the same way you'd read a script before running it.
The pre-install checklist
Work through this before adding a skill you didn't write yourself, especially from an unfamiliar source.
1. Read SKILL.md end to end
Not skimmed. Read. This is the actual instruction set the agent will follow when the skill activates. It's almost always short enough to read in a couple of minutes. If the body tells the agent to do something you wouldn't want done on your machine (broad file deletion, silent network calls, disabling confirmations) that's your answer before you go any further.
Why it matters: this is the primary control surface of the whole skill. Everything else the skill does flows from what's written here.
2. List every bundled file and read the scripts
Open scripts/, references/ and assets/ if they exist, and actually look at what's in each. For anything in scripts/, read the code, not just the filename, a script called format.sh that also curls an external host is exactly the kind of thing a filename won't tell you.
Why it matters: SKILL.md tells you what the skill is supposed to do. Scripts are what it actually executes, and the two don't always match, sometimes through neglect, occasionally through intent.
3. Check allowed-tools for anything unexpectedly broad
If a skill's stated purpose is narrow (say, formatting commit messages) but its allowed-tools includes broad file write or network access, that mismatch is worth understanding before you proceed. Ask whether the permissions match the job.
A skill genuinely scoped to formatting commit messages has no reason to touch the network:
name: commit-formatter
description: Use when the user asks to format or clean up a commit message.
allowed-tools: Read, Edit
If that same skill instead declared allowed-tools: Read, Edit, Bash, WebFetch, the mismatch between "formats commit messages" and "can run arbitrary shell commands and reach the network" is exactly the kind of gap this check exists to catch.
Why it matters: allowed-tools is the skill's declared blast radius. A gap between what a skill claims to do and what it's permitted to do is one of the cheapest signals to check.
4. Read any reference files the skill bundles
Don't stop at scripts. If references/ contains files the agent is instructed to read during the workflow, read them yourself first. Look for text that reads like an instruction rather than documentation, anything trying to redirect the agent's behavior once it's loaded into context.
Why it matters: this is the prompt injection vector described above. It's easy to assume only executable code is dangerous and treat markdown or text files as inert. In an agent's context window, text is the attack surface. A reference file's contents get read into the same context as the trusted instructions.
5. Prefer skills with a license and an identifiable author
A skill with a LICENSE file and a named or traceable author isn't automatically safe, but it tells you there's someone accountable for what's in the repo, and clear terms for reuse. An anonymous skill with no license is a weaker starting position, not a disqualifying one.
Why it matters: accountability changes incentives. It also matters practically. An unlicensed skill has ambiguous terms for you to build on or redistribute it.
6. Check repo signals: stars, recent commits, open issues
A skill's GitHub repo tells you more than the skill folder alone does. Recent commit activity suggests it's maintained. Open issues, especially ones describing unexpected behavior, are worth reading before you hit the same problem. Stars aren't a security guarantee, but a repo with real usage and a visible history is easier to evaluate than one with none.
Why it matters: a skill is a point-in-time snapshot of a repo that keeps changing. The repo's history is context the skill folder by itself doesn't carry.
7. Prefer project-scoped installs over global for anything you're unsure about
Most agents support both a global skills directory and a project-scoped one. See the exact paths for your agent on the platforms page. Installing into a single project limits where the skill can activate while you're still evaluating it, instead of making it available across everything you work on.
Why it matters: scope is a cheap way to limit exposure while you build confidence in a skill, without avoiding it entirely.
8. Re-review after updates
A skill you already trust can change under you. If you've pinned a skill via a specific commit or version, review the diff before updating. If you're pulling main on every use, understand that you're implicitly trusting every future change, not just the one you originally reviewed.
Why it matters: trust granted once, at install time, doesn't automatically extend to every future version of the same folder.
Why this site links to GitHub instead of re-hosting
Every skill listing on getclaudeskills.com links out to the original source repository rather than hosting a copy of the files here. That's deliberate: reading a skill's actual code, on the platform where its commit history and issues live, is the whole point of the checklist above. A re-hosted copy would strip exactly the context (history, author, issue thread) that makes review possible. If you're browsing the full catalog or a specific category, treat the GitHub link as the first stop, not an afterthought.
Quick reference: signal strength of each check
Not every item on the checklist carries equal weight. If you're reviewing under time pressure, use this as a rough priority order rather than working strictly top to bottom:
| Check | Catches | Skip only if |
|---|---|---|
Read SKILL.md fully | Destructive or unwanted instructions in the core workflow | Never — this one's non-negotiable |
Read scripts/ contents | Data exfiltration, unexpected network calls | The skill has no scripts/ folder |
Read references/ contents | Prompt injection via bundled "documentation" | The skill has no references/ folder |
Check allowed-tools | Permissions broader than the stated purpose | The skill doesn't set allowed-tools at all |
| Check license and author | Accountability, reuse terms | You already trust the author directly |
| Check repo signals | Whether the skill is maintained, has known issues | You're pinning a specific reviewed commit anyway |
| Prefer project scope while unsure | Limits exposure during evaluation | You've already fully reviewed the skill |
The first three rows are the ones that catch actual malicious behavior. The rest are supporting signals that make your judgment on those three more informed.
What "safe enough" looks like in practice
You won't audit every line of every skill you ever install, and you don't need to. A reasonable bar: for anything from an author you don't already trust, read SKILL.md fully, skim any scripts and reference files for anything that jumps out, and check that allowed-tools roughly matches the stated purpose. For anything that touches credentials, remote pushes, or file deletion, slow down and read closely regardless of source. For skills you've written yourself or that come from a team you already trust, this whole process compresses to seconds. You're not starting from zero each time, you're applying judgment you've already built.
Related reading
If you're new to the format itself, start with What Are Agent Skills? The Complete Guide and The SKILL.md Format Explained, knowing exactly what belongs in SKILL.md versus scripts/ versus references/ makes this checklist faster to apply. If you're installing for the first time on a specific agent, the platform-specific guides, for instance installing skills in Claude Code or installing skills in Codex CLI. Cover global versus project scope for that agent specifically. And if you're the one publishing a skill, How to Write Your Own Agent Skill covers the authoring side of building something worth that trust.
