50 Claude Prompts That Write Technical Documentation

You are an API documentation specialist who writes precise endpoint references. <context> I need full reference documentation for one API endpoint, complete enough that a developer can integrate without asking us anything. </context> <inputs> - Method and path: [E.G. POST /v1/invoices] - What it does and when to use it: [DESCRIBE] - Auth requirement and scopes: [DETAILS] - Request parameters: [PATH, QUERY, BODY FIELDS WITH TYPES AND REQUIREDNESS] - Success response: [PASTE REAL JSON] - Error responses: [STATUS CODES AND MEANINGS] - Rate limits, idempotency, pagination behavior: [DETAILS] </inputs> <task> Write the endpoint reference: a one-line summary, when to use it and when to use a different endpoint instead, auth and scope requirements, a parameters table (name, type, in, required, default, constraints, description), a request example in curl plus one language SDK, the full success response with every field described, an error table with status, code, message, and how to recover, and notes on idempotency, pagination, and rate limits. </task> <constraints> - Every field gets a type, a requiredness marker, and a description with a real example value. - Describe error recovery, not just error meaning. - Do not invent fields that are absent from the JSON I pasted; list them as unknown instead. </constraints> <format> Return the reference as a markdown artifact with parameter, response-field, and error tables plus fenced examples. Then output the same endpoint as an OpenAPI 3.1 fragment. </format>

You are a technical writer who documents command line tools the way engineers actually read them. <context> Our CLI help text is terse and there is no reference page. I need documentation for one command and all of its flags. </context> <inputs> - Command: [E.G. mytool deploy] - What it does: [DESCRIBE] - Synopsis and arguments: [PASTE USAGE LINE] - Flags: [NAME, SHORT FORM, TYPE, DEFAULT, WHAT IT DOES] - Environment variables that affect it: [LIST] - Exit codes: [CODE AND MEANING] - Realistic use cases: [2 TO 4 SCENARIOS] </inputs> <task> Write the command reference: synopsis line, a one-paragraph description, an arguments table, a flags table (flag, short, type, default, description), environment variable overrides and their precedence order, an exit code table, then a set of worked examples where each shows the command, the situation it fits, and the output. Add a "related commands" line and a gotchas section for destructive or irreversible behavior. </task> <constraints> - State precedence explicitly when flags, env vars, and config files can all set the same value. - Mark destructive flags clearly and say what cannot be undone. - Examples must be copy-paste runnable, not illustrative fragments. </constraints> <format> Return the reference as a markdown artifact with tables for arguments, flags, and exit codes, plus worked examples. Then propose the improved short help text for the command. </format>

You are an infrastructure documentation writer who documents configuration surfaces. <context> Our service reads configuration from a file and from environment variables, and nobody outside the original team knows what is safe to change. </context> <inputs> - Service name and role: [DESCRIBE] - Config file format and location: [E.G. YAML AT /etc/app/config.yaml] - Settings: [KEY, TYPE, DEFAULT, WHAT IT CONTROLS] - Environment variable equivalents: [NAMING PATTERN] - Settings that require a restart: [LIST] - Secrets among these settings: [LIST] </inputs> <task> Write a configuration reference: how configuration is loaded and in what precedence order, a full settings table (key, env var, type, default, required, restart needed, description), grouped by concern such as networking, storage, auth, and observability, a minimal working config example, a production-hardened config example with commentary, and a section on which settings are secrets and how they should be supplied. </task> <constraints> - Never show real secret values; use clearly fake placeholders. - Mark every setting that takes effect only after a restart or reload. - Include valid ranges or allowed enum values, not just types. </constraints> <format> Return the reference as a markdown artifact with grouped settings tables and two annotated config examples. Then list settings whose default you would change for production and why. </format>

You are an API writer who specializes in error documentation that reduces support load. <context> Our errors return a code and a terse message, and integrators open tickets because they cannot tell whether to retry, fix their request, or call us. </context> <inputs> - Product or API: [NAME] - Error list: [CODE, HTTP STATUS, MESSAGE TEXT] - What triggers each: [CAUSE] - Whether each is retryable: [YES OR NO, WITH BACKOFF ADVICE] - Errors that indicate a problem on our side: [LIST] - Where error details appear: [RESPONSE BODY SHAPE, LOG FIELDS] </inputs> <task> Write an error reference: the error object shape with every field explained, a master table (code, HTTP status, meaning, retryable, first action), then one section per error with the literal message, the cause, the fix from the integrator's side, whether to retry and how, and what to send us if it persists. Add a short decision guide: given an error, how to tell in one step whether it is a client, network, or platform problem. </task> <constraints> - Retry guidance must be explicit, including backoff strategy and whether the request is safe to repeat. - Use the exact message strings so they are searchable. - Distinguish errors the caller can fix from errors only we can fix. </constraints> <format> Return the reference as a markdown artifact with the master table plus per-error sections. Then list any error where retry safety was unclear from my inputs. </format>

You are a technical writer who follows task-based documentation principles. <context> Our docs describe features. Users search for tasks. I need one page that answers a single "how do I" question completely. </context> <inputs> - The exact task: [E.G. HOW DO I ROTATE AN API KEY WITHOUT DOWNTIME] - Who performs it and what access they need: [ROLE AND PERMISSIONS] - Preconditions: [WHAT MUST BE TRUE FIRST] - Steps as I know them: [ROUGH LIST, UI OR CLI OR API] - What can go wrong mid-task: [FAILURE POINTS] - How the user confirms success: [SIGNAL] </inputs> <task> Write a task-based how-to: a title phrased as the user's task, a one-line statement of the outcome and the time it takes, required permissions, preconditions as a checklist, numbered steps with one action each and the interface named for every action, inline warnings placed immediately before the risky step, a verification section, and a rollback section if the task can be undone. End with two related tasks. </task> <constraints> - No feature tour and no background theory; link out for concepts instead. - Warnings appear before the dangerous step, never after it. - Each step names where the action happens (which screen, which command, which endpoint). </constraints> <format> Return the how-to as a markdown artifact with a preconditions checklist, numbered steps, and verification. Then suggest the search phrases this page should rank for. </format>

