Get Full Access 50% off

Blog 4 min read

Before you trust a SKILL.md

Agent skills are instructions your AI follows without asking twice. That makes them useful, and it makes them an attack surface. How to vet a skill before you let it near your codebase, and where to find ones worth trusting.

Agent skills are having a moment. Cursor reads them, Claude Code reads them, and a growing pile of directories and GitHub repos offer skills for everything from Git hygiene to deploying on Cloudflare. Drop a SKILL.md in the right folder and your AI suddenly knows how to do something it didn’t know before.

Which is exactly why you should read one before you install it.

A skill is code you run with your voice

A skill isn’t documentation. It’s instructions your agent follows, with your permissions, in your project. When a skill says “run this command to verify the setup,” your agent runs that command. When it says “fetch this URL for the latest reference,” your agent fetches that URL.

Most skills are written in good faith. But the format has no sandbox of its own: the trust model is you. A malicious or just sloppy skill can tell an agent to run a shell script it shouldn’t, send data somewhere it shouldn’t go, or quietly steer every future edit in a direction you never chose. Security folks call this prompt injection; for practical purposes, it’s the same care you’d apply to a shell script from a stranger.

Treat installing a skill like adding a dependency, because that’s what it is.

The five-minute vet

Before a skill goes anywhere near a real project, I read it and check five things:

  1. Read the whole file, including anything it references. Skills can link to other files in the same folder: scripts, reference docs, templates. The SKILL.md might be innocent while a referenced setup.sh is not. If you wouldn’t run the script by hand, don’t let a skill run it for you.
  2. Look for network calls. URLs the agent is told to fetch, endpoints to POST to, “check for updates” instructions. A design-conventions skill has no business phoning home.
  3. Look for shell commands. Some skills legitimately run things: a release skill runs builds. But the commands should be readable, specific, and explainable. Piped-to-shell installers and encoded strings are an immediate no.
  4. Check who wrote it and why. A skill from the tool’s vendor, or from the author of the code it describes, has aligned incentives. A skill from a random listing has whatever incentives it has.
  5. Watch the scope. A skill for formatting commit messages that also gives itself opinions about your deploy pipeline is overreaching. Narrow skills are auditable; sprawling ones aren’t.

None of this is exotic. It’s the same review you’d give a pull request from outside the team, applied to a file most people currently install without opening.

Where to actually get skills

The safest sources, in rough order:

  • Your tools’ vendors. Anthropic publishes official skills, and Cursor ships and documents its own skill format with curated examples. Vendor skills are reviewed, maintained, and have a reputation attached.
  • The authors of the code the skill describes. A framework’s own skill for using that framework, a theme’s own skill for extending that theme. The author knows the conventions because they wrote them, and they have the most to lose from a bad skill.
  • Community directories and awesome-lists. Useful for discovery, but a listing is not a review. Everything from these sources gets the five-minute vet, no exceptions.

You may have guessed the pattern: proximity to the code is trust. The further a skill travels from the codebase it describes, the more skeptical you should be.

Why Lexington skills are extracted, not collected

Every Lexington theme ships its skills in the repository, written by me, extracted from that theme’s actual code. The design skill documents the tokens and spacing the theme really uses; the rules encode conventions you can verify by reading the source sitting next to them. There’s nothing to fetch, nothing to install, and nothing in them I haven’t run against my own catalog first.

That’s not a boast about my trustworthiness. It’s the structural point: skills that live with the code they govern can be checked against that code. A skill you can audit in one sitting, from the person who wrote what it describes, is a different object from a mystery file in a listing.

Use skills. They’re the best quality lever AI-assisted work has right now. Just read them first, the whole file, every time.

/Michael Andreuzza