AI Prompts for Documentation

Write a docstring for this [language] function:
[function code]
Use the standard format for [language] ([JSDoc/Python docstring/Rustdoc/JavaDoc]).
Include: one-line summary, extended description (if non-obvious), parameters (name, type, description, default), return value (type + description), exceptions raised, and a usage example. If the function has side effects, document them.

Write a README.md for the project: [project name].
Tech stack: [stack]. What it does: [description]. Target users: [devs/end users].
Sections: badges, description (2–3 sentences), features (5 bullets), prerequisites, installation (code blocks), usage examples (3 scenarios with code), configuration options (table), contributing guide, and license. No filler — every section should be useful on day 1.

Write API documentation for the following endpoint:
Endpoint: [method + URL]. Purpose: [what it does].
Document: description, authentication required, request parameters (path/query/body — name, type, required, description), request example (JSON), response schema (all fields), response example, error codes with meanings, rate limiting notes, and a code example in [language].

Write an Architecture Decision Record (ADR) for the decision: "[decision title]".
Context: [what situation forced this decision]. Options considered: [options]. Decision made: [chosen option].
Sections: title, date, status (Accepted/Deprecated), context, decision, consequences (positive + negative), and alternatives considered with why they were rejected. Keep it under 500 words.

Write a technical specification for implementing: [feature/system].
Audience: engineers who will build it. Timeline: [timeline].
Sections: overview (problem + solution), requirements (functional + non-functional), system design (components + data flow), API contracts, database changes, error handling, testing strategy, rollout plan, and open questions. Flag any decisions still needed before implementation starts.

Review and improve the comments in this code:
[code block]
Language: [language].
Rules for good comments: explain WHY not WHAT, remove comments that just restate the code, add comments for: non-obvious business logic, workarounds for known issues, algorithm explanations, and invariants that must be maintained. Return the code with improved comments and a note on what you changed.

Write a CHANGELOG.md entry for version [version number] of [project].
Changes in this release: [list of commits or PR titles]. Release date: [date].
Follow the Keep a Changelog format: sections for Added, Changed, Deprecated, Removed, Fixed, Security. Write each entry from the user's perspective (what changed for them), not the developer's perspective (what code changed). Link to PRs/issues where relevant.

Write developer onboarding documentation for the [project name] project.
Stack: [stack]. New developer profile: [junior/mid/senior].
Sections: project overview (purpose + context), local development setup (step-by-step with code), architecture overview (key concepts + diagram description), how to run tests, how to deploy (to each environment), code conventions, how to get help (who to ask + channels), and a "first task" suggestion to make the first week productive.

Write a user guide for the feature: "[feature name]" in [product name].
User skill level: [beginner/intermediate]. Goal: help the user [accomplish task].
Format: intro (what this feature does and why it's useful), prerequisites, step-by-step instructions (with UI element names in bold), screenshots notes (where to add them), common errors + fixes, and a "next steps" section linking to related features.

Write release notes for [product] version [version].
Audience: [end users/developers/both]. Key changes: [list]. Breaking changes: [if any].
Format: version number + release date header, one-paragraph executive summary, new features (with screenshots notes), improvements, bug fixes, deprecations, and upgrade instructions. User-friendly language — no implementation details unless relevant.

Write an internal wiki page for: "[process/system/decision]".
Audience: new and existing engineers. Use case: [when would someone read this].
Sections: summary (TL;DR at the top), context/background, detailed explanation, decision log (key decisions made + why), how to use / runbook, known issues, owner (team + DRI), and last-reviewed date. Scannable format with clear headings.

Write an operational runbook for: "[operational task or incident type]".
System: [system description]. Audience: on-call engineer, potentially unfamiliar with this system.
Sections: overview, prerequisites (access/tools needed), step-by-step procedure, decision tree for common variants, rollback procedure, verification steps (how to confirm success), escalation path, and contact list. Optimise for speed in a high-pressure situation.

Write user-facing documentation for these error codes in [product]:
[list of error codes and internal descriptions]
For each error: code, plain-English title, what caused it, who can fix it (user vs support vs system), what to do right now (step-by-step), and a link to related help articles. Avoid technical jargon. Reduce user anxiety — be reassuring, not robotic.

Write an OpenAPI 3.0 spec for this API:
Base URL: [URL]. Authentication: [bearer/API key/OAuth].
Endpoints to document: [list].
For each endpoint: path, method, summary, description, parameters (in, name, required, schema), request body schema, response schemas (200, 400, 401, 404, 500), and example values. Output as valid YAML.

Write the documentation for a Postman collection for the [API name] API.
Endpoints: [list]. Auth: [auth method].
For each request: name, description (what it does + when to use it), required headers, URL parameters, request body (with field descriptions), example request, example response (success + error), and pre-request script notes if needed. Also write the collection-level README.

Write a textual description for a system architecture diagram of [system name].
Components: [list of services/components]. Data flows: [main flows]. External integrations: [integrations].
Describe: what each component does, how data flows between them (request → response), where data is stored, where authentication happens, and what happens when each component fails. Use this to generate a diagram in Mermaid, Lucidchart, or draw.io.

Write a knowledge base article for: "[question/issue]".
Product: [product]. Audience: [customers/internal team].
Structure: title (the question they searched for), direct answer (first 2 sentences answer the question), step-by-step detail (numbered, with screenshots notes), related articles (3 links), and tags/categories for search. Optimise for people who are frustrated — get to the answer fast.

Write a deprecation notice for [feature/API/endpoint] in [product].
Deprecation date: [date]. Removal date: [date]. Replacement: [new feature/approach].
Include: what is being deprecated and why, timeline (deprecation → end-of-life), migration guide (step-by-step), code examples (old approach → new approach), FAQ (3 questions), and where to get help. Communicate clearly without causing panic.

Write a CONTRIBUTING.md for the open-source project: [project name].
Stack: [stack]. Community size: [small/growing/large].
Sections: welcome message (encouraging tone), ways to contribute (not just code), development setup, branch naming and commit message conventions, PR process (what to include, review SLA), code style guide reference, testing requirements, and a code of conduct link. Make it welcoming for first-time contributors.

Create an outline for a technical blog post titled: "[title]".
Audience: [junior/mid/senior developers]. Main concept: [concept]. Publication: [company blog/Dev.to/Medium/personal].
Outline: intro hook (problem statement), prerequisites (what readers need to know), 5 main sections with code example notes, a "gotchas" section, conclusion with key takeaways, and suggested code repo/demo link placement. Target: [1,500 words].