READMEs, API references, tutorials, and architecture docs. The pattern throughout: give the model the raw material (code, specs, notes), name the audience precisely, and enforce a docs structure.
You are a senior technical writer. Write a README for the project below.
Audience: [AUDIENCE — e.g., developers evaluating whether to adopt this library, 5-minute attention span].
Structure:
1. One-paragraph pitch — what it does and why it exists (no marketing fluff).
2. Quick start — the shortest path to a working example, with copy-paste commands.
3. Core usage — the 2-3 most common operations, each with a code example.
4. Configuration — table of options: name, type, default, description.
5. [OPTIONAL SECTIONS — e.g., troubleshooting, contributing].
Rules: every code example must be runnable as written. Don't document internals the user never touches. If something is unclear from the source, insert a TODO comment rather than guessing.
[PASTE CODE / PACKAGE FILES]
API Endpoint Reference
Document the API endpoint(s) below as reference documentation.
For each endpoint produce:
- Method + path, one-line description
- Parameters table: name, in (path/query/body), type, required, description
- Request example (curl) with realistic values
- Success response example (JSON) with realistic values
- Error responses: status code, when it happens, example body
- Notes: rate limits, auth requirements, pagination — only if evident from the source
Tone: neutral reference. No tutorials, no "simply". Mark anything you inferred rather than found in the source with "(inferred)".
[PASTE HANDLER CODE / OPENAPI SPEC / NOTES]
Step-by-Step Tutorial
Write a tutorial: "[TITLE — e.g., Deploying X to Y in 15 minutes]".
Audience: [SKILL LEVEL — e.g., knows Docker basics, has never used Y].
End state: by the end, the reader has [CONCRETE WORKING RESULT].
Format:
- Prerequisites list (with versions) up front.
- Numbered steps. Each step: what to do, the exact command/code, what they should see if it worked.
- One "checkpoint" every 3-4 steps so readers can verify before continuing.
- A troubleshooting section for the 3 most likely failure points.
Rules: never combine two actions in one step. Show expected output after every command that produces any.
Source material:
[PASTE NOTES / COMMANDS / DOCS]
