30 Claude Prompts That Write Documentation

You are a senior technical writer who produces clear, task-oriented documentation. <context> I need a complete how-to guide that walks a user through accomplishing one specific task with our product, returned as a single self-contained Markdown document ready to paste into our docs site. </context> <inputs> - Product and feature: [WHAT IT IS, WHAT THE FEATURE DOES] - The task the reader wants to complete: [THE GOAL] - Target reader and skill level: [WHO, BEGINNER / INTERMEDIATE] - Prerequisites: [ACCOUNTS, PERMISSIONS, VERSIONS] - Where they do this: [UI PATH, CLI, OR API] - Common mistakes to warn about: [PITFALLS] </inputs> <task> Write the guide with: a one-line summary of what the reader will achieve and roughly how long it takes, a prerequisites checklist, numbered steps each with a short instruction plus the exact UI element, command, or code to use, expected result after each key step, a callout for any pitfall, a short verification section proving it worked, and a next-steps links block. </task> <constraints> - Valid Markdown only: H1 title, H2 sections, numbered steps, fenced code blocks with language tags, and blockquote callouts for notes and warnings. - Task-first and skimmable; no marketing language; every step is a concrete action. - Use realistic example values in commands, never lorem ipsum. </constraints> <format> Return the full how-to guide as a Markdown artifact, then a short note on which screenshots to add and where. </format>

You are a developer-experience writer who documents API integrations end to end. <context> I need a how-to guide that shows a developer how to integrate our API for a specific use case, from authentication to a working first request, as one self-contained Markdown document. </context> <inputs> - API and use case: [WHAT THE API DOES, WHAT WE ARE INTEGRATING] - Base URL and auth method: [E.G. BEARER TOKEN, API KEY, OAUTH] - Primary endpoint(s) for this flow: [METHOD + PATH] - Preferred language for examples: [CURL, JS, PYTHON, ETC] - Rate limits or gotchas: [ANY] - Success criteria: [WHAT A CORRECT RESPONSE LOOKS LIKE] </inputs> <task> Write the guide with: overview and what you will build, prerequisites and how to get credentials, an authentication section with a real request example, a step-by-step walkthrough of the core flow with request and response samples, error handling for the most common failure codes, rate-limit and pagination notes if relevant, and a copy-paste minimal working example at the end. </task> <constraints> - Valid Markdown: fenced code blocks tagged with the language, request and response shown side by side, tables for parameters. - Redact secrets as YOUR_API_KEY placeholders; use realistic sample payloads. - Every code sample must be runnable as written after substituting placeholders. </constraints> <format> Return the full integration guide as a Markdown artifact, then note which endpoints deserve their own reference pages. </format>

You are a technical writer who documents command-line tools for engineers. <context> I need a usage guide for our CLI tool that gets a new user from install to their first successful command, returned as one self-contained Markdown document. </context> <inputs> - CLI name and purpose: [WHAT IT DOES] - Install methods: [E.G. NPM, BREW, BINARY DOWNLOAD] - The 3-5 most-used commands: [COMMAND + WHAT IT DOES] - Global flags and config file: [ANY] - Typical first workflow: [WHAT A NEW USER DOES FIRST] - OS support: [MAC / LINUX / WINDOWS] </inputs> <task> Write the guide with: a short intro, installation for each method, a quickstart that runs the very first command and shows output, a section per key command with syntax, common flags, and a real example, a config-file section, and a troubleshooting note for the most common install or auth error. </task> <constraints> - Valid Markdown: fenced shell blocks tagged bash, tables for flags, inline code for commands and paths. - Show expected terminal output under commands where useful; use realistic arguments. - No filler; every command shown must be copy-paste runnable. </constraints> <format> Return the full CLI guide as a Markdown artifact, then suggest which commands warrant a separate command reference page. </format>

You are a technical writer who specializes in getting-started documentation. <context> I need a complete installation and setup guide that takes someone from nothing to a running, verified install, returned as one self-contained Markdown document. </context> <inputs> - Software and what it is: [NAME, TYPE] - Environments to cover: [LOCAL, DOCKER, CLOUD, ETC] - System requirements: [OS, RUNTIME VERSIONS, MEMORY] - Required dependencies and services: [DB, REDIS, ETC] - Configuration and env vars needed: [KEY ONES] - How to know it worked: [HEALTH CHECK, TEST COMMAND] </inputs> <task> Write the guide with: system requirements, a prerequisites checklist, step-by-step installation for each environment, a configuration section listing required environment variables in a table with descriptions and example values, a first-run command, a verification section with the exact success output, and a common-setup-errors troubleshooting block. </task> <constraints> - Valid Markdown: H2 per environment, fenced code blocks, an env-var table, blockquote warnings. - Redact secrets; use placeholder values that make the format obvious. - Every command must be runnable; verification step must be concrete and testable. </constraints> <format> Return the full setup guide as a Markdown artifact, then note which prerequisites most often trip people up. </format>

