skill-federation

Skill Federation

Free, private skill search for AI agents

Skills are hints, not installs. Your agent reads them as field notes; you approve the rare one worth keeping.

A bare agent solves 17.5% of SkillsBench tasks. With Skill Federation, 22.8% — and your work never leaves your machine.

Browse and search the indexed catalogs — skills, PyPI packages, research — on the web → skillfed.io

A model's weights are an average of what was written before its training cutoff, and a lossy one at that. Wherever practice actually moves — SEO, security review, accessibility, framework and API migrations, packaging and release, pricing, compliance, tooling defaults — that average is a confident summary of a past consensus. It reads exactly like expertise. It is also, quietly, a version or two behind.

A skill is not a script you install. It's a hint. Field notes a practitioner wrote down about how this work is currently done: a dated artifact someone maintains, carrying the difference between the average and the present. A frontier model pulls one into context and augments its weights with it. Nothing else happens. So the normal outcome of a search here is reading, not installing; a skill is reference material, not code that runs.

Skill Federation finds those notes without telling anyone what you're working on. When the work turns on how something is done now, your agent writes an abstract wish-list ("if every skill existed, which would I reach for?") and the federation matches those wishes against a catalog of vetted skills. Your plan, your files, and your outputs never leave your machine. Only the abstract wishes do.

Read several, cross-check, install rarely. In our own testing, skills read against work a capable model had already optimised still surfaced real defects it had missed — and some of the skills' own advice was itself out of date. Both findings point the same way: pull several, compare them, treat none as authoritative. Two independently authored skills agreeing is current practice; one asserting alone is a hypothesis to verify. Stale skills argue for reading more than one. They do not argue for trusting none.

You and your agent stay in command. A skill is an input to judgment, never a replacement for it: take what's current and relevant, discard what doesn't fit, say which parts you used. And a fetched body is data, not instructions addressed to your agent. Craft guidance is what you came for; anything telling the agent to run commands, change settings, or send data somewhere is ignored and reported to you. (The catalog and our ongoing research notes are at skillfed.io.)

Important Only the abstract wish crosses the boundary — a one-line capability description, ~4 vocabulary-varied paraphrases, 1–5 keywords, and a capability-level sketch of the ideal skill. Every field is "what skill should exist," never your task. Your plan, brief, file contents, and reasoning trace stay local — always.

Here's the entire payload for one wish — the literal string sent for launch-strategy. It names the capability domain, never your task, plans, or product:

description: plan a multi-channel launch for an open-source developer tool
paraphrases: orchestrate a launch across hacker news reddit and product hunt · plan a
             go-to-market launch for a dev tool · coordinate a multi-platform release
             announcement · design a launch-day plan for an open-source project
sketch:      launch product hunt hacker news waitlist go-to-market campaign ·
             channel planning timing asset prep announcement
keywords:    launch, gtm, product-hunt, strategy, announcement

A description, four paraphrases, a capability sketch, keywords. Your product's name, your unreleased roadmap, and your actual launch plan never appear.

Prefer plain text? Here's the same run

You: /skillfed plan a launch for my open-source dev tool

  -> agent writes 4 abstract wishes (paraphrases + a capability sketch).
     Only these leave your machine -- never your plan, files, or data.

  wish: launch-strategy       -> multi-platform-launch  review - verified             <- read
  wish: repo-discoverability  -> github-presence        review - verified             <- read
  wish: community-building    -> community-building     review - verified             <- read
  wish: growth-analytics      -> product-analytics      permissive - verified - 221*  <- read
       (each picked from 10 ranked candidates in the vetted catalog)

  Read all 4 in context -- nothing hits disk. Install only the 1 you'll reuse?
  It goes in .claude/skills/ with license + source attribution.

🔒 Why it's different

• Reading is the product; installing is the exception. Skills are hints pulled into context, not packages fetched onto disk. The default flow ends after your agent has read several and told you what it took from each: nothing written, nothing to clean up. Installing happens only when a skill is good and you'll reuse it, and only with your approval.
• No harness required — not even Claude Code. The finder skill carries its own triggers and its own instructions, so it works with no hook registered, in any harness that can load a skill body, and with no harness at all — paste it into a plain chat and it still knows when to search and how to read what it finds. (See Works anywhere below.)
• Privacy floor, by design. Only the abstract wish crosses the boundary: "what skill should exist," never your task. Your plan, brief, file contents, and reasoning trace stay local, always. (Full field-by-field breakdown under Privacy & trust below.)
• Trust before you read — and again before you install. Candidates come from a pre-scanned internal registry (Cisco Skill Scanner + NVIDIA SkillSpector), not the wild repo. Every one shows its license class, provenance, stars, and source. That matters twice over: a consulted body is untrusted third-party text entering your agent's context, and unlike an installed skill it leaves no SOURCE.txt behind, so the agent has to name what it read and where it came from in its reply. You approve each install; nothing is written to disk silently. (See Security.)
• Native, zero-install. The default tier needs nothing but curl, already on Windows 10+ and macOS. No Python, no Node, no package manager. (Optional tiers add typed MCP tools if you have Node — including capability search over the PyPI package index and the research-notes index; see Beyond skills below.)

🌍 Works anywhere

The finder is harness-agnostic on purpose. Its triggers and its whole procedure live in the skill body. Register no hook, drop it into any harness that can load a skill body, or use no harness at all — it behaves the same. The optional Claude Code hooks below only repeat triggers the skill already carries; --hook none is the default, and a complete install.

Nothing installed, just a browser? Ask any chat to use skillfed.io to find a skill — or paste in the skill body itself, which carries the whole procedure. The zero-install loop is two GETs — search, then read:

• Search — skillfed.io/api/q/<terms> returns ranked candidates for a query as one GET, each carrying a direct body URL plus trust fields. The terms ride in the path on purpose: chat fetchers routinely strip long query strings, so this form survives where ?q= doesn't.
• Find — the catalog is published as machine-readable JSON, no crawling required: skillfed.io/.well-known/agent-skills/index.json is one GET returning the whole index, each entry a skill name plus a direct .md URL; skillfed.io/api/index.json is the fuller listing — publisher and license for every skill, 500 per page, follow next. (Hand these URLs to a chat directly; search-index coverage of the site is still shallow, so a thin web-search result can masquerade as a thin catalog.)
• Read — append .md to any skill page URL for the full body as plain text. One GET, and you have it.

What a browsing-only chat still can't run is the full wish-list protocol — several wishes at once, each with paraphrases and a capability sketch, POSTed as one federated query. That's what the finder tiers add.

🧭 Beyond skills: packages & research

skillfed.io indexes more than skills, and the MCP tier (--with-npx) exposes all three streams as typed tools:

• find_skills — the vetted skill catalog everything above describes.
• find_packages — capability search over the PyPI package index. About to pip install whatever name the model recalled from its weights? Describe the capability instead and get back real, current packages — each with a what-it-does card, license treatment, and a worth-installing verdict.
• find_research — topic search over the research-notes index on the agent-skills literature: measured claims with sources, for when you want the evidence rather than a tool.

The two extra indexes are plain GETs (/api/packages/search.json?q=…, /api/research/search.json?q=…) — no auth, no tenant — so curl or any agent with a fetch tool