You are an integrations documentation writer who specializes in event-driven APIs. <context> We send webhooks and integrators are guessing about payload shape, ordering, retries, and signature verification. </context> <inputs> - Event types we send: [LIST WITH WHEN EACH FIRES] - Payload example for each: [PASTE JSON] - Delivery guarantees: [AT LEAST ONCE, ORDERING, DEDUPE KEY] - Retry policy: [SCHEDULE AND CUTOFF] - Signature scheme: [HEADER, ALGORITHM, SECRET SOURCE] - Expected receiver behavior: [STATUS CODE, TIMEOUT BUDGET] </inputs> <task> Write a webhook reference: how delivery works end to end, the common envelope fields, a table of event types with trigger conditions and payload links, one section per event with the trigger, the full payload with field descriptions, and the typical handling logic. Then document signature verification with a working code example, the retry schedule, idempotency and deduplication guidance, ordering caveats, and a local testing recipe. </task> <constraints> - Include a runnable signature verification snippet in one language. - State explicitly that duplicates are possible and show how to dedupe. - Do not promise ordering guarantees that my inputs do not support. </constraints> <format> Return the reference as a markdown artifact with an event table, per-event payload sections, and code blocks. Then give a testing checklist an integrator can run before going live. </format>

You are a senior engineer who writes documentation comments that survive code review. <context> I have source code with missing or useless docstrings. I want proper docstrings that generated API docs can consume. </context> <inputs> - Language and docstring convention: [E.G. PYTHON GOOGLE STYLE, TYPESCRIPT TSDOC, JAVA JAVADOC] - Source code: [PASTE THE FUNCTIONS OR CLASS] - Non-obvious behavior a reader would miss: [SIDE EFFECTS, MUTATIONS, BLOCKING CALLS] - Errors raised and when: [LIST] - Thread-safety or concurrency notes: [IF ANY] </inputs> <task> For each function, method, and class, write a docstring containing: a one-line summary in the imperative mood, a longer description only when behavior is non-obvious, every parameter with type and meaning, the return value with type and meaning, every raised error with its trigger condition, side effects and mutations called out explicitly, and one short usage example for anything a caller could reasonably misuse. Keep the exact convention I named. </task> <constraints> - Describe behavior visible to a caller; do not narrate the implementation line by line. - Never restate the function name as its description. - Flag any parameter whose purpose you cannot infer instead of guessing. </constraints> <format> Return the full source code with docstrings inserted, as a code artifact. Then list the behaviors you flagged as unclear and the functions whose signature you think should change. </format>

You are a security-minded API writer who documents authentication flows. <context> Integrators get stuck on our auth model, and some of them are storing keys in ways that will eventually leak. </context> <inputs> - Auth methods supported: [E.G. API KEY, OAUTH 2.0, JWT, MTLS] - How to obtain credentials: [EXACT STEPS AND SCREEN OR ENDPOINT] - Scopes or permission model: [LIST] - Token lifetime and refresh behavior: [DETAILS] - Where credentials go in a request: [HEADER OR PARAM, EXACT FORMAT] - Rotation and revocation process: [STEPS] </inputs> <task> Write an authentication guide: which method to choose for which use case, how to create credentials step by step, a scopes table with the least-privilege recommendation per use case, an authenticated request example in curl and one SDK, token lifetime and refresh flow described as a sequence, secure storage guidance for server, client, and CI contexts, rotation without downtime, revocation and incident response, plus a table of auth failure responses and their causes. </task> <constraints> - Recommend least privilege by default and name the specific scopes for each use case. - Explicitly warn against embedding secrets in client-side code or repositories. - Use obviously fake placeholder credentials everywhere. </constraints> <format> Return the guide as a markdown artifact with a scopes table, code examples, and an auth error table. Then add a mermaid sequence diagram of the token refresh flow. </format>

You are a technical writer who specializes in upgrade and migration documentation. <context> We are releasing a new major version with breaking changes and I need a migration guide that gets existing users across without support tickets. </context> <inputs> - Old and new versions: [E.G. 2.x TO 3.0] - Breaking changes: [LIST EACH WITH OLD BEHAVIOR AND NEW BEHAVIOR] - Renamed or removed APIs: [OLD NAME TO NEW NAME OR REPLACEMENT] - New requirements: [RUNTIME, DEPENDENCY, CONFIG] - Automated migration tooling: [CODEMOD OR SCRIPT IF ANY] - Support window for the old version: [DATES] </inputs> <task> Write a migration guide: who needs to migrate and who does not, the support timeline, an effort estimate by integration type, a pre-migration checklist, then step-by-step migration in dependency order with before-and-after code for every breaking change, a rename mapping table, how to run the automated tooling if it exists, how to verify the migration with tests, and a rollback plan. End with a FAQ of the questions this change will trigger. </task> <constraints> - Every breaking change needs before code and after code, not prose alone. - Order steps so the codebase stays runnable between steps where possible. - State clearly what happens to users who do nothing. </constraints> <format> Return the guide as a markdown artifact with a rename mapping table, paired code blocks, and a verification checklist. Then produce a short in-product upgrade notice. </format>

You are a staff engineer who writes architecture documentation for people joining a codebase. <context> Our system has grown organically and only two people understand how the pieces fit. I need an architecture overview that gets a new engineer productive. </context> <inputs> - Services and components: [LIST WITH RESPONSIBILITY OF EACH] - Data stores and what lives where: [LIST] - How components communicate: [SYNC HTTP, QUEUES, EVENTS] - The main request path end to end: [DESCRIBE ONE FLOW] - Known weak points and tech debt: [LIST] - Deployment topology: [ENVIRONMENTS, REGIONS, SCALING UNITS] </inputs> <task> Write an architecture overview: a one-paragraph summary a new hire can repeat, a component table (name, responsibility, owner, language, data it owns), the communication map, a walkthrough of one full request from entry to response naming every hop, where state lives and what the source of truth is for each entity, failure modes and what degrades when each component is down, deployment topology, and an honest known-limitations section. </task> <constraints> - Name one source of truth per data entity; flag any entity with two. - Describe failure behavior per component, not just the happy path. - Keep it current-state only; put wished-for architecture in a separate section. </constraints> <format> Return the overview as a markdown artifact with a component table and a mermaid diagram of the request path. Then list the questions you would ask the two people who know the system. </format>

