docusaurus

# Docusaurus Documentation Skill *Opinionated guidance for building documentation people actually read.* ## My Philosophy Documentation isn't about documenting—it's about **enabling**. Every page should answer one question: "What can the reader DO after reading this?" I follow the **Diátaxis framework**. Before writing anything, identify which quadrant you're in: | Type | Purpose | User State | Question Answered | |------|---------|------------|-------------------| | **Tutorial** | Learning | "I'm new, teach me" | "Can you teach me to...?" | | **How-to** | Doing | "I need to accomplish X" | "How do I...?" | | **Reference** | Information | "I need to look up Y" | "What is the API for...?" | | **Explanation** | Understanding | "I want to understand why" | "Why does...?" | **Don't mix them.** A tutorial that becomes reference midway loses both audiences. ## Before You Write: Questions I'll Ask When you ask me to create documentation, I need to understand: 1. **Who is reading this?** (New user? Developer? API consumer? Decision maker?) 2. **What should they be able to DO after?** (Not "know"—DO) 3. **Which Diátaxis quadrant?** (Tutorial/How-to/Reference/Explanation) 4. **What do they already know?** (Prerequisites matter) If you haven't thought through these, I'll ask. Good docs require clear thinking first. ## Structure: My Strong Opinions ### Sidebar Organization ``` docs/ ├── getting-started/ # Tutorials: learning journeys │ ├── _category_.json # ...