GPTPROMPTS.AI
HOW-TO GUIDE · 2026
How to Use Claude for Technical Writing: 2026 Guide
An 8-step workflow for documentation engineers and technical writers. Load your full product context into a Claude Project, generate API references from OpenAPI specs, draft tutorials and runbooks, and ship release notes in 15 minutes instead of 90.
Technical writing with Claude in 2026 is a different category of useful than technical writing with ChatGPT or Microsoft Copilot. The difference is that Claude can hold an entire product's source-of-truth in working memory at once: the README, the architecture overview, the OpenAPI spec, 10 exemplar pages from your docs, the style guide, the glossary, and the recent release notes. A typical SaaS product Project lands at 40,000 to 100,000 tokens of background context, well inside Claude's 200K window. Every paragraph Claude writes is grounded in your actual product behavior and your team's house voice, not guessed from training data, and the feature-hallucination rate that frustrates docs reviewers on smaller models drops by roughly 80 percent.
The 8-step workflow below is built for production docs work: API reference generation from specs, tutorials with concrete user goals, runbooks built from incident history, release notes from merged PRs, conceptual guides that hold up across a product's evolution, and quarterly review passes that flag drift without rewriting. The first two steps are upstream investments (build a Project per product, load the style guide and exemplars) that pay back inside the first week. The middle steps (API reference, tutorials, Artifacts iteration, release notes, runbooks) are the daily-cadence doc tasks where Claude saves the most time. The final step (review passes that flag without rewriting) is what keeps a docs site from drifting as the product evolves. Every step has tool-specific patterns that lean on Claude's strengths instead of fighting the model.
01 Build a Claude Project per product with full source-of-truth context02 Load the style guide, glossary, and 5-10 exemplar pages03 Generate API reference docs directly from your OpenAPI or GraphQL spec04 Draft tutorials starting from a concrete user goal, not a feature inventory05 Iterate inside Artifacts for multi-section long-form drafts06 Generate release notes and changelogs from merged PRs in minutes07 Build runbooks from incident summaries, then pair with on-call engineers for the institutional knowledge08 Run a Claude review pass on existing docs to flag issues without rewriting
Who this guide is for
- • Documentation engineers and technical writers at SaaS, developer tools, or platform companies who own a docs site of 100+ pages and ship new pages weekly
- • Developer advocates and DevRel engineers who write tutorials, conceptual guides, and code-sample-heavy long-form content for external developers
- • SREs and platform engineers writing runbooks, on-call docs, and operational guides where the structure is formulaic and the value is in the institutional knowledge
- • Engineering managers who edit team-authored docs and want a faster review pipeline that catches drift without rewriting
- • Founders and early-stage product engineers at startups that do not yet have a dedicated docs team but need shipping-grade developer documentation
- • Open-source maintainers writing READMEs, contribution guides, and API references where consistent voice across thousands of pages is the goal
Why Claude specifically (vs. ChatGPT, Copilot, or Gemini)
For technical writing workflows, Claude has four specific advantages over alternatives. First, the 200K token context window is the biggest technical differentiator. A typical product's source-of-truth (README, architecture, OpenAPI spec, exemplar pages, style guide, glossary) lands at 40,000 to 100,000 tokens, well inside Claude's window. ChatGPT's 128K context fits a similar load but Claude's needle-in-haystack recall on long context is materially better, which matters when Claude needs to find the right callout pattern 80,000 tokens deep in your style guide. Second, Projects let you load the product context, style guide, and exemplars once and inherit them across every conversation; the time saved over a single quarter exceeds the Pro subscription cost by 10x. Third, Artifacts gives you an editable doc panel where Claude updates the draft in place across turns rather than rewriting from scratch every message; this cuts long-form draft time by 40-60 percent on multi-section pages. Fourth, Claude's code reading and writing accuracy is consistently strong for technical content; pasting a 500-line module and getting a correct plain-English description (without invented methods) is reliable in a way that competitors are not.
Where Claude loses: Microsoft Copilot wins when your docs live inside Word and SharePoint, especially for compliance, policy, and internal-process documentation. ChatGPT is competitive for short blog-style posts and marketing-adjacent content where structural rigor matters less. Gemini integrates natively with Google Docs if your stack is fully Google Workspace and your docs ship as Google Docs rather than markdown. GitHub Copilot is better for in-IDE autocomplete inside the docs source files. The realistic answer for a docs team is to use Claude as the primary collaborator for long-form structured content and reach for the environment-native tool when the task is a fit.
The 8 steps below are tuned for Claude but the underlying logic translates to any major LLM with a long context window. The patterns that matter (Project setup, style-guide loading, OpenAPI-driven reference generation, Artifacts iteration, four-turn draft cycle, review without rewrite) are model-agnostic; the specific UX advantages (Projects, Artifacts) are Claude-specific in 2026. For paired workflows, see our Claude for coding guide, the Claude for research guide, and the general how to use Claude guide.
The 8-Step Workflow
01
Build a Claude Project per product with full source-of-truth context
The single highest-leverage upstream activity is building a Claude Project per product and loading its source-of-truth files. Include the README, architecture overview, OpenAPI or GraphQL spec, public SDK reference, 5-10 representative example pages from your existing docs, recent release notes, and a list of the 20 most common reader questions from support tickets or search logs. For a typical SaaS product this Project lands at 40,000 to 100,000 tokens of background context, well inside Claude's 200K window. Every conversation in the Project inherits this context without re-pasting. The setup takes 60-90 minutes once and pays back inside the first week. Without this step, Claude will hallucinate features, default values, and behaviors at a rate of 5-10 percent on first-draft docs against a real product.
Example prompt
In a new Claude Project named '[Product] Docs', upload these files: (1) README.md with product overview and value prop, (2) ARCHITECTURE.md with the system diagram and component descriptions, (3) openapi.yaml or schema.graphql for the public API, (4) sdk-reference.md with method signatures and examples, (5) examples/ folder with 5-10 representative shipping doc pages, (6) RELEASES.md with the last 6 months of release notes, (7) reader-questions.md with the top 20 questions from support and search logs. Then in any new conversation: 'Using the context in this Project, write [doc task]'. Every Claude response now grounds in your actual product instead of training-data approximations.02
Load the style guide, glossary, and 5-10 exemplar pages
Voice consistency across hundreds of pages comes from loading the style guide and example pages, not from reminding Claude in every prompt. Build a style-guide markdown file covering: voice and tone (formal, conversational, instructional), forbidden phrases (the marketing-speak your team avoids), preferred terminology with disallowed synonyms (use customer not user when referring to paying users; use logged-in user when referring to authenticated state), sentence-length guidance, callout patterns (when to use note vs warning vs tip), and code-sample conventions (language tags, comment density, error handling). Pair the guide with 5-10 actual pages from your docs that demonstrate the house style across different doc types (concept, tutorial, reference, runbook). Add this to the shared Project that all your product Projects can reference. After 3-4 weeks of refining the file from real edits, voice drift on Claude output drops to near zero.
Example prompt
Upload style-guide.md to your shared Claude Project. Structure: '# House Style Guide\n\n## Voice\nDirect, instructional, second-person. Avoid hedging ("sometimes", "often"). Avoid marketing-speak ("powerful", "seamless", "cutting-edge").\n\n## Terminology\n- customer: paying user (not user, not client)\n- logged-in user: authenticated state\n- API key: capitalized\n- webhook (lowercase, not Webhook)\n\n## Structure\n- Lead with the action, then the why\n- Code samples must compile and run as written\n- Every tutorial step ends with a 1-line check\n\n## Callouts\n- :::note for context\n- :::warning for behaviors that may cause data loss\n- :::tip for non-obvious shortcuts\n\n## Forbidden\n- it should be noted that\n- in today's fast-paced world\n- powerful, seamless, cutting-edge'. Then upload examples/ folder with 5-10 shipping pages.03
Generate API reference docs directly from your OpenAPI or GraphQL spec
API reference is the highest-volume doc task at most product companies and is where Claude saves the most time. Paste or upload the OpenAPI YAML or JSON (or GraphQL schema) into the Project. Ask Claude to generate the human-readable reference for each endpoint: a 1-2 sentence description that goes beyond restating the path, the use case, request and response schemas with example values that match real product data shapes, error codes with explanations of when each fires, and a working curl plus an SDK example in your supported languages. For a 60-endpoint API, Claude produces a first draft of the entire reference in one session of 1-2 hours. Always verify the generated examples against your actual API; specs sometimes drift from runtime behavior, and Claude will faithfully reproduce whatever the spec says. First-pass quality is 80-90 percent shippable.
Example prompt
'Schema in Project. For each endpoint in openapi.yaml under the /v1/customers/* path: (1) generate a 2-sentence description that explains the use case beyond restating the path, (2) document the request body and query params with example values that look like real customer data (not foo and bar), (3) document the response body with a fully-populated example, (4) list every error code from the spec with a 1-line explanation of when each fires, (5) provide a working curl example using the API key placeholder ck_live_*, (6) provide an SDK example in TypeScript and Python. Format each endpoint as a single markdown page with frontmatter title and slug fields. Output the customer-create endpoint first so I can review tone before you proceed.'04
Draft tutorials starting from a concrete user goal, not a feature inventory
Tutorial quality lives or dies on the framing. Bad tutorials list features; good tutorials walk a specific persona through a specific outcome. Tell Claude the persona (junior backend engineer, no prior experience with your product), the concrete outcome (deploy a working webhook receiver in under 10 minutes), the prerequisites (Node 20, an API key, a public ngrok URL), and the anti-goals (do not cover advanced auth flows, do not link out to other tutorials mid-stream, do not assume familiarity with your product's internal terminology). Ask Claude to draft the tutorial in 6-10 numbered steps. Each step needs: a specific code block, expected output, and a 1-line check that confirms the step worked. After the draft, run the tutorial yourself end-to-end against a fresh environment; almost every untested tutorial has at least one missing step.
Example prompt
'Schema and style guide in Project. Tutorial outcome: a junior backend engineer deploys a working webhook receiver for our [Event Name] event in under 10 minutes. Persona: knows Node 20, has not used our product before, comfortable with curl and basic Express. Prerequisites to declare upfront: Node 20+, free [Product] account, ngrok or similar tunneling tool, $0 in credits required. Anti-goals: do not cover signature verification yet (separate tutorial), do not cover production deploy, do not link out to other tutorials mid-stream. Draft 6-10 numbered steps. Each step has: a heading, 1-paragraph explanation of what the step does and why, a code block in TypeScript using our SDK, expected output (literal text or HTTP response), and a 1-line check the reader can run to confirm the step worked. End with a Next steps section listing 2-3 follow-up tutorials by name.'05
Iterate inside Artifacts for multi-section long-form drafts
For docs longer than 800 words (most tutorials, conceptual guides, architecture overviews), ask Claude to put the draft in an Artifact. Artifacts gives you an editable doc panel where Claude updates the draft in place across turns instead of rewriting from scratch every message. This is materially faster for structural rewrites, voice consistency passes, and adding sections because you and Claude share a single source of truth. The pattern: first turn produces the draft in an Artifact; subsequent turns request specific changes ('expand step 4 with the timeout edge case', 'rewrite the intro to lead with the user goal', 'add a callout in the middle of step 6 about the staging-vs-prod difference'); Claude updates the Artifact with diff-style summaries. For a 3,000-word tutorial, Artifacts cuts the development time by 40-60 percent compared to chat-only iteration.
Example prompt
'Put the tutorial draft in an Artifact so we can iterate. After the first version lands, I will ask for specific changes: sections to expand, callouts to add, voice tweaks against the style guide, code-sample fixes. Update the Artifact in place each time, and after each update give a 2-line summary of what changed and why. Do not rewrite sections I have not asked you to touch; the goal is incremental refinement, not regeneration.'06
Generate release notes and changelogs from merged PRs in minutes
Release notes are a daily-cadence doc task that Claude reduces from 90 minutes to 15. Paste the PR titles, descriptions, and labels for the release window (export from GitHub or your tracker as a CSV or markdown list). Ask Claude to group changes by user impact (new features, improvements, bug fixes, breaking changes), drop internal-only changes (label your repo with user-facing vs internal so Claude can filter), write the user-facing description for each item in 1-2 sentences using your style guide voice, and rank the most important items at the top. For breaking changes, ask for a separate migration section with before/after code blocks and the upgrade steps. The first-pass release notes are usually 70-80 percent shippable; the editorial pass focuses on tone, ordering, and verifying nothing user-facing was dropped.
Example prompt
'Style guide in Project. Below is the merged PR list for the [v2.18.0] release window: [paste PR title, description, labels for each merged PR]. (1) Group by impact: New features, Improvements, Bug fixes, Breaking changes. Drop any PR with the internal label. (2) For each item, write a 1-2 sentence user-facing description in our voice (no marketing-speak, no it should be noted that). (3) Rank items inside each group: customer-requested first, then high-traffic-affected, then niche. (4) For Breaking changes, write a Migration section with before/after code blocks and the exact upgrade steps. (5) Add a 1-paragraph release summary at the top suitable for the email announcement. Output the full release notes as markdown ready to paste into our changelog page.'07
Build runbooks from incident summaries, then pair with on-call engineers for the institutional knowledge
Runbooks are structurally formulaic (alert description, symptoms, immediate triage, root-cause investigation, mitigation, post-incident actions, contacts) which makes them an ideal Claude use case. Provide the alert name, the historical incident summaries (dates, severity, root cause, resolution time), the relevant dashboards, log queries, and the rollback procedure. Claude drafts the runbook structure with placeholders for the specific commands and dashboards. Always pair the draft with a real on-call engineer who has handled the alert; the value of a runbook is in the institutional knowledge that lives in their head, not in the structure. Claude turns 40 minutes of unstructured tribal knowledge into a 15-minute editing pass on a clean draft. For a 100-alert system, runbook coverage compresses from a multi-month project to 2-3 weeks of focused work.
Example prompt
'Schema and style guide in Project. Build a runbook for the [Alert Name] alert. Historical incidents: [paste 3-5 past incident summaries with date, severity, root cause, resolution time, what worked, what did not]. Relevant dashboards: [list URLs and what each shows]. Relevant log queries: [paste the 2-3 most useful queries]. Rollback procedure: [describe]. Generate the runbook with these sections: (1) Alert summary (1 paragraph), (2) Symptoms a responder will see, (3) Immediate triage steps in numbered order with the exact commands or dashboard links, (4) Root-cause investigation steps if triage does not resolve, (5) Mitigation options ranked by reversibility, (6) Post-incident actions (postmortem trigger, customer communication, monitoring updates), (7) Contacts. Use placeholders for any specific command, query, or URL we have not provided yet; mark them clearly as TODO.'08
Run a Claude review pass on existing docs to flag issues without rewriting
Existing docs accumulate problems over time: contradictions with the source-of-truth as the product evolves, jargon that creeps in, missing information for the persona the page was written for, structural issues (assumed knowledge, broken progression, dead-end sections). A 30-minute Claude review pass on a 2,000-word page typically surfaces 8-15 actionable issues. The discipline that makes review useful: ask Claude to flag issues for a human writer to fix, not to rewrite whole sections. Rewrites introduce voice drift and lose the human writer's ownership of the page; flagged issues with suggested fixes preserve both. Run the review pass quarterly on the most-trafficked 20 percent of pages; the impact compounds because the fixes from the first pass strengthen the style guide for subsequent passes.
Example prompt
'Schema, style guide, and source-of-truth in Project. Page under review: [paste full page]. Persona: [persona]. Review the page and flag (do not rewrite) the following classes of issue: (1) Sentences that contradict the source-of-truth in the Project (cite the file and line where the conflict occurs). (2) Jargon that could be replaced with plain language without losing precision (suggest the replacement). (3) Information a [persona]-level reader would need that is missing or assumed. (4) Structural issues: assumed knowledge that breaks the progression, dead-end sections, callouts placed where the reader has already lost context. (5) Voice drift from the style guide (cite the rule). Output as a numbered list of issues, each with: severity (P0 blocks publish, P1 ship-blocker, P2 nice-to-fix), location in the page (line or section), the issue, the suggested fix. Do not rewrite the page; the human writer will apply the fixes.'Common Mistakes That Break Claude Doc Output
1. Asking for docs without loading the product context
The single biggest source of broken docs. Claude will produce plausible-looking documentation with feature names that do not exist, default values that are wrong, and behaviors assumed from training data instead of read from your spec. Build a Project per product with the README, OpenAPI spec, architecture overview, and exemplar pages once and inherit it across every conversation.
2. Skipping the style-guide load
Without the style guide and 5-10 exemplar pages, Claude defaults to a competent but generic technical voice that will not match an established docs site. Every page reads like a different writer authored it. Load the style guide once and treat it as the highest-leverage upstream investment for any team writing more than 20 pages a month.
3. Treating Claude as a one-shot doc generator
The 4-turn cycle (draft, edit against actual product, paste corrections back, refine) produces shippable docs. The 1-turn cycle produces docs that need a full rewrite. Always run tutorials end-to-end on a clean machine and paste the failures back to Claude. Skipping the loop is the second-fastest way to ship broken docs.
4. Trusting Claude-written code samples without running them
Claude is right roughly 85-95 percent of the time on common languages, but the 5-15 percent of subtly wrong samples will frustrate readers and erode trust faster than any other doc problem. Code in docs that has not been executed against the current product version is worse than no code at all. Always run every code sample before publishing.
5. Letting Claude rewrite whole pages instead of flagging issues
Rewrites introduce voice drift and lose the human writer's ownership. For review passes, ask Claude to flag issues with suggested fixes, not to rewrite. The human writer applies the fixes. This preserves voice consistency and ownership while still catching real problems.
6. Drafting tutorials from feature inventories instead of user goals
Bad tutorials list features; good tutorials walk a specific persona through a specific outcome. Always tell Claude the persona, the concrete outcome (deploy a working webhook in under 10 minutes), the prerequisites, and the anti-goals. Without this framing, Claude produces feature-tour content that does not teach.
7. Letting Project context go stale as the product evolves
Stale Project context is worse than no context because it looks authoritative but leads Claude to confidently produce outdated docs. Set a quarterly maintenance cadence to refresh each product Project's source-of-truth files: README, OpenAPI spec, architecture overview, recent release notes, exemplar pages.
8. Pasting customer data or unreleased product information into a public LLM
Never paste customer-identifiable data or unreleased product details into the consumer Claude. For organizations with stricter data policies, Claude is available through AWS Bedrock and Google Vertex AI with enterprise data agreements. Check your company AI policy before pasting any non-public technical content.
Pro Tips (What Most Docs Teams Miss)
Build one shared Project for cross-product assets, plus one product Project per product. The shared Project holds the style guide, glossary, and brand voice; product Projects hold READMEs, specs, and exemplars. Writers branch off conversations from whichever Project matches the task, with both layers of context available.
Add a tooling section to your style guide that documents your Markdown flavor. Specify CommonMark vs GFM vs MDX, callout syntax (:::note vs blockquote vs custom React component), frontmatter schema, code-block conventions, and any custom shortcodes. Claude inherits the patterns and stops drifting on small details.
Use Opus 4.6 for long-form drafts and conceptual guides; Sonnet 4.6 for the daily 20-40 doc tasks. Opus's structural and tonal judgment is materially better on tutorials, architecture overviews, and conceptual guides. Sonnet is roughly 90 percent as accurate at 3-5x the response speed for API endpoint descriptions, error message rewrites, release notes, and changelog entries.
Refine the style guide from real edits, not theory. Every time you correct a Claude draft on voice, add the rule to the style guide. After 3-4 weeks the file converges on a pattern Claude can follow with 90 percent fidelity, and editing time drops sharply.
Run a Claude review pass quarterly on the most-trafficked 20 percent of pages. A 30-minute pass on a 2,000-word page typically surfaces 8-15 actionable issues: source-of-truth contradictions, jargon creep, missing information for the persona, structural drift. Fixes from the first pass strengthen the style guide for subsequent passes.
For API reference, paste the spec in YAML even if your repo uses JSON. Claude's chunking handles indented YAML hierarchy more cleanly than JSON when the spec is large; the result is fewer cases of Claude losing track of which endpoint a parameter belongs to.
Treat tutorials as un-shippable until they have been run end-to-end on a clean machine. No exceptions. Almost every untested tutorial has at least one missing step (an env var, a directory, a permissions flag, a dependency version). Running the tutorial yourself catches what no review pass will.
For runbooks, capture institutional knowledge from on-call engineers in 15-minute interviews, then let Claude turn the transcript into structure. The unstructured tribal knowledge is the value. Claude's contribution is the structure: alert summary, symptoms, triage, investigation, mitigation, post-incident. The combined workflow compresses 100-alert runbook coverage from months to weeks.
Claude Technical Writing Prompt Library (Copy-Paste)
25 production-tested prompts organized by doc task. Replace bracketed variables with your specifics. Always run prompts inside a Claude Project with your product context and style guide loaded for ground-truth accuracy.
Project setup and context loading
'I am setting up a Claude Project for technical writing on [Product Name], a [1-line description]. Generate a context-loading checklist: which files to upload (README, OpenAPI spec, architecture overview, exemplar pages, style guide, glossary, release notes, top-20 reader questions), how to structure each file, and what coverage gaps would block useful doc work. Format as a checklist I can use to validate the Project is complete before writing.'
'Style guide in shared Project. Build a starter style-guide.md template covering: voice and tone, terminology with preferred terms and disallowed synonyms, sentence-length guidance, callout patterns, code-sample conventions, frontmatter schema, and a forbidden-phrases list. Output as markdown I can paste into a new file and refine over the next 3-4 weeks.'
API reference from OpenAPI or GraphQL
'Schema in Project. For each endpoint in openapi.yaml under /v1/customers/*: (1) 2-sentence description beyond restating the path, (2) request body and query params with realistic example values (not foo and bar), (3) response body with fully-populated example, (4) every error code with 1-line explanation of when it fires, (5) curl example with API key placeholder, (6) SDK example in TypeScript and Python. Format as one markdown page per endpoint with frontmatter title and slug. Output the customer-create endpoint first so I can review tone.'
'Schema in Project. Generate the GraphQL schema reference page for the [TypeName] type. Include: the full type definition, descriptions for every field (1 line each), example values that look like real product data, the queries and mutations that return or accept this type, and 2 working query examples that exercise the most common reader use cases. Format as markdown with code blocks tagged graphql. Lead with a 1-paragraph plain-language description before the schema.'
Tutorials and how-to guides
'Schema and style guide in Project. Tutorial outcome: a junior backend engineer deploys a working webhook receiver for our [Event Name] event in under 10 minutes. Persona: knows Node 20, has not used our product before. Prerequisites: Node 20+, free [Product] account, ngrok. Anti-goals: do not cover signature verification (separate tutorial), do not link out mid-stream. Draft 6-10 numbered steps. Each step has heading, 1-paragraph explanation, code block in TypeScript, expected output, and 1-line check the reader runs to confirm. End with Next steps section listing 2-3 follow-up tutorials.'
'Schema and style guide in Project. How-to outcome: an existing customer migrates from API v1 to v2 in under 30 minutes. Persona: backend engineer, has shipped against v1 for 6+ months. Prerequisites: existing v1 integration, ability to run database migrations, staging environment. Cover: breaking changes in request and response shapes (with before/after code blocks), the dual-write pattern for zero-downtime migration, the rollback procedure if v2 is buggy in production, the cutover checklist. Format as a how-to with numbered steps and migration checkpoints.'
Conceptual guides and architecture docs
'Schema and style guide in Project. Topic: how [Product] handles webhook delivery (retry policy, ordering guarantees, idempotency, security). Persona: senior backend engineer evaluating whether to integrate. Length: 1500-2000 words. Structure: 1-paragraph TLDR, then sections on delivery model, retry behavior with exact backoff schedule, ordering guarantees, idempotency keys, signature verification, and a final section on production readiness checklist. Use diagrams in mermaid syntax for the retry timeline and the signature verification flow. Lead with the question the reader is actually trying to answer ("can I trust this for production?") not the feature name.'
'Schema in Project. Architecture overview for [Component Name]. Audience: a new engineer joining the team in week 1. Length: 1000-1500 words. Sections: 1-paragraph summary, where this component sits in the system (with mermaid diagram), responsibilities, dependencies (upstream and downstream), data shapes flowing through, the 3 most common operational issues and how to debug them, and a starter reading list of 5 source files to read in order to understand the implementation.'
Release notes and changelogs
'Style guide in Project. Below is the merged PR list for the [v2.18.0] release window: [paste PR title, description, labels per PR]. (1) Group by impact: New features, Improvements, Bug fixes, Breaking changes. Drop any PR with the internal label. (2) For each, write 1-2 sentence user-facing description in our voice. (3) Rank inside each group: customer-requested first, high-traffic-affected second, niche third. (4) For Breaking changes, add Migration section with before/after code blocks and exact upgrade steps. (5) Add 1-paragraph release summary at the top suitable for the email announcement. Output as markdown ready to paste into our changelog page.'
'Style guide in Project. Convert this terse internal changelog entry into a customer-facing release note: [paste internal entry]. Keep the technical accuracy, drop the internal references (PR numbers, ticket IDs, internal team names), add the user-facing why, and end with a 1-line callout if the change requires reader action. Length: 60-100 words.'
Runbooks and on-call docs
'Schema and style guide in Project. Build a runbook for the [Alert Name] alert. Historical incidents: [paste 3-5 past incident summaries with date, severity, root cause, resolution time, what worked, what did not]. Relevant dashboards: [list URLs]. Relevant log queries: [paste 2-3 most useful]. Rollback procedure: [describe]. Generate sections: alert summary, symptoms a responder will see, immediate triage steps in numbered order with exact commands or dashboard links, root-cause investigation steps if triage does not resolve, mitigation options ranked by reversibility, post-incident actions (postmortem trigger, customer comms, monitoring updates), contacts. Mark unresolved details as TODO.'
'Style guide in Project. Below is a 15-minute interview transcript with an on-call engineer about how they handle [Alert Name]: [paste]. Convert this to a runbook in our standard structure (alert summary, symptoms, triage, investigation, mitigation, post-incident, contacts). Preserve the engineer\'s specific commands and dashboard URLs verbatim. Mark anything ambiguous or contradicted as TODO for follow-up. Output as markdown ready for a docs review pass.'
Doc reviews and audits
'Schema, style guide, and source-of-truth in Project. Page under review: [paste full page]. Persona: [persona]. Flag (do not rewrite) the following classes of issue: (1) Sentences that contradict the source-of-truth (cite file and line). (2) Jargon replaceable with plain language without losing precision (suggest replacement). (3) Information a [persona]-level reader would need that is missing or assumed. (4) Structural issues: assumed knowledge breaking the progression, dead-end sections, callouts placed where reader has lost context. (5) Voice drift from style guide (cite the rule). Output as a numbered list with severity (P0/P1/P2), location, issue, suggested fix.'
'Style guide in Project. Audit our docs site at [URL or paste sitemap]. Identify the 10 highest-impact gaps: pages that should exist but do not, pages that overlap and should be consolidated, pages that are too long for their persona and should be split, and missing index or hub pages. Rank by estimated reader impact. Output as a 10-row table with: gap description, current state, proposed fix, persona affected, estimated reader impact (high/medium/low).'
Information architecture and reorgs
'Style guide in Project. Below is our full table of contents for [Product] docs: [paste]. Reader personas and their top questions: [paste]. Propose a top-level navigation structure (max 7 categories, 3 levels deep). Identify pages that overlap or duplicate, recommend pages to consolidate or split, and surface the 5 highest-impact gaps. Output: proposed sitemap as a nested markdown list, plus a separate list of consolidation recommendations and gap proposals. Verify before committing by running usability tests on the new structure.'
'Style guide in Project. Build a content matrix for our [Product Area] docs. Rows: doc types (concept, tutorial, how-to, reference, runbook). Columns: the 5 user personas. Each cell: which specific pages already exist (cite URLs), which are gaps to fill, which are duplicate coverage to consolidate. Use the matrix to prioritize the next quarter of doc work. Output as a markdown table.'
Code samples and SDK examples
'Schema and style guide in Project. Generate code samples for the [Endpoint Name] endpoint in TypeScript, Python, Go, and curl. Each sample: matches our SDK conventions (async, typed, error-handled), uses realistic placeholder values, includes the imports or setup needed, shows handling for the 2-3 most common error cases. Length per sample: 30-60 lines. Add 1-line comments explaining non-obvious decisions. Output as one markdown page with tabbed code blocks per language.'
'Schema in Project. Below is a 500-line module from our codebase: [paste]. Generate a plain-English description (300-500 words) of what this module does and why, suitable for the architecture overview. Stay grounded in what the code actually does (do not invent functions or behaviors). Cover: purpose, key functions and their responsibilities, data shapes flowing through, dependencies, and the 2-3 places where future maintainers should be careful. End with a Reading order section listing related files in the order a new engineer should read them.'
Want more Claude prompts for technical workflows? See our how to use Claude (full guide), Claude for coding, Claude for research, Claude for writing, and Claude for SQL queries. For comparable doc workflows on other tools, see Microsoft Copilot in Word and ChatGPT for content creation.
Frequently Asked Questions
Related Guides
How to Use Claude (full guide)/how-to-use-claudeHow to Use Claude for Coding/how-to-use-claude-for-codingHow to Use Claude for Research/how-to-use-claude-for-researchHow to Use Claude for Writing/how-to-use-claude-for-writingHow to Use Claude for SQL Queries/how-to-use-claude-for-sql-queriesHow to Use Microsoft Copilot in Word/how-to-use-microsoft-copilot-in-word