Skip to main content
You tried to publish a skill and the registry refused. That’s SkillSafety doing its job: the same review that stamps a public safety band (Passed / Caution / Blocked / Not-yet-reviewed) also gates the publish itself. Almost every refusal is a fixable finding, not a dead end — the two exceptions are called out below. This page maps every refusal reason to what it means and exactly how to clear it.

​
The order the gates run

Publish runs four gates in sequence. The first one that fails is the reason you see — fix it, re-publish, and the next gate runs.
The publish gate itself is always free — you never spend quota to attempt a publish, no matter how many times you retry.

​
Reason → meaning → fix

content_removed is the one terminal outcome. CSAM and credible threats are removed, not returned for editing — there is no fix-and-retry loop for these categories.

​
safety_blocked — Tier-1 static scan

Tier-1 is pure text analysis: regex and structural checks, no LLM, run instantly and free on every publish. It groups its checks into four families. Not every check in that catalog can refuse a publish. Only a critical finding does — the live-payload patterns listed in the safety_blocked row above. The rest are advisory: they are recorded as warnings, show up in the findings and on a Caution band, and the skill still publishes. The findings modal is built to be actioned line by line. For each critical finding you get:
  • Check — which rule fired (e.g. data-exfiltration)
  • Line — where in the body it matched
  • Evidence — the offending snippet, with any secret redacted — the scanner never echoes a credential back to you
  • Fix — the concrete change that clears it
Tier-1 is context-aware. When the prose immediately around a match plainly teaches about the pattern rather than instructing it, the finding is downgraded to a warning instead of a block — that is what lets a secret-scanner or injection-resistance skill publish. Write your security skill so the prose next to the payload explains what it is. A security category on its own will not clear a behavioral finding.

​
intent_rejected — Tier-2 AI security review

Where Tier-1 reads patterns, Tier-2 reads intent. An LLM judge evaluates what the skill is actually trying to make an agent do and returns safe / review / reject. A reject becomes intent_rejected. This tier exists to catch what a regex structurally can’t: fluent, well-written social engineering. The classic case is a skill with a friendly “Prerequisites” section that instructs the agent to curl a URL and pipe it to a shell before doing anything useful — every individual line looks benign, but the intent is to fetch-and-run attacker code. To fix: read the judge’s rationale, cut the instruction that steers the agent toward the unsafe action, and re-publish. If you believe the skill is legitimate security tooling, make the framing explicit in the body: say what the payload is and why you’re showing it, right where you show it. The judge weighs framing the same way Tier-1 does.

​
content_blocked / content_removed / content_unverified — Tier-3 content safety

Tier-3 asks a different question from the first two tiers: not is this skill dangerous to run, but does the published text itself carry prohibited content. An LLM reviews the body against these categories:
  • Hate
  • Graphic violence
  • Sexual content / CSAM
  • Self-harm
  • Illegal goods
  • Doxxing / PII
  • Credible threats
Two rules to remember:
  1. Examples must be synthetic. If your skill needs to show a sample email, sample PII, or sample abusive message, fabricate it. Real personal data trips the doxxing/PII check.
  2. Two categories are terminal. CSAM and credible threats produce content_removed — the skill is taken down and cannot be re-published. Every other category is remediable: edit the text and re-publish.
content_unverified is not a violation at all — it’s the fail-open state when a reviewer was momentarily unavailable. The skill shows Not yet reviewed and is re-checked automatically. You never get a false block from a reviewer outage.

​
The remediation loop

Every refusal returns structured findings, each with its own fix. The loop is short:
1

Fix the body

Apply the per-finding fix from the modal — remove the secret, rewrite the manipulative step, replace real PII with synthetic, and frame legitimate security content so the prose around a payload explains what it is.
2

Re-run checks (free, Tier-1 only)

The Re-run checks button re-runs the Tier-1 static scan on any skill you own — no publish required, no quota spent. Use it to confirm you cleared a safety_blocked finding before you attempt the full publish.
3

Re-publish (re-runs all three gates)

Publishing re-runs Tier-1, Tier-2, and Tier-3 in order. The publish attempt is always free, so there’s no cost to iterating.
Re-run checks covers Tier-1 only — the deterministic scan is free to run as often as you like. The LLM tiers (Tier-2 and Tier-3) run at publish time, or on demand via Deep review below.

​
Deep review — clear the LLM tiers before your launch

The publish gate runs Tier-2 and Tier-3 at the moment you publish. If you’d rather not discover an intent_rejected or content_blocked during your launch, run those LLM tiers ahead of time against a private draft with Deep review. It runs the same Tier-2 + Tier-3 checks on an unpublished skill so you can fix findings on your own schedule. Deep review is metered. Each plan gets a monthly quota:
The quota applies only to Deep review — the on-demand LLM run against a private draft. The publish gate itself is always free, and so is the Tier-1 Re-run checks button. Deep review buys you the LLM verdict before the launch moment; it doesn’t gate publishing.

​
Catch it locally, before the server ever sees it

The same scanner that powers Tier-1 runs on your machine — free, no API key, and nothing leaves your laptop. Run it in your editor or wire it into CI so a safety_blocked never reaches a publish attempt.
Output formats: --format text | json | github | sarif. Blocked findings exit 1, so the scan fails your build. sarif uploads straight to GitHub code scanning.
The local scan judges context from your local files and frontmatter alone — it can’t see the server-side signals (benchmark history, published verdict, category reputation) the gate uses to downgrade a borderline finding, so it’s deliberately allowed to be stricter than the publish gate, never looser. Treat a clean local scan as advisory: it means you’ve cleared the obvious Tier-1 findings, not that the server-side gate will pass.

​
When a live skill goes bad

Review doesn’t stop at publish. Every version carries its own scan and verdict history, and a real adverse verdict on an already-published skill de-lists it — the skill drops out of the registry and the owner gets an email that the band worsened. If you own a published skill, watch for that mail; it means a re-check found something the original publish didn’t.

Community Registry

Publishing, forking, and the benchmark-presence gate that runs before SkillSafety.

SkillScore

The effectiveness band that sits beside SkillSafety on every skill.

skillevaluation

The package that ships the scan command and the A/B benchmark.