What this prompt does
This prompt creates a developer documentation style guide for a [company_type] writing for [audience], covering [doc_types] published on [doc_platform]. It produces the shared standard that keeps API docs, READMEs, tutorials, and wikis consistent — addressing the inconsistency that erodes reader trust fastest.
The structure works because it standardizes every axis where docs drift. Voice and Tone defines the writing voice as [tone_description], sets rules for "you" versus "we," and shows before/after rewrites. Structure Standards give templates per doc type — API reference, tutorial, how-to, conceptual. Code Examples require [languages_to_support] variants, realistic variable names, error handling, and version-pinned dependencies. A terminology dictionary standardizes [domain_terms], Visual Standards specify when to use diagrams and the [diagram_tool], Versioning rules cover [version_count] supported versions, and a peer-review checklist of [checklist_items] checkpoints enforces accuracy, completeness, and clarity.
When to use it
- Your docs across
[doc_types]feel inconsistent in voice and structure. - You want shared templates per documentation type for the whole team.
- You need code-example rules covering
[languages_to_support]and error handling. - You want a terminology dictionary to standardize
[domain_terms]. - You support
[version_count]versions and need rules for deprecation and selectors. - You want a review checklist enforcing quality before docs publish.
Example output
Expect a complete style guide organized into the areas where documentation tends to drift. A Voice and Tone section defines the writing voice as [tone_description], sets rules for second person versus first person plural, and shows before/after rewrites that turn passive, jargon-heavy sentences into clear instructions. Structure Standards supply templates for API reference, tutorial, how-to guide, and conceptual docs, each with its required sections. Code Examples rules require [languages_to_support] variants, realistic variable names rather than foo/bar, visible error handling, copy-pasteable markers, and version-pinned dependencies. A terminology dictionary standardizes [domain_terms], Visual Standards specify when to use diagrams, screenshots, and tables along with the [diagram_tool] and alt-text rules, Versioning rules cover maintaining docs across [version_count] versions with deprecation markers and version selectors, and a peer-review checklist of [checklist_items] checkpoints enforces accuracy, completeness, clarity, and tested code.
Pro tips
- Anchor the Voice and Tone section with before/after rewrites; abstract adjectives like
[tone_description]only become actionable when paired with concrete examples. - Make the terminology dictionary exhaustive for
[domain_terms]; inconsistent capitalization and naming is what quietly erodes reader trust. - Require
[languages_to_support]variants on every code example so no audience segment is left guessing. - Insist on realistic variable names and version-pinned dependencies in examples — foo/bar and floating versions both break copy-paste reliability.
- Tie the review checklist's
[checklist_items]to things reviewers can actually verify, including that code examples were run. - Keep the versioning rules explicit about deprecation marking and version selectors so docs across
[version_count]versions stay navigable.
