Readme

A README documents a tool. It states what the tool does, shows it running, and explains how to install, use, and remove it. It never persuades. If the facts are good, they carry the README; if they need dressing up, that is a signal about the tool, not a writing problem.

Rules

1. First line says what the thing is. Plain declarative sentence: "Backup for sqlite databases, scheduled by cron." No problem/solution framing, no pain narrative, no "Tired of X?". A reader should know what they are looking at in five seconds.
2. Show a real invocation early. A command and its actual output beat any description. Copy from a real session, not an idealized one.
3. Facts over adjectives. Delete "powerful", "simple", "elegant", "blazing fast", "seamless". State the mechanism instead: not "lightning-fast search" but "searches 100k files in ~50ms (ripgrep)".
4. Say what it touches. Anything that runs code, registers hooks, writes files, or makes network calls gets stated next to the install command, along with how to disable or uninstall it. This is documentation of behavior, not a trust-building exercise.
5. One mention per fact. If install is documented in Install, do not repeat it elsewhere. Repetition reads as selling.
6. Collapse depth with <details>, don't cut it. Architecture notes, design rationale, and reference tables go inside <details> blocks with markdown inside (blank line after <summary>, blank line before </details>).
7. No narrative voice. No "I built this because...", no "What I learned", no origin story, no philosophy section up top. If design rationale matters, put a short note in a collapsed section.
8. Order follows use. What it is → Install → Usage/example → How it works → Reference/FAQ → License. A reader who wants to try the tool should never scroll past theory to find a command.

Workflow

1. Gather context silently