Browse without signing up
the registry is public. Preview any skill, including its full SKILL.md body, with no account required.
Install = fork
Installing copies the skill into your org as an independent fork. Your edits don’t affect upstream, and upstream changes don’t auto-overwrite yours.
Publish what's tested
Publishing requires an eval suite and a completed benchmark run — proof the skill was measured, not that it scored well. The registry ranks by effectiveness, not by post date.
Every ranking on the registry is a SkillScore — a skill’s proven effectiveness from real benchmark, live-eval, AI-rating, and adoption signals. See that guide for how it’s calculated and what’s public vs. private to your team.
1. Discover
Browse the registry
- Web
- SDK
- cURL
Visit
/skills — no login required. Each card shows:- Name + description
- SkillScore — proven effectiveness blended from up to 4 signals (benchmark · live eval · AI rating · adoption), not a vanity formula. See SkillScore for the canonical definition.
- Install count (cumulative across all orgs)
- Source badge:
verified(DecimalAI-curated),featured(algorithmically promoted),community(user-published),imported(auto-synced from GitHub) - Skill type badge:
CapabilityorPreference, plus apublic/privatescope — the skill’s two-axis classification and when to expect it to retire (onlycapability · publicdoes). You can also filter the browse view by skill type. Unlabeled skills simply show no type badge. (LegacyModel-gap/Proprietary/Conventionlabels map onto these.) - Invocation badge:
Automatic(the model fires it from its description) orOn-demand(invoked explicitly — it never occupies your agent’s context until called) - Trend: improving / stable / degrading
Preview a skill (no fork)
Sometimes you want to see what a skill does before committing to fork it.preview returns the body + metadata as an ephemeral snapshot — no fork is created, no fork count is incremented, no row added to your org.
What the skill detail page shows
Beyond the body and version history, each published skill’s detail page carries three trust surfaces:- Trigger health — for Automatic skills, how reliably the skill fires at the right times: trigger recall and false-fire rate from the skill’s own trigger cases, joined with production-side routing data (how often the skill was offered vs. actually selected). A skill that helps but never fires is broken in a way a benchmark alone can’t see; this panel shows both halves.
- Re-verification history — “Verified on ⟨model⟩ — re-tested ⟨date⟩”. Lift (the with-vs-without improvement) is model-relative: a skill that lifted on last year’s model may be absorbed by this year’s. The history shows which model the benchmark ran on and when it was last re-tested, so you can tell fresh evidence from stale.
- Skill type explainer — one line of what the type badge means for lifespan, e.g. “Fills a current model gap — re-tested against each model release” or “Convention — steers output to a standard form”.
2. Fork into your org
“Fork” is the canonical verb — forking copies the registry skill into your org as an independent skill you own. (The SDK method isinstall(), which forks and writes SKILL.md to disk in one call; an older HTTP /install route is a deprecated alias for the same fork.)
1
Fork via SDK (recommended)
- Fork on the platform: copies the registry skill into your org with a
forked_from_skill_idpointer - Write to disk: produces
SKILL.md+ bundled scripts/attachments in the right agent directories (e.g..claude/skills/pdf/,.agents/skills/pdf/)
2
Or install via the web UI
From
/skills, click any skill card → Fork. A modal lets you:- Install only — creates the fork but doesn’t assign it to any agent
- Install & Assign — creates the fork AND subscribes selected agents in one step
3
Assign to agents (if you didn't in step 1)
A forked skill exists in your org but isn’t loaded by any agent until you assign it. From a skill’s Settings tab or an agent’s Skills tab, pick which agents subscribe to it. The Skill Router only surfaces skills that are subscribed to the requesting agent.See Agent Skill Assignment for the full assignment surface.
4
See effectiveness in the dashboard
Once the agent runs with the skill loaded, the next turn’s trace stamps a
routing_id. The platform joins routing_decision × activations × eval_scores to give you per-skill, per-(skill, model) effectiveness — automatically, with no extra instrumentation.What exactly happens when you fork a skill
What exactly happens when you fork a skill
The fork endpoint performs a transaction:
- Validates the source exists and is
visibility='public' - Rejects duplicates — if your org already has a fork of this skill, returns 409 with the existing fork’s name in the
X-Installed-Asheader - Checks your plan’s skill cap (10 / 50 / 250 / unlimited)
- Creates a fork in your org: a new
Skillrow withsource_type='platform', the same body markdown, and two fork pointers —forked_from_skill_idandforked_at_version_id - Copies attachments (scripts, references, templates, assets)
- Increments
source.install_counton the upstream
3. Receive upstream updates
When the author of an installed skill publishes a new version, your fork doesn’t auto-update — you decide whether to merge.Check for updates
A daily background job setshas_upstream_update=True on any fork whose forked_at_version_id differs from upstream’s latest_version_id. Check the flag on a skill’s detail view (web UI badge, or API response field).
Preview before merging
Merge
forked_at_version_id. Your prior versions remain in the history — nothing is lost.
`update_skills` vs `merge_upstream` — they sound similar, they do different things
`update_skills` vs `merge_upstream` — they sound similar, they do different things
router.update_skills()— pulls platform-state down to your local disk for skills already in your org. It’s a disk sync, not a content-merge. Useful when you’ve made dashboard edits and want SKILL.md files on disk to match.router.merge_upstream(name)— pulls registry upstream content into your forked skill, creating a new version. It’s a content-merge, not a disk operation.
merge_upstream(..., mode="replace") then update_skills().4. Publish your own skill
Once you’ve built a skill in your org that you’d like to share publicly:visibility from org to public:
Failing any gate returns a
400 or 409 with a clear error message pointing at which gate.
There is deliberately no minimum version count or activation count. Pre-publish, the only activations a skill can have are your own — a gameable self-signal, not community evidence. Evidence tiering lives in the registry ranking instead: skills earn their placement from real, post-publish use.
What the server does on publish
What the server does on publish
The published skill stays in your org — there is no migration into the registry org. The change is purely metadata:
visibility: 'org' → 'public'categoryset (from thecategoryarg)tagsset (lowercased + trimmed)skill_badge: 'community'(registry-curated skills getverified; auto-imported GitHub skills getimported)source_typedefaults to'platform'if unset
Unpublish
visibility back to 'org'. Existing forks are untouched — see the upstream-orphan accordion above for the contract.
How effectiveness is computed
Every published skill gets a SkillScore (0–100) — a quality-first composite. Install counts and star counts are deliberately excluded: a heavily-installed stale skill shouldn’t outrank a skill that actually works. SkillScore is the canonical source for how the score is built; this section summarizes the four signals it blends.
A skill can have any subset of the signals; more signals → a more trustworthy score. Skills with fewer than 10 activations in the window aren’t hidden — they’re relegated below scored skills in the default sort, so cold-start skills stay discoverable without outranking proven ones. Scores update daily via the
registry_stats_scheduler.
The registry defaults to sorting by SkillScore. The leaderboard adds three more axes:
You can also sort by
"popular", "installs", or "recent" — popularity exists as a sort, it just doesn’t contaminate the score.
All inputs are anonymized across consumer orgs. Per-org data is never exposed on the public registry.
Router vs disk auto-loading
A subtlety worth knowing if you mix DecimalAI with an IDE-managed runtime:Why running Claude Code / Cursor *and* the Router loader at the same time can duplicate skills
Why running Claude Code / Cursor *and* the Router loader at the same time can duplicate skills
Some runtimes (Claude Code, Cursor) auto-discover
SKILL.md files from
.claude/skills/ or .agents/skills/ and inject them into the system
prompt themselves. The Skill Router also
injects skills into the system prompt — from the platform. Running
both means the same skill ends up in the prompt twice.The simplest fix: pick one source of skill injection per agent process.The SDK auto-detects known disk runtimes (
CLAUDECODE, CLAUDE_CODE_ENTRYPOINT, CURSOR_AGENT env vars) and logs a one-shot warning when enable_skill_loader=True fires inside one. Silence with DECIMALAI_SUPPRESS_DISK_RUNTIME_WARNING=1 if you’ve chosen the setup deliberately.See the Router’s disk-vs-Router section for the full matrix and the disk_sync=False behavior.Plan limits
Browsing and installing are Free — the value scales with skill count and you’ll outgrow the cap before publishing matters.
Related
- Assemble an agent from skills — how to read the badges as a consumer and turn a registry bundle into one agent
- Skills Guide — what a skill is, SKILL.md format, manual creation, agent assignment
- Skill Router — the runtime that picks which skills to load per turn
- SkillRouter Python class — full SDK reference
- Skills API endpoints — raw REST surface