> ## 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. # Community Registry > Browse, install, fork, and publish skills — with real production effectiveness data, not just star counts. The DecimalAI Public Registry is a community marketplace for agent skills. Every published skill carries **real production effectiveness data** — pass rate, install count, model compatibility, trend — aggregated from anonymized usage across all consumers. 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**. ```mermaid theme={null} %%{init: {'theme':'base','themeVariables':{'primaryColor':'#f5f5f4','primaryBorderColor':'#a8a29e','primaryTextColor':'#44403c','lineColor':'#a8a29e'}}}%% flowchart LR A[Discover] --> B[Fork into your org] B --> C[Use in your agents] C --> D[Receive upstream updates] D --> E[Publish your own] E --> A ``` the registry is public. Preview any skill, including its full SKILL.md body, with no account required. 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. 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](/guides/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 Visit [`/skills`](https://app.decimal.ai/skills) — no login required. Each card shows: * **Name + description** * **[SkillScore](/guides/skillscore)** — proven effectiveness blended from up to 4 signals (benchmark · live eval · AI rating · adoption), not a vanity formula. See [SkillScore](/guides/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**: `Capability` or `Preference`, plus a `public`/`private` scope — the skill's [two-axis classification](/guides/authoring-skills#the-two-axes) 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 ```python theme={null} 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", # or "popular" | "rating" | "installs" | "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)') ``` ```bash theme={null} # Public — no auth required curl -s "https://api.decimal.ai/api/v1/registry/skills?q=code+review&sort=effectiveness&limit=10" ``` ### 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. ```python theme={null} 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 method is `install()`, which forks **and** writes `SKILL.md` to disk in one call; an older HTTP `/install` route is a deprecated alias for the same fork.) ```python theme={null} result = router.install( "pdf", agents=["claude-code", "cursor"], # which agent runtimes to write SKILL.md for scope="project", # "project" or "global" ) print(f"Installed as: {result['skill_name']}") print(f"Files written: {result['export']['paths']}") ``` This combines two operations: 1. **Fork on the platform**: copies the registry skill into your org with a `forked_from_skill_id` pointer 2. **Write to disk**: produces `SKILL.md` + bundled scripts/attachments in the right agent directories (e.g. `.claude/skills/pdf/`, `.agents/skills/pdf/`) From [`/skills`](https://app.decimal.ai/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 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](/guides/skills#agent-skill-assignment) for the full assignment surface. 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. The fork endpoint performs a transaction: 1. **Validates** the source exists and is `visibility='public'` 2. **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 3. **Checks your plan's skill cap** (10 / 50 / 250 / unlimited) 4. **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` 5. **Copies attachments** (scripts, references, templates, assets) 6. **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 ```python theme={null} 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 ```python theme={null} 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. 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. * **`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: ```python theme={null} 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](/guides/trust-safety/how-skills-are-vetted)** for the full SkillSafety pipeline, and **[Fixing a blocked publish](/guides/trust-safety/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 community evidence. Evidence tiering lives in the registry ranking instead: skills earn their placement from real, post-publish use. 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'` (registry-curated skills get `verified`; auto-imported GitHub skills get `imported`) * `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 ```python theme={null} 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**](/guides/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](/guides/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** | Real 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 update daily via the `registry_stats_scheduler`. 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](/guides/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 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: 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](/api-reference/skills/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 — `install(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](/api-reference/skills/router#router-vs-disk-auto-loading-pick-one) for the full matrix and the `disk_sync=False` behavior. ## Plan limits | | Free | Core | Pro | Enterprise | | --------------------------- | :--: | :--: | :-: | :--------: | | Skills in your org | 10 | 50 | 250 | Unlimited | | Install from registry | ✓ | ✓ | ✓ | ✓ | | Publish to registry | — | ✓ | ✓ | ✓ | | Registry browse (anonymous) | ✓ | ✓ | ✓ | ✓ | 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](/guides/agents-from-skills) — how to read the badges as a *consumer* and turn a registry bundle into one agent * [Skills Guide](/guides/skills) — what a skill is, SKILL.md format, manual creation, agent assignment * [Skill Router](/api-reference/skills/router) — the runtime that picks which skills to load per turn * [SkillRouter Python class](/sdk/python/skills) — full SDK reference * [Skills API endpoints](/api-reference/skills/overview) — raw REST surface