Gaia Skill Tree Meta Audit Series

Honestly, this started as a simple question: what are the best agent skills out there that we haven't curated yet? Gaia's registry is deliberate and slow by design — we don't crawl and import; we evaluate. But the flip side of that discipline is genuine curiosity. Are we missing something? Is there a skill that 400,000 agents are using that we've never looked at? That felt worth knowing.

So we went to skills.sh — the closest thing the agent skills ecosystem has to a public leaderboard — and pulled the top 100 non-Microsoft entries. Fresh eyes. No assumptions. We genuinely wanted to find things worth adding.

What we found instead was a lesson in what install count actually measures. The leaderboard isn't a ranking of quality, usefulness, or originality. It's a ranking of distribution. And distribution, it turns out, is trivially gameable when you're a large SaaS platform that bundles skills with your product and counts every agent initialization as an install. The top of the leaderboard isn't the best skills — it's just the most-bundled ones. That distinction matters enormously if you're trying to curate.

The Funnel

We started with all 100 entries. Before any embedding or deduplication work, 23 were flagged and set aside immediately: the entire Microsoft/Azure cluster from microsoft/azure-skills. We'll come back to why. The remaining 77 non-Microsoft candidates entered the mechanical pipeline — embedding similarity against Gaia's 321-node registry, deduplication, and L4 human review.

Here's how the full 100 collapsed:

Of the genuinely independent entries — non-vendor, non-duplicate — only two contributors' work cleared the L4 human review gate: supabase and remotion-dev.

Two Vendor Clusters, 73 Entries

Here's the number that stopped us: 73 of the top 100 entries come from just two vendor clusters — and both tell the same story.

Lark/Feishu: 50 entries, two identities. open.feishu.cn accounts for 27 packets; larksuite/cli accounts for 23 more. These are the international and China-facing names for the same ByteDance product. The repo itself has 16,323 stars — legitimate — but those stars are for the full Lark CLI platform, not for the agent skills specifically. The skills ship bundled with Lark. Every Lark agent initialization is an install. That's not adoption; that's distribution.

Microsoft/Azure: 23 entries, 1,364 stars. The microsoft/azure-skills repo has fewer GitHub stars than remotion-dev/skills (4,255) — a niche video framework skill suite. Yet it contributes 23 entries to the top 100 with an average of ~475,000 installs each. The repo was created in February 2026 and has 224 forks — almost certainly enterprise Azure deployments bundling the skills into agent scaffolding. Same mechanism as Lark: product distribution masquerading as organic install count.

Together, these two clusters account for 73% of the leaderboard and represent a combined ~34 million installs — none of which reflects a developer deliberately seeking out and installing a skill. All 73 rows are held. Lark pending source topology resolution (#1512); Azure pending a repo-level audit before any skill-level intake.

Why Install Count Is a Bad Signal

skills.sh is essentially an npm registry for agent skills. Like npm, it is good at tracking distribution. Like npm, it is bad at tracking quality. Install count tells you how many agents have downloaded a file. It does not tell you whether the file describes a real, reusable capability, whether anyone actually verified the author wrote what they claim, or whether the skill would survive contact with a codebase that isn't the vendor's own product.

We are attribution-driven, not distribution-driven. Every Gaia registry node traces back to a real author, a real repo, and a real demonstrated capability. Trust Magnitude — our scoring system — weights peer review, benchmark evidence, and independently verifiable source quality. A skill with 472,000 installs and zero peer review evidence does not automatically outrank a skill with 12,000 installs and two independent benchmark citations.

This matters more as the ecosystem matures. The era of "install everything, sort it out later" produced npm's current state: millions of packages, a few thousand that actually matter, and a long tail of abandoned or trivially duplicated code. We are deliberately building a smaller, curated graph. The skills.sh run confirmed: if we had blindly imported the top 100, we would have duplicated roughly half our registry and introduced at least one leaderboard-inflated vendor cluster. Hard pass.

What Actually Passed

Supabase — both their core skill and their Postgres best practices skill — passed cleanly. The Postgres one is worth noting: it comes in at rank 99 on the leaderboard with 338,426 installs, and its scope is genuinely broad. It's not just "use Supabase Postgres." It covers schema design, migrations, RLS policies, pgvector, pg_cron, pgmq, EXPLAIN plan analysis, connection exhaustion, locking, bloat — the full stack of operational Postgres concerns. The skill earns its place on capability grounds, not install count. Rank 99 on skills.sh; approved.

Remotion is the more interesting story. The skills.sh entry is rank 55, 472,033 installs, one skill. We pulled the source repo (remotion-dev/skills) and found twelve distinct skills covering the full Remotion production pipeline: core API, Lambda rendering, Player embedding, Cloudflare Workers, CLI tooling, GitHub Actions integration, Tailwind compatibility, and more. The single leaderboard entry was essentially a compressed archive of a complete skill suite. We expanded it. That's what good curation looks like — you don't just stamp the manifest, you find the actual shape of the capability and model it properly.

The Remotion suite is approved with one open question: issue #1513 tracks whether the suite qualifies for router/suite elevation. That's a separate calibration question; the skills themselves cleared the bar.

On Demotion

A short honest note: both the remotion- skills and the supabase- skills are tagged as non-standalone. They describe capabilities that are entirely specific to a single product ecosystem. That's not disqualifying — many valuable skills are product-specific — but it does create a ceiling on how highly they can rank without broader adoption evidence.

A future calibration pass may lower these skills one level under a "non-standalone" classification. The reasoning: a skill tied entirely to Remotion or Supabase cannot transfer to adjacent work without the product. That's a different kind of evidence requirement than, say, a skill about Postgres index design, which travels across any Postgres deployment. We are flagging this now, not acting on it yet. The approved skills keep their current levels while we watch how they perform in practice and gather independent benchmark evidence.

This is a live classification, not a verdict.