Scaffold structural templates for Diataxis-aligned page archetypes (Quickstart, How-To, API Reference, Webhooks, Troubleshooting) with concrete anatomy per type. Use when creating new documentation pages, choosing page structures, or enforcing archetype-specific anatomy. Triggered by: page archetype, quickstart template, how-to template, API reference layout, webhook docs, troubleshooting page, error dictionary, page scaffold, diataxis archetype, page anatomy, doc template, page structure.
Generate structural templates for five Diataxis-aligned documentation page types. Each archetype defines a concrete, opinionated anatomy — required sections, ordering, content slot types, and UX patterns — so that every page of a given type is structurally consistent across the documentation site.
This skill produces page skeletons with annotated content slots. It does not write final copy (handled by writing-focused skills) or assess Diataxis compliance generically (handled by the docs-designer agent).
Goal: Zero to working code in under 5 minutes.
Required Anatomy (in order):
| Section | Content Slot | Notes |
|---|---|---|
| Header + Outcome | Title, one-sentence outcome promise | "By the end, you will have [concrete result]" |
| Prerequisites | Bulleted checklist | Account, API key, runtime version, installed tools |
| Step Blocks | Numbered sequential actions | Each step: instruction → code block → expected output |
| Verification | Success confirmation | "You should see [expected result]" with screenshot or output |
| Next Steps | 2-3 linked follow-on paths | Link to How-To guides, API Reference, or concepts |
Rules:
Goal: Accomplish a specific real-world task.
Required Anatomy (in order):
| Section | Content Slot | Notes |
|---|---|---|
| Action Header | Verb-first title | "Configure webhook retries", not "About webhook retries" |
| Context | 1-2 sentences | When and why you would do this |
| Solution Steps | Numbered actions | No setup — assume prerequisites from the quickstart |
| Edge Case Admonitions | Callout blocks | Warning/note boxes for gotchas at the relevant step |
| Verification | Confirmation of completion | How to confirm the task succeeded |
Rules:
Goal: Complete, scannable reference for every endpoint.
Required Anatomy (per endpoint):
| Section | Content Slot | Notes |
|---|---|---|
| Endpoint Header | Method + path + short description | POST /v1/messages — Create a message |
| Authentication | Auth scheme indicator | Bearer token, API key, OAuth scope required |
| Parameter Table | Name, type, required, description, default | Grouped: path params → query params → body params |
| Request Example | Code block with realistic data | Multi-language tabs if supported |
| Response Example | JSON with all fields annotated | Include both success and error response shapes |
| Error Codes | Table of endpoint-specific errors | Code, message, resolution |
Layout Pattern: Three-column where viewport allows — navigation (left), content (center), code examples (right).
Rules:
foo/bar/testGoal: Enable reliable event consumption.
Required Anatomy (in order):
| Section | Content Slot | Notes |
|---|---|---|
| Event Overview | Event name + trigger description | When this event fires and what it represents |
| Payload Schema | Typed field table | Distinguish thin events (ID + type) from snapshot events (full object) |
| Signature Verification | Step-by-step HMAC validation | Include HMAC-SHA256 code in multiple languages |
| Delivery Guarantees | At-least-once semantics, retry policy | Retry schedule, timeout (5-second response window) |
| Idempotency | Handling duplicate deliveries | Idempotency key location and deduplication strategy |
| Testing | Local testing instructions | CLI tools, webhook forwarding setup, sample payloads |
Rules:
Goal: Rapid symptom-to-resolution path.
Required Anatomy (in order):
| Section | Content Slot | Notes |
|---|---|---|
| Error Code Dictionary | Searchable code → message → cause → resolution table | One row per error code |
| Symptom Index | Common symptom descriptions | User-language symptoms mapped to error codes |
| Diagnosis Flow | Symptom → Diagnosis → Resolution | Decision tree or numbered steps per symptom |
| Common Patterns | Grouped resolution patterns | Auth errors, rate limits, validation errors, network errors |
| Escalation | When to contact support | What information to include in a support request |
Rules:
| User Intent | Archetype | Signal Phrases |
|---|---|---|
| "How do I get started?" | Quickstart | first time, get started, hello world, initial setup |
| "How do I do X?" | How-To Guide | configure, set up, enable, migrate, deploy |
| "What does this endpoint do?" | API Reference | endpoint, parameter, request, response, API |
| "How do I receive events?" | Webhooks | webhook, event, callback, notification, subscription |
| "Why is this failing?" | Troubleshooting | error, failing, broken, not working, debug |
For any documentation page, verify:
{page title}Archetype: [Quickstart | How-To | API Reference | Webhooks | Troubleshooting]
Content Slots:
[Complete markdown skeleton with annotated placeholders for each content slot]
Checklist:
Cross-References: