Write API reference documentation for an endpoint.

Endpoint: [METHOD /path — e.g., POST /api/v2/users]
Description: [one sentence — what does this endpoint do?]
Authentication: [describe required auth — e.g., Bearer token, API key]
Request parameters:
  - Path parameters: [list with name, type, required/optional, description]
  - Query parameters: [list with name, type, required/optional, description, default value]
  - Request body: [describe the JSON schema — key fields with type and description]
Response:
  - Success: [status code, response body schema]
  - Error codes: [list relevant error codes with description]
Example request: [provide a curl example]
Example response: [provide a sample JSON response]

Format: API reference format. Developer-facing. Be precise with types, constraints, and error codes. Developers copy the example and expect it to work.

Write a getting started guide for a new API user.

API name and purpose: [describe what the API does]
Prerequisites: [what does the user need before starting — account, API key, tools]
Step 1 — Authentication: [describe how to authenticate with a working example]
Step 2 — First API Call: [describe the simplest meaningful API call with a working example]
Step 3 — Handle the Response: [show how to parse the response]
Step 4 — Common Next Steps: [list 2-3 natural follow-on tasks]
Error handling basics: [describe the most common errors and how to handle them]

Format: step-by-step getting started guide, 350 words. Every code example must be complete and runnable. Use the language most common to your developer audience.

Add inline documentation comments to this code sample for developer docs.

Language: [programming language]
Code: [paste the code here]
Audience: [beginner developer / intermediate developer / experienced developer]
Document: [every function, parameter, return value, and non-obvious logic]
Style: [JSDoc / docstrings / inline comments — specify]

Format: annotated code with comments integrated. Do not change the code logic — only add documentation. Comments should explain why, not just what.

Write release notes for a software update.

Version number: [version]
Release date: [date]
New features: [list with 1-sentence description each]
Bug fixes: [list with 1-sentence description each — describe the symptom that was fixed, not just the code change]
Breaking changes: [list any — describe impact on existing integrations and migration path]
Deprecations: [list any — describe timeline and replacement]
Known issues: [list any — describe workaround if available]

Format: release notes, developer-facing. Breaking changes first if any exist — developers scan for what might break them before reading about new features. Plain, direct language.

Write a README for a software library or SDK.

Library name and purpose: [describe in one sentence]
Language / platform: [describe]
Installation: [package manager command]
Quick start (5-minute working example): [describe the simplest useful implementation]
Configuration: [describe key configuration options]
Core features: [list 3-5 main capabilities with one-line descriptions]
API reference location: [where is the full reference?]
Contributing: [brief — how to submit issues and PRs]
License: [license type]

Format: README.md format, 300 words. Developers decide whether to use a library in the first 30 seconds of reading the README. The quick start must work.

Write a how-to article for a product feature.