You are a release manager who turns engineering output into customer-readable release notes. <context> I have a list of merged pull requests and commit messages for this release and I need release notes written for the people who use the product, not for the people who built it. </context> <inputs> - Product and version: [NAME AND VERSION] - Release date: [DATE] - Merged PR titles and descriptions: [PASTE THE LIST] - Audience: [END USERS, DEVELOPERS, ADMINS] - Anything that requires user action: [FLAG IT] - Items to exclude: [INTERNAL REFACTORS, TEST CHANGES] </inputs> <task> Group the changes into New, Improved, Fixed, and Action Required. Rewrite each item from the user's point of view: what they can now do, or what stopped being broken, in one sentence starting with a verb. Drop internal-only work. Put anything needing user action at the top with the deadline and the exact steps. Open with a two-sentence summary naming the single most valuable change in this release. </task> <constraints> - No internal jargon, ticket numbers, or file names in the user-facing text. - One sentence per item; no marketing adjectives. - If a change has no user-visible effect, exclude it and say so in your notes to me. </constraints> <format> Return the release notes as a markdown artifact with the grouped sections. Then list which PRs you excluded and which ones you could not classify without more detail. </format>

You are a maintainer who keeps a disciplined CHANGELOG.md. <context> I maintain a library and need a changelog entry that follows Keep a Changelog and semantic versioning conventions exactly. </context> <inputs> - Package name and previous version: [NAME AND VERSION] - Changes in this release: [LIST WITH TYPE IF KNOWN] - Breaking changes: [LIST OR NONE] - Deprecations: [LIST OR NONE] - Security fixes: [LIST OR NONE] - Issue and PR references: [NUMBERS] </inputs> <task> Write the changelog entry using the Added, Changed, Deprecated, Removed, Fixed, and Security headings, omitting empty sections. Recommend the next version number and justify it against semantic versioning rules based on the changes given. Each bullet is one line, present tense, describing the change and its consequence, with the issue or PR reference at the end. Flag anything that would force a major bump. </task> <constraints> - Follow Keep a Changelog headings and ordering exactly; no invented sections. - Recommend the version bump and state the rule that forced it. - Keep every bullet to one line. </constraints> <format> Return the entry as a markdown artifact ready to paste at the top of CHANGELOG.md, followed by the recommended version number with its justification and any release blockers you spotted. </format>

You are a developer relations writer who announces breaking changes without losing customer trust. <context> We have to ship a breaking change. I need a notice that tells integrators exactly what breaks, when, and what to do, with no ambiguity. </context> <inputs> - What is changing: [OLD BEHAVIOR TO NEW BEHAVIOR] - Why we are doing it: [REAL REASON] - Who is affected: [WHICH INTEGRATIONS, HOW MANY IF KNOWN] - Effective date and any grace period: [DATES] - Required action: [EXACT STEPS] - How to check if you are affected: [DETECTION METHOD] </inputs> <task> Write the notice: a headline stating what breaks and when, a one-line summary of the required action, a "check if this affects you" section with a concrete test the reader can run in under a minute, before and after code, the full timeline with dates for announcement, deprecation, and enforcement, the migration steps, what happens if they miss the deadline, the honest reason for the change, and where to get help. </task> <constraints> - Lead with impact and deadline, not with the rationale. - Give a self-check the reader can run rather than asking them to audit their code. - No softening language that hides the fact that something will stop working. </constraints> <format> Return the notice as a markdown artifact, then produce three shortened variants: an email subject line plus 80 word body, an in-app banner under 120 characters, and a changelog line. </format>

You are an API lifecycle writer who documents deprecations that people actually act on. <context> We are deprecating a feature or endpoint and need a notice that stays accurate for the entire deprecation window. </context> <inputs> - What is being deprecated: [FEATURE OR ENDPOINT] - Replacement: [WHAT TO USE INSTEAD, OR NONE] - Reason: [WHY] - Deprecation date and end-of-life date: [DATES] - Behavior during the window: [STILL WORKS, WARNS, RATE LIMITED] - Signals we will send: [DEPRECATION HEADER, EMAIL, DASHBOARD WARNING] </inputs> <task> Write a deprecation notice: what is deprecated and the end-of-life date in the first sentence, current status and what still works today, the replacement with a side by side mapping of old to new including code, a dated timeline table of every phase and what changes at each, how the reader will be warned, how to migrate in numbered steps, and what happens on the end-of-life date. If there is no replacement, say so plainly and explain the alternative path. </task> <constraints> - Distinguish deprecated (still works) from removed (does not work) throughout. - Use absolute dates, never relative ones like "in six months". - If no replacement exists, do not imply one does. </constraints> <format> Return the notice as a markdown artifact with the phase timeline table and old-to-new mapping. Then draft the deprecation warning text for the API response header and the dashboard banner. </format>

You are a product marketing writer who publishes a monthly product update for existing customers. <context> Every month we ship a mix of features, improvements, and fixes across several areas, and I need one readable update that makes customers try the new things. </context> <inputs> - Month and product: [PERIOD AND NAME] - Shipped items: [LIST WITH SHORT DESCRIPTIONS] - The one item we most want adopted: [PICK ONE] - Customer segments and what each cares about: [LIST] - Metrics or usage numbers we can share: [OPTIONAL] - Coming next month: [TEASER ITEMS] </inputs> <task> Write the monthly roundup: a headline naming the month's biggest win, a two-sentence intro, a lead section on the flagship item covering what it does, who it helps, and how to turn it on in two steps, then grouped shorter sections for the rest with one line each on the benefit and a link cue, a "small but nice" list of minor improvements and fixes, a what-is-coming teaser, and a closing invitation for feedback. </task> <constraints> - Every item states a user benefit, never a feature name alone. - The flagship item gets an activation path in two steps or fewer. - No superlatives; specifics only. </constraints> <format> Return the roundup as a markdown artifact. Then give me an email subject line, a preview text line, and a three-bullet in-app version of the same update. </format>

You are a product content designer who writes in-product release messaging. <context> Our app has a what-is-new panel with very little room. I need copy that gets a user from noticing a change to using it inside the product. </context> <inputs> - Feature or change: [WHAT SHIPPED] - Where it lives in the UI: [EXACT LOCATION OR MENU PATH] - Who it is for: [USER ROLE OR SEGMENT] - The one action we want: [E.G. OPEN SETTINGS, TRY THE NEW VIEW] - Character limits: [TITLE AND BODY LIMITS] - Anything that changed visually: [DESCRIBE] </inputs> <task> Write the panel entry: a title under the character limit that names the outcome, a body of two sentences saying what changed and where to find it, a button label that is a verb plus object, and an optional one-line note if existing behavior moved. Then write two alternates for the title and body at different tones, one plain and one warmer, so I can pick. </task> <constraints> - Respect the character limits exactly and state the count for each line. - Name the UI location precisely so nobody has to hunt for it. - Button labels never say "Learn more" when the user can act right now. </constraints> <format> Return a markdown artifact with a table of title, body, button label, and character counts for the primary version plus both alternates. Then note the one change that most needs a tooltip instead of a panel entry. </format>

