> ## Documentation Index
> Fetch the complete documentation index at: https://docs.decimal.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Content policy
> What a published skill's text may not contain — the eight prohibited-content categories DecimalAI's content-safety review enforces, and how to fix a flag.
Publishing a skill makes its text public. **SkillSafety** — the registry's safety brand, sibling to [SkillScore](/guides/skillscore) — runs a **content-safety review** on that text as the last stage of the publish gate: an AI reviewer reads the exact copy going live and checks whether it carries prohibited content. This page is the policy that review enforces. It's a reference, not a tutorial — read it before you publish, and again if a publish comes back flagged.
The content review is about **what the text says**, not what the skill *does*. A separate static scan and AI security review already look for dangerous *behavior* (secrets, remote-code-execution, prompt injection). Content policy is the other half: even a perfectly safe, well-behaved skill can't ship copy that violates the categories below.
## What gets reviewed
The review covers every piece of text you attach to a skill and everything you write about it in the registry:
* **The `SKILL.md` body** and any bundled reference text.
* **Eval cases** — prompts, expected outputs, and fixtures. These are text too, and they publish with the skill.
* **Display name, description, and tags.**
* **Ratings and comments** you post on any skill in the registry.
The policy applies to the **content of the text**, regardless of where it lives. A slur in an eval fixture is treated the same as a slur in the body.
## Prohibited categories
A skill's text may not contain, promote, or provide operational instructions for any of the following.
| Category | Not allowed |
| --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Hate & harassment** | Slurs, dehumanizing language, or content that attacks or demeans people based on a protected characteristic; targeted harassment of an individual. |
| **Graphic violence** | Gratuitous gore or depictions of violence intended to shock rather than inform. |
| **Sexual content** | Pornographic or sexually explicit material. |
| **CSAM** | Any sexualization of minors. Terminal — see below. |
| **Self-harm** | Content that encourages, instructs, or glorifies suicide, self-injury, or disordered eating. |
| **Illegal goods** | Instructions to obtain or produce weapons, controlled substances, or other illicit goods. |
| **Doxxing & PII** | Real personal data — home addresses, government IDs, private contact info — that could identify or expose a real person. |
| **Credible threats** | A specific, actionable threat of violence against a real person or group. Terminal — see below. |
These categories bind the **published text**, not the skill's subject matter. A skill *about* content moderation, threat detection, or security research is welcome — it just has to describe abuse without reproducing it. See the synthetic-examples rule next.
## The synthetic-examples rule
Plenty of legitimate skills need to *talk about* the very things this policy prohibits — a moderation classifier, a PII redactor, a self-harm-detection helper. That's allowed. What's not allowed is putting **real, live instances** of prohibited content into your examples or eval cases.
The line is **synthetic and redacted, not real**:
* A slur-detection skill may describe the *shape* of a slur or use a clearly fabricated placeholder — it may **not** ship a list of real slurs as test strings.
* A doxxing-detector's eval cases must use **invented** names, addresses, and IDs — never a real person's data.
* A threat-classifier illustrates with **synthetic** example threats, plainly marked as fabricated — not a real, actionable threat against a real target.
When you need an example of something on the prohibited list, make it obviously fake and label it. Redact anything that resembles real personal data. Synthetic examples pass; real ones get the skill flagged even when the skill's purpose is legitimate.
## What happens when text is flagged
A flag falls into one of two buckets. Most are **remediable** — fix the text and re-publish. Two are **terminal** — the content is removed and can't be re-submitted.
| Outcome | Categories | What happens | Your move |
| -------------- | -------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- |
| **Remediable** | Hate & harassment, graphic violence, sexual content, self-harm, illegal goods, doxxing & PII | The publish is **held** — the skill is not listed on the registry — and you get structured findings pointing at the offending text. | Revise the flagged text and re-publish. The gate re-runs. |
| **Terminal** | **CSAM**, **credible threats** | The content is **removed**, not held. There is no revise-and-retry path. | [Contact support](mailto:support@decimal.ai) if you believe this was a mistake. |
Content flags are the one case where SkillSafety **holds** a skill rather than listing it with a warning. Other Caution-level findings still appear on the registry with a badge; content-flagged skills do not appear at all until the text is fixed (or, for terminal categories, at all).
Every version of a skill carries its own review history, so fixing a later version never erases the record of an earlier one — and if a skill that's *already published* has its content band worsen, the owner gets an email.
### Fail-open, never a false block
If the content reviewer is briefly unavailable when you publish, your skill is **not** blocked. It shows **Not yet reviewed** and is re-checked automatically once the reviewer is back. A publish is only ever *held* on an actual finding — never on the reviewer being down.
## Fixing a flagged skill
A held publish returns **structured findings** — each one names the category and points at the specific text that tripped it, with a suggested fix. Real personal data and secrets are redacted in the report, never echoed back.
Edit the body, eval cases, name, or tags to remove the prohibited content — or, for a legitimate moderation/security skill, replace real instances with **synthetic, redacted** examples per the rule above.
Publishing again re-runs the full gate. Once the content review passes, the skill lists normally.
Want to catch a content flag **before** you publish? Run a **deep review** on a private draft — it runs the AI security and content-safety reviewers against unpublished text so you see the findings first. Deep review is metered (a monthly quota by plan); the publish gate itself is always free.
## Related
How publishing works, including the full publish gate the content review sits at the end of.
The effectiveness score that sits beside SkillSafety on every skill.
Write a skill — and its eval cases — that passes review the first time.