Technical Documentation Writer

Why this prompt works

Most generated docs blur reference content and tutorial together, producing pages that don't quite work for either purpose. This prompt separates them on purpose: the Quick Start gets a minimal working example, then the Parameters table gives the reference, then the Detailed Usage section provides 2 or 3 fully-worked examples of common use cases. The 'second person and active voice throughout' constraint is what gives the output the unmistakable feel of good technical writing, and the 'avoid jargon without defining it first' rule is the discipline that makes docs accessible to developers who are new to the specific feature.

When to reach for it

• You're documenting a new API endpoint or feature and want a complete first draft that follows the conventions developers expect.
• You're auditing existing docs and want a benchmark for what good looks like in this format.
• You're shipping internal documentation for a tool your team built and want it to be usable by future hires without you in the room.
• You're rewriting docs that grew organically and have inconsistent structure across pages.

How to customise it

The 'feature/API endpoint/process' field works best with concrete inputs: 'POST /api/users/[id]/permissions' produces sharper docs than 'the permissions API'. The programming language field doesn't just affect code samples; it shifts conventions (Python docs use different structure than Rust docs). For docs targeting public release, add 'include rate limiting and auth requirements explicitly'; the standard template touches on auth but doesn't always cover rate limits. If you have an internal style guide (e.g. 'always use cURL for examples'), tell the model.

What good output looks like

A structured doc with eight named sections. The Quick Start is usually 15 to 25 lines of code plus 1 to 2 lines of context. The parameters table is the densest section, with name, type, required, default, description columns. Detailed Usage shows 2 to 3 worked examples in code blocks with surrounding prose. Error handling lists 3 common errors with cause and fix. Best Practices is short (3 to 4 tips) and concrete. Total length depends on feature complexity, typically 800 to 1,500 words.

Watch out for

The model sometimes invents parameter names or default values when the actual feature isn't part of its training data. Treat the parameters table as a draft to verify against the real interface before publishing. The error codes section similarly: the model produces plausible-looking 4xx/5xx examples that may not match what the system actually returns. Run a real failing request and check the actual response shape, then update.