review-legibility

Reviews pull request diffs for readability issues using eleven explicit legibility heuristics.

Updated May 19, 2026
One-click install
npx skills add https://github.com/kmosher/claude-plugins --skill review-legibility-kmosher
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: review-legibility
Source: https://github.com/kmosher/claude-plugins/tree/main/plugins/kmosher-review/skills/review-legibility
Command: npx skills add https://github.com/kmosher/claude-plugins --skill review-legibility-kmosher

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code that passes correctness review can still be hard to read: comments that restate code, misleading names, branch fanout, stale references, and iteration-history scars accumulate during PR iteration and slow down every future reader. This Skill applies a dedicated readability lens so those issues are caught before merge. ## Core Features & Use Cases - Eleven explicit heuristics: Tests for one-sentence purpose, comment deletion, branch fanout, name genericization, reader onramp, reference staleness, iteration-history scars, comment-to-code distance, duplication (including cross-file decision duplication), tests as documentation, and comment density. - Structured findings output: Returns JSONL findings with severity (P1/P2/P3), confidence, category, and the heuristic number that flagged each issue, following shared review conventions. - Comment rewrite delegation: Hands non-trivial comment rewrites to a dedicated comment-writer agent with bake-off evaluation, avoiding over-trimming of load-bearing detail. - Use Case: After a heavily iterated PR is confirmed correct, run this lens as the final pre-merge pass to flag a 6-branch if/else chain that should be a classifier table and a 50-line inline rationale that should become a function doc. ## Quick Start Ask the AI to run a legibility review on the current branch's diff, applying the eleven heuristics and reporting findings with severity and proposed cleanups.

Frequently Asked Questions about review-legibility

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review a PR for readability after correctness is confirmed?▼

Run a legibility review that applies explicit tests rather than asking whether code is clear: one-sentence purpose per function, branch fanout counts, comment deletion checks, and reader onramp evaluation. Each finding gets a severity, file:line reference, and a concrete proposed cleanup.

What is the difference between a legibility review and a correctness code review?▼

Correctness review asks what could go wrong; legibility review assumes the code is correct and asks what makes a fresh reader stop and re-read. Run correctness review first, then legibility as the final pre-merge cleanup pass.

How do I detect duplicated decision logic across files in a codebase?▼

Inventory each decision the new code makes with its inputs and outputs, then grep adjacent packages for matches on the same accessors or output values. Compare encodings side by side and extract a shared helper, consolidate to one source of truth, or add a drift-catching test.

When should comments be deleted versus kept during code review?▼

Delete comments whose removal makes nothing harder to understand or that merely restate what the code does. Keep comments explaining the non-obvious why behind a choice, and apply a load-bearing test before compressing long comments so no critical facts are lost.

When should I not use a legibility review lens?▼

Skip it for initial bug-finding, where a correctness lens belongs, and for pure formatting, which linters handle. It also defers mechanical issues like unused identifiers and dead code to gopls, staticcheck, ESLint, or clippy rather than human judgment.