CtrlK
BlogDocsLog inGet started
Tessl Logo

readme-doctor

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.

69

Quality

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Advisory

Suggest reviewing before use

SKILL.md
Quality
Evals
Security

Quality

Content

85%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A highly actionable, well-sequenced audit skill with concrete scoring anchors, prioritization logic, and explicit safety checkpoints around PR creation. The only real slack is minor framing prose that could be tightened for token efficiency.

Suggestions

Trim the two introductory framing paragraphs ('Most README problems…' and 'The skill's quality comes from…') to one or two sentences; the value is the rubric, not the rationale.

Consider moving the full §2.1–2.9 rubric anchors into a references file and keeping a condensed rubric summary in SKILL.md, so the overview stays scannable.

DimensionReasoningScore

Conciseness

The bulk is lean, actionable rubric substance (scoring anchors, named checks) with no padding about what a README is. However, the two opening framing paragraphs and 'The skill's quality comes from…' meta commentary could be trimmed without losing guidance value, so it sits at 'mostly efficient but could be tightened' rather than fully lean.

2 / 3

Actionability

Gives concrete executable guidance: 5/3/1 scoring anchors per criterion, line-number evidence citations, explicit P0/P1/P2 definitions tied to specific criteria, and real commands/inputs (`gh repo view`, shallow clone, package.json/Cargo.toml/pyproject.toml checks). Copy-paste ready and specific rather than abstract.

3 / 3

Workflow Clarity

Four phases (Discovery → Audit → Punch list → Optional output) are clearly sequenced, with explicit gating checkpoints for the risky PR operation — 'Confirm scope', 'showing the diff', and 'Never auto-apply edits without explicit user confirmation'. Evidence-required scoring ('Default 3, evidence required to move') acts as a per-criterion validation loop.

3 / 3

Progressive Disclosure

A single, well-organized SKILL.md with clear H2 phases and H3 subsections and no nested references; no bundle files exist to evaluate, and the content is appropriately sectioned rather than a monolithic wall. Matches the 'well-organized sections, no external references needed' allowance.

3 / 3

Total

11

/

12

Passed

Description

82%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A specific, well-scoped description with strong natural trigger terms and clear distinctiveness. Its main weakness is the absence of an explicit 'Use when…' clause, which leaves the invocation condition implied rather than stated.

Suggestions

Add an explicit trigger clause, e.g. 'Use when the user asks to review, audit, or improve a README, or wants a punch list of README fixes.'

Lead with the trigger context before the capability list so 'when to use' is as prominent as 'what it does'.

DimensionReasoningScore

Specificity

Lists multiple concrete actions — 'Audit a GitHub repo's README', 'produce a prioritized punch list of fixes', and a structured review covering named checks (hero presence, install-to-first-success, scannability, drift signals). Matches the anchor for listing several specific concrete actions rather than vague language.

3 / 3

Completeness

Clearly answers *what* the skill does, but lacks an explicit 'Use when…' trigger clause; 'opens a PR only when the user explicitly asks' describes output behavior, not when to invoke. Per the judging guidelines a missing trigger clause caps completeness at 2.

2 / 3

Trigger Term Quality

Uses natural terms a user would actually say — 'README', 'audit', 'punch list of fixes', 'opens a PR' — giving good coverage of the phrasings that would trigger this skill. Not merely technical jargon, though a 'Use when README…' phrasing would be even more direct.

3 / 3

Distinctiveness Conflict Risk

Targets a clear niche — README auditing/diagnosis — with triggers unlikely to fire for adjacent skills. The explicit 'What this skill does NOT do' boundaries (not repo-visuals, not markdownlint) further reduce conflict risk.

3 / 3

Total

11

/

12

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
livlign/claude-skills
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.