What this prompt does
This prompt instructs the AI to produce a complete documentation suite in a single pass: a README with shields.io or similar badge rows, a quick-start section timed to your stated [setup_time], an API reference in your preferred format (OpenAPI fragments, Markdown tables, or JSDoc-style), a configuration table, contributing guidelines, a changelog scaffold, and a license block. It works because every output section is explicitly named in the template — the AI has less room to wander into generic filler or skip the parts developers actually need.
The [api_doc_format] and [doc_style] variables are load-bearing. They force the model to commit to a specific style (e.g., "OpenAPI 3.1 YAML snippets" vs "GitHub-flavored Markdown tables") rather than defaulting to whatever it finds easiest. The instruction to include copy-pasteable code for every endpoint is what separates usable output from documentation that looks complete but requires another hour of work before it helps anyone.
When to use it
- Launching a new open-source library and need a README that clears the "no docs = no trust" bar before the first star.
- Generating internal API documentation for a microservice so new team members can onboard without a Slack thread.
- Standardising docs across multiple repositories that currently each have their own inconsistent format.
- Scaffolding a documentation draft after an exploratory phase when the project shape is clear but writing time is not.
- Creating contributing guidelines for a team project before the first external pull request arrives.
Example output
For [project_name]=Herdkit, [project_description]=Laravel local dev toolkit, [api_doc_format]=Markdown table, [endpoint_count]=4, [license_type]=MIT:
# Herdkit
 
## Quick Start
composer require mejba/herdkit
php artisan herdkit:install
Setup time: under 3 minutes.
## API Reference
| Method | Endpoint | Description | Auth |
|--------|----------|-------------|------|
| GET | `/api/sites` | List all local sites | Bearer |
Output continues through config table, CHANGELOG format, and contributor checklist — all wired to the same project name and style.
Pro tips
- Be specific with
[badge_services]— list them: "shields.io CI, Packagist version, license" not just "badges." Vague inputs produce badge rows that link to nowhere. - Set
[setup_time]to a real constraint — "5 minutes" forces the quick-start to stay scannable; "30 minutes" produces an exhaustive guide. Neither is wrong, but they are very different documents. - For
[api_doc_format], use "OpenAPI 3.1 YAML snippets" if you plan to paste output into Swagger UI. Use "Markdown tables with curl examples" for GitHub rendering without tooling overhead. - Pair with your actual endpoint list — paste your route list or controller method names directly after the prompt. The model will map each route to a row and produce accurate examples rather than invented ones.
- Run linters on any code blocks before committing — AI-generated shell commands and code snippets are usually correct but occasionally have flag typos or version mismatches. Treat them as a draft, not a final artefact.