Technical writers live at the intersection of complexity and clarity. You translate engineering specs, API references, developer guides, and internal processes into documentation that people can actually use. Your job is to make complicated things simple—and to do it fast, across dozens of products and audiences simultaneously.
The challenge: every deliverable starts from scratch. A new API guide, a release note, a troubleshooting article, a runbook—each one is a blank page that needs structure, research, and careful prose before it becomes useful.
ChatGPT doesn't know your product or your codebase. But it's excellent at documentation scaffolding: outlines, first drafts, boilerplate, rewriting for audience, and consistency checks. These 35 prompts eliminate blank-page friction on your most common deliverables.
Organized by documentation type: API reference, user guides, release notes, internal docs, and professional work. Copy, adapt to your product, and ship faster.
API and Developer Documentation
Prompt 1 — Document an API endpoint
Write API reference documentation for the following endpoint: [method] [endpoint path]. Parameters: [list name, type, required/optional, description]. Request body: [schema or example]. Response: [schema or example]. Error codes: [list]. Authentication: [method]. Write this in the style of Stripe or Twilio docs — clear, terse, with a working example. Include a curl example request.
Prompt 2 — Write a quickstart guide
Write a developer quickstart guide for [product/API name]. Audience: [e.g., "backend developers new to our API"]. Goal: help them make their first successful API call in under 10 minutes. Cover: prerequisites, installation/setup, authentication, a minimal working example, and next steps. Use numbered steps, code blocks, and callouts for important notes. Assume no prior knowledge of our product.
Prompt 3 — Document a code sample
Write inline documentation and a companion explanation for this code: [paste code]. The audience is [developer level — beginner/intermediate/advanced]. Include: what the code does, parameter explanations, expected output, and one common gotcha. Format as: (1) annotated code with inline comments, (2) plain-English explanation below. Keep the explanation under 150 words.
Prompt 4 — Write an authentication guide
Write a developer guide for authenticating with [product] using [auth method — OAuth 2.0 / API keys / JWT / etc.]. Cover: how to obtain credentials, the authentication flow step by step, a working code example in [language], token refresh/expiry handling, and security best practices. Assume the reader has used REST APIs but not our specific auth implementation.
Prompt 5 — Write an error reference section
Write an error reference section for [product/API]. Error codes to document: [list codes, HTTP status, brief meaning]. For each error, include: error code, HTTP status, what it means, common causes, and how to resolve it. Format as a table for scanning, with an expandable detail section for each. Model after Stripe or GitHub API error docs.
Prompt 6 — Write SDK documentation
Write documentation for a [language] SDK method: [method name]. What it does: [description]. Parameters: [list]. Returns: [type and description]. Throws/exceptions: [list]. Usage example: [paste example or describe]. Write in the style of official SDK documentation — concise, precise, and scannable. Include a minimal working code snippet.
User Guides and How-To Articles
Prompt 7 — Write a how-to article
Write a how-to article for [task] in [product]. Audience: [persona — e.g., "non-technical business users"]. Goal: help them complete [specific outcome] independently. Structure: brief intro (why this matters), prerequisites, numbered steps with screenshots [placeholder], expected result at each key step, troubleshooting tips, and next steps. Keep steps atomic — one action per step.
Prompt 8 — Write a conceptual overview
Write a conceptual overview of [feature or concept] for [audience]. This article should help readers understand: what it is, how it works at a high level, when to use it vs. alternatives, and key terminology. This is NOT a how-to — it's background knowledge. Keep it under 600 words. Use an analogy to explain the core concept if helpful.
Prompt 9 — Write a troubleshooting article
Write a troubleshooting article for the issue: [problem description] in [product]. Structure: problem statement, symptoms/error messages that indicate this issue, diagnostic steps to confirm the root cause, resolution steps for each cause, prevention tips, and when to contact support. Format each cause-resolution pair clearly. Use "if X, then Y" structure.
Prompt 10 — Write feature release documentation
Write user-facing documentation for a new feature: [feature name]. What it does: [description]. Who it's for: [user persona]. How to access it: [navigation or setup steps]. Key things users need to know: [list]. Any limitations or known issues: [list]. Write for a user who will encounter this feature for the first time. Avoid internal jargon.
Prompt 11 — Simplify a complex explanation
Rewrite this technical explanation for a non-technical audience: [paste text]. The reader is [audience — e.g., "a business stakeholder who doesn't code"]. Goals: preserve accuracy, remove jargon, use analogies where helpful, and keep it under [word count]. If any technical terms must stay, define them inline on first use.
Prompt 12 — Write a UI walkthrough
Write a UI walkthrough for [screen or workflow] in [product]. Audience: first-time users. Cover each element the user will encounter, what it does, and what to do. Structure: numbered steps with clear action verbs. Include what the user should see after each action (expected state). Flag any non-obvious elements or decisions the user needs to make.
Release Notes and Changelogs
Prompt 13 — Write release notes
Write release notes for version [X.X.X] of [product]. Changes included: [paste raw changelog, PR titles, or ticket descriptions]. Audience: [end users / developers / both]. For each change: categorize as New Feature / Improvement / Bug Fix / Deprecation / Breaking Change. Write each entry in plain language with a brief explanation of the user impact. Lead with the most important changes.
Prompt 14 — Rewrite raw changelog entries
These are raw changelog entries written by engineers: [paste entries]. Rewrite each for a user-facing release note. Rules: no ticket IDs, no internal jargon, focus on user benefit not technical implementation, use active voice, keep each entry to 1-2 sentences. Here is the audience: [description].
Prompt 15 — Write a deprecation notice
Write a deprecation notice for [feature/API/endpoint]. What's being deprecated: [description]. Why: [reason]. Timeline: deprecated [date], removed [date]. Migration path: [what users should do instead]. Impact if they don't migrate: [consequences]. Write this in a tone that is clear and direct without being alarming. Include a migration example if applicable.
Prompt 16 — Write a breaking change notice
Write documentation for a breaking change in [product]. What changed: [technical description]. Who is affected: [which users or use cases]. What breaks if they don't update: [specific behavior]. What they need to do: [migration steps]. Estimated migration time: [if known]. Format for a prominent warning callout at the top of the release notes plus a dedicated migration guide section.
Internal Documentation and Runbooks
Prompt 17 — Write a runbook
Write a runbook for [operational process — e.g., "database failover" or "deploy to production"]. Audience: on-call engineers who may not have run this process before. Cover: when to use this runbook, prerequisites, step-by-step procedure with commands, expected output at each step, what to do if something goes wrong, rollback procedure, and who to escalate to. Include every command — assume nothing is memorized.
Prompt 18 — Document an internal process
Write internal process documentation for [process name]. Audience: new team members. Cover: what this process is, when it runs, who is responsible, step-by-step instructions, tools used, common pitfalls, and where to find help. Format as a living document with a "last updated" field. Keep it scannable with headers and bullets.
Prompt 19 — Write an architecture decision record (ADR)
Write an Architecture Decision Record (ADR) for the following decision: [decision description]. Cover: context (why this decision was needed), options considered, decision made, rationale, consequences (positive and negative), and status (proposed/accepted/deprecated). Use the MADR format. Keep the rationale section evidence-based, not opinion-based.
Prompt 20 — Write an onboarding guide for a codebase
Write a developer onboarding guide for the [product/repo name] codebase. Audience: new engineers joining the team. Cover: repo structure overview, how to run it locally, key concepts they need to understand, the most important files/modules to know, common workflows (branch, test, PR), gotchas and tribal knowledge, and where to ask questions. Keep it honest — include the rough edges.
Prompt 21 — Write a postmortem document
Write a postmortem document for the following incident: [brief description]. Timeline: [list events with timestamps]. Root cause: [technical cause]. Contributing factors: [list]. User impact: [description]. Immediate response: [what was done]. Follow-up action items: [list with owners]. Lessons learned: [what we'll do differently]. Use a blameless tone. Focus on systems and process, not individual mistakes.
Style and Consistency
Prompt 22 — Review for voice and style consistency
Review the following documentation for voice and style consistency with this style guide excerpt: [paste relevant style guide rules]. The document: [paste text]. Flag: inconsistent terminology, passive voice where active is preferred, jargon that should be avoided, tone mismatches, and formatting inconsistencies. List each issue with a suggested fix. Do not rewrite the whole document — just flag and fix specific issues.
Prompt 23 — Create a style guide entry
Write a style guide entry for [term or rule]. This entry should cover: the preferred usage, examples of correct and incorrect usage, the rationale behind the rule, and any exceptions. Format as a style guide entry that a writer can reference quickly. Keep it under 200 words.
Prompt 24 — Audit for plain language compliance
Audit this documentation for plain language compliance: [paste text]. Check for: words over 3 syllables that have simpler alternatives, passive voice, sentences over 20 words, jargon without definition, nominalization (turning verbs into nouns), and unclear pronoun references. List each issue, line by line, with a plain-language rewrite.
Prompt 25 — Standardize terminology
I need to standardize the following terms across our documentation. Preferred terms: [list preferred → banned variants, e.g., "sign in" not "log in"]. Here is a document to check: [paste text]. Flag every instance of a non-preferred term and suggest the replacement. Also flag any terms I may have missed that appear in multiple forms.
Content Planning and Doc Strategy
Prompt 26 — Audit a docs site for gaps
Here is a list of our current documentation pages: [paste sitemap or page list]. Our product does: [brief description]. Typical user persona: [description]. Identify: missing articles that users commonly need, pages that should be split or combined, gaps in the beginner-to-advanced learning path, and any documentation types (tutorials, reference, conceptual, how-to) that are underrepresented.
Prompt 27 — Write a documentation plan
Write a documentation plan for [new feature or product launch]. Deliverables needed: [list what must be written]. Audience: [user personas]. Dependencies: [what you need from engineering, design, etc.]. Timeline: [target launch date]. For each deliverable: estimated word count, input needed, review cycle, and owner. Format as a project brief.
Prompt 28 — Create a docs taxonomy
Design a documentation taxonomy for [product type]. Create a top-level navigation structure with: main categories, subcategories, and the content type (tutorial, how-to, reference, explanation) for each section. Model on best-in-class documentation sites for this product type. Explain the rationale for the top-level categories.
Professional Development
Prompt 29 — Prepare for a docs review meeting
I'm presenting draft documentation to [audience — engineering, product, legal]. The docs cover: [topic]. Likely feedback I'll get: [your assumptions]. Help me prepare: anticipated questions and suggested responses, areas of the doc most likely to get pushback and how to defend my choices, and one framing statement to open the review that sets the right expectations.
Prompt 30 — Write a self-review before submitting docs
I'm about to submit documentation on [topic] for review. Help me self-audit before I send it. Check for: factual gaps I may have overlooked, structural issues that might confuse readers, audience mismatches in technical level, missing examples or callouts, and anything that looks like it was written for the writer rather than the reader. Here is the draft: [paste].
Prompt 31 — Write a content brief for a SME interview
I'm interviewing a subject matter expert (SME) about [topic] to gather information for documentation. Create a content brief for the interview: background questions to establish context, specific technical questions to get the information I need, questions to surface edge cases and gotchas, and clarifying questions I should ask if their answers are unclear. The documentation output will be: [description].
Prompt 32 — Write a docs metrics report
Write a quarterly documentation metrics report for [team/product]. Data I have: [list metrics — page views, search queries, support tickets, CSAT, etc.]. Audience: product and engineering leadership. Cover: what the metrics tell us about documentation quality, top user needs we're not meeting, recommendations for the next quarter, and one success story. Keep it to 1 page.
Specialized Formats
Prompt 33 — Write a FAQ section
Write a FAQ section for [topic/product]. Questions to address: [list questions, or describe the user scenarios that generate questions]. For each: write the question as the user would phrase it (not how you'd phrase it internally), give a direct answer in 1-3 sentences, and link to related documentation if applicable. Organize by topic, not alphabetically.
Prompt 34 — Write a glossary entry
Write glossary entries for the following terms: [list terms]. For each entry: definition (1-2 sentences, plain English), context for when this term is used in our product, related terms, and an example of correct usage in a sentence. Avoid circular definitions. Write for a reader who is new to both our product and the technical domain.
Prompt 35 — Convert a video transcript to documentation
Convert this video transcript into structured written documentation: [paste transcript]. The video covers: [topic]. The documentation format should be: [how-to / conceptual / reference]. Remove filler words, verbal tics, and repetition. Restructure for scannable reading rather than listening. Add headers, bullets, and code blocks where appropriate. Preserve all technical accuracy.
Getting the Most From These Prompts
Front-load context. Technical writing prompts live or die on specifics. Include audience, product name, technical level, and any style constraints before the task description.
Use for scaffolding and first drafts. ChatGPT is best at structure and boilerplate. Your expertise is what makes documentation accurate, precise, and trustworthy. Review every output carefully.
Iterate on style. Run your organization's style guide constraints through the prompt (Prompt 22-25) to catch issues before review.
Never paste proprietary code or unreleased specs. Review your organization's acceptable use policies before inputting any confidential material.
The Complete Technical Writer's AI Toolkit
These 35 prompts cover the most common documentation deliverables. If you want the full system—advanced prompts for API docs at scale, docs-as-code workflow templates, SME interview frameworks, and a complete documentation planning toolkit—the Technical Writer AI Toolkit has everything organized and ready.
Get the Technical Writer AI Toolkit →
Bookmark this page. Share it with your docs team. Start with one prompt on your next deliverable—you'll be surprised how much time you reclaim.
Top comments (1)
I'd be awesome that ChatGPT added support for custom commands similar to what Claude, Augment, Codex do, where we can have a commands folder where we can put files. Each of these prompts could be its own custom command and be invoke with /custom-command.