You are a technical writer who documents version migrations and breaking changes. <context> We are shipping a new major version and I need a migration guide that helps existing users upgrade safely, returned as one self-contained Markdown document. </context> <inputs> - Product and versions: [FROM VERSION -> TO VERSION] - Breaking changes: [WHAT CHANGED, OLD VS NEW] - Deprecated features and replacements: [LIST] - Data or config migration steps: [ANY] - Rollback path: [HOW TO REVERT] - Estimated effort and risk level: [SMALL / LARGE] </inputs> <task> Write the guide with: a summary of what changed and why, a before-you-begin backup and prerequisites section, a breaking-changes table mapping old behavior to new with the required code or config edit, step-by-step upgrade instructions, a data or config migration section, a post-upgrade verification checklist, and a rollback procedure. </task> <constraints> - Valid Markdown: a before/after code diff style using two fenced blocks, a breaking-changes table, numbered steps, warning callouts. - Be precise about ordering; call out any irreversible step explicitly. - Use real symbol, flag, and config names, never placeholders where the actual name is known. </constraints> <format> Return the full migration guide as a Markdown artifact, then a one-line risk summary and the single most dangerous step. </format>

You are an API documentation specialist who writes precise endpoint reference pages. <context> I need a complete reference page for one REST endpoint (or a small group), returned as one self-contained Markdown document that could go straight into our API docs. </context> <inputs> - Endpoint(s): [METHOD + PATH] - What it does: [PURPOSE] - Auth required: [SCOPE / TOKEN] - Path, query, and body parameters: [NAME, TYPE, REQUIRED, DESCRIPTION] - Example request and response: [OR ASK CLAUDE TO INFER REALISTIC ONES] - Error responses: [STATUS CODES + MEANINGS] </inputs> <task> Write the reference with: endpoint signature and one-line description, auth and required scope, parameter tables split by path, query, and body (name, type, required, description, default), a request example in curl, a full success response example with status code, an error table with status codes and messages, and any rate-limit or pagination notes. </task> <constraints> - Valid Markdown: parameter tables, fenced JSON and shell code blocks, HTTP status codes in inline code. - Types must be explicit (string, integer, boolean, ISO 8601 datetime, etc.); mark every parameter required or optional. - Sample payloads must be internally consistent between request and response. </constraints> <format> Return the endpoint reference as a Markdown artifact, then note any fields that need clearer descriptions or examples. </format>

You are a technical writer who documents configuration options and environment variables. <context> I need a complete configuration reference for our application so users can look up any setting, returned as one self-contained Markdown document. </context> <inputs> - Application and where config lives: [FILE, ENV VARS, DASHBOARD] - The settings to document: [NAME, TYPE, DEFAULT, WHAT IT CONTROLS] - Which are required vs optional: [FLAG EACH] - Any that are secrets: [MARK THEM] - Related settings that interact: [DEPENDENCIES] - Example config for a common setup: [OR ASK CLAUDE TO WRITE ONE] </inputs> <task> Write the reference with: an intro on where config is loaded from and precedence order, a master table of every setting (name, type, default, required, description), grouped subsections for related settings with fuller explanations and examples, a note on secrets handling, and a complete annotated example configuration for a typical deployment. </task> <constraints> - Valid Markdown: a settings table, fenced code for the example config with inline comments, inline code for keys and values. - Every setting has an explicit type and default; secrets clearly flagged and never shown with a real value. - Alphabetical or logical grouping stated up front; no duplicated entries. </constraints> <format> Return the configuration reference as a Markdown artifact, then flag any settings whose defaults seem risky or undocumented. </format>

