Before you install an Agent Skill, inspect what it can do.

An Agent Skill can include scripts that run on your machine — so it deserves the same scrutiny as any other code you install. This is not a reason to avoid skills; most are benign and useful. It is a reason to look before you load. This guide is a practical checklist.

For context on what a skill is, see What are AI Agent Skills? and the SKILL.md guide.

Why skills deserve code-like scrutiny

A skill isn't only text. Its instructions can direct an agent to run scripts, call tools, read files and reach the network. Because the agent executes on your behalf, a malicious or careless skill can do real damage — exfiltrate data, install software, modify files. The risk is similar to installing a package or running a script from the internet.

That said, the overwhelming majority of skills are harmless. The goal is to confirm that, not to assume the worst.

Read SKILL.md first

Start with the instructions themselves. A trustworthy skill states clearly what it does. Watch for instructions that seem to hide intent — for example, telling the agent to ignore your other instructions, to act secretly, or to fetch and run remote code at runtime.

Inspect scripts

Open every file in scripts/. Read what they do. Be cautious of obfuscated code, encoded blobs, or scripts that download and execute further payloads. Small, readable scripts are easier to trust than large opaque ones.

Check shell commands

If a skill runs shell commands, look at exactly which ones. Commands that curl a remote URL and pipe it into a shell, or that modify your shell profile, are red flags. Understand the commands before you approve them.

Look at network calls

Any outbound request is worth noticing. A skill that posts your files to an unknown endpoint, or that "phones home" with environment details, is a serious concern. Legitimate network use is usually obvious and tied to the skill's stated purpose.

Look for credential access

Check whether a skill reads environment variables, tokens, SSH keys, or secrets. Some skills legitimately need credentials to do their job — but you should understand which, and why.

Review package installation

Some skills install dependencies (for example via npm or pip). Installation runs code, so treat it as part of the trust decision. Prefer skills that declare their dependencies explicitly.

Check filesystem writes

Note where a skill writes. Writing into your project is expected; rewriting dotfiles, modifying config outside the project, or deleting files is not.

Check provenance

Who wrote the skill, and is this the real one? Prefer skills from authors you trust or repositories you control. Namespace collisions and typosquats are the same threat they are in any package ecosystem — see the marketplaces guide.

Pin versions where appropriate

If a skill can update remotely, a pinned version lets you review what runs and update deliberately. Avoid setups that silently pull and execute the latest code without your involvement.

Understand runtime sandbox differences

How much a skill can do depends on the agent and environment running it — local CLI, hosted product, or containerised runtime. The same skill may have broad access in one context and restricted access in another. Know the runtime before you install.

A quick pre-install checklist

• [ ] Read SKILL.md and understand the intent.
• [ ] Read every script in scripts/.
• [ ] Identify shell commands, network calls, and credential access.
• [ ] Confirm where files are written and what packages are installed.
• [ ] Verify provenance and pin a version.

Frequently asked questions

Are skills dangerous? Not inherently. Most are benign. The point is to inspect them, because they can run code.

Do I need to be a developer to check a skill? Basic reading of SKILL.md and small scripts is often enough to form a judgment. For anything complex, get a second opinion.

Does my agent sandbox skills? It depends on the agent and how you run it. Confirm the runtime's capabilities before installing.

Where do trusted skills come from? Prefer authors and repositories you control or have reason to trust, and pin versions.