Community Registry

The DecimalAI Public Registry is an open marketplace for agent skills: anyone with an account can publish into it, DecimalAI included — we author and publish skills here on the same terms as everyone else, and they carry the same community badge and the same measured evidence. “Community” describes where a skill was authored, not who wrote it, and no badge on this registry means “endorsed”. Every published skill carries real production effectiveness data — pass rate, install count, model compatibility, trend — aggregated from usage across consumer organizations. Not stars. Not vanity metrics. Actual signal about whether the skill works. This guide walks the full lifecycle: discover → fork → use → receive updates → publish your own.

Browse without signing up

the registry is public. Preview any skill, including its full SKILL.md body, with no account required.

Install links, Fork copies

Installing links the skill into your workspace — no copy, and you keep getting the author’s updates. Fork takes an editable copy instead: 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.

Install, Fork, Export and the two numbers on every card are defined once, in Vocabulary. If a word here and a word there ever disagree, that page is the one that is right.

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
MCP (ask your agent)
Claude Code plugin

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 — where the skill came from, not a seal of approval: community (authored on the DecimalAI platform and published by its author — the default for every publish, DecimalAI’s own skills included), imported (auto-synced from a public GitHub repo), featured (a community skill promoted automatically on its own numbers — a strong SkillScore, real adoption, and a recent publish date; nobody hand-picks it, and it falls back to community when it stops qualifying). An older verified tier was retired in July 2026 and no skill carries it; the API field still accepts the value, so treat it as legacy if you ever see it.
Skill type badge: Capability or Preference, plus a public/private scope — the skill’s two-axis classification and when to expect it to retire (only capability · public does). You can also filter the browse view by skill type. Unlabeled skills simply show no type badge. (Legacy Model-gap / Proprietary / Convention labels map onto these.)
Invocation badge: Automatic (the model fires it from its description) or On-demand (invoked explicitly — it never occupies your agent’s context until called)
Trend: improving / stable / degrading

from decimalai.skill_router import SkillRouter
router = SkillRouter(api_key="dai_sk_...")

results = router.search(
    query="code review security",
    category="code-review",     # optional
    sort="effectiveness",        # alias of "recommended"; also "popular" |
                                 # "installs" | "top_rated" | "biggest_improvement" |
                                 # "efficiency" | "recent"
    limit=20,
)
for skill in results:
    eff = skill.get("effectiveness") or {}
    print(f'{skill["name"]:30}  {eff.get("avg_effectiveness", "N/A"):>5}  ({skill["install_count"]} installs)')

# Public — no auth required
curl -s "https://api.decimal.ai/api/v1/registry/skills?q=code+review&sort=effectiveness&limit=10"

Add the registry to any MCP client once, and discovery becomes a question instead of a browse:

claude mcp add decimalai -- uvx decimalai-mcp

Find me a measured skill for code-review security, and show me its
benchmark evidence and safety scan before I install anything.

Three read-only tools — search_skills, get_skill, get_leaderboard — so the agent can search, then pull the full record (trust bands, verified lift, SKILL.md body) without you leaving the editor. No API key required. It never writes files: once you’ve picked one, install it with decimalai skills pull.

Search and install are both slash commands — no key, nothing to pip install. Once:

/plugin marketplace add decimal-labs/decimalai-claude-plugins
/plugin install decimalai@decimalai

/decimalai:search code review security

Results come back in ranking order, each row carrying its SkillScore, verified lift and safety band. Blocked skills are listed last under a heading saying they will not install — visible, never pickable. /decimalai:install <url_slug> then writes SKILL.md plus the skill’s bundled files into .claude/skills/.That is an Export in this registry’s vocabulary, whatever the command is called: a local copy, no fork, no link, and no row in your workspace — so nothing you install this way feeds the effectiveness numbers you just read. Details: Use skills without the SDK.

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.

snap = router.preview("pdf")
if snap:
    print(snap["body_markdown"][:500])
    print(f"\nEffectiveness: {snap['effectiveness']}")

This is useful for sandboxed evaluation runs, “try before you fork” UX, and read-only registry consumers.

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 methods are router.fork() for the copy, router.use() for the link, and router.export() to write files. The older HTTP /install route was retired on 2026-08-11 and answers 410; the SDK’s router.install() still forks and writes to disk but is deprecated in favour of those three.)

Fork via SDK (recommended)

