Anatomy of a good README
- Name and one-liner. A visitor decides in seconds whether the project is relevant. Say what it does, not how it’s built.
- Badges (optional). Build status, version, license. Keep it to a handful; a wall of badges is noise.
- Features. Three to six bullets of what it can do for the reader.
- Installation. Copy-pasteable commands in a fenced code block, with prerequisites stated first.
- Usage. The smallest working example. A screenshot or Mermaid diagram helps for anything visual.
- Contributing and license. How to help, and under what terms people can use the code.
README tips
- Write for someone who has never seen the project. Avoid internal jargon.
- Keep long reference docs in a
docs/folder and link to them. - Use relative links to files in the repo (
[license](LICENSE)) so they work on forks. - Check the result in the Markdown editor or viewer before committing.