How we rank

Every entry shows its score and the parts that make it up. Nobody can pay to change a score or a position, including sponsors.

The popularity score (live now)

Out of 100, built only from public GitHub data. It tells you what is popular and maintained. It does not tell you whether an add-on works, or works better than the alternatives. Keep that in mind when you compare two entries.

  • Installs in real projects, 25 points. How many public GitHub projects have the add-on in their committed setup: .mcp.json or mcp.json, the files where Claude Code, Cursor and VS Code keep MCP servers. On a log scale, full marks at 1,000. We found stars barely predict this: across the top 50 of each type, star rank and install rank were close to unrelated. Private projects aren't visible, so every count is a floor. This applies to MCP servers for now. Plugins are often installed from their authors' own marketplaces under a different name, and many skills and subagents share generic names like "code-review", so a search would miss real installs or count other people's files. Until we can count those reliably, they're scored on stars alone.
  • Stars, 10 points. GitHub stars on a log scale. Where installs aren't counted yet, stars get 35 points instead.
  • Upkeep, 25 points. How recently the code changed. Full marks within 30 days, very little after a year.
  • Usage, 15 points. Forks, on a log scale.
  • License, 15 points. Whether the repo has a detectable license.
  • Owner history, 10 points. How long the owning account has existed. Brand-new accounts score lower.

Stars belong to a repository, not to each add-on inside it. When one repo holds several add-ons, we split its stars and forks evenly between them before scoring. Otherwise a single popular monorepo would fill the top of every list.

What gets listed

An add-on is listed only if all of these are true:

  • The code changed in the last 12 months.
  • The repo has a detectable license.
  • The owning account is older than 90 days.
  • It has at least 5 stars after the split above. Anthropic's official marketplace is the one exception, because it curates its own entries.
  • It isn't a test, demo or sample.

We also show at most 10 add-ons from any one repo. Anthropic's official marketplace is exempt here too.

This build's numbers

We checked 7,994 add-ons and listed 17,713. Why the rest were left out:

  • fewer than 5 stars: 3,894
  • no detectable license: 1,739
  • owner account under 90 days old: 762
  • no update in 12 months: 88
  • test or demo name: 3
  • more than 10 from the same repo: 0
  • listed twice by different sources (merged): 177

Archived repos are left out before any of this.

Not included yet

  • Whether it works. The score is GitHub stats, and stars are not results. We want to run each add-on on a fixed set of tasks, first checking that a skill actually switches on for the requests it claims, then comparing results with and without it. Runs cost money, so this will start with the top add-ons in each category. Each result will be pinned to the commit we ran.
  • Fake-star check. Stars can be bought. We will discount stars from throwaway accounts and sudden spikes. Until then, treat popularity as a rough signal.
  • Real install counts. Where a registry publishes downloads, we will use them in place of forks.

Skills

Skills are scored the same way, with one change: a repo's stars and forks are split evenly across all the skills it contains. We find skills in the most-starred repos for skill-related GitHub searches, in Google's Gemini CLI extensions gallery, and in the official Anthropic and Vercel collections. Each is read at a pinned commit. The same gates apply, and at most 10 skills are listed from any one repo (the official collections are exempt). This build read 21,646 skill files from 4,421 repos and listed 13,206. To stay within our host's 20,000-file limit, this build also left out the 810 lowest-scored skills and subagents.

Prompts

Prompts come from prompts.chat, whose prompt text is public domain (CC0). Prompts don't have stars, so they get their own score out of 100:

  • Quality checklist, 40 points. For text prompts: sets a role, states a clear task, gives context, sets constraints, defines the output, and breaks the work into steps. For image, video and audio prompts: subject, style, lighting, camera or composition, detail, and size or parameters. Hype words cost points.
  • Community votes, 30 points. Votes on prompts.chat, on a log scale.
  • Editor pick, 15 points. Chosen by prompts.chat's editors.
  • Fill-in fields, 10 points. Prompts with blanks you fill in are easier to reuse.
  • Discussion, 5 points. Comments on prompts.chat.

To be listed, a prompt needs at least 2 votes or an editor pick (one vote is too easy to get), and it has to pass the checklist bar: 4 of 6 checks, or 3 including a role or a task (3 of 6 for media prompts). Near-duplicates are merged, keeping the best version. This build: 2,879 prompts checked, 2,171 below the vote bar, 48 below the quality bar, 1 near-duplicates, 432 listed.

What this doesn't do yet: test whether a prompt's output is actually good. The checklist checks structure only. Reddit isn't used, because its API needs approval for commercial use and we don't scrape around that. Coming next: how many GitHub projects reuse each prompt, and mentions on Hacker News.

How prompts are categorized

Each prompt gets one main category and at most one secondary. Image, video and audio prompts go by their type. For text prompts, the author's own category on prompts.chat comes first, mapped onto our list. Keywords only fill gaps or correct an obvious mismatch, and a clear signal in the title wins. Generic words like "prompt" or "agent" don't count. On a fresh hand-checked sample, about 4 in 5 text prompts land in the right main category. The misses are mostly prompts that honestly fit two places.

