Documentation Patterns
Use this skill when the main problem is document shape and consistency rather than writing quality alone.
- Leverage native parallel subagent dispatch and 200k+ context windows where available.
Activation Conditions
Use symptom -> action triggers: when one matches, apply this skill and verify with the protocol below.
- Creating a new API, feature, or config guide
- Standardizing Markdown sections across repositories
- Writing migration or runbook documents
- Picking the right template for a doc request
Pattern Selection
- API docs: endpoints, auth, request and response schema, errors
- Feature docs: purpose, UX, dependencies, rollout, support
- Config docs: env vars, defaults, examples, failure modes
- Migration docs: changed behavior, upgrade path, verification
Cross-Skill Workflow
- Use documentation-authoring to gather context and draft the content before template selection becomes the bottleneck.
- Use this skill when structure, section order, or template choice is the main problem.
- Finish with documentation-quality to review the final document against quality expectations.
Agent Prompt Template
Use the documentation-patterns skill to choose and apply the best structure for a [document type].
Context: [feature, system, migration, or runbook].
Bias toward: [API docs, feature docs, config guide, migration guide, etc.].
Return the recommended section outline with short notes on why each section exists.
Shared Documentation Stack
Use this as the inherited baseline for documentation-authoring, documentation-quality, documentation-automation, and documentation-verification.
- Source of truth: identify owner, audience, canonical files, and freshness requirements before drafting.
- Structure: choose the smallest reusable pattern that fits the reader task.
- Verification: check links, commands, examples, screenshots, and version-sensitive claims before publishing.
- Handoff: state unresolved gaps, owners, and next review trigger instead of implying false completeness.
Cross-Client Portability
This skill is written to stay usable across GitHub Copilot, Claude Code, and Codex.
- GitHub Copilot: keep the folder in a Copilot-visible skill path or wrap the
workflow in project instructions when folder discovery is unavailable.
- Claude Code: keep the folder in a local skills directory or a compatible plugin source.
- Codex: install or sync the folder into
$CODEX_HOME/skills/documentation-patterns and restart Codex after major changes.
MCP Availability And Fallback
Preferred MCP Server: None required
- Fallback prompt: "Use the Documentation Patterns skill without MCP. Rely on its local instructions, bundled resources, standard shell or editor tools, and direct verification. Show the evidence used before concluding."
- Do not claim an MCP operation was used when the active host does not expose it.
- Treat local files, tests, rendered outputs, logs, or screenshots as the fallback evidence path.
Anti-Patterns
- Writing for the author instead of the reader: It bakes in unstated context and leaves the actual audience unsure what to do next.
- Skipping concrete examples or commands: Abstract guidance is easy to approve and hard to apply correctly.
- Letting links, screenshots, or versions drift: Polished formatting does not help if the instructions are no longer true.
Verification Protocol
Before claiming "skill applied successfully":
- Pass/fail: The Documentation Patterns output identifies audience, purpose, source of truth, and freshness requirements.
- Pass/fail: Shared documentation-stack guidance is referenced instead of duplicating another documentation skill.
- Pass/fail: Claims, links, commands, examples, and screenshots are verified or explicitly marked unverified.
- Pressure-test scenario: Apply the skill to a doc request with a stale command, missing owner, and conflicting audience.
- Success metric: Zero undocumented assumptions; every reader-facing claim is sourced or scoped.
References & Resources
Documentation
Scripts
Related Skills
- documentation-authoring: Use it when the workflow also needs drafting structured technical or product documents.
- documentation-quality: Use it when the workflow also needs documentation review standards and quality gates.
- documentation-verification: Use it when the workflow also needs final documentation validation before publishing.
- notion-docs: Use it when the workflow also needs Notion page and database publishing workflows.
1---2name: documentation-patterns3description: Templates and structural patterns for API docs, feature docs, config guides, and REST endpoint documentation. Use when structuring docs, applying Markdown templates, or standardizing doc formats.4---5# Documentation Patterns
6
7Use this skill when the main problem is document shape and consistency rather than writing quality alone.
8
9- Leverage native parallel subagent dispatch and 200k+ context windows where available.
10
11
12## Activation Conditions
13
14Use symptom -> action triggers: when one matches, apply this skill and verify with the protocol below.
15
16- Creating a new API, feature, or config guide
17- Standardizing Markdown sections across repositories
18- Writing migration or runbook documents
19- Picking the right template for a doc request
20
21## Pattern Selection
22
23- API docs: endpoints, auth, request and response schema, errors
24- Feature docs: purpose, UX, dependencies, rollout, support
25- Config docs: env vars, defaults, examples, failure modes
26- Migration docs: changed behavior, upgrade path, verification
27
28## Cross-Skill Workflow
29
30- Use [documentation-authoring](../documentation-authoring/SKILL.md) to gather context and draft the content before template selection becomes the bottleneck.
31- Use this skill when structure, section order, or template choice is the main problem.
32- Finish with [documentation-quality](../documentation-quality/SKILL.md) to review the final document against quality expectations.
33
34## Agent Prompt Template
35
36```text
37Use the documentation-patterns skill to choose and apply the best structure for a [document type].
38Context: [feature, system, migration, or runbook].
39Bias toward: [API docs, feature docs, config guide, migration guide, etc.].
40Return the recommended section outline with short notes on why each section exists.
41```
42
43## Shared Documentation Stack
44
45Use this as the inherited baseline for documentation-authoring, documentation-quality, documentation-automation, and documentation-verification.
46
471. Source of truth: identify owner, audience, canonical files, and freshness requirements before drafting.
482. Structure: choose the smallest reusable pattern that fits the reader task.
493. Verification: check links, commands, examples, screenshots, and version-sensitive claims before publishing.
504. Handoff: state unresolved gaps, owners, and next review trigger instead of implying false completeness.
51
52<!-- MCP:START -->
53
54<!-- PORTABILITY:START -->
55## Cross-Client Portability
56
57This skill is written to stay usable across GitHub Copilot, Claude Code, and Codex.
58
59- GitHub Copilot: keep the folder in a Copilot-visible skill path or wrap the
60 workflow in project instructions when folder discovery is unavailable.
61- Claude Code: keep the folder in a local skills directory or a compatible plugin source.
62- Codex: install or sync the folder into
63 `$CODEX_HOME/skills/documentation-patterns` and restart Codex after major changes.
64
65<!-- PORTABILITY:END -->
66
67## MCP Availability And Fallback
68
69Preferred MCP Server: None required
70
71- Fallback prompt: "Use the Documentation Patterns skill without MCP. Rely on its local instructions, bundled resources, standard shell or editor tools, and direct verification. Show the evidence used before concluding."
72- Do not claim an MCP operation was used when the active host does not expose it.
73- Treat local files, tests, rendered outputs, logs, or screenshots as the fallback evidence path.
74
75<!-- MCP:END -->
76
77## Anti-Patterns
78
79- Writing for the author instead of the reader: It bakes in unstated context and leaves the actual audience unsure what to do next.
80- Skipping concrete examples or commands: Abstract guidance is easy to approve and hard to apply correctly.
81- Letting links, screenshots, or versions drift: Polished formatting does not help if the instructions are no longer true.
82
83## Verification Protocol
84
85Before claiming "skill applied successfully":
86
871. Pass/fail: The Documentation Patterns output identifies audience, purpose, source of truth, and freshness requirements.
882. Pass/fail: Shared documentation-stack guidance is referenced instead of duplicating another documentation skill.
893. Pass/fail: Claims, links, commands, examples, and screenshots are verified or explicitly marked unverified.
904. Pressure-test scenario: Apply the skill to a doc request with a stale command, missing owner, and conflicting audience.
915. Success metric: Zero undocumented assumptions; every reader-facing claim is sourced or scoped.
92
93## References & Resources
94
95### Documentation
96- [API Documentation Templates](./references/api-templates.md) - Endpoint, SDK, and function documentation patterns
97- [Feature Documentation Templates](./references/feature-templates.md) - Feature overview, rollout, and troubleshooting patterns
98- [Configuration Documentation Templates](./references/config-templates.md) - Config and environment variable templates
99
100### Scripts
101- [Doc Template Picker](./scripts/doc-template-picker.py) - Print a starter Markdown template for `api`, `feature`, `config`, or `migration`
102
103## Related Skills
104
105- [documentation-authoring](../documentation-authoring/SKILL.md): Use it when the workflow also needs drafting structured technical or product documents.
106- [documentation-quality](../documentation-quality/SKILL.md): Use it when the workflow also needs documentation review standards and quality gates.
107- [documentation-verification](../documentation-verification/SKILL.md): Use it when the workflow also needs final documentation validation before publishing.
108- [notion-docs](../notion-docs/SKILL.md): Use it when the workflow also needs Notion page and database publishing workflows.