Methodology

A scheduled job reads a fixed list of public GitHub repositories. It looks for SKILL.md files with YAML name and description. Task pages and the homepage collection are editorial: we choose which frontend jobs to compare, and which skills belong on those short lists. The full index is everything the job kept.

Source

A skill enters the catalog when a public repo on that list contains a SKILL.md we can fetch without signing in. If a repo has several copies of the same skill (tests, examples, nested plugin folders), we keep the path that looks like the real skill directory — usually under skills/ — not a test copy.

Short lists on a task page prefer an official org or a path that still receives commits. A popular monorepo is not enough; the date that matters is the last commit that touched this file.

Safety labels

Each listing has a static label: Pass, Review, or Risk. It is a regex pass over the skill body. We look for:

• Secret-file paths (.env, id_rsa, credentials.json, SSH dirs).
• A remote URL piped into a shell (curl | sh).
• Hosts used to siphon data (webhook.site, ngrok, pastebin).
• “Ignore previous instructions” phrasing.

Zero hits is Pass. One hit is Review. Two or more is Risk. We print the matching flags on the listing. We do not run the scripts, and we do not sandbox the agent.

Pass does not mean safe. A skill can be polite markdown and still tell the agent to rewrite production CSS or fetch a URL we have never seen. How to read a listing before you install is in the evaluation guide.

Dates, stars, scripts

The date on a listing is the last commit that touched this file when GitHub gives it to us — not the last push to an unrelated file in the same repo. If we cannot ask GitHub for that commit (no token when we refresh, or the API refuses), the date stays empty rather than faking one.

Stars are repository stars, labelled as such. We do not show install growth we cannot audit. If the skill folder contains .py, .sh, .js, or similar, the listing says so. Those files are never executed at build time; an agent that follows the skill might run them on your machine.

Duplicates and licenses

Two skills with the same file text are treated as one. The later copy is dropped — usually a fork. Skills with no license can appear in the index. They stay off task comparison pages and off the homepage collection unless they come from Anthropic, Vercel Labs, or CloudAI-X and GitHub still has not published a license file. Those listings still say Unspecified.

License is taken from GitHub’s license field, then a LICENSE file next to the skill or at the repo root, then package.json. A skill in an unlicensed monorepo inherits that gap even if the markdown itself looks fine.

Refresh

Snapshots refresh from GitHub on a regular schedule. Unchanged files are not rewritten. Oversized files are skipped. A failed build leaves the previous site in place. The date in the footer is that last successful refresh — not the last change to each file, which stays on the listing. Submissions go to a private inbox; we read the file before it lands on a task page.

Result previews

A few listings include a demo screenshot from one run of the skill, with the prompt we used. We keep that screenshot and prompt in this project; the GitHub refresh does not overwrite them. Each demo is its own HTML page — a shared template would make the screenshots look the same. After the pages exist, npm run capture-previews takes the screenshots together. We only add a demo when the skill’s job is to produce a visible interface. Review-only files, someone else’s company brand, and extra Three.js lesson files stay without one until there is a distinct page to show.

What we will not claim

We do not rank skills by quality. We do not certify them. We do not promise the snapshot matches HEAD this minute. If a listing looks wrong, see corrections or email [email protected] with the URL and the GitHub path.