You are a product manager writing the documentation that ships alongside a beta program. <context> We are opening a beta and need one page that sets expectations so testers give useful feedback instead of filing bugs about known gaps. </context> <inputs> - Feature in beta: [NAME AND WHAT IT DOES] - Beta stage: [PRIVATE, PUBLIC, OPT-IN] - What works and what does not yet: [BOTH LISTS] - Known limitations and rough edges: [LIST] - How to join and how to leave: [STEPS] - Feedback channel and what we want feedback on: [DETAILS] - Data, stability, and support expectations: [DETAILS] </inputs> <task> Write the beta doc: what the beta is and who should join, an explicit works-today versus not-yet table, known limitations stated plainly, how to enable it and how to turn it off, the support and stability expectations including whether data can be lost, the specific questions we want feedback on, how to send feedback, and the criteria and rough timing for general availability. </task> <constraints> - Be blunt about limitations; understating them produces noisy bug reports. - State whether beta data carries over to general availability. - Name the exact feedback we want, not "any thoughts welcome". </constraints> <format> Return the doc as a markdown artifact with the works-today versus not-yet table. Then write the invitation message for the beta signup and the in-product beta badge tooltip. </format>

You are an incident communications writer producing the note that ships with an urgent patch. <context> We just shipped a hotfix for a bug that affected customers and I need a short, factual patch note that does not create new questions. </context> <inputs> - Version shipped and time: [VERSION AND TIMESTAMP WITH TIMEZONE] - The bug and its user-visible symptom: [DESCRIBE] - Who and what was affected: [SCOPE, DURATION, DATA IMPACT] - Root cause in one sentence: [CAUSE] - The fix: [WHAT CHANGED] - Action required from users: [UPGRADE STEPS OR NONE] </inputs> <task> Write a hotfix note: version and release time, the symptom as customers experienced it, the affected scope and window, whether any data was lost or corrupted and the current state of that data, the root cause in one sentence, what the fix does, the required user action with exact upgrade commands or a statement that none is needed, and how to verify the fix took effect. </task> <constraints> - State data impact explicitly, including when the answer is none. - Facts only; no apology paragraph and no blame. - If the root cause is still under investigation, say that instead of speculating. </constraints> <format> Return the patch note as a markdown artifact. Then produce a status page update under 400 characters and a one-line entry for the changelog. </format>

You are a technical writer and developer advocate announcing a major version to a developer audience. <context> We are shipping a major version and I need a launch post that explains the thinking, shows the code, and points people to the migration path. </context> <inputs> - Product and version: [NAME AND VERSION] - The theme of this release: [ONE IDEA] - Headline changes: [LIST WITH TECHNICAL DETAIL] - Performance or reliability numbers: [BEFORE AND AFTER IF ANY] - Breaking changes and migration effort: [SUMMARY] - Who contributed: [TEAM, COMMUNITY CONTRIBUTORS] </inputs> <task> Write the release post: an opening that states what is now possible that was not before, a short "why we rebuilt this" section with the real constraint that forced the change, one section per headline change with a before and after code comparison and the benefit stated concretely, any measured improvement with the method behind the number, an honest section on breaking changes with a link cue to the migration guide, upgrade instructions, thanks to contributors, and what is next. </task> <constraints> - Every claimed improvement gets a number or a code comparison; no unsupported adjectives. - Explain measurement method for any benchmark you cite. - Do not bury breaking changes below the fold. </constraints> <format> Return the post as a markdown artifact with code comparisons. Then propose three title options and a 280 character summary for social. </format>

You are a security communications writer who publishes advisories for a software product. <context> We fixed a security issue and I need an advisory that gives users what they need to assess and act, without giving attackers a recipe. </context> <inputs> - Affected component and versions: [DETAILS] - Fixed version: [VERSION] - Vulnerability class: [E.G. AUTHORIZATION BYPASS, XSS, SSRF] - Severity and CVSS if assigned: [SCORE AND VECTOR] - Preconditions for exploitation: [WHAT AN ATTACKER NEEDS] - Evidence of exploitation: [NONE OBSERVED, OR DETAILS] - Workaround if upgrade is not possible: [DETAILS] - Reporter credit: [NAME OR ANONYMOUS] </inputs> <task> Write the advisory: a summary paragraph, an affected versions table with the fixed version, the impact in terms of what an attacker could achieve, severity with the CVSS vector, preconditions for exploitation, whether exploitation has been observed, how a user can check their own exposure, the upgrade instructions, the workaround for users who cannot upgrade immediately, an indicators-of-compromise section, the disclosure timeline, and reporter credit. </task> <constraints> - Describe impact and detection; do not publish exploitation steps or proof-of-concept code. - Give a concrete self-assessment method so readers can tell whether they are exposed. - Keep the timeline factual with dates. </constraints> <format> Return the advisory as a markdown artifact with an affected versions table and the disclosure timeline. Then write the notification email to affected customers in under 150 words. </format>

You are a site reliability engineer who writes runbooks that work at three in the morning. <context> I am on call for a service that has no runbook. I need a document a tired engineer with no context can follow under pressure. </context> <inputs> - Service name and what it does: [DESCRIBE] - Dependencies upstream and downstream: [LIST] - Dashboards, logs, and trace links: [URLS OR NAMES] - Alerts that page for this service: [LIST WITH THRESHOLDS] - Common failure modes and their fixes: [LIST] - Safe operations: [RESTART, SCALE, DRAIN, FEATURE FLAG] - Escalation contacts: [ROLES, NOT NAMES] </inputs> <task> Write the runbook: a service summary in three lines, a first-five-minutes triage sequence with the exact checks in order, a table of alerts mapped to first action, one procedure per failure mode with commands and expected output, the safe operations with their blast radius and when each is allowed, what must never be done and why, escalation criteria with timeboxes, and a post-incident checklist. Put the triage sequence at the very top. </task> <constraints> - Every command is copy-paste ready with placeholders clearly marked. - State the blast radius before any destructive action. - Assume the reader does not own this service and has never opened its code. </constraints> <format> Return the runbook as a markdown artifact with the triage sequence first, then the alert-to-action table, then procedures. Then list the information you would need to verify each command against reality. </format>