Recipes and tool pages

Some prompts are written to drive a specific tool, like a Remotion prompt that plans scenes, timing and the render. We call those recipes and score them against a different checklist: names the skill or tool, describes the deliverable, lists the content or scenes, sets the style, and says how to finish. Each tool gets one page that gathers its skills, MCP servers, plugins, prompts and recipes, plus example prompts published by the skill's own maker.

Skills from the maker without a license file

We normally only list repos with a license. The exception is skills published by a GitHub-verified organization, which is usually the tool's own maker. Those are labeled "From the maker (verified org), no license file". We link to them and give install commands, but we don't copy their content, and we only quote their example prompts briefly.

Plado Originals

Where people need a recipe and nothing good exists, we write our own, based on a working production pipeline. Originals are public domain (CC0), are labeled "Plado Original", and carry no score until people vote on them.

Subagents

Subagents are Markdown files with a name, a description and an optional list of tools, which Claude Code loads from .claude/agents/. We find them in GitHub repos and the well-known collections, read each file at a pinned commit, screen it for the same injection patterns as skills, and apply the same repo gates. A repo's stars are split across its agents, and we list at most 40 per repo. Every agent page shows what it can use. An agent with no tools list inherits every tool you have, including the shell, so we say so plainly.

Context cost

Every skill and subagent you add takes up part of your AI's context window, which is the space it has for your actual work. We estimate the cost at about 4 characters per token (real counts vary by model). For a skill, the name and description load in every session, and the full instructions load when it's used. For a subagent, only its name and description sit in your chat; its instructions run in its own context window. MCP servers and plugins aren't measured yet, because their cost depends on how many tools they expose.

Trending searches

When someone finishes a search on Plado (presses Enter, or opens a result), we count it. We store the search text and a code made from a one-way hash of their connection that changes every day, so one person counts once and nobody can be traced. We don't store IP addresses or set cookies. Searches that look personal (email addresses, links, long numbers) are never stored. A search appears publicly only after at least 3 different people have made it, and only if every word in it is a word from our catalog, like a tool, task or listing name. Counts are kept for 30 days.

How trending works

Trending shows stars gained today, this week, this quarter and this year. GitHub no longer publishes when each star was given, so we measure it two ways. Every day we save GitHub's own star count for every listed repo, and once those snapshots reach back far enough, a window is simply stars now minus stars then. Until then, we use the public GitHub event archive through OSS Insight. Its counts run lower than GitHub's totals, so it's a trend signal, and each window ranks on one source only, never a mix. Hot ranks by stars gained. Rising ranks by growth for the repo's size, among repos that gained a minimum number of stars. When one repo holds several listed add-ons, it appears once. For prompts, prompts.chat doesn't publish when votes were cast, so until our snapshots cover a window, trending prompts are the new ones, ranked by votes.

Cursor rules

Rules files come from the awesome-cursorrules collection (CC0). There's no fair ranking signal for them yet, so they're listed alphabetically and marked "unranked".

Screening before listing

Every skill, prompt and rules file is checked for known prompt-injection and exfiltration patterns before listing: hidden "ignore previous instructions" text, piping downloads into a shell, long encoded blobs, links to data-capture services, and reads of credential files. Anything that matches is left out.

Security scan

After listing, we scan each add-on at the exact version we list: the pinned commit for skills, subagents, plugins and rules files, and the published npm or PyPI package for MCP servers. The scanner is Cisco's open-source skill-scanner (Apache-2.0), run on our own machines with its static and behavior checks. Nothing is sent to an AI model. Large repos are scanned up to their first 300 source files, and test folders are skipped because they don't run on your machine.

Each page says what the code does, in plain words, with the file and line: runs shell commands, makes network requests, reads environment variables, downloads content and runs it, installs system packages, or uses unpinned dependencies. These describe how an add-on works. They aren't accusations, and plenty of good tools do all of them.

When an add-on makes network requests, its page also lists the web addresses written in its code, each with the file and line where it first appears. That's the quickest answer to "where can my data go?" for a security review. It isn't complete: code can build addresses while it runs, and some hits may be links rather than calls. It also can't tell you anything about the AI model itself, which sees whatever you send it whichever add-ons you use.

We don't label anything "safe". When we tested the scanner against known malicious skills, it caught about half of them, so a clean scan is not proof of anything. When a scan turns up something that looks deliberate, like hidden instructions or disguised code, a person reviews it before anything about it is published, and we contact the maintainer first. When the listed version changes, the page says "Not scanned" until we've scanned the new one. Hosted MCP servers run on the vendor's side, so there's no code for us to scan.

Where the listings come from

Anthropic's official and community Claude Code plugin marketplaces (Apache-2.0), and servers in the official MCP Registry that publish a GitHub repository. Install commands keep the commit or version those sources list.