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
- kensaurus/skillsword for word, first seen Oct 1, 2026
Other versions1 project uses a version of this.
Word for word · 1
- kensaurus/skills★ 9100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository165 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .cursor/rules/approved-plan-execution.mdcCursor rule
- .cursor/rules/skill-workflows.mdcCursor rule
- .cursor/rules/verification-before-completion.mdcCursor rule
- llms.txtllms.txt
- audit-accessibilitySkill
- audit-agent-speedSkill
- audit-analyticsSkill
- audit-auth-flowsSkill
- audit-backend-architectureSkill
- audit-bundle-sizeSkill
- audit-cicdSkill
- audit-codemod-safetySkill
- audit-code-qualitySkill
- audit-code-reviewSkill
- audit-db-schemaSkill
- audit-doctrineSkill
- audit-env-paritySkill
- audit-fe-apiSkill
- audit-gate-logicSkill
- audit-i18nSkill
- audit-infra-costSkill
- audit-langfuse-llmSkill
- audit-llm-securitySkill
- audit-monetization-iapSkill
- audit-payment-systemSkill
- audit-performanceSkill
- audit-realworldSkill
- audit-resilienceSkill
- audit-responsiveSkill
- audit-securitySkill
- audit-skill-conflictsSkill
- audit-ui-statesSkill
- audit-uiux-design-systemSkill
- audit-ux-journeysSkill
- audit-uxSkill
- backend-db-performanceSkill
- backend-error-handlingSkill
- backend-observabilitySkill
- backend-patternsSkill
- backend-realtimeSkill
- burndown-fullSkill
- complete-everythingSkill
- data-pipelineSkill
- data-visualizationSkill
- debug-errorSkill
- debug-fe-be-integrationSkill
- debug-sentry-monitorSkill
- deploy-npmSkill
- deploy-verifySkill
- design-apiSkill
- design-canvasSkill
- design-emailSkill
- design-frontendSkill
- design-generative-artSkill
- design-mobile-firstSkill
- design-motionSkill
- design-prdSkill
- design-systemSkill
- design-themeSkill
- The first 60 shown.
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
- Distinctive: line 18
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.
- Very specific: line 35
Do not fire for "make the README prettier" → enhance-readme.
- Distinctive: line 113
Read-only: No README, manifest, or repo-settings edits here.
≈ “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.
Files
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
| Skill | Owns |
| audit-registry-listing (this) | Findings on README hero, registry metadata, GitHub surface, manifests, install path |
enhance-readme | Hero image, tour grid, screenshots — the fix |
docs-writer | README prose, quickstart wording |
deploy-npm | The publish itself; files/publishConfig changes ship through it |
plan-aso | App Store / Play listings |
enhance-web-seo | The website, not the registry |
plan-dependency-provenance | Whether dependencies are real — not this package's listing |
Do not fire for "make the README prettier" → enhance-readme.
How to reason
- Surface — which registry or page does a stranger hit first for this repo?
- Ten lines — can they say what it is, for whom, and how to install, before scrolling?
- Metadata — does the registry card (name, description, keywords, homepage, repo, license) say the same thing?
- Tarball — does the published artifact contain what the README promises and nothing it should not?
- 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;
homepagepoints at skills.sh (good). Tarball:npm pack --dry-runshowsdocs/screenshots/(12 MB) shipping;llms.txtpresent. Path:npx @kensaurus/skills --allworks; 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-npmfiles).
Self-critique before reporting
- Evidence — every finding quotes the line, field, or
npm packoutput - 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 buildlisting: everything promised present; no.env*, keys, screenshots, tests, or 10 MB+ assets unless intended;fileswhitelist present.binnames 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 andfilesfixes.docs-launch-kit→ announce the refreshed listing.
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
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.

