Docs Write
Quick Checklist
- Audience and doc type (tutorial/how-to/reference/explanation)
- Clear style, active voice, consistent terms
- Structure: headings, skimmable, examples first
- Include visuals when helpful (mermaid inline; puml when reused)
- API: auth, requests/responses, errors, breaking changes
- ADR/runbook: context, decision/steps, rollback, contacts
- Cross-links and filenames; run docs-check after edits
Workflow
Writing Documentation
IMPORTANT: Before writing documentation, read references/documentation-guide.md to understand all standards, patterns, and requirements. Do not make assumptions about documentation style, structure, or content - always reference the guide for specific details.
Read the full guide first: Load references/documentation-guide.md to understand complete documentation standards
- This ensures you have all context about style, structure, doc types, and examples
- Do not proceed with writing until the guide is loaded in context
Determine doc type: Read references/documentation-guide.md section "Doc Types (Divio)" to choose tutorial, how-to, reference, or explanation
- Tutorial: Learning-oriented, step-by-step for beginners
- How-to: Goal-oriented, task-focused
- Reference: Fact-oriented, API/technical details
- Explanation: Understanding-oriented, concepts and context
Review style guidelines: Read references/documentation-guide.md sections:
- "Style and Voice" - Active voice, clear language, consistent terminology
- "Structure and Skimmability" - Headings, examples first, clear organization
- Reference the guide for exact formatting, terminology, and style requirements
Draft content: Use the checklist above, include code examples, and follow the structure guidelines from the guide
Add visuals if needed: Read references/documentation-guide.md section "Visuals and Diagrams"
- Use Mermaid for inline diagrams (ER diagrams, sequence diagrams)
- Use PlantUML (.puml files) for diagrams referenced from multiple docs
- See examples in the guide for exact syntax - do not guess
- Use
look_at to interpret screenshots or diagrams before documenting
- Use
ui_to_artifact for a starter code snippet from a mockup
For API documentation: Read references/documentation-guide.md section "API Documentation"
- Document authentication, request/response formats, error codes
- Include examples for all endpoints (see guide for format)
- Document breaking changes prominently
For ADRs/Runbooks: Read references/documentation-guide.md section "ADRs and Runbooks"
- ADRs: Context, decision, consequences
- Runbooks: Steps, rollback procedures, contacts
- Follow exact templates from the guide
Review and finalize: Read references/documentation-guide.md section "Templates and Checklists"
- Verify all checklist items are addressed
- Add cross-references to related documentation
- Ensure consistent terminology (check guide for exact terms)
Verify: Run bash skills/docs-check/scripts/check-docs.sh to ensure documentation is complete
Reference Files
REQUIRED: Always read references/documentation-guide.md before writing documentation. The guide contains all standards, examples, and requirements. Do not make assumptions - load the guide and reference specific sections.
Read these sections from references/documentation-guide.md as needed:
- Style and Voice (
#style-and-voice) - Writing style, active voice, terminology
- Structure and Skimmability (
#structure-and-skimmability) - Organization, headings, examples
- Doc Types (Divio) (
#doc-types-divio) - Tutorial, how-to, reference, explanation types
- API Documentation (
#api-documentation) - API docs patterns, examples, error handling
- ADRs and Runbooks (
#adrs-and-runbooks) - Decision records and operational procedures
- Visuals and Diagrams (
#visuals-and-diagrams) - Mermaid and PlantUML usage
- Templates and Checklists (
#templates-and-checklists) - Documentation checklists
- When to Document (
#when-to-document) - What changes require documentation
Full guide: references/documentation-guide.md - Complete documentation standards and best practices
Integration with Other Skills
- Use after
ada::docs:check flags required updates.
- Combine with
ada::code-review outcomes to address documentation feedback.
- Run
ada::code-quality after docs updates if code touched.
Examples
- New feature: choose how-to; add overview, steps, examples, and links; add diagram if complex.
- API change: document auth, requests/responses, errors, breaking changes; link to workflows.
- Schema change: update schema doc and ER diagram; link from API/feature docs if impacted.
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: lukasstrickler-ai-dev-atelier-docs-write3description: Docs Write4---56# Docs Write78## Quick Checklist910- Audience and doc type (tutorial/how-to/reference/explanation)11- Clear style, active voice, consistent terms12- Structure: headings, skimmable, examples first13- Include visuals when helpful (mermaid inline; puml when reused)14- API: auth, requests/responses, errors, breaking changes15- ADR/runbook: context, decision/steps, rollback, contacts16- Cross-links and filenames; run docs-check after edits1718## Workflow1920### Writing Documentation2122**IMPORTANT**: Before writing documentation, read `references/documentation-guide.md` to understand all standards, patterns, and requirements. Do not make assumptions about documentation style, structure, or content - always reference the guide for specific details.23241. **Read the full guide first**: Load `references/documentation-guide.md` to understand complete documentation standards25 - This ensures you have all context about style, structure, doc types, and examples26 - Do not proceed with writing until the guide is loaded in context27282. **Determine doc type**: Read `references/documentation-guide.md` section "Doc Types (Divio)" to choose tutorial, how-to, reference, or explanation29 - Tutorial: Learning-oriented, step-by-step for beginners30 - How-to: Goal-oriented, task-focused31 - Reference: Fact-oriented, API/technical details32 - Explanation: Understanding-oriented, concepts and context33343. **Review style guidelines**: Read `references/documentation-guide.md` sections:35 - "Style and Voice" - Active voice, clear language, consistent terminology36 - "Structure and Skimmability" - Headings, examples first, clear organization37 - Reference the guide for exact formatting, terminology, and style requirements38394. **Draft content**: Use the checklist above, include code examples, and follow the structure guidelines from the guide40415. **Add visuals if needed**: Read `references/documentation-guide.md` section "Visuals and Diagrams"42 - Use Mermaid for inline diagrams (ER diagrams, sequence diagrams)43 - Use PlantUML (.puml files) for diagrams referenced from multiple docs44 - See examples in the guide for exact syntax - do not guess45 - Use `look_at` to interpret screenshots or diagrams before documenting46 - Use `ui_to_artifact` for a starter code snippet from a mockup47486. **For API documentation**: Read `references/documentation-guide.md` section "API Documentation"49 - Document authentication, request/response formats, error codes50 - Include examples for all endpoints (see guide for format)51 - Document breaking changes prominently52537. **For ADRs/Runbooks**: Read `references/documentation-guide.md` section "ADRs and Runbooks"54 - ADRs: Context, decision, consequences55 - Runbooks: Steps, rollback procedures, contacts56 - Follow exact templates from the guide57588. **Review and finalize**: Read `references/documentation-guide.md` section "Templates and Checklists"59 - Verify all checklist items are addressed60 - Add cross-references to related documentation61 - Ensure consistent terminology (check guide for exact terms)62639. **Verify**: Run `bash skills/docs-check/scripts/check-docs.sh` to ensure documentation is complete6465## Reference Files6667**REQUIRED**: Always read `references/documentation-guide.md` before writing documentation. The guide contains all standards, examples, and requirements. Do not make assumptions - load the guide and reference specific sections.6869Read these sections from `references/documentation-guide.md` as needed:7071- **Style and Voice** (`#style-and-voice`) - Writing style, active voice, terminology72- **Structure and Skimmability** (`#structure-and-skimmability`) - Organization, headings, examples73- **Doc Types (Divio)** (`#doc-types-divio`) - Tutorial, how-to, reference, explanation types74- **API Documentation** (`#api-documentation`) - API docs patterns, examples, error handling75- **ADRs and Runbooks** (`#adrs-and-runbooks`) - Decision records and operational procedures76- **Visuals and Diagrams** (`#visuals-and-diagrams`) - Mermaid and PlantUML usage77- **Templates and Checklists** (`#templates-and-checklists`) - Documentation checklists78- **When to Document** (`#when-to-document`) - What changes require documentation7980**Full guide**: `references/documentation-guide.md` - Complete documentation standards and best practices8182## Integration with Other Skills8384- Use after `ada::docs:check` flags required updates.85- Combine with `ada::code-review` outcomes to address documentation feedback.86- Run `ada::code-quality` after docs updates if code touched.8788## Examples8990- New feature: choose how-to; add overview, steps, examples, and links; add diagram if complex.91- API change: document auth, requests/responses, errors, breaking changes; link to workflows.92- Schema change: update schema doc and ER diagram; link from API/feature docs if impacted.9394---95> Converted and distributed by [TomeVault](https://tomevault.io/claim/lukasstrickler) — claim your Tome and manage your conversions.96<!-- tomevault:4.0:skill_md:2026-04-13 -->