Write a README people can actually follow
Produces a README with a working quick start, clear setup steps, and usage examples, and marks whatever it could not work out from what you gave it.
By Maya FernandesVersion 1Updated 7 Oct 2026
Prompt
Write a README for my project.
Project name: {{name}}
What it does, in my own words: {{what_it_does}}
Who it is for: {{audience:developers who have never seen this project}}
Sections, in this order:
1. Title and a one-sentence description that says what it does and for whom. No slogans.
2. Why it exists: the problem it solves, in two or three sentences.
3. Quick start: the fewest commands that take someone from nothing to seeing it work.
4. Requirements: runtime versions, system dependencies, accounts or API keys.
5. Installation and configuration: every step, and every environment variable in a table with its purpose and an example value.
6. Usage: two or three realistic examples, with the output to expect.
7. Project structure: only if it helps, and only the top level.
8. Development: how to run it locally, run the tests, and check formatting.
9. Troubleshooting: the two or three problems a newcomer is most likely to hit.
10. License and how to contribute, one or two lines each.
Rules:
- Every command must come from what I gave you. If you are not certain of a command, a version, or a variable name, write [CONFIRM: what to check] instead of guessing.
- Put commands in code blocks, one runnable command per line.
- Write for someone smart who has no context. Do not assume they know the project's internal names.
- No badges, emoji, or marketing language.
What I can tell you about the project (file list, package file, setup notes, anything else):
{{details}}Use this prompt
Result
Write a README for my project.
Project name: {{name}}
What it does, in my own words: {{what_it_does}}
Who it is for: developers who have never seen this project
Sections, in this order:
1. Title and a one-sentence description that says what it does and for whom. No slogans.
2. Why it exists: the problem it solves, in two or three sentences.
3. Quick start: the fewest commands that take someone from nothing to seeing it work.
4. Requirements: runtime versions, system dependencies, accounts or API keys.
5. Installation and configuration: every step, and every environment variable in a table with its purpose and an example value.
6. Usage: two or three realistic examples, with the output to expect.
7. Project structure: only if it helps, and only the top level.
8. Development: how to run it locally, run the tests, and check formatting.
9. Troubleshooting: the two or three problems a newcomer is most likely to hit.
10. License and how to contribute, one or two lines each.
Rules:
- Every command must come from what I gave you. If you are not certain of a command, a version, or a variable name, write [CONFIRM: what to check] instead of guessing.
- Put commands in code blocks, one runnable command per line.
- Write for someone smart who has no context. Do not assume they know the project's internal names.
- No badges, emoji, or marketing language.
What I can tell you about the project (file list, package file, setup notes, anything else):
{{details}}Still to fill in: name, what_it_does, details
Test run
Fill in name, what_it_does, details to run it. A blank input would spend a test run on a prompt with holes in it.