You are an incident review facilitator who writes blameless postmortems that produce real fixes. <context> We had an incident and I have the raw timeline from chat, alerts, and deploy logs. I need a postmortem the team will actually learn from. </context> <inputs> - Incident summary and severity: [WHAT BROKE AND HOW BAD] - Timeline of events: [PASTE RAW NOTES, ALERTS, MESSAGES WITH TIMESTAMPS] - Customer impact: [WHO, HOW MANY, WHAT THEY EXPERIENCED, DURATION] - Detection: [HOW WE FOUND OUT AND HOW LONG IT TOOK] - Contributing factors as we understand them: [LIST] - What made recovery slow: [LIST] </inputs> <task> Write the postmortem: a summary any executive can read in 30 seconds, impact with numbers, a clean timeline table (time, event, who or what observed it, source), detection and response analysis with time to detect, time to mitigate, and time to resolve, contributing factors organized as trigger, amplifiers, and missing defenses, what went well, what was luck rather than design, and action items each with a specific owner role, a due window, and the class of failure it prevents. </task> <constraints> - Never attribute cause to a person; describe systems, defaults, and missing guardrails. - Separate what we know from what we believe. - Every action item must reduce recurrence, detection time, or recovery time, and say which. </constraints> <format> Return the postmortem as a markdown artifact with the timeline table and an action item table (action, category, owner role, due window). Then list the unanswered questions the review meeting should resolve. </format>

You are a monitoring specialist who documents alerts so that each page has an obvious next step. <context> One of our alerts fires regularly and nobody knows exactly what to do with it, so it gets acknowledged and ignored. </context> <inputs> - Alert name and the condition that fires it: [EXACT RULE AND THRESHOLD] - What it actually indicates: [UNDERLYING PROBLEM] - Severity and whether it should page or ticket: [CURRENT AND YOUR VIEW] - Diagnostic queries or dashboards: [LINKS OR QUERIES] - Known causes ranked by frequency: [LIST] - Mitigations for each cause: [STEPS] - What a false positive looks like: [DESCRIBE] </inputs> <task> Write the alert playbook: the alert definition in plain language, why we care stated as user impact, a decision tree from the alert to the likely cause using the diagnostic queries, one mitigation procedure per cause with commands and verification, how to recognize and handle a false positive, when to escalate and to whom by role, and a tuning section recommending threshold or grouping changes if this alert is noisy. </task> <constraints> - Start from what the responder sees in the alert, not from the system internals. - Every branch of the decision tree ends in an action, never in "investigate further". - Include the exact query text, not a description of the query. </constraints> <format> Return the playbook as a markdown artifact with a decision tree in mermaid, per-cause procedures, and an escalation table. Then state whether this alert should page a human at all, with your reasoning. </format>

You are a release engineer who documents deployment procedures for people who did not build the pipeline. <context> Deploys depend on tribal knowledge. I need a runbook covering the normal deploy and, more importantly, how to get back to safety fast. </context> <inputs> - Service and deployment target: [E.G. KUBERNETES, ECS, VM FLEET] - Pipeline stages: [DESCRIBE] - Deploy command or trigger: [EXACT] - Health checks and success signals: [WHAT TO WATCH AND FOR HOW LONG] - Rollback mechanism: [EXACT COMMAND OR PROCESS] - Migration or stateful concerns: [DATABASE CHANGES, CACHES, QUEUES] - Deploy freeze rules: [WHEN NOT TO DEPLOY] </inputs> <task> Write the runbook: pre-deploy checklist, the deploy procedure step by step with the exact commands and what to watch after each, the definition of a healthy deploy with metrics and observation window, abort criteria stated as thresholds, the rollback procedure with its own verification, how to handle a rollback when a database migration has already run, communication steps and who to notify at each stage, and the freeze rules. </task> <constraints> - Abort criteria must be numeric thresholds, not judgement calls. - Cover the irreversible case: rollback after a schema change. - Every command shows the expected healthy output. </constraints> <format> Return the runbook as a markdown artifact with checklists, commands, and an abort criteria table. Then list the parts of this process that should be automated first, ranked by risk removed. </format>

You are a reliability engineer who writes disaster recovery documentation that survives an audit and a real outage. <context> We have backups but no tested recovery procedure. I need a document that explains exactly how to restore service after a serious loss. </context> <inputs> - Systems in scope: [LIST] - Backup strategy: [WHAT IS BACKED UP, HOW OFTEN, WHERE, RETENTION] - Recovery targets: [RTO AND RPO PER SYSTEM] - Failover capability: [MULTI REGION, STANDBY, NONE] - Restore commands or tooling: [DETAILS] - Dependencies that must come back in order: [SEQUENCE] - Who can authorize a failover: [ROLE] </inputs> <task> Write the disaster recovery procedure: scenarios covered (region loss, data corruption, accidental deletion, credential compromise), the declaration criteria and who authorizes recovery, a recovery sequence with dependency order and estimated time per step, restore commands with verification for each system, data loss assessment after restore and how to quantify it, how to communicate to customers during recovery, and a post-recovery validation checklist. State RTO and RPO per system and whether the procedure meets them. </task> <constraints> - Include the point where you must decide between faster recovery and less data loss. - Every restore step ends in a verification that proves the data is usable, not just present. - Be explicit where the current setup cannot meet the stated targets. </constraints> <format> Return the procedure as a markdown artifact with a scenario table, ordered recovery steps, and an RTO and RPO table. Then list the gaps between our stated targets and what this procedure can actually deliver. </format>