You are a documentation engineer who writes complete command references for CLI tools. <context> I need a full command reference (like a man page) for our CLI, returned as one self-contained Markdown document listing every command and flag. </context> <inputs> - CLI name: [NAME] - Commands and subcommands: [LIST WITH ONE-LINE PURPOSE] - Flags per command: [NAME, SHORTHAND, TYPE, DEFAULT, DESCRIPTION] - Global flags: [ANY] - Exit codes: [IF DEFINED] - Real usage examples: [OR ASK CLAUDE TO WRITE THEM] </inputs> <task> Write the reference with: a synopsis showing overall usage, a global flags table, a section per command with synopsis line, description, a flags table, and at least one worked example with output, and an exit-codes table. Keep entries uniform so the whole document reads consistently. </task> <constraints> - Valid Markdown: consistent H2/H3 per command, flag tables, fenced bash blocks for examples. - Show flag shorthand and long forms; state defaults; mark required flags. - Examples must be copy-paste runnable with realistic arguments. </constraints> <format> Return the command reference as a Markdown artifact, then note any commands missing examples or clear descriptions. </format>

You are a technical writer who documents SDKs and code libraries. <context> I need a function and class reference for our SDK so developers can look up any method, returned as one self-contained Markdown document. </context> <inputs> - Library name and language: [NAME, LANGUAGE] - Functions/classes/methods to document: [SIGNATURES OR NAMES] - Parameters and return types: [PER FUNCTION] - Errors or exceptions thrown: [ANY] - Usage examples: [OR ASK CLAUDE TO WRITE THEM] - Versioning notes: [SINCE VERSION, DEPRECATIONS] </inputs> <task> Write the reference with: a short intro and import statement, then one entry per function or method with its signature, a one-line description, a parameters table (name, type, required, description), the return type and shape, exceptions or errors it can raise, and a minimal runnable example. Group related methods under class or module headings. </task> <constraints> - Valid Markdown: fenced code blocks tagged with the language, parameter tables, signatures in code formatting. - Types must match the language's conventions; mark optional parameters and defaults. - Every example must compile or run as written after import. </constraints> <format> Return the SDK reference as a Markdown artifact, then note which functions need clearer return-type documentation. </format>

You are a technical writer who documents data models and database schemas. <context> I need a schema reference that describes our data model so engineers understand every entity and relationship, returned as one self-contained Markdown document. </context> <inputs> - System and storage: [APP, DATABASE TYPE] - Entities/tables/collections: [NAMES + PURPOSE] - Fields per entity: [NAME, TYPE, NULLABLE, DESCRIPTION] - Relationships: [ONE-TO-MANY, FOREIGN KEYS, ETC] - Indexes and constraints: [ANY] - Enums and allowed values: [ANY] </inputs> <task> Write the reference with: an overview of the model and a Mermaid entity-relationship diagram, then one section per entity with a purpose line, a field table (name, type, nullable, default, description), primary and foreign keys, indexes and constraints, and any enum value lists. End with a relationships summary. </task> <constraints> - Valid Markdown: field tables, and a fenced ```mermaid erDiagram block that parses. - Types must be explicit database types; mark nullability and keys clearly. - Keep entity and field names exactly as given; no invented columns. </constraints> <format> Return the schema reference as a Markdown artifact including the Mermaid ER diagram, then note any relationships that look ambiguous. </format>

You are a staff engineer who writes clear system architecture documentation. <context> I need a system architecture overview that a new engineer or reviewer can read to understand how the whole system fits together, returned as one self-contained Markdown document with a diagram. </context> <inputs> - System name and purpose: [WHAT IT DOES] - Major components/services: [NAMES + RESPONSIBILITIES] - Data stores and external dependencies: [DB, QUEUES, THIRD-PARTY APIs] - Request/data flow: [HOW A TYPICAL REQUEST MOVES] - Key technologies: [LANGUAGES, FRAMEWORKS, INFRA] - Scaling and reliability concerns: [ANY] </inputs> <task> Write the doc with: a one-paragraph system summary, a component overview table (component, responsibility, tech), a Mermaid architecture diagram showing components and data flow, a section describing the main request lifecycle end to end, data storage and external integrations, and a short notes section on scaling, failure modes, and security boundaries. </task> <constraints> - Valid Markdown: a component table, prose sections, and a fenced ```mermaid flowchart block that parses. - Describe responsibilities and boundaries precisely; avoid vague statements. - Use the real component and service names provided. </constraints> <format> Return the architecture overview as a Markdown artifact with the Mermaid diagram, then list the two areas most in need of deeper docs. </format>

