Every skill is now scanned before it reaches your team

A skill is a folder of instructions your AI tools will follow. That makes sharing one an act of trust: whatever is in that folder — a pasted API key, a colleague’s email address, a run of invisible Unicode characters hiding text no human reviewer will ever see — travels to every machine that installs it. We looked at how skills get shared across the ecosystem right now, and the honest answer is: zipped up and posted, with at most a check that the frontmatter parses. Nobody is reading the contents.

As of this week, shareskills does. Every time a skill is created or updated — from the web, or by an agent over MCP — the full file tree is scanned by a deterministic validator. No LLM, no network calls, no judgement calls: the same input always produces the same findings, and the checks themselves live in a versioned contract file, not in code.

What we scan for

• Leaked secrets — cloud access keys, API tokens, private-key blocks, signed tokens, connection strings with embedded passwords, webhook URLs. Placeholder values like YOUR_API_KEY are recognised and left alone.
• Personal data — real email addresses and personal home-directory paths that reveal who wrote the skill on which machine.
• Invisible-Unicode smuggling — Unicode tag characters, bidirectional overrides and zero-width characters: the raw material of instructions that are invisible to a human reviewer but perfectly legible to the agent that installs the skill.
• Discoverability — a description too brief to trigger. This one matters more than it sounds: Vercel’s evaluation found agents never retrieved the relevant skill in 56% of their eval cases. A skill that never fires is indistinguishable from no skill at all, and the description is what decides.

Suggestions, not blockers

Findings never block a save. Most skills here are written by an agent mid-conversation, so the validation results ride back in the tool response itself — the agent sees “line 14 looks like an access key” the moment it saves, tells you, and fixes it in the same session. On the web, the skill page now shows open findings with two buttons: Dismiss, for the deliberate example (“yes, that fake key is meant to be there”), and Fix these for me, which applies the mechanical corrections — placeholder in place of secret, stripped smuggling characters — through the same change-tracked update path as any other edit.

The one hard rule sits at the boundary that matters: a skill cannot be published to the public directory while it has an undismissed critical finding. Private and team skills are never blocked — your drafts are your business.

The Checks passed badge

Directory listings whose current version was scanned clean now carry a Checks passed badge, and the cross-org install gate we shipped in August folds any outstanding hygiene findings into the same warning screen it already uses for material changes. One place to look, before anything lands on your machines.

Why now

The research this year has converged on two facts about skills. They can be remarkably effective: NVIDIA measured an average ~41-point correctness lift across hundreds of verified skills, and their open-source SkillEvaluator — whose Tier-1 quality gates directly inspired this release — makes validation a first-class stage of skill distribution. And they are only effective when they encode what the model doesn’t already know: org-specific knowledge, your tools, your conventions. That is exactly the kind of content a team library holds — and exactly the kind of content most likely to have a real credential or a real colleague’s details pasted into it. Distribution infrastructure for skills needs trust infrastructure. Now ours has it.