How installs are counted

Every skill on the shelf carries a small curve — installs over time — and a number beside it. Numbers that decide rankings get gamed, so the rules that produce this one are public, dull, and deliberately hard to flatter. Here is exactly what moves the number, what leaves it alone, and why we built the counting to resist the person most motivated to inflate it: the author.

What counts

An install is one specific thing: an agent, in a real project, pulling a skill's SKILL.md in order to use it. Not a page view. Not a click on the install button. Not an admiring human reading your proof. The counter moves at the moment the file that does the work leaves the building.

The install API serves each skill as a manifest plus a set of files. Reading the manifest tells an agent what the skill is and shows it the proof and the stats; that read does not count. The count fires one level deeper — when the agent fetches SKILL.md itself, the file it must have to run the skill at all. A kit counts a step earlier, when an agent pulls the kit manifest, and each member skill then earns its own install as its SKILL.md is fetched in turn. You get credited for the thing being used, not for the thing being looked at.

That fetch writes one row:

installs
  skill_id        -- which skill
  client_hash     -- who, hashed (never the raw address)
  source          -- 'claude' when the fetch looked like an agent, else 'web'
  installed_at
  uninstalled_at  -- set on removal; the row is never deleted

One row per unique environment per skill. A unique index on the pair means the second fetch from the same place is a no-op: it inserts nothing and increments nothing. You install a skill once from a given environment, and that is the install, however many times your agent re-reads the file afterward. Because only agent fetches ever reach the counting path, every row on the graph carries the same source tag — the number under your name is agent installs, end to end.

What doesn't move the number

Most things don't. The counter is quiet by design, and the quiet is the feature.

• A browser looking at the page. The counter responds only to fetches whose user-agent looks like an agent — Claude Code, or an Anthropic client. A human refreshing your skill all afternoon moves it by zero.
• A second install from the same place. Unique per environment, forever. There is no thirty-day reset and no counting the same machine twice; re-pulling the file after an uninstall does not re-mint the install.
• Rotating user-agents. Identity is the network address, not the user-agent string, so swapping headers to look like a hundred fresh clients still hashes down to one installer.
• A flood from one address. A single environment can mint at most twenty new installs a day, across every skill on the site. Past that the fetches still serve the files; they just stop counting.

We are honest about the ceiling here. User-agents are spoofable, and identity keyed to an address is coarse — several machines behind one office router share one installer. The number is a floor on real use, not a cryptographic proof of it. The honest fix, signed install receipts from the client, is on the list. Until then the rules make casual padding more work than it is worth, which is all a public number needs to be.

The who is never kept as an address. We take the best client IP the proxy chain gives us, salt it, and store only the SHA-256 hash of the result. That is enough to recognize the same environment coming back and refuse to double-count it, and not enough to reconstruct where it came from. The ledger can tell that you installed twice without ever knowing your address once.

The number is a cache, the rows are the ledger

The count on the card is a denormalized integer — a running tally kept next to the skill so a page load doesn't have to recount from scratch. It is a convenience, not the record. The record is the installs table: one row per event, every one of them recoverable. If the cached number and the rows ever disagree, the rows win and the number gets rebuilt from them. Nothing you see is a figure we cannot show our work for.

That shape is also why an uninstall erases nothing. It does not delete a row; it stamps the row with the time the skill left. The history stays intact — the number can fall without the ledger forgetting it ever rose. Net counting is a door we deliberately left open in the schema, and one measurement already walks through it.

Why the curve won't flatter you

A raw total rewards being early. The curve rewards being good now.

The sparkline is thirty days of real install events, bucketed by day and drawn cumulatively. Everything older than the window collapses into a flat baseline — an old skill coasting on installs it earned a year ago draws a level line, not a manufactured climb. If the curve is rising, people are installing the skill this month. If it is flat, they aren't, whatever the lifetime total says.

The directory does sort by that lifetime total, so the number carries weight. But two skills sitting at a thousand installs are not the same product if one earned its thousand last month and the other three years ago, and the curve is what separates them at a glance. A total tells you a skill was once wanted. The curve tells you whether it still is.

The week-later question

An install is a hypothesis: someone's agent judged this skill worth pulling into a real project. Whether the judgment held is a separate measurement, and it is the one we find most honest. On every skill page, once a cohort is old enough to judge, we show retention — of the installs that have had at least a week to prove themselves, the share still in place, never uninstalled. Before that cohort exists there is nothing to show, so we show nothing rather than a flattering guess.

That figure is quieter than the install count and much harder to game, because it is not about getting pulled once; it is about not getting removed. A skill can spike to a thousand installs on a strong demo and a good day. It cannot fake a room of people who tried it a week ago and kept it around.

This is what we mean when we say the shelf does the talking. The counting is built to be boring on purpose, so the number under your name means the thing it claims to mean — not that people looked, but that agents used your work and left it installed. Publish the file, and the ledger keeps an honest tally. That is the only kind worth putting your name on.