You are a principal engineer who writes disciplined Architecture Decision Records. <context> I need a single ADR documenting one significant technical decision so the team has a durable record of the choice and its trade-offs, returned as one self-contained Markdown document. </context> <inputs> - Decision title: [WHAT WE DECIDED] - Context and problem: [WHY A DECISION IS NEEDED] - Options considered: [2-4 ALTERNATIVES] - Chosen option and why: [THE DECISION] - Trade-offs and consequences: [PROS, CONS, RISKS] - Status: [PROPOSED / ACCEPTED / SUPERSEDES X] </inputs> <task> Write the ADR using the standard structure: title with an ID and date, status, context (the forces and problem), decision (what we chose, stated in the active voice), considered options each with pros and cons, consequences (positive, negative, and follow-up work), and any references or links. Keep it factual and durable. </task> <constraints> - Valid Markdown: H1 title, clear H2 sections matching the ADR template, a comparison table for options. - State the decision decisively; capture real trade-offs, not a sales pitch for the winner. - Concise and self-contained so it reads clearly years later. </constraints> <format> Return the ADR as a Markdown artifact, then suggest a filename and ADR number convention for the repo. </format>

You are a senior engineer who writes thorough technical design documents (RFCs). <context> I need a technical design doc for a feature or system change so reviewers can evaluate the approach before I build it, returned as one self-contained Markdown document. </context> <inputs> - Feature/change and goal: [WHAT WE ARE BUILDING AND WHY] - Requirements and non-goals: [IN SCOPE / OUT OF SCOPE] - Proposed approach: [HIGH-LEVEL DESIGN] - Key components and data changes: [APIS, SCHEMA, SERVICES] - Alternatives considered: [OTHER APPROACHES] - Risks, testing, and rollout plan: [ANY] </inputs> <task> Write the design doc with: summary and motivation, goals and non-goals, proposed design with component and data-model changes plus a Mermaid diagram of the flow, API or interface changes, alternatives considered with why they were rejected, testing strategy, rollout and migration plan, and open questions. Write for a reviewer who will poke holes in it. </task> <constraints> - Valid Markdown: structured H2 sections, tables for API or schema changes, a fenced ```mermaid block, an open-questions list. - Be specific about data and interface changes; state assumptions explicitly. - Clearly separate what is decided from what is still open. </constraints> <format> Return the design doc as a Markdown artifact, then list the three questions a reviewer is most likely to raise. </format>

You are a systems architect who documents data flows and third-party integrations. <context> I need a design doc describing how data moves through our system and how we integrate with an external service, returned as one self-contained Markdown document with a diagram. </context> <inputs> - Integration/flow name: [WHAT IT CONNECTS] - Systems involved: [OUR SERVICES + EXTERNAL PARTIES] - Trigger and direction: [WHAT STARTS IT, INBOUND / OUTBOUND] - Data exchanged: [PAYLOAD FIELDS, FORMATS] - Sync vs async, retries, idempotency: [DETAILS] - Failure and security handling: [AUTH, ERRORS] </inputs> <task> Write the doc with: overview of the flow and its purpose, a Mermaid sequence diagram of the end-to-end exchange, a step-by-step description of each hop with the payload at that stage, a data-contract table for the exchanged fields, error handling and retry/idempotency strategy, security and auth handling, and monitoring or alerting recommendations. </task> <constraints> - Valid Markdown: a fenced ```mermaid sequenceDiagram that parses, a data-contract table, fenced JSON for sample payloads. - Be explicit about sync vs async, retry behavior, and idempotency keys. - Sample payloads must match the field table exactly. </constraints> <format> Return the integration design doc as a Markdown artifact with the Mermaid sequence diagram, then list the top failure modes to monitor. </format>

You are an API designer who writes clear API contracts before implementation. <context> I need an API design spec that defines a new set of endpoints as a contract for both backend and frontend teams, returned as one self-contained Markdown document. </context> <inputs> - API purpose and resource(s): [WHAT IT MANAGES] - Endpoints to define: [METHOD + PATH + INTENT] - Resource shape/fields: [NAME, TYPE, RULES] - Auth and permissions: [WHO CAN CALL WHAT] - Validation and error rules: [CONSTRAINTS] - Versioning and pagination approach: [ANY] </inputs> <task> Write the spec with: an overview and design principles, the resource model as a field table, an endpoints table, then a per-endpoint contract giving method, path, auth, request schema, response schema, status codes, and validation rules with example request and response bodies, plus sections on error format, pagination, and versioning. </task> <constraints> - Valid Markdown: resource and endpoint tables, fenced JSON for request/response examples, consistent error envelope. - Define a single standard error shape and reuse it; state status codes for every outcome. - Examples must be internally consistent and follow the field rules. </constraints> <format> Return the API design spec as a Markdown artifact, then note where an OpenAPI schema could be generated from this contract. </format>