Create README
Make the README a useful front door: explain what the project does, who it serves, how to start, and where to go next.
Read references/readme-guidance.md when the README is complex, public-facing, package-published, or being audited.
Workflow
- Inspect the existing README, manifests, package metadata, build files, scripts, docs, license, examples, CI, and relevant entry points.
- Identify the primary reader and first-use path. Put purpose, audience, value, requirements, installation, and the shortest working example before deep detail.
- Preserve useful structure, links, terminology, and voice. Remove stale claims, broken links, obsolete setup, and filler.
- Include only relevant sections: status, requirements, installation, configuration, quick start, usage, development, troubleshooting, docs, support, contributing, security, license, or maintainers.
- Verify commands and claims against the repository. Use relative links for repo files, fenced copyable commands, and alt text for images.
- Finish with a heading, Markdown, link, and accuracy pass.
Quality Rules
- Prefer plain active language and short paragraphs.
- Keep package-facing instructions self-contained; link long references elsewhere.
- Keep contributor detail out of user quick starts unless contributors are the main audience.
- Do not add decorative badges or screenshots that do not help a reader succeed.
Output
Edit the README directly when asked. Report the commands, links, and claims checked, plus anything that remains inferred or worth maintainer review.
1---2name: create-readme3description: Create or update accurate README.md files. Use when asked to draft, rewrite, audit, or refresh a README for a repository, package, app, library, CLI, service, dataset, or docs folder.4---56# Create README78Make the README a useful front door: explain what the project does, who it serves, how to start, and where to go next.910Read `references/readme-guidance.md` when the README is complex, public-facing, package-published, or being audited.1112## Workflow13141. Inspect the existing README, manifests, package metadata, build files, scripts, docs, license, examples, CI, and relevant entry points.152. Identify the primary reader and first-use path. Put purpose, audience, value, requirements, installation, and the shortest working example before deep detail.163. Preserve useful structure, links, terminology, and voice. Remove stale claims, broken links, obsolete setup, and filler.174. Include only relevant sections: status, requirements, installation, configuration, quick start, usage, development, troubleshooting, docs, support, contributing, security, license, or maintainers.185. Verify commands and claims against the repository. Use relative links for repo files, fenced copyable commands, and alt text for images.196. Finish with a heading, Markdown, link, and accuracy pass.2021## Quality Rules2223- Prefer plain active language and short paragraphs.24- Keep package-facing instructions self-contained; link long references elsewhere.25- Keep contributor detail out of user quick starts unless contributors are the main audience.26- Do not add decorative badges or screenshots that do not help a reader succeed.2728## Output2930Edit the README directly when asked. Report the commands, links, and claims checked, plus anything that remains inferred or worth maintainer review.
jlave-dev