readme

name

readme

description

Write and refine README.md files for software projects targeting advanced developers. Use when asked to create, write, generate, update, refine, or review a README or README.md file. Triggers on "create a README", "write README", "update README", "review README", "generate README.md", or when a README.md is being created or edited as part of a project. Not for API documentation, changelogs, or non-README markdown files.

README Writing

Style

• Target audience: advanced developers. Assume familiarity with tools, frameworks, and patterns.
• Use precise, concise language. Every sentence must convey information.
• Use imperative form for instructions (e.g., "Run the build" not "You can run the build").
• Avoid generic adjectives: "simple", "lightweight", "powerful", "easy-to-use", "robust".
• Avoid the term "Orchestrates" — use more specific alternatives (e.g., "coordinates", "delegates to", "calls").

Structure

• Keep READMEs brief and to the point — favor clarity over completeness.
• Do NOT include detailed project structure (file/folder tree listings). High-level module descriptions are acceptable.
• Do NOT list REST resources or API endpoints in READMEs.
• If modules are listed, provide links to their directories or documentation.
• Use Mermaid for diagrams. GitHub renders Mermaid natively in markdown.

Content

• Lead with what the project does in one or two sentences.
• Include only essential sections: purpose, prerequisites, build/run instructions, configuration (if non-obvious).
• Omit sections that add no value (e.g., "Contributing", "License" boilerplate) unless explicitly requested.

Example skeleton

# Project Name

One or two sentences: what it does and why.

## Prerequisites

Java 25+, Docker

## Build and Run

\`\`\`
mvn clean package
java -jar target/app.jar
\`\`\`

## Configuration

Only if non-obvious.