Choose with more than a star count.

What decides each list's order

The main leaderboard lists the most-starred tracked repositories, ordered by GitHub stars, with repository name breaking ties; search covers every tracked repository. Trending lists repositories whose GitHub stars grew at least 5% in 24 hours, ordered by percentage growth: the change divided by the star count 24 hours earlier. New lists repositories created less than 30 days before the latest data update. Community votes do not change the main star ranking.

How the weekly community vote works

Hot ranks projects by valid votes for the current week, from Monday to Sunday in Europe/Rome. Each eligible GitHub account has one vote and can change its choice before the week ends. Voting happens through an authenticated MCP connection and requires explicit user confirmation.

Accounts must be at least 30 days old, and you cannot vote for your own repository. Security and abuse checks can block, hold or void votes. We publish totals, never who voted. Sponsorship never changes the votes or their order.

Hot captures community opinion about project usefulness. We do not verify that a voter installed or used a project, or that the project completed a task successfully.

Read the voting rules and examples →

How Heat measures momentum

Heat combines six signals into a score from 0 to 10. It describes recent momentum, rather than an approval rating or a count of users:

• Star growth over seven days and over 24 hours: two separate signals, with a minimum starting star count in the calculation so very small projects do not dominate.
• Movement in the star ranking over seven days.
• Commits in the last 30 days.
• Eligible accounts asking about the project through MCP over a seven-day window. Requests show interest; they do not prove installation or use.
• Valid Hot votes from the current week, capped at 20 per project for this calculation.

Each component becomes a percentile among admitted repositories: how many other projects have a lower value. Configured weights combine the available components. A missing component, or one with no variation, drops out and its weight moves to the others. Repositories without seven-day star history or any usable components show Insufficient history.

Heat appears next to each repository, and you can sort or filter a list by it in your browser. The Heat page lists repositories by heat, then by stars. Heat never changes the leaderboard, which stays ordered by GitHub stars. Hot votes are one input to Heat; Heat remains a momentum score, not the weekly vote tally.

Sponsorship never touches heat. For a repository with an active MCP campaign, and for 7 days after it ends, MCP interest does not count.

Read the monthly State of agent skills report

How My skills saves count

Signed-in developers can keep the skills they use in My skills on their hotskills account, from a skill page or from their agent after confirming. “Saved N times” counts the active GitHub accounts at least 30 days old that saved a repository, and appears only from 3 saves, so no single person can be recognized. The Most saved page lists repositories by saves, then by stars.

Saves never change the leaderboard, which stays ordered by GitHub stars, and they are not part of Heat. Sponsorship never changes them.

Tools never change catalog data. The only writes are your weekly Hot vote and your own My skills list, always after your confirmation.

See the most saved skills

What gets included

We track public GitHub repositories that distribute agent skills. Discovery, verification and ranking run without an LLM. Inclusion follows the same rules for discovered projects and submitted suggestions.

A repository needs a public SKILL.md outside internal agent configuration folders and at least three verification points. A root SKILL.md earns two points; having at least 20% of files in skill folders also earns two. A skill folder matching the repository name, skill in the repository name, ten or more SKILL.md files, discovery from a skills topic or curated list, and valid frontmatter each earn one point.

Archived repositories, forks below ten stars, link-only lists with more than 60 README links and fewer than three skills, and copies with the same tree are excluded. Explicit allow and deny lists override automatic rules.

Skills are counted by unique SKILL.md content, rather than by file copies. Missing growth history is shown as unavailable, never as zero.

What the security signals mean

Static scans flag scripts, network use, broad shell permissions, dangerous operations, access to secrets, obfuscation and instruction overrides. Each signal links to its source file and line. A badge is not a security audit or an endorsement.

We currently publish three levels: Instructions only, Local scripts, and Network or broad shell.

Needs a closer look comes from rules that read what a skill’s files actually run and what its SKILL.md orders the agent to do. Prose that describes, quotes or warns about an attack does not count. On a blind sample of 100 skills, labelled by people who do not write the scanner, 2.2% of the skills that did not need a closer look were flagged anyway (95% interval 0.3% to 7.8%).

When a file that runs could not be analyzed to the end, the skill keeps the level it had until that file changes. A change in our rules does not lower it: the file has to be read in full first.

Detected signals for secrets, obfuscation and instruction overrides still appear with source files and lines on the skill page, whatever its published level.

Security results apply to the scanned commit. If the current repository commit has not been scanned, its level is shown as Not checked yet. Results produced with older scanner rules are marked as checked with an earlier scanner version. Check dates and source links help you judge how current the evidence is.

Explore the Scanner and its setup requirements →

Smokecheck: the security levels

Every security level on hotskills comes from Smokecheck, our own scanner: deterministic, offline, no LLM, tied to the commit. It reads the code that would run and the imperative instructions in the SKILL.md, and gives one of four levels from seven families of signals. We publish the families and the method, not the signal-by-signal detail. Automated signals, not a guarantee.

How Smokecheck works →

What Active, Slowing and Abandoned mean

Each repository gets a project activity label from its own GitHub data. Active means a push in the last 60 days or at least one commit in the last 30 days. Abandoned means no push for more than 365 days and no commits in the last 30 days. Everything else is Slowing.

Issues count too. Each night, in rotation, we read up to 20 of the latest issues opened in the last 90 days and measure the hours until someone other than the author first replies. Replies from bots and issues opened by maintainers do not count, issues younger than 7 days wait until they are older, and an issue still waiting for a reply counts the time it has waited so far. A repository with at least 100 open issues and a median first reply above 14 days is Slowing, even with recent commits. We keep only that median, never issue text, comments or usernames.

Repositories with issues turned off, or with fewer than 3 issues we can measure, are judged on pushes and commits alone.

Source and licenses

SKILL.md excerpts appear only when the export confirms a compatible license. Token counts are estimates. Installation commands refer to a recorded commit, so later repository changes do not silently change that version.

Sponsorship stays separate

Sponsors never change the ranking order, star counts or security results. Paid placements are clearly labeled Sponsored suggestion and are shown outside the ranked list.