Proof beats promises

Every catalog on the internet has to answer one question before a visitor will touch anything on it: why should I believe you. Most answer with adjectives. Powerful. Seamless. Blazing-fast. We sell agent skills to the one audience on earth those words bounce straight off, so we built the listing to answer with receipts instead.

Developers spend their working lives reading claims and then checking them against a compiler. A README that promises the world and a test suite that says otherwise teaches the same lesson a few thousand times over: the marketing is the part you skip. By the time someone reaches our shelf, they carry the best-tuned marketing detector on the internet, and it is set to reject on sight. You cannot flatter that reader into an install. You can only show them something they can check.

The detector every developer ships with

Adjectives are free, and being free is exactly their tell. A developer reads "supercharge your workflow" as an absence — the place where a number should have gone and didn't. Every synonym of supercharge is a small confession that there was nothing measurable to say. So the page says nothing about a skill that the skill's own record can't back.

That constraint turns out to be clarifying. Once you refuse to make a claim you can't substantiate, the list of things you are allowed to put on a page gets short and honest. Three kinds of thing survive: a count, a piece of real usage, and the file itself. None of them care how we feel about the skill. That is the point of leading with them.

What the listing leads with

The listing puts three things first, in roughly this order of weight:

• Installs, with their curve. Not a raw click count — the installs table holds one row per unique environment, so the number is real setups, not page views. Uninstalls are stamped with a timestamp rather than deleted, so the history keeps what actually happened. We show the direction more prominently than the total, because a total is a snapshot and a direction is an argument.
• Real usage over time. Because uninstalls are stamped rather than erased, we can show how many environments still hold a skill a week after they pulled it. A launch-day spike is cheap; anyone with a few friends can manufacture one. A week-later number is a different kind of claim, and a harder one to fake.
• The file itself. Every skill's SKILL.md is readable in full before it touches your setup — the install API serves the whole thing, and the web listing shows it. The strongest proof a skill can offer is that you can read every line and decide for yourself. A skill that has to be hidden to be sold is not much of a skill.

We also record where an install came from. The fetch either looked like an agent or it looked like a browser, and we tag which. A curve built from real agent pulls means something different from a curve built from curious visitors, and we would rather know which one we are looking at than average them into a flattering blur.

Proof is a publish rule, not a suggestion

Here is the part that keeps the page honest under load: proof is not a field an author can leave blank. It is the gate.

You cannot publish a skill on Generalized without attaching at least one piece of proof — the publish transaction simply refuses to commit otherwise. The message that greets an author who tries to skip it is not gentle: receipts first. A proof link has to carry a title, because a bare URL is a dare, not evidence. And the caps are deliberately small: at most three links, at most six pieces of media, enforced not only in the form but by a trigger in the database, so nothing sneaks in through a side door.

proofs
  ≥ 1 per published skill    — checked in the publish transaction
  ≤ 3 links, ≤ 6 media       — enforced by a database trigger
  every link needs a title   — no title, no publish

One detail we are quietly proud of: the same gate runs on publish and on edit. An author cannot ship a skill with three solid receipts, collect the trust, and then quietly strip them out in an update. The rule that lets a skill onto the shelf is the same rule that keeps it there. There is no second, laxer path for a listing that already exists.

You can't adjective your way past a developer. You can only hand them the receipt.

What we left off

Plenty of things could have gone on the listing. The interesting design work was deciding what not to.

• Badges. Verified, featured, editor's pick — every badge is a claim the platform makes on the author's behalf, and any claim a platform can grant is a claim a platform can eventually be talked into selling. We do not have a badge we would trust on someone else's page, so we do not print one on ours.
• Star ratings. A five-star average with no denominator is theatre. Five stars from three friends and five stars from three thousand strangers render as the same five stars, which is precisely the problem. A rating that hides its sample size is an adjective wearing a number's clothes.
• Follower counts. A follower count measures how popular a person is, not how useful their file is. We sell the file. The author's name rides along as a signature — a way to build a reputation one checkable install at a time — not as a leaderboard where the already-famous start three laps ahead.

The pattern underneath all three is the same. Anything that can be gamed, bought, or inflated without the skill actually getting better is decoration, and on a page like this, decoration is a lie of omission. It borrows credibility the skill hasn't earned and spends it on the reader's trust. If a claim can't be checked, it doesn't get pixels.

None of this makes the listing warm. It makes it trustworthy, which for this audience is the warmer thing. A developer who installs from our shelf did it because the count was real, the file was readable, and nothing on the page insulted the detector they have spent a career sharpening. That is the entire design, and it is deliberately hard to fake.

Publish a skill and you inherit the same deal: no adjectives to hide behind, a receipt required at the door, and a curve that will tell the truth either way. Put your name on the file. Let the count do the arguing.