You are a platform engineer building a service catalog that answers "who owns this and how does it work". <context> When something breaks, we waste time finding the owner and the context. I want a standard ownership entry for each service. </context> <inputs> - Service name and purpose: [DESCRIBE] - Owning team and on-call rotation: [TEAM AND ROTATION NAME] - Tier or criticality: [E.G. TIER 1] - Repositories, dashboards, runbooks, and alerts: [LINKS] - Dependencies and consumers: [LISTS] - SLOs and current error budget policy: [DETAILS] - Data classification handled: [E.G. PII, PAYMENT DATA] - Operational quirks a newcomer must know: [LIST] </inputs> <task> Write the catalog entry: a one-paragraph description of what breaks for users if this service is down, an ownership block (team, rotation, escalation path by role, business hours coverage), a criticality and SLO block with the error budget policy, a links block for repo, dashboards, runbook, alerts, and logs, dependency and consumer tables including what degrades in each direction, data handled with its classification and retention, and a quirks section listing the non-obvious operational behavior. </task> <constraints> - Reference roles and rotations rather than individual names so the entry does not rot. - State user-visible consequence of downtime, not just technical function. - Keep the whole entry scannable in under two minutes. </constraints> <format> Return the entry as a markdown artifact with the blocks and tables described, plus a YAML version of the same metadata for a machine-readable catalog. Then list the fields I left empty that matter most. </format>

You are an incident management lead who writes severity and escalation policy that removes hesitation. <context> Our team argues about severity during incidents and people hesitate to wake anyone up. I need a policy that makes both decisions mechanical. </context> <inputs> - Products and user types affected by outages: [LIST] - Severity levels we use: [LIST OR PROPOSE] - Examples of past incidents and the severity they deserved: [LIST] - Roles available to escalate to: [E.G. SECONDARY ON-CALL, SERVICE OWNER, INCIDENT COMMANDER, LEADERSHIP] - Communication channels and tooling: [DETAILS] - Business hours and coverage model: [DETAILS] </inputs> <task> Write the policy: a severity table where each level is defined by observable criteria such as users affected, revenue path impacted, data at risk, and workaround availability, with two real examples per level. Then define response expectations per severity (acknowledge time, who joins, comms cadence, whether to wake people), escalation triggers stated as timeboxes, how to escalate in each channel, how and when to change severity mid-incident, and who declares resolution. </task> <constraints> - Severity criteria must be observable during an incident, not knowable only afterwards. - Include an explicit rule that over-escalating is never penalized. - Every escalation trigger has a time limit attached. </constraints> <format> Return the policy as a markdown artifact with the severity table, a response expectations table, and escalation triggers. Then produce a one-page quick reference card version. </format>

You are an incident communications lead writing public status page updates during an active outage. <context> An incident is happening now and I need a sequence of public updates that keeps customers informed without over-promising or leaking internals. </context> <inputs> - What customers are experiencing: [SYMPTOM] - Affected components and regions: [SCOPE] - Current status: [INVESTIGATING, IDENTIFIED, MONITORING, RESOLVED] - What we know and what we do not: [BOTH] - Workaround available: [YES WITH STEPS, OR NONE] - Next update commitment: [INTERVAL] - Start time with timezone: [TIMESTAMP] </inputs> <task> Write the full update sequence: the initial acknowledgement within minutes, an investigating update, an identified update naming impact and the fix in progress, a monitoring update, and a resolved update. Each is under 90 words, states customer impact in customer terms, gives the workaround if one exists, and commits to the next update time. Keep the same terminology across all five so the timeline reads consistently. </task> <constraints> - No internal component names, no speculation about cause, no estimated fix time unless I supplied one. - Every update except the last commits to a next update time. - Impact described from the customer's side, not the system's. </constraints> <format> Return the sequence as a markdown artifact, one block per status with a word count. Then give a short customer support macro that agents can send while this is open. </format>

You are a customer communications writer announcing planned maintenance for a technical product. <context> We have planned maintenance coming and I need a notice that tells customers exactly what to expect and when, so they can plan around it. </context> <inputs> - What we are doing and why: [DESCRIBE] - Window start and end with timezone: [TIMESTAMPS] - Expected impact: [FULL OUTAGE, DEGRADED, READ ONLY, NONE EXPECTED] - Affected features and regions: [LIST] - What customers should do before, during, and after: [ACTIONS] - Rollback plan if it goes badly: [SUMMARY] - How we will communicate during the window: [CHANNEL] </inputs> <task> Write the maintenance notice: a subject line with the date and impact, the window in a primary timezone plus two conversions, exactly what will and will not work during the window, a table of affected features with their expected state, actions customers should take before the window such as pausing jobs or draining queues, what to expect if a request lands mid-maintenance, how to know when it is over, and where updates will appear. </task> <constraints> - Never describe an outage as a brief interruption; give the real expected duration. - Include the behavior of in-flight requests and retries during the window. - Give timezone conversions so nobody miscalculates. </constraints> <format> Return the notice as a markdown artifact with the affected features table. Then produce three variants: an email version, an in-app banner under 140 characters, and a status page scheduled entry. </format>

You are a database reliability engineer who documents schema changes on live systems. <context> We need to run a schema migration on a production database with real traffic, and I want a runbook that makes the risky parts explicit. </context> <inputs> - Database engine and version: [DETAILS] - Table size and traffic profile: [ROWS, WRITES PER SECOND, PEAK HOURS] - The change: [PASTE DDL OR DESCRIBE] - Whether the change is backward compatible: [YES OR NO] - Application deploy coupling: [WHAT CODE MUST SHIP BEFORE OR AFTER] - Tooling available: [E.G. ONLINE SCHEMA CHANGE TOOL, MIGRATION FRAMEWORK] - Maintenance window availability: [YES OR NO] </inputs> <task> Write the migration runbook: a risk assessment naming locking, replication lag, and rollback difficulty for this specific change, the expand and contract sequence broken into phases with the code and schema state at each phase, pre-flight checks including a dry run on a copy, the execution steps with monitoring queries to run during the migration, abort criteria with thresholds for lag and lock wait, the rollback plan per phase and where rollback becomes impossible, and post-migration verification including row counts and query plans. </task> <constraints> - Use an expand and contract sequence so the application stays runnable throughout. - Identify the exact point of no return. - Every phase lists what must already be deployed before it starts. </constraints> <format> Return the runbook as a markdown artifact with a phase table (phase, schema state, code state, rollback possible) plus monitoring queries. Then estimate the duration of each phase given my table size. </format>

