documentation-structure
Documentation Structure
This skill defines how documentation is organized and maintained in this repository.
Core Principles
| Principle | Description |
|---|---|
| Separation of Concerns | README (landing), docs/ (reference), CONTRIBUTING (dev workflow) |
| Single Source of Truth | Define once, link everywhere. Never duplicate content. |
| Hub-and-Spoke | docs/README.md is the central navigation hub |
| Vendor Isolation | Each AI platform gets its own directory in docs/ |
Document Responsibilities
User vs Developer Content Separation
CRITICAL RULE: User documentation must ONLY contain fully automated installation methods. All manual setup belongs in developer documentation.
More from miroapp/miro-ai
miro-mcp
>-
235miro-platform
>-
82miro-code-review
Use when the user wants to create a visual code review on a Miro board from a pull/merge request (GitHub, GitLab, or any forge), local uncommitted changes, or a branch comparison — produces a file-changes table, summary/architecture/security docs, and architecture diagrams, then links them back from the PR/MR.
70miro-spec-guide
>-
49miro-diagram
Use when the user wants to create a diagram (flowchart, mindmap, UML class, UML sequence, entity-relationship) on a Miro board from a natural-language description or Mermaid/PlantUML notation.
17miro-browse
Use when the user wants to list, explore, or filter items on a Miro board (frames, sticky notes, cards, shapes, text, images, documents, embeds), or wants to discover what's on a board before diving in.
15