Check a skill before you trust it.

You shouldn't have to spend 30 minutes auditing a stranger's markdown before you trust your agent with it. Every skill, rules file and MCP server here passes an automated scanner. A person reviews entries when they can, and only reviewed ones say Verified: the review covers the exact bytes, so change one byte and the badge comes off. Most entries haven't been reviewed yet, and the count at the top says how many have.

The skill on the right looks harmless. Step 2 hides an instruction in characters you can't see. Press Check, or paste your own.

Check before you install Runs in your browser. Nothing is uploaded.

The registry

Verified scanner + human review of these exact files Scanned scanner passed, review pending Review outdated files changed since review

How checking works

Built from what actually goes wrong: skills that fail to load, skills that never trigger, and the attacks researchers have documented in skills, rules files and MCP servers.

Does it load

Frontmatter against the Agent Skills spec: name is 1–64 lowercase characters and matches its folder, description is at most 1,024 characters, no unknown fields. YAML that doesn't parse (usually an unquoted colon). Links to references/ or scripts/ files that aren't there.

Will it trigger

The agent only reads the description when deciding whether to use a skill. Descriptions that are too short, or never say when to use the skill, are flagged, because a skill that never triggers is just as useless as a broken one.

Hidden text

Unicode Tag characters (decoded, so you see the hidden message), bidirectional controls, zero-width characters, variation-selector smuggling, and long HTML comments that GitHub doesn't show but the agent reads.

Instructions that turn on you

"Ignore previous instructions", "don't tell the user", fake <IMPORTANT> blocks, and instructions to send keys or tokens to a URL. Mentions of SSH keys, cloud credentials or other agents' MCP configs.

Risky code

curl | bash, decode-and-execute, reading credential files, copying the whole environment in a file that also makes network calls, cron jobs and shell-profile edits, sudo, binaries nobody can read, and real API keys.

MCP servers

Package versions pinned exactly, no plain-http remotes, Docker images pinned by digest. The server's tool descriptions are captured from the running server, scanned, and kept so a later change shows up as a diff.

What a check can't tell you

  • A clean scan means nothing obvious is wrong. It doesn't mean the skill is good. That's what a human review is for, and most entries haven't had one yet.
  • For MCP servers we check the config and what the tools say about themselves, not the server's source code.
  • Pattern checks catch known tricks. A new trick can get past them, and a person can miss it too.

Field test: Anthropic's official skills

We ran the scanner over all 19 skills in anthropics/skills at commit 34040c9. 14 had no issues. 4 needed a look: three descriptions never say when to use the skill, and one script installs a package without pinning its version. 1 was blocked: claude-api has a 1,068-character description, over the spec's 1,024 limit. The first run raised seven false alarms. Each was fixed and is now a test that keeps it from coming back.

Submit a skill

Or through GitHub

  1. Check it here first. Fix every problem, or be ready to explain why it's safe.
  2. Open a pull request adding registry/<name>/ with the files and a godsplan.yml saying where it came from and under what license.
  3. The scanner runs on the pull request. Anything allowed past a check needs a written reason, and that reason is shown on the entry page.
  4. A maintainer may review it when they have time, and runs godsplan review, which pins the review to the content hash. Until then it is listed as Scanned.