You are a documentation lead who writes style guides that contributors actually follow. <context> Several people write our docs and every page reads differently. I need a style guide short enough to be used and specific enough to settle arguments. </context> <inputs> - Product and audience: [DESCRIBE] - Voice we want: [E.G. DIRECT, PEER TO PEER, NO HYPE] - Existing conventions worth keeping: [LIST] - Recurring inconsistencies: [E.G. YOU VS THE USER, TITLE CASE, CODE FORMATTING] - Terminology decisions: [PREFERRED TERM AND BANNED ALTERNATIVES] - Base style reference: [E.G. GOOGLE DEVELOPER STYLE GUIDE, MICROSOFT WRITING STYLE GUIDE] </inputs> <task> Write a style guide covering: voice and person, tense and mood for instructions, heading capitalization, sentence length and structure targets, how to write procedures, how to format code, commands, UI labels, file paths, and placeholders, how to write links, how to handle notes, warnings, and cautions with the specific rule for each, number and date formats, a preferred terms table with banned alternatives, and rules for screenshots. Give a correct and an incorrect example for every rule. </task> <constraints> - Every rule needs a do and a do-not example taken from our domain. - Decide contested cases outright; no "either is acceptable". - Keep it to what a reviewer can check in a pull request. </constraints> <format> Return the style guide as a markdown artifact with a preferred terms table and paired examples. Then give a ten-item reviewer checklist distilled from it. </format>

You are a documentation editor performing a compliance pass against a house style guide. <context> I have a doc page written by an engineer and a style guide. I want the page brought into compliance with the reasoning visible so the author learns the rules. </context> <inputs> - Our style rules: [PASTE THE RULES OR THE GUIDE] - The document to edit: [PASTE FULL TEXT] - Audience and doc type: [E.G. HOW-TO FOR ADMINS] - Rules that are strict versus preferences: [DISTINGUISH] - What must not change: [TECHNICAL FACTS, COMMANDS, VERSION NUMBERS] </inputs> <task> Produce the edited document in full, then a change log table listing each edit with the original text, the revised text, the rule applied, and whether it was a strict violation or a preference. Flag separately any sentence where the style fix would change technical meaning, and any factual claim that looks wrong or unverifiable, without silently correcting it. </task> <constraints> - Never alter commands, code, version numbers, or parameter names. - Preserve the author's technical content; change only expression and structure. - Keep a list of judgement calls where a reasonable editor could disagree. </constraints> <format> Return a markdown artifact with the edited document first, then the change log table, then the flagged items. Do not use track-changes markup inside the document itself. </format>

You are an editor who specializes in plain-language technical writing for mixed audiences. <context> This page is technically accurate but too dense for its readers, some of whom are not engineers. I need it readable without losing precision. </context> <inputs> - The text to rewrite: [PASTE] - Primary audience and their background: [DESCRIBE] - Target reading level: [E.G. GRADE 9] - Terms that must be kept exactly: [PRODUCT NAMES, STANDARDS, PARAMETERS] - Terms that can be simplified or explained: [LIST] - Length constraint: [SAME LENGTH, SHORTER BY X PERCENT] </inputs> <task> Rewrite the text in plain language: shorten sentences to one idea each, prefer active voice, replace abstract nouns with verbs, define any unavoidable jargon on first use in a parenthetical, break dense paragraphs into steps or lists where the content is procedural, and add subheadings so the page can be scanned. Keep every technical fact identical. Then show a short before and after comparison of the three worst sentences with a note on what made each hard. </task> <constraints> - Do not simplify away precision; if a simpler word changes the meaning, keep the precise one and define it. - Keep all required exact terms untouched. - Report the approximate reading level before and after. </constraints> <format> Return a markdown artifact with the rewritten text, the before and after sentence comparison, and the reading level estimates. Then list any place where plain language and precision conflicted and how you resolved it. </format>

You are a terminology manager auditing a documentation set for inconsistent naming. <context> The same thing is called three different names across our docs, product UI, and API, and readers cannot tell whether they are the same thing. </context> <inputs> - Documents or pages to audit: [PASTE TEXT OR LIST WITH CONTENT] - Product UI labels: [LIST] - API and code identifiers: [LIST] - Terms we have already standardized: [PREFERRED TERM LIST] - Terms we know are messy: [LIST] </inputs> <task> Audit the material and produce: a table of every concept that has more than one name, showing each variant, where it appears, and how many times, a recommended single preferred term per concept with the reason, a mapping of variants to the preferred term, a list of cases where two similar names are actually different things and must stay distinct, and a prioritized fix list ordered by how much confusion each inconsistency causes. Include the exact find and replace guidance, noting where a blind replace would be wrong. </task> <constraints> - Align documentation terms with what the UI and API actually call things; flag it when those two disagree. - Never merge two concepts that are genuinely different, even when the names overlap. - Note every place a blind find and replace would break code or quoted output. </constraints> <format> Return a markdown artifact with the variants table, the preferred terms glossary, and the prioritized fix list. Then output the glossary as a machine-readable list I can add to a linter. </format>

You are an information architect who restructures documentation sets. <context> Our docs grew page by page and the navigation now reflects our org chart rather than how people look for answers. </context> <inputs> - Current page list and nav structure: [PASTE TITLES AND HIERARCHY] - Top search queries or support questions: [LIST] - Reader roles and their goals: [LIST] - Analytics signals if available: [MOST AND LEAST VISITED PAGES] - Pages we know are duplicated or stale: [LIST] </inputs> <task> Review the structure and deliver: a diagnosis naming the specific structural problems with evidence from my inputs, a proposed navigation tree organized by reader task and doc type (tutorial, how-to, reference, concept), a page-by-page disposition table (keep, rewrite, merge, split, delete, create) with a reason and a target location for each, a redirect map for anything that moves, and a phased rollout order that keeps the docs usable while the change happens. </task> <constraints> - Every proposed top-level section must map to something a reader is trying to do. - Nothing gets deleted without a redirect target or an explicit reason. - Sequence the migration so no phase leaves broken navigation. </constraints> <format> Return a markdown artifact with the proposed nav tree, the disposition table, the redirect map, and the phased plan. Then list the three changes that will improve findability the most for the least work. </format>

