Readme Generator

• Configuration options (CLI flags, config file format)
• Integration points (webhooks, APIs, external services)
• Demo assets (GIFs, screenshots, video URLs)
• License type
• Contribution stance

If the user provides source code or a repo dump, extract this context programmatically rather than asking for it.

Step 2: Map to Structure

Using references/readme-structure.md, determine which sections apply to this project:

• All projects: Header Block, Features, Installation, Usage, Contributing, License
• CLI/TUI tools: add Demo, Keyboard Shortcuts
• Config-driven tools: add Configuration File section
• Integration-heavy tools: add per-feature deep-dive sections
• Multi-platform tools: use <details> collapsibles in Installation

Omit sections that don't apply rather than padding them with placeholder content.

Step 3: Draft the README

Apply the style guide throughout. Key enforcement points:

Prose:

• Detached authority voice—no "I" or "we"; frame as systemic observations
• Low modality by default; reserve "must/requires" for hard technical constraints
• Paragraphs capped at 4-5 lines; transition to lists only for enumerable steps or options
• Inject dry, domain-adjacent humor sparingly in dense sections

Structure:

• Every command, flag, config snippet, and JSON payload in a fenced code block
• Inline backticks for short identifiers only
• Option docs format: - \--flag`: Description (default: value)`
• > **Note:** callouts used sparingly and only when genuinely warranted

Depth:

• Features section: benefit-framed, no implementation details
• Configuration: 60% current actionable state, 40% context for why it's structured that way
• Avoid theoretical deep-dives unless the underlying mechanic directly affects user behavior

Step 4: Deliver

Output the complete README as a raw Markdown file delivered via present_files.

If the user asks for revisions, apply targeted edits rather than regenerating the full document— preserve sections that weren't in scope for the change.

Common Failure Modes to Avoid

• Feature-dumping in the header: The tagline and badge row carry the hook; save feature details for the Features section.
• Flat Installation sections: Use <details> collapsibles for multi-platform installs. A wall of platform-specific commands in one block destroys scannability.
• Options without grouping: Ungrouped flag lists become unnavigable past ~8 flags. Always organize into named groups (Basic, HTTP, Output, etc.).
• Marketing language in config docs: Configuration option descriptions are factual, not persuasive. "Enables powerful real-time webhook alerting" -> "Webhook URL for up/down notifications."
• Missing examples section: A Usage section without concrete, copy-pasteable examples is incomplete. Examples carry more instructional load than prose descriptions.