fork = router.fork("pdf")                # workspace copy you own (DB only)
result = router.export(                  # then put the files on disk
    "pdf",
    agents=["claude-code", "cursor"],    # which agent runtimes to write SKILL.md for
    scope="project",                     # "project" or "global"
)
print(f"Forked as: {fork['skill']['name']}")
print(f"Files written: {result['paths']}")

That’s the two halves of adoption, one call each:

Fork on the platform: copies the registry skill into your org with a forked_from_skill_id pointer
Write to disk: produces SKILL.md + bundled scripts/attachments in the right agent directories (e.g. .claude/skills/pdf/, .agents/skills/pdf/)

Or install / fork via the web UI

From /skills, open any skill. The two buttons match the two ownership models:

Install (linked) — a linked reference to the registry skill; it keeps tracking upstream, and you don’t own a copy. Once it’s installed the button becomes Update link, next to an ✓ Installed badge
Fork a copy — an owned, editable copy in your org; your edits are yours, and upstream changes never overwrite them

The SDK equivalents keep their original names: router.use() is what the Install button calls, and router.fork() is what Fork a copy calls.Either way the skill is offered to every agent in the workspace by default; narrowing it to specific agents is optional (next step).

Assign to specific agents (optional)

A forked or used skill is already offered to every agent in the workspace — that is the default. Assigning it to an agent adds an explicit row (and an optional version pin) without taking it off other agents’ menus. To have the Skill Router surface a forked skill only to its assigned agents, set Offered to → Only agents it’s assigned to on its Settings tab. For a linked (Install) skill, choose Apply to → specific agents… at install time instead, so no workspace-wide row is written; that picker requires a Pro or Enterprise plan.See Agent Skill Assignment for the full assignment surface.

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

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-As header
Checks your plan’s skill cap (10 / 50 / 250 / unlimited)
Creates a fork in your org: a new Skill row with source_type='platform', the same body markdown, and two fork pointers — forked_from_skill_id and forked_at_version_id
Copies attachments (scripts, references, templates, assets)
Increments source.install_count on the upstream

The fork is fully yours. Edits to it create new versions on your fork; the upstream is never modified by your activity.Idempotent: forking the same skill twice returns 409, not a duplicate row. Safe to retry.

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 sets has_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

preview = router.merge_upstream("pdf", mode="preview")
print("UPSTREAM BODY:\n", preview["upstream_body"])
print("\nCURRENT BODY:\n", preview["current_body"])
print(f"\nUpstream version: {preview['upstream_version_number']}")
print(f"Change summary:  {preview['upstream_change_summary']}")

No write — you get both bodies side by side so you can decide.

Merge

result = router.merge_upstream("pdf", mode="replace")

This creates a new version on your fork with the upstream body and advances forked_at_version_id. Your prior versions remain in the history — nothing is lost.

merge_upstream(mode="replace") overwrites your fork’s body with upstream’s. If you have local edits you want to preserve, capture them with router.get_skill_body(name) first, or skip the merge and cherry-pick by hand.

What if the author unpublishes the upstream skill?

By design:

Your fork keeps working. It’s an independent copy — body, attachments, and version history all live in your org.
The upgrade banner disappears. When the author calls unpublish_skill, the server sweeps all forks and sets has_upstream_update=False. No phantom “merge available” UI.
Merge is blocked. merge_upstream raises 404 ("Upstream skill is no longer available in the registry") — the platform refuses to pull a body the author has revoked.

If the author re-publishes later, the next daily job re-enables upstream-update detection.

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.

If you want both — newer body from upstream AND fresh disk files — call 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:

router.publish_skill(
    "refund-policy",
    category="support",
    tags=["billing", "refunds"],
    author_display_name="Acme Support Team",  # optional, defaults to your user id
)

The publish endpoint enforces four gates before flipping visibility from org to public:

Gate	Why
You are the skill creator, a workspace editor, or an org admin	Prevents teammates from publishing each other’s work-in-progress
Name is globally unique among public skills	The registry can’t disambiguate two `code-review`s. Rename yours if there’s a collision.
An eval suite with at least one case, plus a completed benchmark run	Proof the skill was measured before going public. This is a presence gate, not a quality gate — you may publish a skill that fails its own benchmark; you may not publish one that was never tested. Trigger-only cases don’t count (they measure routing, not lift), and a run where most cases errored (e.g. a provider outage) doesn’t count either — re-run it.
Safety review passes	The exact body going public is scanned for dangerous content (live secrets, remote-code-execution instructions, data-exfiltration steps, hidden unicode), then reviewed by an AI security judge and a content-safety check. Critical findings block the publish with the flagged lines, so you can fix and retry. See How skills are vetted for the full SkillSafety pipeline, and Fixing a blocked publish to resolve a refusal.

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 evidence from other people’s use. Evidence tiering lives in the registry ranking instead: skills earn their placement from real, post-publish use.

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'
category set (from the category arg)
tags set (lowercased + trimmed)
skill_badge: 'community' — every publish through this endpoint gets it, whoever you are; it records that the skill was authored on the platform. Skills auto-synced from GitHub get imported instead, and the ranking may later promote a community skill to featured.
source_type defaults to 'platform' if unset

the registry browse query automatically picks up the new row on the next request. No build step, no cache flush.

Unpublish

result = router.unpublish_skill("refund-policy")
print(f"Cleared upgrade banner on {result['forks_cleared']} consumer forks")

Flips visibility back to 'org'. Existing forks are untouched — see the upstream-orphan accordion above for the contract.

Unpublishing is non-destructive on your side and minimally disruptive on the consumer side. Use it if the skill has a problem you want to address before re-publishing. The version history is preserved.

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.

Signal	What it measures
Benchmark	A/B run on example tasks (with the skill vs. without it) — did it produce lift? The strongest signal, produced by skillevaluation.
Live eval pass rate	Pass rate of evals on production traces where the skill activated
AI quality rating	LLM-judge mean (1–10) over sampled activations — gated until ≥ 10 rated traces in the last 30 days
Adoption	Cross-org usage over the last 30 days — capped so heavy use inside a single org can’t inflate it

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 are recomputed daily. The registry defaults to sorting by SkillScore. The leaderboard adds three more axes:

Axis	Ranks by	Signal source
Biggest lift	Measured benchmark lift vs. no-skill baseline	Benchmark (skillevaluation)
Most Efficient	Token savings	Benchmark
Top live rating	★ user ratings	AI rating

You can also sort by "popular", "installs", or "recent" — popularity exists as a sort, it just doesn’t contaminate the score. All inputs are aggregated 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

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.

Setup	What to use
Python app with framework adapter (LangChain / OpenAI Agents / Pydantic AI)	Router — `instrument(enable_skill_loader=True)`
Claude Code / Cursor (IDE-managed agent)	Disk auto-loading; skip the Router
Both at once	Pass `disk_sync=False` to the SDK install and remove local `SKILL.md` files so the Router is the only source

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

	Free	Core	Pro	Enterprise
Skills you own (authored or forked)	10	50	250	Unlimited
Skills installed from the registry	50	250	1,000	Unlimited
Publish to registry	—	✓	✓	✓
Registry browse (anonymous)	✓	✓	✓	✓

The two allowances are separate and never added together — installing a skill never consumes your owned-skill allowance, and authoring one never consumes your install allowance. You may install roughly five times what you own, because the costs differ: a skill you own carries storage, benchmark runs, safety scanning and embeddings, while an install is a live pointer to the publisher’s copy. Uninstalling frees an install slot immediately; installing the same skill for several agents counts once.

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

Get Started

Foundation

Ship Safely

Improve with skills

Trust & Safety

Data & Training

Operate

Research

Core Concepts

Platform

Community Registry

Browse without signing up

Install links, Fork copies

Publish what's tested

1. Discover

Browse the registry

Preview a skill (no fork)

What the skill detail page shows

2. Fork into your org

3. Receive upstream updates

Check for updates

Preview before merging

Merge

4. Publish your own skill

Unpublish

How effectiveness is computed

Router vs disk auto-loading

Plan limits

Browse without signing up

Install links, Fork copies

Publish what's tested

​1. Discover

​Browse the registry

​Preview a skill (no fork)

​What the skill detail page shows

​2. Fork into your org

​3. Receive upstream updates

​Check for updates

​Preview before merging

​Merge

​4. Publish your own skill

​Unpublish

​How effectiveness is computed

​Router vs disk auto-loading

​Plan limits

​Related

1. Discover

Browse the registry

Preview a skill (no fork)

What the skill detail page shows

2. Fork into your org

3. Receive upstream updates

Check for updates

Preview before merging

Merge

4. Publish your own skill

Unpublish

How effectiveness is computed

Router vs disk auto-loading

Plan limits

Related