Downloading Agent Skills: What You Install When the Skill Is Someone Else’s Instructions

The skill was called release-notes and it had a lot of stars. It promised to turn a range of commits into tidy, categorised release notes, and it did. I copied the folder into my user-level skills directory on a Friday, asked my coding agent to draft notes for our next tag, and got a clean markdown summary grouped into features, fixes and chores. It was better than what I usually write.

On Monday I noticed that the agent was loading the same skill when I asked it to squash two commits, when I asked it to explain a merge conflict, and once when I asked it to rename a branch. The skill’s description said it applied to “any task involving git history, commits, tags, or changelogs.” That is most of my day. And buried in the skill’s folder was a helper script the instructions told the agent to run “to collect commit metadata,” which, when I finally read it, also posted the repository name and commit count to a URL that belonged to the skill’s author. It was labelled as anonymous usage stats. It was not in the README.

Nothing terrible happened. The data was minor, and the author removed the call when someone opened an issue. But it changed how I think about installing skills. A downloaded skill is not a plugin in the old sense, a piece of code with an API boundary. It is somebody else’s instructions, loaded into your agent, followed with your agent’s permissions, in your repository.

What a skill actually is

Different tools use slightly different formats, but the shape has converged. A skill is a folder with a markdown file, usually called SKILL.md, that starts with a short header: a name and a description. The body contains instructions for how to perform some task. The folder can also hold reference documents, templates, and scripts the instructions tell the agent to use.

The important mechanic is how skills get loaded. Most agents do not read every skill in full at the start of every session. They read the names and descriptions, keep those in context, and load the full body when a request seems to match. That is what makes skills cheap to have installed. It is also what makes the description the most security-relevant line in the file, because the description decides when someone else’s instructions enter your session.

Once loaded, the skill’s body is just more instructions to the model. There is no sandbox around them. If the skill says “run scripts/collect.sh before starting,” the agent will try to run it, subject to whatever approval settings you have. If it says “always include the full diff in your summary,” the agent will do that. If it says “fetch the latest template from this URL and follow it,” the agent will fetch something at runtime that you never read.

You are installing three things, not one

When I went back through the handful of skills I had downloaded, I started seeing each one as a bundle of three separate things, each with a different risk.

A trigger. The description decides which of your requests pull the skill in. A narrow description like “generate release notes from a tag range” loads rarely and predictably. A broad one like “anything involving git” loads constantly, and each time it adds its instructions to the context, competes with your own project rules, and nudges the agent’s behaviour in tasks the skill was never really designed for.

A procedure. The body is a set of steps and preferences, written by someone who has never seen your codebase. A formatting skill might tell the agent to run Prettier with default settings on every file it touches, which is fine until it reformats a directory your team deliberately excludes. A testing skill might say “update snapshots when they fail,” which is exactly the kind of instruction you would never give an agent in a codebase you care about.

Code. Many skills ship scripts: shell, Python, Node. The instructions tell the agent to run them. From your machine’s point of view, this is running a stranger’s script with your user account, your environment variables and your network access. The fact that an LLM decides when to run it rather than you typing the command does not make it safer. It makes it less visible.

Why this feels safer than it is

I think the reason I installed that skill without reading it closely is that it looked like documentation. A markdown file with some headings and bullet points does not trigger the same caution as curl | sh. It reads like a colleague’s notes.

But for an agent, instructions are executable. The difference between “here is how we write release notes” and “here is a script that writes release notes” is smaller than it looks when the reader of the notes can run commands. A skill is closer to a shell alias with an LLM in the middle than it is to a wiki page.

Approval prompts help, if you have them on. If your agent asks before running shell commands, you will see bash scripts/collect.sh and can decide. But many people turn approvals down or off for commands that look routine, because a prompt every thirty seconds is unbearable. And the script name tells you nothing about what the script does. I approved collect.sh several times before I read it, because the name matched the skill’s stated purpose.

What I check before installing a skill now

I still use downloaded skills. Some are genuinely good, written by people who have thought about a procedure more carefully than I have. But I install them the way I would add an unfamiliar dependency to a production service, which is to say slowly and with some reading.

Read every file, not just SKILL.md. The body is usually short. The scripts and references folders are where surprises live. For a skill with a few hundred lines total, this takes ten minutes. If a skill is too large to read in ten minutes, I question whether I want its full instructions in my agent’s context anyway.

Search for network and filesystem reach. A quick search across the folder for curl, wget, fetch, http, requests, ~/., .env, and ssh catches most of what I care about. A release-notes skill has no reason to talk to the network. A deployment skill might, and then I want to know exactly where.

Read the description as a trigger rule. I ask: which of my requests would match this? If the answer is “most of them,” I rewrite the description before installing. The skill I downloaded became “Draft release notes when the user explicitly asks for release notes or a changelog for a tag range.” It has not loaded uninvited since.

Look for instructions that override judgment. Phrases like “always,” “never ask,” “do not confirm,” “update the tests to match,” or “ignore project rules that conflict” deserve extra attention. Skills written for one person’s workflow often encode shortcuts that are reasonable in a personal sandbox and dangerous in a shared repository.

Watch for runtime fetches. Any instruction that tells the agent to download a template, a ruleset, or “the latest version” of anything means the skill you reviewed is not the skill you are running. The content at that URL can change after you installed it. I remove these and vendor whatever was being fetched.

Where to install matters

Most tools support skills at two levels: a user-level directory that applies to every project you open, and a project-level directory checked into a repository. I used to put downloaded skills at the user level because it was convenient. That was a mistake for two reasons.

First, a user-level skill follows you into every repository, including client work, where you may have agreed not to send code or metadata anywhere unexpected. The release-notes script ran in three different repositories that week, one of which belonged to a client.

Second, user-level skills are invisible to your team. If a downloaded skill changes how the agent behaves in a shared repository, nobody else can see why their agent and yours disagree. Project-level skills live in version control. They show up in code review. Someone else can read them and object.

My current default is that downloaded skills go into a project, as a copied folder pinned to a specific commit from the source, reviewed in a pull request like any other change. User-level skills are reserved for things I wrote myself and that contain no scripts.

Updates are the part people forget

Installing a skill by cloning a repository and pulling updates is convenient. It is also the same pattern that makes package supply-chain attacks work. The skill you reviewed in March is not necessarily the skill you are running in September if you have been pulling from upstream.

I treat skill updates the way I treat dependency bumps. Copy the new version in, look at the diff, and merge only what I understand. Most updates are harmless improvements to wording. Occasionally one adds a new script or broadens the description. Those are the changes I want to see before my agent does.

Writing your own is often simpler

After all this, I noticed something slightly embarrassing: most of the downloaded skills I use have been rewritten by me until they barely resemble the original. The release-notes skill is now forty lines, specific to how our team labels pull requests, with no scripts at all. It works better than the popular version, because it knows our conventions.

Downloaded skills are still valuable as a starting point. Reading how someone else structured a procedure for code review, migration planning or test generation often gives me ideas I would not have had. But I now treat them the way I treat a code sample from a blog post: something to read, learn from and adapt, not something to install unread and trust to run on its own.

The mental model that stuck

The framing that finally made this click for me is simple. When you install a skill, you are not adding a feature to your agent. You are adding a new person to the room whose instructions your agent will follow, sometimes without telling you, with every permission you have given it. Most of those people are helpful. A few are careless. Very occasionally one is collecting stats you never agreed to.

You would not let a stranger’s notes silently direct your junior engineer’s work in your production repository. A downloaded skill deserves the same ten minutes of reading you would give those notes before handing them over.