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.

Open in Markdown Output Builder

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.

How to use this resource

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

FAQ

Why does this docs prompt require a code example in every behavior section?

Because usage sections drift into abstraction without one. The CODE RULES require that "every section that describes behavior or usage must include a fenced code example with a language tag," and that examples be "usable as written — no pseudo-code, no '...' placeholders." That keeps Usage and How It Works concrete. The markdown-output-builder shapes the prompt; your assistant fills the fenced blocks, and you still verify the code runs.

Who is the "define every term at first use" rule written for?

A competent reader who is new to THIS system — the DOCUMENT block names exactly that audience. So Key Concepts defines the terms a reader must know, and jargon gets defined where it first appears rather than shipped to a glossary. It's not writing for a beginner engineer generally; it assumes competence but zero familiarity with your specific system.

Is this for API endpoint reference docs?

Not quite — this is the five-section feature-page skeleton: Overview, Key Concepts, How It Works, Usage, Troubleshooting. Per the notFor, endpoint references need parameter tables and stricter rules that the API Documentation setup adds. Use this one for feature pages that share one shape, with a pinned Troubleshooting section so failure modes get documented while they're remembered.

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

Copy it as-is, or use Open in Markdown Output Builder to load it pre-filled and customize it with your own context.

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.

More resources from Markdown Output Builder

Resource

Markdown Output Prompt — Lock the Document Structure

The contract that stops AI documents from restructuring themselves: a pinned section skeleton, forced tables, and strict consistency rules.

Prompt Engineering

Resource

README Prompt Template

Overview, Installation, Usage, Examples, Configuration — the README skeleton with required, runnable code examples.

Engineering

Resource

API Documentation Prompt

Overview, Authentication, Endpoints, Error Handling, Rate Limits — endpoint docs in an identical structure, with parameter tables and runnable examples forced.

Engineering

Resources that pair well

Resource

Executive Summary Prompt

Summary, Why It Matters, What Happens Next — the executive summary contract for readers who will never open the source.

Operations

Resource

Force JSON Output from AI

Stop getting 'Sure, here is the JSON…' — the output-contract pattern that forces models to return only parseable JSON: schema, example, and a strict rule block.

Prompt Engineering

Resource

Fix Invalid JSON from AI

The JSON won't parse and you can't see why. Deterministic cause-sniffing — trailing commas, single quotes, unclosed brackets — and the repair prompt that fixes it.

Engineering

Related tools

Tool

Markdown Output Builder

Build prompts that produce documents in a fixed structure — headings, sections, and tables.

Structured Output

Projects that use this resource

Project

Build an AI Meeting Assistant with AI

The full path to an AI meeting assistant — define the use case, turn transcripts into structured notes, extract decisions and action items, classify follow-ups, write a shareable summary, evaluate accuracy, then ready it for the team.

7 stages AI Systems

Project

Build a Documentation Website with AI

The full path to docs people can actually navigate — plan the doc set, structure the site, write the guides and the API reference, then ship it as a coherent documentation site.

5 stages Websites

Project

Build a Knowledge Base with AI

The full path to knowledge that's findable by people and AI — plan the taxonomy, structure it for search, write the articles, tag the metadata, make it retrievable, then ship it maintainable.

6 stages Knowledge Systems

Workflows that use this resource

Workflow

AI Project Architecture Workflow

Design a system's architecture on its real trade-offs instead of a confident diagram — put the model in an architect's seat, work the decisions one at a time, and write down the why.

3 steps 45–90 minutes

Workflow

AI Database Design Workflow

Design a schema on its data, not a hunch — model the entities and relationships, set the constraints that protect integrity, plan indexes around real queries, then document the schema and migration.

4 steps 45–75 minutes

Workflow

AI Integration & Webhook Workflow

Connect systems so they don't break each other — map the integration boundaries, design the event and webhook contracts, plan retries and failure handling, then document the integration.

4 steps 40–70 minutes

Workflow

AI Architecture Recovery Workflow

Recover a legacy system's architecture before you change it — package the codebase context, explain the current structure, surface the risks and seams, then document the recovered architecture.

4 steps 40–70 minutes

Workflow

AI Data Pipeline & ETL Workflow

Design a pipeline that moves data without corrupting it — map the sources and ingestion, design the transformation stages, set validation and quality gates, then document the pipeline and monitoring.

4 steps 45–75 minutes

Workflow

AI Content Writing Workflow

Turn source material and a target audience into clear docs, help, or knowledge-base content — gather the material, outline the piece, write it section by section, then check it for clarity and gaps.

4 steps 30–60 minutes

Workflow

AI Website Structure Workflow

Organize a site so people and crawlers find things — inventory the content, group it into a real hierarchy, design the sitemap and navigation, then document the information architecture for the build.

4 steps 40–70 minutes

Guides for this resource

Guide

How to Document System Architecture With AI

The new engineer asks how the system actually works and gets a whiteboard photo from two years ago, or an AI answer that confidently names a queue that isn't there. Here is how to document system architecture with AI: the current state, with every component traced to a fact or marked unconfirmed.

Software Development with AI

Tip: Save time by exploring related resources and tools that integrate with this resource.