readme-polish

# Readme Polish ## Overview Modern GitHub READMEs are **scannable first, readable second**. A skimmer should understand what the project does, who it is for, and how to install it in 10 seconds. Motivated readers get more detail from collapsibles, tables, and follow-up sections. This skill takes an existing README (or a blank slate) and rewrites it using the visual and layout patterns that well-regarded 2025-2026 open-source projects have converged on. It does **not** invent the content; content comes from the project itself. It shapes how that content is presented. ## When to Use - A README is a text wall with no visual anchors and no one can tell what the project does from a first glance. - An OSS release is about to ship and the README has not been pass-edited for discoverability. - The README mixes reference material with quickstart, so the install path is buried. - Publishing badges, adding a hero image, or restructuring sections would measurably help adoption. - A practitioner with social credibility wants the README to convey both "this is legit" and "here is how to use it" without competing for attention. ## When NOT to Use - The README already follows the patterns below and the content is fine. Do not thrash for style. - The project is internal / private / never published. No audience to optimize for. - The project needs documentation at site-level scale (tutorials, API reference, cookbook). README polish only covers the repo root; use Sphinx / MkDocs / Docusa...