readme-doctor

name	readme-doctor
description	Audit a GitHub repo's README against best-practice patterns and produce a prioritized punch list of fixes. Runs a structured review covering hero presence, install-to-first-success length, "what is this in one sentence" clarity, audience-jargon match, scannability, and drift signals (stale versions, dead links, badge sprawl). Read-only diagnostic; opens a PR only when the user explicitly asks.

readme-doctor

Most README problems aren't typos or missing sections — they're shape problems: the hero never lands, install-to-first-success buries the lede, the "what is this" sentence assumes prior context, the badge row is louder than the content. This skill audits a README against patterns that consistently correlate with maintainer outcomes (stars, contributor onboarding, issue quality) and produces a punch list a maintainer can act on in an afternoon.

The skill's quality comes from the rubric being grounded in the repo's actual audience and category, not from a generic checklist. A README for a 50K-star framework needs different things than a personal-project utility.

Phases

1. Discovery — pick operating mode (Auto / Semi-auto / Manual, §1.1), input the README, infer the repo's category and audience from the scan, agree on what "good" looks like for this specific repo.
2. Audit — walk the rubric, score each criterion, gather evidence (cite line numbers).
3. Punch list — prioritize findings P0 (blocking) / P1 (high-leverage) / P2 (nice-to-have), each with a one-line fix.
4. Optional output — read-only summary by default; on user request, open a PR with concrete edits.

---

Phase 1 — Discovery

1.1 Operating mode (ask first)

Same three modes as repo-visuals — Auto, Semi-auto (recommended), Manual. Use AskUserQuestion. Mode affects how many decisions are silent vs surfaced; it does not skip rubric checks.

1.2 Input

User may provide:

• GitHub URL → gh repo view + clone shallow
• Local path → read directly
• Pasted README text → analyze in place, but the rubric loses any check that needs file-tree context (manifest signals, screenshot presence, examples/ dir, etc.). Flag these as "skipped — paste-only mode."
• Nothing → ask first

1.3 Scan (collect before judging)

• README full text + rendered length (lines, words, time-to-scan estimate at 250wpm)
• Manifest: package.json, Cargo.toml, pyproject.toml, etc. — version, description, keywords
• File tree (depth 2): does an examples/ exist? docs/? Image assets?
• Recent commits (last 10): is the repo active? When was last release?
• GitHub signals: stars, topics, open issues count, latest release date

1.4 Repo classification (drives rubric weighting)

Categorize the repo from the scan — different categories get different rubric weights:

• Library / package — installable, imported by other code (npm, PyPI, crates). Weight: install-to-first-success, concrete example, API stability signal.
• CLI tool — terminal-run binary or script. Weight: one-line install, single-command demo, output screenshot/GIF.
• Framework — opinionated structure others build on (Next, Rails, etc.). Weight: "why this over alternatives," opinionated example, conceptual model.
• App / service — runnable thing, not imported (self-hosted, web app). Weight: deploy story, config surface, screenshot.
• Standard / spec / docs — knowledge artifact, not code. Weight: scope statement, navigation, change log.
• Personal project / experiment — explicitly unstable. Weight: honest scope, "what this isn't," low-friction trial.

State the inferred category back to the user with one-line evidence ("inferred CLI tool — bin/ entry in package.json, README opens with a $ npx line"). In Auto mode proceed silently; Semi-auto/Manual let the user override.

1.5 Audience inference

Who is this README written for? Infer from jargon density, claimed prerequisites, comparison points named.

• Working developers in the same domain — assumes vocabulary, optimizes for "do I want this in my project."
• Newcomers to the domain — explains terms, shows simple example before deep one.
• Maintainers / power users — assumes deep familiarity, optimizes for reference.
• Mixed — most common; means the README needs explicit on-ramps for each.

A README that's pitched at the wrong audience for its category is the single most common shape problem. Catch it here.

---

Phase 2 — Audit (the rubric)

Each criterion: score 1–5 with one-line evidence and (for any score ≤3) one-line fix. Default 3, evidence required to move.

2.1 The "what is this" sentence

The first sentence after the title should answer "what is this thing" without prior context. Test: imagine a stranger landing here from a Hacker News link. Do they know what it is in 10 seconds?

• 5: One sentence, no jargon, names the category and the differentiator
• 3: Says what it is but buries the "why" or assumes prior context
• 1: Slogan, brand-voice, or lists features before saying what it is

2.2 Hero presence above the fold

Above-the-fold = first ~25 lines, before any heading deeper than H2. Does the README open with an image, GIF, or visible-output block that makes the project's value legible without reading?

