Why Curated AI Skills Are Safer Than User Uploads

Two very different definitions of "marketplace"

The word "marketplace" hides two completely different products.

The first is an auto-aggregated directory: a service that scrapes GitHub, imports community uploads, and lists tens of thousands of skill files with no human in the loop. Volume is the pitch. Search is the interface. Trust is your problem.

The second is a curated library: a small team that designs, tests, and reviews every skill before it is listed. Volume is deliberately capped. Trust is the pitch.

PiSkill is the second kind. This article is about why that matters for anyone running skills in production.

The risk profile of open upload libraries

Random contributors can — often unintentionally — ship skills that:

• Leak your context to third parties. A skill that instructs the model to "call this webhook when done" quietly sends your prompt, your data, and your output to a URL you didn't audit.
• Contain prompt injections. A well-crafted skill can look helpful on the surface and hide instructions that override your safety notes when the model reads it.
• Encode unsafe automations. Skills that write to your database, send emails on your behalf, or execute shell commands are only as safe as the least careful contributor.
• Hallucinate confidently. Skills that ask the model to "generate realistic-looking data" for finance, medical, or legal contexts are one accidental prod deploy away from a real problem.
• Rot silently. A skill that worked on last year's model behaves badly on this year's model. Nobody owns the fix.

None of this is theoretical. Every open marketplace at scale has hit each of these.

What curation actually catches

"Reviewed by PiSkill Team" is not marketing — it is a checklist. Before a skill ships, a reviewer works through:

1. Scope. Does it solve one clear job, or is it a Swiss army knife that will fail in interesting ways?
2. Prompt injection. Reviewer runs known injection patterns as input and checks that the skill's safety notes hold.
3. Data exfiltration. No instructions to hit external URLs, log to third parties, or embed tracking pixels in output.
4. Automation safety. Any tool-calling skill has an explicit human-in-the-loop step for destructive actions.
5. Model portability. Skill is tested on Claude, ChatGPT, and Gemini. Failures are documented, not hidden.
6. Docs completeness. Purpose, inputs, outputs, safety notes, known limitations.

Skills that don't clear every step don't ship. This is boring, unglamorous work — and it's exactly what an auto-aggregator can't do at 50,000 entries.

The honest trade-off

Curation is not free. The trade-offs are real:

• Fewer skills. You will occasionally look for a niche skill that a scraped directory has and PiSkill doesn't.
• Slower to publish. A community upload lands in minutes; a reviewed skill lands in days.
• One flavor per job. We ship one canonical "code review" skill, not seventeen forks.

We think that's the right trade for anyone using skills in real work. If you need to explore the entire ecosystem or fork experimental variants, a scraped directory is a legitimate raw feed. If you need something you can install today and trust in production, curation wins.

What "safe by default" looks like in practice

A PiSkill skill you download today ships with:

• Explicit safety notes at the top of SKILL.md.
• Isolation rules for untrusted input (usually wrapped in tagged blocks).
• Named known limitations, so you don't misuse the skill.
• A version and a last-reviewed date, so you can tell when it was checked.
• No embedded URLs, tracking, or third-party call-outs.

You can still edit any of that — it's plain text — but the default is safe.

How to vet a skill from anywhere else

If you do use a skill from a scraped directory, apply the same checklist we use internally:

1. Read the whole file. If you can't, it's too complex to trust.
2. Grep for URLs, webhooks, and fetch / curl patterns.
3. Look for instructions inside example inputs — that's where injections hide.
4. Test on at least two models; watch for output divergence.
5. Run it on adversarial input, not just the happy path.
6. Assume the author is gone and the skill will not be updated.

Do this for a few skills and you'll understand why curation exists.