Engineering

Technical Documentation Prompt

Overview, Key Concepts, How It Works, Usage, Troubleshooting — docs pages with the same shape for every feature, and code in every usage section.

Overview

Documentation rots fastest when every page has its own structure — readers can't build navigation instincts and writers can't tell what's missing. This setup generates docs pages against a five-section skeleton with tech-docs rules: define every term at first use (assume a competent reader new to THIS system), document what the system does rather than roadmap dreams. Require Code Examples puts a fenced, language-tagged, usable-as-written block in every behavior-describing section.

Workflow

One skeleton, every feature
Each feature's page comes back with the same five sections — navigation instincts transfer.
Watch the term rule
"Define every term at first use" assumes the right reader: competent, but new to this system.
Trust the Troubleshooting slot
A pinned section means failure modes get documented while they're remembered, not after the third support ticket.

Why This Works

Sibling-shaped pages teach readers where to look
First-use definitions beat a glossary nobody opens
Required code keeps usage sections concrete

Best for

Docs sites where pages should feel like siblings
Teams onboarding engineers through documentation
Systems with jargon that needs first-use definitions

Not for

API endpoint references — the API Documentation setup adds tables and stricter rules
Summarizing existing docs — that's the Structured Summary Prompt

Use cases

Documenting features in an identical page structure
Forcing term definitions where readers actually need them
Keeping Troubleshooting from being forgotten

Customize This Resource

Opens this setup in Markdown Output Builder. Generate to get the full markdown prompt — then adjust the sections, table rules, and consistency level.

Open in Markdown Output Builder

Prompt Template

TASK
Produce developer documentation pages with the same structure for every feature.
Produce a new markdown document — there is no source text to summarize.

DOCUMENT
The document is technical documentation for developers.
- Define every term at first use — assume a competent reader new to THIS system.
- Document what the system does, not what it might do someday.

DOCUMENT STRUCTURE
Start with one "# " title line, then use exactly these sections, in this order:
## Overview
What the system does, in plain language.
## Key Concepts
Terms the reader must know, each defined.
## How It Works
The main flow, step by step.
## Usage
How to use it, with concrete examples.
## Troubleshooting
Common failures and their fixes.

MARKDOWN RULES
- One "# " title at the top; every section below it is a "## " heading.
- Use markdown lists for enumerations — no walls of prose.
- No HTML tags — pure markdown.

TABLE RULES
- Use a markdown table when content is naturally tabular — comparisons, option matrices, parameter lists; otherwise prefer prose.
- Every table needs a header row and a separator row.

CODE RULES
- Every section that describes behavior or usage must include a fenced code example with a language tag.
- Code examples must be usable as written — no pseudo-code, no "..." placeholders.

CONSISTENCY RULES
- Use every section defined above, in the order given.
- Do not add new top-level sections — put extra material inside the closest existing section.

OUTPUT RULES
- Return only the markdown document — no preamble, no closing commentary.
- Start directly with the "# " title line.
- Do not wrap the document in code fences.

Related Resources

Explore more resources that work well with this one.