Methodology

What counts as a Claude Mod

A Claude Mod is a Claude Code plugin whose behaviour lives in hooks modules, named by the modules field of hooks/hooks.json (for example ["./register.ts"]). A package counts as a mod only after this evidence has been read:

• At the commit of the package's latest snapshot, the collector reads .claude-plugin/plugin.json and the hooks configuration it points to (hooks/hooks.json by default), parsed as JSON text only.
• modules must be one or more relative .ts/.js paths; a configuration that only declares event hooks (hooks) is not a mod.
• Each check is recorded per repository, commit and package path, append-only. A new upstream commit makes a new snapshot that is checked again; a package not checked yet is not a mod.

Discovery around the clock

The collector runs on the server that hosts this site and shares its SQLite database; it depends on no one's computer. A scheduler on the server checks once a minute whether a run is due:

• A full run every 6 hours: at most 20 repositories and 3 discovery searches (GitHub or web). Pending submissions are checked first, then repositories from the discovery queue.
• While submissions are pending, a submissions-only run starts at most every 5 minutes (at most 5 repositories each). Submission limit: 10 per IP per 60 minutes.
• Besides the GitHub repository and code searches, two of the rotating discovery queries search the open web (Exa's free search). Only GitHub repository links that appear in the results are kept; a small model (GLM 5.3 Flash on RunInfra) picks the ones that look like Claude Code mods, at most 10 per search. They join the queue as leads and are verified like everything else.
• Discovery is bounded: each run reads only part of the search results and the queue, so not every mod on the internet is listed; coverage grows run by run.
• Once a day, SQLite VACUUM INTO writes a consistent backup on the same volume; the latest 7 are kept. It recovers from bad writes, not from losing the volume itself.

Scheduler

Running · last check Oct 2, 2026

Next full run

Oct 2, 2026

Latest backup

Oct 2, 2026

Submit a mod repository

Data sources

Package records come from public GitHub repositories and from the marketplace manifests (marketplace.json), plugin manifests, skill files and settings files inside them.

• Social posts and third-party directories are discovery leads only, never evidence of quality or performance.
• Repository stars are a repository-level popularity signal, not package quality.
• A package without a clear public open-source license may still be indexed, but its license shows as “unknown”.

Package and version identity

Identifiers follow the upstream location; this site does not assign them:

• A package ID is made of the repository and the package's path inside it, with ~ standing for the repository root; several packages in one repository each get their own ID.
• A version ID is the package ID plus @ and the full 40-character commit SHA, and names one immutable snapshot. A new upstream commit creates a new snapshot; old snapshots are never overwritten.
• A version number declared upstream is only a label: one label can map to several commits, and pages mark that case as “same label, several commits”.
• The license is taken from the upstream record; when there is none it shows “unknown” and nothing is inferred.

Metric definitions

Repository stars

The GitHub star count of the repository, a repository-level popularity signal. Packages in the same repository share one number, and it says nothing about the quality of any single package.

Download requests

The number of valid download requests this site received; the counting rules are in the next section. A package page shows the total across all its versions, and a version page shows that version's own count.

Repository updated

The upstream repository's update time as collected. After 365 days without an update the list adds a “Not updated for over 365 days” badge. It is a hint, not a quality score.

Last checked

When the collector last checked the package. After 14 days the page warns that the data may be out of date.

Date indexed

When this site first discovered the package; it drives the “Date indexed” sort.

Data that does not exist

The registry does not collect or show token usage, cache hits, benchmark results or quality scores. Whatever was not measured stays missing, is never estimated, and metrics from different sources are never added together.

Downloads and download requests

Every version has a download entry point that redirects to the upstream GitHub source archive at that commit.

• Only real GET requests to the download entry point are counted.
• HEAD requests, browser prefetch and prerender requests, and requests with an empty User-Agent or one that calls itself a bot, crawler, spider, preview and the like are not counted.
• One visitor counts at most once per version per UTC day. Visitors are told apart by a daily salted hash; the raw IP address and User-Agent are not stored.
• A download request is not a completed download and certainly not an install: this site cannot see whether the transfer finished, nor installs done directly from GitHub or through a Claude Code marketplace.
• The archive is the entire repository at the pinned commit, not an individually packaged plugin. Package pages show the package's directory inside the repository.

Install commands

This site is not an npm protocol server and has no command-line tool of its own.

• A /plugin command is shown only when a version appears in a verified Claude Code marketplace manifest. The command is assembled from the marketplace name, the marketplace repository and the entry name in that manifest, using strictly validated characters only.
• These commands install the marketplace's current upstream state, not the commit snapshot pinned here.
• A package without a verified marketplace command shows no install command at all.

Collection limits

The collector runs within the limits below. Gaps caused by a limit are written to the run record instead of being treated as complete coverage.

• Only public GitHub repositories are read; no private repositories and no arbitrary URLs.
• Code, hooks and install scripts in indexed repositories are never executed.
• Marketplace sources that are supported: relative paths, github, HTTPS GitHub url and git-subdir. Sources such as npm, archive and command are recorded as unsupported and are neither run nor fetched.
• Response size, file count, tree entry count and request timeouts are all bounded; a truncated tree or a rate limit is called out explicitly in the run record. Early snapshots may not record omissions beyond 20 JSON configuration files or 64 KB of inline configuration. Original snapshots remain unchanged; component lists are not guaranteed to be exhaustive.
• A run processes 20 repositories by default and the discovery queue continues across runs, so coverage grows over time instead of being complete at once.

Unsupported sources

No unsupported sources have been recorded.

Collection runs

Status and messages come from the run records the collector wrote; these are the latest 10. Select a number for that run's details; without one, the latest run is shown.

API

The site's data is available through JSON APIs; observations are also available as an Atom XML feed. The only write endpoint is submissions (POST /api/submissions with a JSON body {"repo": "owner/repo"}), under the same rate limit. It is not npm protocol compatible and does not support publishing.

• GET /api/packages
• GET /api/packages/{id}
• GET /api/versions/{id}
• GET /api/skill-declarations?version={id}
• GET /api/stats
• GET /api/runs
• GET /api/runs/{id}
• GET /api/updates
• GET /updates.atom
• GET /api/sources
• GET /api/sources/{name}
• GET /api/following/{id}
• GET /api/submissions
• POST /api/submissions

The endpoints need no login and are bounded in page and response size.