• 5: Visual hero matches the project's identity (CLI: terminal screencast; UI: screenshot; framework: code sample)
• 3: Has a visual but it's generic (logo only, badge row pretending to be a hero)
• 1: No visual; opens with prose or badge sprawl

2.3 Install-to-first-success length

Count the lines (or clicks) from "I want to try this" to "I see the thing working." Less is more. Measure as: line of first install command → line of first runnable example → line of first observable output.

• 5: ≤ 3 lines, all copy-pasteable
• 3: 4–8 lines, requires switching contexts (file edits)
• 1: > 8 lines, or requires a full project setup before any output

2.4 Concrete example before API docs

Does a runnable, real-world-shaped example appear before the reference docs / option list / config schema?

• 5: Example is realistic (named entities from the domain, not foo/bar/baz), runs end-to-end as shown
• 3: Has an example but it's contrived or after the API table
• 1: No example, or example is just import foo from 'foo'

2.5 Audience-jargon match

Does the jargon density match the audience inferred in §1.5?

• 5: Jargon load matches audience; unfamiliar terms are linked or briefly defined on first use
• 3: Mostly matches but a few terms are introduced cold
• 1: Pitches a tool to newcomers using domain-expert vocabulary, or vice versa

2.6 Scannability

Headings, paragraphs, lists, tables — can a skim-reader find what they need in 30 seconds?

• 5: Clear H2s, short paragraphs, tables for comparable choices, no walls of prose
• 3: Has structure but inconsistent heading depth or one big prose blob hides key info
• 1: Wall of text, deep heading nesting, or so many H2s the TOC is unusable

2.7 Drift signals

Things that should not be in a README a year later:

• Stale versions — hardcoded version numbers in prose (not badges) that don't match latest release
• Dead links — broken anchors, removed-org URLs, archived dependencies
• Badge sprawl — more than ~5 badges, or badges from defunct services
• TODO / WIP markers in shipped sections
• Outdated screenshots — UI shown doesn't match current build

Score:

• 5: None
• 3: 1–2 signals
• 1: 3+ signals

2.8 "What this isn't" honesty

For non-1.0 / personal / experimental projects: does the README set scope honestly? "This is a weekend project. It works for X. It will not handle Y."

• 5: Explicit scope statement; unsupported cases named
• 3: Stable / production framing implied but not earned
• 1: Personal experiment pitched as production-ready

(Skip this check for repos clearly past 1.0 with active maintenance.)

2.9 Contribution surface

For repos that want contributors: is there a low-friction on-ramp? CONTRIBUTING.md, "good first issue" labels, dev-setup section?

• 5: Clear contribution path with at least one named entry point
• 3: CONTRIBUTING.md exists but is generic boilerplate
• 1: No contribution surface, but the repo otherwise reads as wanting contributors

(Skip for repos that explicitly don't accept contributions.)

---

Phase 3 — Punch list

Convert scored criteria into a prioritized list:

• P0 (blocking) — score ≤ 2 on §2.1, §2.2, §2.3, or §2.4. These are the criteria that determine whether a stranger-from-HN tries the repo at all.
• P1 (high-leverage) — score ≤ 2 on any other criterion, OR score = 3 on a P0 criterion.
• P2 (nice-to-have) — everything else with room to improve.

For each item: what's wrong (one sentence, citing line numbers), why it matters (one sentence tied to the inferred audience), suggested fix (one sentence, concrete enough to act on).

Display the punch list grouped by priority. In Auto mode, also output an overall README health score (simple average of the rubric × 20 = /100).

---

Phase 4 — Optional output

By default this skill is read-only. The punch list lives in the chat.

If the user asks ("write the fixes," "open a PR," "apply P0/P1"):

1. Confirm scope (which priority tier, which specific items)
2. Edit README.md locally — minimal diffs, one item per commit ideally
3. Same upstream-PR machinery as repo-visuals Phase 5: detect ownership, fork if needed, open PR with the punch list as the PR description, alt-text where relevant

Never auto-apply edits without explicit user confirmation. This skill's value is the diagnosis; the surgery is the user's call.

---

What this skill does NOT do

• Does not rewrite the README in the maintainer's voice — that's a different skill (and risky)
• Does not auto-open PRs — only on explicit ask, and only after showing the diff
• Does not score visual quality of screenshots/GIFs (that's repo-visuals's job)
• Does not lint markdown syntax (use markdownlint for that)
• Does not generate badges or shields.io URLs