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).