Feature name: [describe]
User's goal: [what are they trying to accomplish?]
Prerequisites: [what must the user have or know before starting]
Step-by-step instructions: [list steps in order — each step = one action]
Expected result: [what does the user see when they've done it correctly?]
Common mistakes: [list 1-2 with how to recover]
Related features or next steps: [list 1-2 things they might want to do after]

Format: user-facing how-to article, 300 words. Active voice. Second person ("you"). One action per step. Every step should be verifiable by the user.

Write a troubleshooting guide for a common user problem.

Problem: [describe the symptom the user experiences — as they would describe it, not as an engineer would]
Possible causes: [list 2-4 likely root causes]
For each cause:
  - How to diagnose it: [what the user checks]
  - How to fix it: [specific steps]
When to escalate to support: [describe — what has the user tried, and what does a "need support" situation look like]
Related documentation: [2-3 related articles]

Format: troubleshooting guide, 300 words. Problem-symptom language in the title and opening — users search for what they see, not for what caused it.

Write a concept overview article explaining a technical concept to non-technical users.

Concept: [name the concept]
Audience: [describe the user — their role, technical level, and what they already know]
Why they need to understand this: [practical context — what decision or action does this enable?]
Analogy to make it concrete: [suggest an analogy from everyday life]
Core elements of the concept: [list 3-4 key ideas]
What it looks like in the product: [describe where/how they encounter it]
Common misconceptions: [list 1-2 and correct them]
Next step: [what should the user do now that they understand this?]

Format: concept article, 350 words. Start with the analogy. Avoid jargon. Users read concept articles because they are confused — give them a mental model, not a technical specification.

Write a user-facing feature announcement.

Feature name: [describe]
What it does (user benefit language): [describe what the user can now do — not what the engineering team built]
Who it's for: [describe the target user or use case]
How to access it: [brief — where is it in the product?]
Key steps to use it: [3-4 steps, brief]
Resources: [link to full documentation, tutorial video, etc.]

Format: 175-word announcement. Lead with the benefit, not the feature name. Users care about what changed for them, not the engineering achievement. Excited but professional tone.

Write an administrator configuration guide for a product setting or system.

Setting or system: [describe]
Who configures this: [admin role description]
When to use this: [what business scenario drives configuration]
Prerequisites: [permissions, access, other settings required]
Step-by-step configuration: [numbered steps — specific and complete]
Validation steps: [how does the admin confirm configuration worked correctly]
Rollback procedure: [how to undo if needed]
Impact on end users: [what changes for users when this is configured]

Format: admin guide, 300 words. Precision over brevity — admins follow documentation exactly. One missed step can affect all users.

Write an interview guide for a subject matter expert interview to support documentation.

Topic to document: [describe the feature or process]
SME role: [engineer / product manager / support lead / etc.]
What I already know: [describe what context you have — so interview focuses on gaps]
Key questions to ask: [list 7-10 specific questions that will give you what you need]
Follow-up probes for complex answers: [list 3-4 probing follow-ups]
What to ask about edge cases: [list 2 questions specifically about failure modes or edge cases]
What to ask for at the end: [e.g., "example user scenarios," "review of my draft," "code samples"]

Format: 200-word structured interview guide. Numbered questions. Start with broad orientation questions and narrow to specifics. Include a note about recording permission.

Analyze an engineering ticket and identify documentation gaps.

Ticket content: [paste the ticket description, acceptance criteria, and notes]
Existing documentation: [describe what documentation currently covers this area]
Questions this ticket raises that documentation must answer: [list based on the ticket]
User scenarios affected: [describe who is affected and how their experience changes]
Terminology introduced: [new terms that need definition]
Documentation tasks generated by this ticket: [list what needs to be written or updated]

Format: documentation gap analysis, 200 words. This is your planning output from a ticket read — translate engineering language into documentation tasks.

Write a review request email to a subject matter expert.

SME name and role: [name, role]
Document requesting review: [describe the doc — type, scope]
What you need them to review for: [accuracy of technical content — not style or grammar]
Specific sections with technical uncertainty: [list 2-3 specific areas you want their attention on]
Questions you have for them: [list 2-3 specific questions]
Review deadline: [date]
How to provide feedback: [tracked changes / comments / meeting]

Format: 150-word email. Specific questions produce useful reviews. Vague "please review" requests come back with typo fixes instead of technical corrections.

Write a documentation audit checklist for a product area.

Product area: [describe]
Checklist items for each article:
  - Accuracy: [list 3 accuracy checks]
  - Completeness: [list 3 completeness checks]
  - Clarity: [list 3 clarity checks]
  - Structure: [list 3 structure checks]
  - Links and references: [list 2 link checks]
  - Code samples: [list 2 code sample checks]
  - Version accuracy: [list 1-2 version-specific checks]
Priority triage: [how do you decide what to fix first — critical vs. nice-to-have]

Format: structured audit checklist, 250 words. Checkbox format. This should be usable by a writer who didn't create the original docs. Be specific enough that every item has a clear pass/fail answer.

Write constructive PR review comments for a documentation pull request.

PR title and scope: [describe what the PR covers]
Structural issues: [list any structural problems — e.g., missing sections, wrong heading hierarchy]
Accuracy concerns: [list any technical accuracy questions — not assumptions, flag for verification]
Clarity improvements needed: [list specific sentences or sections that are unclear]
Consistency issues: [list any deviations from the style guide — be specific]
Positive feedback: [list 1-2 things done well — PR reviews are more effective when balanced]

Format: PR review comment format, 200 words. Every comment should be actionable. Prefer "consider changing X to Y because Z" over "this is unclear."

Edit this text for compliance with our style guide.

Text to edit: [paste text here]
Style guide rules to apply: [list the specific rules — e.g., Oxford comma, serial comma, second person, active voice, sentence case for headings, no contractions in formal docs, specific terminology preferences]
Do not change: [what should stay the same — e.g., technical accuracy, code samples, specific product names]

Format: edited version of the text with tracked-changes-style annotation showing what was changed and why. Group changes by rule so the writer can learn the pattern.

Rewrite this technical content in plain language.

Original text: [paste text here]
Target audience: [describe — e.g., "non-technical business user," "first-time user," "customer support agent"]
Reading level target: [Grade 8 / Grade 10 / as simple as possible]
Terms that must be kept (even if technical): [list any required technical terms]
Terms to avoid: [list jargon to replace]

Format: rewritten version with a brief note for each significant change explaining the plain language decision. The goal is the simplest version that is still accurate.

Identify and correct passive voice constructions in this text.

Text: [paste text here]
Convert passive constructions to active where possible. Where passive is preferable (e.g., "the request is sent" in API docs where the actor is the system), note why passive is retained.

Format: corrected text with annotations marking each change. Include a brief explanation for retained passive constructions.

Improve the readability of this technical content.

Text: [paste text here]
Target audience: [describe]
Specific issues to address: [list — e.g., long sentences, unexplained acronyms, buried lede, dense paragraphs]
Maintain technical accuracy — do not simplify concepts, only improve expression.

Format: improved version with an annotation for each significant structural or sentence-level change. Note reading level before and after if possible.

Audit this document for terminology consistency.

Document: [paste or describe the document]
Approved terminology list: [list the correct terms — e.g., "select" not "click," "the application" not "the app" or "the tool," "user" not "customer"]
Identify: [list all instances of non-standard terminology]
Suggest: [the approved replacement for each]

Format: terminology audit table — column 1: found term, column 2: location (section or paragraph), column 3: approved replacement. Followed by a corrected version of the document.

Write a migration guide for users upgrading from one version to another.

From version: [version number]
To version: [version number]
Breaking changes: [list each — describe what breaks and why]
Migration steps: [for each breaking change, the exact steps to migrate]
Configuration changes needed: [list any config updates required]
Code changes needed: [describe code patterns that must change — with before/after examples]
Testing recommendations: [what should users test after migration]
Rollback procedure: [how to revert if migration fails]
Time estimate: [rough time for a typical migration]

Format: migration guide, 400 words. Breaking changes drive urgency — list them at the top. Every change needs a before/after code example if code is involved.

Write a deprecation notice for an API endpoint or feature being sunset.

Deprecated item: [name of endpoint, feature, or parameter]
Deprecation date: [when it is deprecated]
End-of-life date: [when it will be removed entirely]
Reason for deprecation: [brief explanation — users deserve to know why]
Replacement: [describe the new endpoint or feature that replaces it]
Migration path: [brief — what do users need to change?]
Support during transition: [what help is available]
Action required by date: [if there is a deadline]

Format: 175-word deprecation notice. Developers hate surprises — give them maximum lead time, a clear replacement, and a concrete action date. Empathetic but direct.

Write a known issues article for a product release.

Release version: [version]
Known issue 1:
  - Description: [symptom the user experiences]
  - Affected users: [who is impacted — by configuration, plan, or usage pattern]
  - Workaround: [describe if available]
  - Resolution timeline: [when will it be fixed — or "investigating"]
[Repeat for 2-3 additional issues]

Format: known issues article. Lead with the workaround — users want to unblock themselves. Describe symptoms in user language, not engineering language. Update this article when issues are resolved.

Write an end-user impact assessment for a proposed documentation change.

Change being considered: [describe the documentation change — e.g., restructuring the help center, rewriting the onboarding guide, removing legacy API docs]
Users affected: [describe the user segments who use this documentation]
Current user behavior: [how do users currently navigate to and use this documentation]
Impact of the proposed change: [describe what changes for users — positive and negative]
Risk of the change: [what could go wrong]
Mitigation: [how will you address the negative impacts]
Success metric: [how will you know the change was an improvement]

Format: 200-word impact assessment. This is a planning document for a documentation decision — use it to build the business case or identify risks before you start.

Write an API version support policy statement.

Current API version: [version]
Previous supported versions: [list versions still supported]
Version support lifecycle: [describe — e.g., "major versions supported for 24 months after release of next major version"]
Breaking change policy: [how and when breaking changes are introduced]
Deprecation notice period: [minimum notice before removing a version]
End-of-life process: [describe what happens when a version reaches EOL]
Communication channels for version updates: [how users are notified]

Format: 200-word policy statement. This goes in your developer documentation — it's a contract between you and your API users. Precise language matters. Vague policies create support escalations.

Write a style guide section on a documentation convention.

Convention topic: [e.g., "Writing Procedures," "API Parameter Descriptions," "Error Messages," "Code Sample Standards"]
Why this convention exists: [brief rationale — writers follow guidelines better when they understand the reason]
The rule: [state the rule clearly]
Examples (do): [provide 2-3 correct examples]
Examples (don't): [provide 2-3 incorrect examples]
Edge cases and exceptions: [list any situations where the rule doesn't apply]

Format: style guide section, 200 words. Rules need examples — abstract rules produce inconsistent application. Every rule that exists to enforce consistency should show the consistent pattern explicitly.

Write a documentation project plan for a new product launch.

Product/feature name: [describe]
Launch date: [date]
Documentation deliverables required: [list each doc — type, audience, purpose]
Information sources: [list who you'll get information from — SMEs, tickets, design specs]
Review process: [who reviews each doc and in what sequence]
Localization requirements: [yes/no — describe if yes]
Milestone schedule: [list key milestones with dates]
Risk: [top 2 risks to hitting the launch date]
Resource required: [writers, reviewers, tools needed]

Format: 225-word project plan. Launch date drives everything — work backwards from it. Identify review bottlenecks early — they kill doc launches more than writing time does.

Write a documentation debt prioritization framework.

Types of doc debt in your system: [list — e.g., outdated content, missing content, poor structure, broken links, untranslated content]
Scoring criteria: [describe how to score each type — e.g., by traffic, user impact, support ticket volume, age]
Priority tiers: [define critical / high / medium / low with criteria]
Resolution SLAs by tier: [when should each tier be addressed]
Review frequency: [how often is doc debt audited]
Owner assignment: [how is ownership assigned for remediation]

Format: 225-word framework document. This is a process document — it should enable a new team member to triage doc debt without asking for guidance.

Write a content strategy recommendation for a documentation improvement.

Current state: [describe the documentation problem — be specific]
Evidence: [what data, user feedback, or support tickets support this assessment]
Proposed solution: [describe the content strategy change]
Expected outcome: [describe the improvement and how it will be measured]
Effort required: [describe the work involved]
Resources needed: [headcount, time, tools]
Risks: [list 1-2 risks with mitigation]
Recommendation: [what you are asking leadership to approve]

Format: 200-word strategy recommendation. Evidence-based. Documentation improvements compete for resources — make the case with user impact data, not gut feel.

Write a review of the current onboarding documentation for a new user persona.

User persona: [describe the user — role, technical level, goals]
Current onboarding documentation: [describe what exists]
Gaps identified for this persona: [list 3-4 specific gaps]
Content that doesn't serve this persona: [list 1-2 items that are irrelevant or confusing]
Recommended changes: [list 3 specific improvements with rationale]
Priority of each change: [high / medium / low]
Success metric: [how would you measure improvement in onboarding for this persona]

Format: 225-word review. User persona focus — documentation that tries to serve everyone often serves no one. Persona-specific gaps are the most actionable kind.

Provide structural editing feedback on this documentation.

Document: [describe or paste the document]
Questions to answer in your feedback:
  - Does the document answer the user's primary question within the first paragraph?
  - Is the information in the most logical sequence for the user's journey?
  - Are there sections that belong in a different document?
  - Is there anything missing that a user would need to complete the task?
  - Is the document the right length — nothing to add, nothing to cut?

Format: structured editorial feedback with specific location references (heading or section name). For each issue, describe the problem and suggest a specific fix.

Review this documentation from the user's perspective.

Document: [describe or paste]
User persona: [describe who this document serves]
Review for:
  - Does the opening immediately orient the user to whether this is the right article?
  - Are user goals and tasks reflected in the structure, or is it organized by system structure?
  - Is every step verifiable — can the user tell if they did it correctly?
  - Are error messages described from the user's perspective?
  - Does the document handle the most common failure paths?

Format: 200-word user-centered review with specific, actionable feedback for each item.

Create a technical accuracy review checklist for this documentation.

Document type: [API reference / user guide / how-to / concept article]
Product area: [describe]
Checklist items:
  - Code samples: [list 3 accuracy checks specific to code]
  - Parameter values and types: [list 2 checks]
  - UI element names and locations: [list 2 checks]
  - Version-specific information: [list 2 checks]
  - URLs and links: [list 2 checks]
  - Screenshots (if present): [list 2 checks]

Format: review checklist, checkbox format. This goes to the SME reviewer — they should be able to work through it without verbal instructions.

Write a short user feedback survey for documentation quality.

Documentation section being surveyed: [describe]
Survey questions (keep to 5 or fewer):
  - Task completion: "Did you find what you were looking for?"
  - Accuracy: "Was the information accurate?"
  - Clarity: "Was the documentation easy to understand?"
  - Completeness: "Was anything missing that you needed?"
  - Open-ended: "What would make this documentation more helpful?"

Format: 5-question survey with brief instructions and a closing thank-you. Keep it short — long surveys have low response rates. Offer an optional free-text field for each question.

Write a documentation retrospective for a product launch or documentation project.

Project: [describe]
What was delivered: [list documentation deliverables]
Timeline vs. plan: [on time / delayed — describe]
What went well: [list 2-3 specific things]
What didn't go well: [list 2-3 specific things — honest]
What we learned about working with this product team: [describe]
Process change for next time: [list 1-2 specific improvements]
Documentation quality assessment: [how do you assess the quality of what was delivered — any gaps noticed post-launch]

Format: 225-word retrospective. Shared with the team and the product team that partnered on the launch. Honest about process failures — retrospectives that only document successes don't improve anything.