Document coach
Project README
Your project's front door — built for the 10-second scan.
Most READMEs are written for the author; good ones are written for the stranger who just landed on the repo. This guided README interview asks the questions a pragmatic open-source maintainer would: what the project does in one sentence, why it exists, the exact commands to install and see it work, and how to contribute. You answer; the document assembles itself into a README that earns the star.
What this expert will cover
- 2 questions
Reader
working notesWho arrives at this README and what they need to succeed — a working note that steers every section, never rendered into the file. Complete means: the stranger who lands on the repo described concretely, what they already know, and what has to happen for their visit to count as a success.
- 3 questions
Overview
The 10-second scan. Complete means: a stranger reading only this section knows what the project is, what problem it solves, who it is for, and its current maturity — enough to decide whether to keep reading.
- 3 questions
Motivation
Why this exists. Complete means: the pain that prompted the project is vivid, and a reader who has evaluated the alternatives understands what this does differently — including what it deliberately does not do.
- 3 questions
Installation
From zero to installed, copy-paste only. Complete means: prerequisites with versions stated first, then the exact install command(s), then how to verify the install worked.
- 3 questions
Usage
The first success, then the primary workflow. Complete means: a minimal end-to-end example a reader can run immediately, with the expected output shown, plus a glimpse of the most common real-world usage.
- 2 questions
Configuration
The knobs that matter. Complete means: the handful of options most users actually change, each with its default and when to change it — not an exhaustive dump.
- 3 questions
Contributing & License
How to help and on what terms. Complete means: the dev-environment setup and test commands a contributor needs, what kind of contributions are welcome, and the license named explicitly.
The kind of questions it asks
- Who lands on this README, and how do they get here — a search result, a dependency they inherited, a recommendation? Describe the actual arriving reader, including what they already know and what they have never heard of.
- What does this project do, in one sentence? Name the problem and who has it — not the tech stack. Pretend the reader has 10 seconds and no context.
- What specific pain made you build this? The concrete story ("we were copy-pasting the same 40 lines into every service") is your most persuasive asset.
Ready when you are.
Every answer inks the page in. Skip anything; return anytime.