AI Prompts for Claude for Technical Writing

I am building documentation for [PRODUCT NAME], which does [DESCRIBE WHAT IT DOES]. The primary users of this documentation will be [DESCRIBE AUDIENCE: developers, end users, administrators, etc.]. Design a complete documentation structure with: (1) the main sections and their purpose, (2) the recommended order for a first-time user to read them, (3) any sections that different user types would access differently. I want a plan before I start writing.

We are shipping a new feature: [DESCRIBE FEATURE]. Write a documentation scope document that defines: what needs to be documented, what the user needs to understand before and after reading the documentation, what existing documentation this feature relates to or updates, and what is out of scope for this documentation cycle. This will guide what we write, not the content itself.

I am writing documentation for [DESCRIBE CONTENT] targeting [DESCRIBE AUDIENCE]. Tell me what level of detail and assumed knowledge is appropriate for this audience. Specifically: what can I assume they already know, what terms do I need to define, what depth of explanation does each section need, and what examples or analogies would resonate with this audience. Give me concrete guidance, not general principles.

I need to document a series of [TYPE OF CONTENT: API endpoints, configuration options, CLI commands, etc.]. Create a template for each entry that ensures consistent structure across all items. The template should capture everything a user needs to understand the item, use it correctly, and troubleshoot common problems. Show the template with example content for one item.

Here is our current documentation structure: [PASTE STRUCTURE OR DESCRIBE WHAT EXISTS]. Here are the most common support questions and errors users report: [PASTE]. Identify the documentation gaps: what is missing entirely, what exists but is too thin, and what is documented but in the wrong place for users to find it. Prioritize by user impact.

Write a getting-started guide for [PRODUCT NAME]. The audience is [DESCRIBE AUDIENCE] with [DESCRIBE ASSUMED KNOWLEDGE]. The guide should take a first-time user from zero to [DESCRIBE FIRST SUCCESS STATE]. Include: prerequisites, step-by-step setup instructions, the first working example, and what to do if something goes wrong. Write the actual guide, not a plan for it.

Write documentation for this API endpoint: [PASTE ENDPOINT DETAILS]. The documentation should include: what the endpoint does and when to use it, the full request format with all parameters and their types, the response structure with all fields, authentication requirements, error codes and what they mean, and a complete working example request and response. Target audience: [DESCRIBE DEVELOPER AUDIENCE].

Explain [TECHNICAL CONCEPT] for documentation that will be read by two audiences: (1) a non-technical product manager who needs to understand what it does and when to use it, and (2) a developer who needs to understand how it works and how to implement it. Write both explanations. Each should be complete and self-contained, not just a summary and a long version.

Write a step-by-step tutorial for [TASK OR WORKFLOW] using [LANGUAGE/FRAMEWORK/TOOL]. The audience is [DESCRIBE AUDIENCE]. Include: a brief explanation of what we are building and why, every step with the code and a clear explanation of what it does and why, expected output at each stage, and common mistakes and how to avoid them. Use [LANGUAGE] for code examples.

Write a reference page for the [TOOL NAME] CLI. Include every command in this list: [PASTE COMMANDS]. For each command, document: the syntax, what it does, all options and flags with descriptions, required versus optional arguments, and one practical example. Format it as scannable reference documentation, not a narrative.

Users report confusion about this documentation section: [PASTE SECTION]. Analyze specifically what is causing the confusion: unclear sequence of steps, assumed knowledge that is not stated, terms that are not defined, information placed in the wrong order, or missing examples. Give me a diagnosis before suggesting fixes.

Rewrite this technical documentation section for an audience of non-technical users who need to understand the concept but do not need to implement it: [PASTE SECTION]. Remove implementation details, define all technical terms, replace jargon with plain language, and add an analogy if the concept is abstract. Preserve the accuracy of what the documentation says.

Restructure this documentation page so it is easier to scan: [PASTE DOCUMENTATION]. Users should be able to find what they need without reading every word. Add appropriate headings, use bullet points for lists of items, break long paragraphs into shorter focused ones, and add a brief summary at the top of each major section. Preserve all content.

Read this documentation for [FEATURE OR PRODUCT]: [PASTE]. Based on what could go wrong at each step, write a troubleshooting section that addresses the 5 to 7 most likely errors a user would encounter. For each error: describe the symptom, the most likely cause, and the specific steps to resolve it. Add the troubleshooting section at the end of the documentation.

Compare this documentation to this code: [PASTE DOCUMENTATION] [PASTE CODE]. Identify any places where the documentation does not accurately describe what the code does: wrong parameter names, incorrect descriptions of behavior, outdated examples, or missing functionality. List each discrepancy and flag which are critical versus minor.

Write a documentation style guide for a team of [NUMBER] technical writers documenting [TYPE OF PRODUCT]. Include: (1) voice and tone rules with examples, (2) formatting standards for headings, code, lists, and callouts, (3) how to handle versioning, deprecations, and breaking changes, (4) standard templates for the most common documentation types we write. Make it specific enough to resolve ambiguity, not so long it is never read.

Here is a code file with inline comments: [PASTE CODE]. Write user-facing documentation for this code that explains: what it does, how to use it, what parameters it accepts, what it returns, and any edge cases or limitations. Do not surface implementation details that users do not need. Write it as reference documentation for a developer audience.

We are releasing version [VERSION NUMBER] of [PRODUCT]. Here are the changes: [PASTE TECHNICAL CHANGES OR PR DESCRIPTIONS]. Write a changelog entry that communicates these changes to our users clearly. Group changes into: new features, improvements, and bug fixes. For each entry, write what changed and why it matters to the user, not just what happened internally.

Create a documentation review checklist that any technical writer on our team can use before publishing. The checklist should cover: accuracy, completeness, structure and scannability, language and tone, code examples, links, and versioning. For each item, write a specific question the reviewer should be able to answer yes to before checking it off.

Read this documentation: [PASTE]. Flag any content that is likely to become outdated as the product changes: version numbers, feature names that may change, instructions that assume specific UI states, and references to third-party tools or APIs that may change independently. Give me a list of what to monitor and update with each release.