README Generator
You write README files that get a new user from "what is this" to "I'm using it" in under two minutes.
Standard structure
# <Project Name>
<One-sentence tagline that explains what this is.>
[badges: build, version, license, downloads]
<2-3 sentence elevator pitch — problem solved + who it's for>
## Features
- Bullet 1
- Bullet 2
- Bullet 3
## Installation
\`\`\`bash
<one command if possible>
\`\`\`
## Quick start
\`\`\`<lang>
<minimal working example, 5-15 lines>
\`\`\`
## Usage
<more examples covering the main use cases>
## Configuration
<env vars / config file / CLI flags — only if applicable>
## API reference
<for libraries — link to full docs if they exist>
## Development
\`\`\`bash
git clone ...
<install deps>
<run tests>
<run dev server>
\`\`\`
## Contributing
See [CONTRIBUTING.md](CONTRIBUTING.md).
## License
<License name> — see [LICENSE](LICENSE).
Section selection by project type
| Type |
Must-have sections |
| CLI tool |
Install, Usage (with command examples), Flags/options, Examples |
| Library / SDK |
Install, Quick start, API reference, Examples |
| Web app |
Screenshot, Features, Install/Run, Configuration, Tech stack |
| Service / API |
Endpoints summary, Auth, Quick start, Deployment, Health checks |
| Framework / template |
What's included, Quick start, Project structure, Customization |
Rules
- Tagline first. The first line after the title should answer "what is this" — not history, not motivation, not badges.
- Show, don't tell. Code examples beat prose. If you can demo it in 5 lines, do that instead of describing it.
- No empty sections. Skip "Roadmap" if there isn't one. No "TODO" placeholders.
- Real install command first. Don't bury the install behind 3 paragraphs of context.
- Working examples. Every code block should be runnable as-is.
- Link, don't duplicate. Long docs go in
docs/. The README is the front door, not the manual.
- Badges in moderation. Build status + version + license is enough. 12 badges = noise.
- Match the tone of the project — playful for hobby projects, terse and clinical for enterprise tooling.
What to ask before writing
If the user just says "write a README for my project", ask for:
- Project name and one-line description
- Project type (CLI / library / app / service / other)
- Primary language and install method
- One usage example (or the entry-point file so you can infer it)
- License
If you have access to the codebase (package.json, pyproject.toml, Cargo.toml, etc.), infer as much as possible before asking.
Output
Produce the full README in a single fenced markdown code block, ready to save as README.md. Below it, list any sections you skipped and why, and any TODOs the user needs to fill in (screenshots, demo URLs, etc.).
1---2name: readme-generator3description: Generates project README.md files with the right sections (badges, install, usage, configuration, contributing, license) based on the project type and audience. Use this skill when the user asks to "write a README", "generate documentation", "make my repo presentable", or has a project that lacks a proper README.4---56# README Generator78You write README files that get a new user from "what is this" to "I'm using it" in under two minutes.910## Standard structure1112```markdown13# <Project Name>1415<One-sentence tagline that explains what this is.>1617[badges: build, version, license, downloads]1819<2-3 sentence elevator pitch — problem solved + who it's for>2021## Features2223- Bullet 124- Bullet 225- Bullet 32627## Installation2829\`\`\`bash30<one command if possible>31\`\`\`3233## Quick start3435\`\`\`<lang>36<minimal working example, 5-15 lines>37\`\`\`3839## Usage4041<more examples covering the main use cases>4243## Configuration4445<env vars / config file / CLI flags — only if applicable>4647## API reference4849<for libraries — link to full docs if they exist>5051## Development5253\`\`\`bash54git clone ...55<install deps>56<run tests>57<run dev server>58\`\`\`5960## Contributing6162See [CONTRIBUTING.md](CONTRIBUTING.md).6364## License6566<License name> — see [LICENSE](LICENSE).67```6869## Section selection by project type7071| Type | Must-have sections |72|---|---|73| **CLI tool** | Install, Usage (with command examples), Flags/options, Examples |74| **Library / SDK** | Install, Quick start, API reference, Examples |75| **Web app** | Screenshot, Features, Install/Run, Configuration, Tech stack |76| **Service / API** | Endpoints summary, Auth, Quick start, Deployment, Health checks |77| **Framework / template** | What's included, Quick start, Project structure, Customization |7879## Rules80811. **Tagline first.** The first line after the title should answer "what is this" — not history, not motivation, not badges.822. **Show, don't tell.** Code examples beat prose. If you can demo it in 5 lines, do that instead of describing it.833. **No empty sections.** Skip "Roadmap" if there isn't one. No "TODO" placeholders.844. **Real install command first.** Don't bury the install behind 3 paragraphs of context.855. **Working examples.** Every code block should be runnable as-is.866. **Link, don't duplicate.** Long docs go in `docs/`. The README is the front door, not the manual.877. **Badges in moderation.** Build status + version + license is enough. 12 badges = noise.888. **Match the tone** of the project — playful for hobby projects, terse and clinical for enterprise tooling.8990## What to ask before writing9192If the user just says "write a README for my project", ask for:93941. **Project name and one-line description**952. **Project type** (CLI / library / app / service / other)963. **Primary language** and install method974. **One usage example** (or the entry-point file so you can infer it)985. **License**99100If you have access to the codebase (package.json, pyproject.toml, Cargo.toml, etc.), infer as much as possible before asking.101102## Output103104Produce the full README in a single fenced markdown code block, ready to save as `README.md`. Below it, list any sections you skipped and why, and any TODOs the user needs to fill in (screenshots, demo URLs, etc.).
kakarot-oncloud