README Creator
Create clear, professional README.md files grounded in the actual project.
Required Sections (always include)
- Title + Description — Project name as
# Title, followed by 1–3 sentences: what it does and its purpose. No badges unless provided.
- Features — Bulleted list of key capabilities. Be specific; don't invent features.
- Installation — Exact commands to install the project and its dependencies.
- Usage — Minimal working example(s) with code blocks. Show the most common use case first.
- Contributing — Brief guide: fork → branch → PR. One short paragraph or 3–4 bullets.
- License — State the license. Default to MIT if unspecified:
Distributed under the MIT License.
Conditional Sections (include only when justified)
- Prerequisites — Only if the project requires specific runtimes, accounts, environment variables, or non-obvious tools. Skip if setup is standard (e.g., just
npm install).
Optional Sections (include when they add clear value)
These sections are not limited to the items listed below. Add any section that would genuinely benefit readers of this specific project.
- Getting Started / Quickstart — When a more guided walkthrough helps beyond Installation + Usage.
- Documentation / Docs — When there's an external docs site or extensive API reference to link to.
- Learn More — When there are tutorials, blog posts, videos, or community resources worth linking to.
Constraints
- No "Project Structure" section
- No invented commands, flags, or capabilities
- No filler text ("Feel free to...", "This project aims to...")
- No generic disclaimers or boilerplate paragraphs
- Omit any section that would be empty or redundant
- No ASCII diagrams — use Mermaid instead
Input Sources
Use only information from:
- User description
- Provided files or repository contents
package.json, README drafts, or source code
If information is missing, omit the section instead of guessing.
Procedure
- Analyze the provided project information (description, source code,
package.json, etc.).
- Identify the project's purpose, core features, and intended users.
- Extract real installation steps and usage examples from the project — do not invent them.
- Include all Required Sections.
- Include Conditional and Optional Sections only when justified.
- Run the Validation Checklist before returning output.
- Return only the final README.md content — no preamble, no explanation.
Style Guidelines
- Professional — clear, authoritative, not casual
- Direct — lead with what matters; no slow build-up
- Concise — one sentence where one sentence suffices
- Technical and precise — use correct terminology for the domain
- No marketing language ("powerful", "seamless", "blazing fast")
Output Format
- Standard Markdown, GitHub-flavored
- Fenced code blocks with language tags (
```bash, ```js, etc.)
- Flat heading hierarchy:
## for sections, ### only when a section genuinely needs subsections
- Blank line between sections for readability
- When a visual diagram adds value (architecture, flow, sequence, git graph, etc.), use a fenced Mermaid block (
```mermaid). Never use ASCII art for diagrams.
Validation Checklist (internal)
Before returning the README, verify:
1---2name: readme-creator3description: Creates high-quality, standardized README.md files for software projects suitable for open-source repositories. Use when asked to create or update a README.4---56# README Creator78Create clear, professional README.md files grounded in the actual project.910## Required Sections (always include)11121. **Title + Description** — Project name as `# Title`, followed by 1–3 sentences: what it does and its purpose. No badges unless provided.132. **Features** — Bulleted list of key capabilities. Be specific; don't invent features.143. **Installation** — Exact commands to install the project and its dependencies.154. **Usage** — Minimal working example(s) with code blocks. Show the most common use case first.165. **Contributing** — Brief guide: fork → branch → PR. One short paragraph or 3–4 bullets.176. **License** — State the license. Default to MIT if unspecified: `Distributed under the MIT License.`1819## Conditional Sections (include only when justified)2021- **Prerequisites** — Only if the project requires specific runtimes, accounts, environment variables, or non-obvious tools. Skip if setup is standard (e.g., just `npm install`).2223## Optional Sections (include when they add clear value)2425These sections are not limited to the items listed below. Add any section that would genuinely benefit readers of this specific project.2627- **Getting Started / Quickstart** — When a more guided walkthrough helps beyond Installation + Usage.28- **Documentation / Docs** — When there's an external docs site or extensive API reference to link to.29- **Learn More** — When there are tutorials, blog posts, videos, or community resources worth linking to.3031## Constraints3233- No "Project Structure" section34- No invented commands, flags, or capabilities35- No filler text ("Feel free to...", "This project aims to...")36- No generic disclaimers or boilerplate paragraphs37- Omit any section that would be empty or redundant38- No ASCII diagrams — use Mermaid instead3940## Input Sources4142Use only information from:43- User description44- Provided files or repository contents45- `package.json`, README drafts, or source code4647If information is missing, omit the section instead of guessing.4849## Procedure50511. Analyze the provided project information (description, source code, `package.json`, etc.).522. Identify the project's purpose, core features, and intended users.533. Extract real installation steps and usage examples from the project — do not invent them.544. Include all Required Sections.555. Include Conditional and Optional Sections only when justified.566. Run the Validation Checklist before returning output.577. Return only the final README.md content — no preamble, no explanation.5859## Style Guidelines6061- **Professional** — clear, authoritative, not casual62- **Direct** — lead with what matters; no slow build-up63- **Concise** — one sentence where one sentence suffices64- **Technical and precise** — use correct terminology for the domain65- No marketing language ("powerful", "seamless", "blazing fast")6667## Output Format6869- Standard Markdown, GitHub-flavored70- Fenced code blocks with language tags (` ```bash `, ` ```js `, etc.)71- Flat heading hierarchy: `##` for sections, `###` only when a section genuinely needs subsections72- Blank line between sections for readability73- When a visual diagram adds value (architecture, flow, sequence, git graph, etc.), use a fenced Mermaid block (` ```mermaid `). Never use ASCII art for diagrams.7475## Validation Checklist (internal)7677Before returning the README, verify:7879- [ ] All Required Sections are present80- [ ] No forbidden sections included (e.g., Project Structure)81- [ ] No invented features, commands, or capabilities82- [ ] Conditional sections are included only when justified83- [ ] Markdown formatting is correct and consistent84- [ ] Content is concise and non-redundant85- [ ] No ASCII diagrams present (Mermaid used where diagrams appear)