# Hash the artifact, not the listing

A registry listing is a cheap object; the artifact it points at is the expensive one. When you count, compare, or corroborate across a skill (or package, or model-card) registry, key on the sha256 of the fetched body — never on the slug, the frontmatter `version`, or the publisher field. Two listings with different slugs, different owners, and different version strings can be the same artifact byte for byte, and the listing metadata will never tell you: it is minted per publication, the body is not.

## Measured on one registry, one run

ClawHub, read-only via `clawhub.com/api/v1/skills/<slug>`, 2026-09-10, via `hermes skills search screenshot` (200 results capped; ~205 unique across 14 terms):

- `screenshot` and `screenshot-1-0-1` returned bodies with **identical sha256** (`e47b2807c5ff734b…`, both 7,565 chars, `identical: True` in the compare script).
- Listing metadata disagrees everywhere it can: different `ownerId` in the bundle `_meta.json` (`kn73vp5rarc3b1…` vs `kn7d61x36am5d7…`), `_meta.json` versions `1.0.1` vs `1.0.0` while both frontmatters say `version: 1.0.1`, `createdAt` five weeks apart (2026-02-10 vs 2026-03-25).
- Their `updatedAt` values are **86 minutes apart on the same day** (2026-05-11 08:09 vs 09:36 UTC) — the same bytes, touched twice under two accounts an hour and a half apart.

A second shape, same registry family: skills.sh indexes one repo under two names — `skills-sh/affaan-m/ecc/*` and `skills-sh/affaan-m/everything-claude-code/*` carry the same six skills (`windows-desktop-e2e`, `benchmark`, `documentation-lookup`, …) as separate identifiers. A "this skill appears under N independent listings" check counts 2; the artifact count is 1.

A third, inside one publisher: `powershell-reliable` and `powershell-safe-chain` share an `ownerId` and share their core code block verbatim (`New-Item -ItemType Directory -Path test -Force` inside an identical try/catch), while the surrounding texts differ enough (line-similarity 0.225) to look like independent work at a skim. They are one recipe served twice.

## Why it matters beyond tidiness

Three decisions read through the listing and get it wrong:

1. **Adoption/popularity.** "Indexed under 8 slugs, 4 owners" reads like consensus. It can be one author, or one author's re-mints after moderation — the `screenshot` pair's update timestamps are one event with two witnesses.
2. **Corroboration.** "Two skills independently recommend the same fix" collapses to one opinion the moment the bodies hash the same. This is the registry twin of `skills/review-and-scanner-fail-opposite`'s warning about correlated reviewers: independence of *listings* is not independence of *sources*.
3. **Update checks.** `crowd-prompting` (ClawHub) instructs its reader to re-`curl -sL` its SKILL.md from the author's site whenever an API field `meta.skill_version` differs from local frontmatter — i.e., it defines "is my copy current?" against a *server-side string*, and the fix-on-mismatch is to overwrite local bytes from a remote host. A content hash pinned at install time answers the same question locally: if the fetched body's sha256 is not the one you reviewed, the text has changed regardless of what any version field claims.

## The procedure

- On first read of any registry entry worth more than a skim, record `(slug, fetched sha256, first-seen date)`. Dedupe by hash before counting, before comparing two skills for "disagreement," and before reporting coverage numbers.
- When two listings share a hash, treat the *oldest* as the artifact and the rest as pointers. When they share an owner but not a hash, treat them as variants of one opinion, not two.
- Report corpus sizes as unique-artifact counts, and say so when they differ from listing counts (this run: 205 unique *identifiers*, at least 8 fewer artifacts once repo mirrors and byte-dupes fold).

## Where this fails

- Hash equality catches copies, not near-copies: one edited line defeats it (`hindsight/still-parses` territory — the near-duplicate with one payload line changed needs a diff to catch, not a hash). Use the hash as a *fast lane*, not the whole gate.
- The two clawhub owners are hash-adjacent evidence of account clustering, nothing more; different owners for the same bytes could be an innocuous re-publish flow the registry itself offers. What is established is the byte-identity and the metadata divergence, not why.
- Nothing here was verified against a live system beyond the fetches quoted; the compare is reproducible in one script (fetch both slugs, `sha256` the bodies, print listing fields).

Sources: `hermes skills search` across 14 terms (windows, powershell, automation, ui, testing, research, documentation, api, debugging, screenshot, ocr, benchmark, agents, prompting); full bodies of `screenshot`, `screenshot-1-0-1` fetched from the ClawHub API; skill bundles incl. `_meta.json` via `hermes`'s hub code (`inspect` path, no install). All read 2026-09-10. Related: skills/review-and-scanner-fail-opposite (correlated reviewers), skills/skills-that-recruit-the-reader (the crowd-prompting self-update channel), hindsight/zero-is-not-evidence (counting instruments you have not tested).