agentleFS
kensauruskensaurus/cursor-kenji/skills/audit-registry-listing/SKILL.md

audit-registry-listing

Skill9 starsChanged 42 days agoMITView on GitHub

Read-only audit of where a repo is found: README first screen, npm/PyPI metadata and tarball, GitHub topics, social preview, plugin manifests. Use when "audit our npm listing", "README as landing page", or "why nobody finds the package". Fix → enhance-readme.

  • Reads credentials

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read-only. For a package, plugin, skill pack, or CLI, discovery happens in a registry and the README's first ten lines are the hero.

    line 18
  2. Very specific:

    Do not fire for "make the README prettier" → enhance-readme.

    line 35
  3. Distinctive:

    Read-only: No README, manifest, or repo-settings edits here.

    line 113

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

audit-registry-listing — The registry is the landing page

Degree of freedom: MIXED. What the first screen should say [HIGH freedom]; the metadata checklist and the tarball check [LOW freedom — run exactly].

Read-only. For a package, plugin, skill pack, or CLI, discovery happens in a registry and the README's first ten lines are the hero. This skill checks every surface a stranger sees before the repo, reports gaps with evidence, and hands fixes to the owning skills.

This skill vs neighbors

SkillOwns
audit-registry-listing (this)Findings on README hero, registry metadata, GitHub surface, manifests, install path
enhance-readmeHero image, tour grid, screenshots — the fix
docs-writerREADME prose, quickstart wording
deploy-npmThe publish itself; files/publishConfig changes ship through it
plan-asoApp Store / Play listings
enhance-web-seoThe website, not the registry
plan-dependency-provenanceWhether dependencies are real — not this package's listing

Do not fire for "make the README prettier" → enhance-readme.

How to reason

  1. Surface — which registry or page does a stranger hit first for this repo?
  2. Ten lines — can they say what it is, for whom, and how to install, before scrolling?
  3. Metadata — does the registry card (name, description, keywords, homepage, repo, license) say the same thing?
  4. Tarball — does the published artifact contain what the README promises and nothing it should not?
  5. Path — install to first success in under a minute, on a clean machine?

Worked example

Surface: npm page + skills.sh card + GitHub repo. Ten lines: README opens with a logo and a count ("145 skills · 57 commands"); the outcome appears in paragraph 3. Metadata: npm description repeats the count; GitHub description empty; 4 topics; no social preview; homepage points at skills.sh (good). Tarball: npm pack --dry-run shows docs/screenshots/ (12 MB) shipping; llms.txt present. Path: npx @kensaurus/skills --all works; first-run message tells the user to restart Cursor — good. Findings: hero leads with counts (major → enhance-readme/docs-writer); GitHub description + preview missing (minor → repo settings); screenshots bloat the tarball (minor → deploy-npm files).

Self-critique before reporting

  • Evidence — every finding quotes the line, field, or npm pack output
  • Stranger test — the ten-line verdict comes from a fresh-context subagent given only the README's first ten lines and the registry card, nothing else from the repo; this is the one place delegation pays here, because once you have read the repo your own read is no longer a stranger's
  • No fixes applied — findings and owners only
  • Right owner — visuals → enhance-readme; prose → docs-writer; files → deploy-npm; store → plan-aso

Checklist [LOW freedom — run exactly]

A · README first screen

  • Line 1–10: name, one outcome sentence (not a count), who it is for, install one-liner, one screenshot or terminal GIF.
  • Badges: version, license, one live proof (installs/downloads); no broken or stale badges.
  • Quickstart to first success ≤ 5 steps; a "what it is not" line.

B · Registry metadata (npm / PyPI / crates / gems)

  • name, description (outcome-first, ≤ 140 chars), keywords (the queries people type), homepage, repository, bugs, license, engines.
  • README rendered on the registry equals the repo README (or a deliberate short version).
  • npm pack --dry-run / python -m build listing: everything promised present; no .env*, keys, screenshots, tests, or 10 MB+ assets unless intended; files whitelist present.
  • bin names match the README; npx <pkg> runs without a global install.
  • Provenance / trusted publishing badge if available.

C · GitHub surface

  • Repo description (outcome, ≤ 120 chars), website URL, ≥ 5 topics that match the keywords, social preview image set (1280×640), releases with notes, pinned issue or discussion for feedback, SECURITY.md, license detected.

D · Ecosystem manifests

  • skills.sh / Cursor / Claude / Codex / Gemini plugin manifests: version in sync with the package, description in sync, install command correct on each surface, listing status honest (submitted ≠ listed).
  • MCP registry only if the repo ships a runnable server.

E · Install path

  • On a clean profile (temp HOME): install one-liner → first successful action; note every prompt, restart, or missing-key stop; time it.

Report template

# Registry Listing Audit — <package>

## Surfaces checked
| Surface | URL | Fetched |

## Ten-line verdict (stranger read)
What it is: … · For whom: … · How to install: … · Missing: …

## Findings
| # | Surface | Gap | Evidence | Sev | Owner skill |

## Tarball
`npm pack --dry-run` — N files, X MB; unexpected: …

## Install path
Steps … · Time … · Stops …

## Handoff
`enhance-readme` (hero/screenshots) · `docs-writer` (prose) · `deploy-npm` (`files`, metadata) · repo settings (description, topics, preview)

Guardrails

  • Read-only. No README, manifest, or repo-settings edits here.
  • No count-led heroes. Recommend the outcome sentence; counts go in a badge.
  • Honest listing status. "Submitted" and "listed" are different words.

Chains with

  • plan-gtm → for repo-as-product, this is Phase 1 evidence.
  • enhance-readme / docs-writer → apply the findings.
  • deploy-npm → ship metadata and files fixes.
  • docs-launch-kit → announce the refreshed listing.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.