Technical Documentation & API Reference Generator

The Concept

Good technical documentation is the difference between developers adopting your API in 10 minutes or rage-quitting after 10. Most AI-generated docs read like a textbook wrote itself — verbose, vague, and missing the details developers actually need. This prompt produces docs that feel like they were written by an engineer who's used the API themselves: concise, example-heavy, and honest about edge cases.

The Prompt

You are a senior technical writer embedded in a developer tools company. Your documentation style is modeled after Stripe, Vercel, and Cloudflare — clear, scannable, example-first, and zero fluff.

I need you to write documentation for: [describe your API/SDK/tool/feature]

Follow these principles:

1. Lead with a working example. Before any explanation, show code that works. A developer should be able to copy-paste the first code block and get a result.
2. Structure for scanning. Use headers, tables, and code blocks aggressively. Nobody reads docs linearly — they ctrl+F and skim.
3. Be honest about limitations. If something is slow, has a rate limit, or breaks under certain conditions — say so. Developers trust docs that acknowledge tradeoffs.
4. Parameters as tables. Every function/endpoint gets a parameter table with: name, type, required/optional, default, and a one-line description.
5. Error responses are first-class. Document what goes wrong, not just what goes right. Include error codes, common causes, and how to fix them.
6. Progressive disclosure. Start with the simplest use case, then layer complexity. Quick start → common patterns → advanced configuration → edge cases.

Output format:

• Use markdown
• Code examples in the most common language for the target audience (default: TypeScript/Python)
• Include curl examples for any HTTP API
• Add "Common Mistakes" callouts where developers typically trip up

Context I'll provide:

• [Paste your API schema / OpenAPI spec / function signatures / existing rough docs]
• Target audience: [beginner/intermediate/advanced developers]
• Primary language: [TypeScript/Python/Go/etc.]

Variations

The Changelog Entry

Write a changelog entry for: [describe the change]. Format: version number, date, then categorized under Added/Changed/Deprecated/Removed/Fixed/Security. Each item is one sentence, present tense, with a link to the relevant docs section. If it's a breaking change, lead with a migration note in a warning callout.

The Migration Guide

Write a migration guide from [v1/old system] to [v2/new system]. Structure: what changed and why (2 sentences max), a before/after code comparison for every breaking change, a step-by-step migration checklist, and a "What if I can't migrate yet?" section with compatibility options.

The SDK Quick Start

Write a quick start guide for [SDK name] that gets a developer from zero to first successful API call in under 5 minutes. Include: install command, minimal configuration, one working code example, expected output, and "Next steps" links. Nothing else — ruthlessly cut anything that isn't on the critical path.

The Internal Runbook

Write an internal operations runbook for: [system/service]. Structure: what this service does (one paragraph), architecture diagram description, common alerts and what they mean, step-by-step playbooks for each incident type, escalation contacts, and a "Things that have gone wrong before" section with postmortem links.

Tips

• Feed it your actual OpenAPI spec or function signatures for dramatically better output — the model will infer correct types, required fields, and relationships
• For API docs, always specify "include curl examples" — it forces the model to think about the HTTP layer concretely
• If the output is too verbose, add: "Write as if you're charged per word. Every sentence must earn its place."
• Chain with a review pass: "Now review this documentation as a developer seeing it for the first time. What's confusing? What's missing?"