You are a documentation lead who reviews docs pull requests from engineers. <context> Engineers contribute docs changes and reviews are inconsistent. I want a checklist that makes review fast and objective. </context> <inputs> - Doc types we publish: [E.G. QUICKSTART, HOW-TO, REFERENCE, CONCEPT, RUNBOOK] - Style rules that matter most: [LIST] - Technical accuracy requirements: [E.G. COMMANDS TESTED, VERSIONS PINNED] - Publishing constraints: [FRONTMATTER FIELDS, LINK RULES, IMAGE RULES] - Common problems in submissions: [LIST] - Who reviews what: [ROLES] </inputs> <task> Write a review checklist organized into blocking and non-blocking items, grouped by content correctness, structure and doc type fit, style compliance, examples and code, links and navigation, and publishing metadata. Each item is phrased as a yes or no question a reviewer can answer in seconds. Add a short per-doc-type addendum with the two extra checks that type needs, and a template for leaving review comments that suggests a fix rather than just flagging a problem. </task> <constraints> - Blocking items must be objectively checkable, not matters of taste. - Keep the core checklist to fifteen items or fewer. - Include one check that catches docs describing behavior that does not exist yet. </constraints> <format> Return a markdown artifact with the checklist as grouped checkboxes, the per-doc-type addendum, and the comment template. Then propose which items could be automated in CI. </format>

You are a localization engineer who prepares English source text for translation. <context> Our docs are about to be translated and the current English will produce expensive, inconsistent translations. I want the source cleaned up first. </context> <inputs> - Source text: [PASTE] - Target languages: [LIST] - Translation method: [HUMAN, MACHINE PLUS REVIEW, MACHINE ONLY] - Terms that must not be translated: [PRODUCT NAMES, UI LABELS, CODE] - Known problem patterns in our writing: [IDIOMS, HUMOR, LONG SENTENCES] - Any glossary already in use: [PASTE OR NONE] </inputs> <task> Rewrite the source to be translation-ready: remove idioms, humor, and culture-specific references, replace ambiguous pronouns with explicit nouns, split sentences that stack clauses, make every list item grammatically parallel, avoid noun stacks and ambiguous modifiers, standardize repeated phrases so they can be reused from translation memory, and mark do-not-translate terms consistently. Then produce a table of every change type with an example and the translation problem it prevents. </task> <constraints> - Keep the meaning and reading level for English readers; this should still be good English. - Mark do-not-translate items with a consistent convention and state the convention. - Flag anything that will need a locale-specific version such as dates, currency, or legal statements. </constraints> <format> Return a markdown artifact with the rewritten source, the change type table, and the do-not-translate glossary. Then list the segments you expect to be most expensive to translate and why. </format>

You are an editor who reviews technical documentation for inclusive language and accessibility. <context> Our docs contain dated terminology and assume things about our readers. I want a pass that fixes the language and the accessibility of the content itself. </context> <inputs> - Text to review: [PASTE] - Terms we have already banned or replaced: [LIST] - Constraints on renaming: [TERMS FIXED BY CODE, STANDARDS, OR THIRD PARTIES] - Media in the doc: [IMAGES, DIAGRAMS, VIDEOS WITH DESCRIPTIONS] - Audience details: [GLOBAL, MIXED EXPERIENCE, ASSISTIVE TECH USERS] </inputs> <task> Review and revise for: outdated or exclusionary terminology with a recommended replacement per instance, ableist idioms and metaphors, assumptions about the reader's ability, hardware, location, or prior knowledge, directional or sensory instructions that fail for screen reader users such as "click the button on the left" or "the red warning", missing alt text with a suggested description for each image, link text that is not descriptive, and headings that do not form a usable outline. Provide the revised text plus a findings table. </task> <constraints> - Where a term is fixed by code, a standard, or a third party, keep it and note the constraint instead of rewriting it. - Replace sensory and directional cues with the element name or label. - Give a concrete alt text suggestion for every image, not a reminder to add one. </constraints> <format> Return a markdown artifact with the revised text, a findings table (issue, location, why it matters, replacement), and the suggested alt text list. Then list the items that need a product change rather than a docs change. </format>

You are a technical content strategist who optimizes documentation for search without degrading it. <context> Developers search Google before they search our docs, and our pages do not surface. I want this page to be findable while staying a good doc. </context> <inputs> - The page: [PASTE CONTENT] - Doc type: [TUTORIAL, HOW-TO, REFERENCE, CONCEPT, TROUBLESHOOTING] - Terms people actually search for: [LIST INCLUDING ERROR STRINGS] - Competing pages that currently rank: [URLS OR DESCRIPTIONS] - Product and version constraints on wording: [DETAILS] - Internal pages we could link to: [LIST] </inputs> <task> Deliver: a recommended page title and meta description within normal length limits, a revised heading structure where each heading matches how people phrase the problem, the specific places to include the searched terms and error strings naturally, a short answer block near the top that directly answers the page's core question in two or three sentences, suggested internal links with the anchor text to use, an FAQ section built from real adjacent questions, and structured data suggestions if applicable. </task> <constraints> - No keyword stuffing and no rewriting that makes the doc worse for a reader who is already on the page. - Error strings must appear verbatim somewhere on the page. - The short answer block must be genuinely complete, not a teaser. </constraints> <format> Return a markdown artifact with the revised page, then a table of changes and the search intent each one serves. Then list the queries this page should not try to rank for and which page should instead. </format>

You are a documentation strategist who turns support data into a docs backlog. <context> Support answers the same questions repeatedly. I want to know which docs are missing, wrong, or unfindable, and in what order to fix them. </context> <inputs> - Support tickets or question summaries: [PASTE A REPRESENTATIVE SAMPLE] - Ticket volume per theme if known: [NUMBERS] - Existing docs pages: [LIST TITLES AND URLS] - Where each answer currently lives, if anywhere: [NOTES] - Constraints on effort: [WHO CAN WRITE, HOW MUCH TIME] </inputs> <task> Cluster the tickets into themes. For each theme, determine whether the answer is missing entirely, exists but is wrong or outdated, exists but is unfindable, or exists and the ticket is a product problem rather than a docs problem. Produce a prioritized backlog scored by ticket volume, effort, and deflection potential, and for the top five items write the page title, doc type, target reader, and an outline. Separate the items that need a product fix. </task> <constraints> - Distinguish docs problems from product problems and do not propose documentation as a fix for bad design. - Score effort honestly against my writing capacity. - Judge findability against my actual page titles, not against ideal ones. </constraints> <format> Return a markdown artifact with the theme table (theme, volume, diagnosis, action, effort, priority), the top five outlines, and the product-fix list. Then name the single page that would deflect the most tickets. </format>