docs-canvas

# Docs Canvas Build a canvas that presents documentation — architecture notes, API references, design docs, runbooks, or codebase walkthroughs — as an interactive, navigable surface rather than as a flat markdown file. > **Status:** placeholder. The skill structure is in place so the canvas > welcome page can surface this plugin via the marketplace query, but the > full skill body still needs to be written. Treat the steps below as a > starting outline and refine as the docs canvas pattern matures. ## Prerequisites Read `~/.cursor/skills-cursor/canvas/SKILL.md` first. It contains the generation policy, design guidance, slop rules, self-check, and file-path conventions you must follow. The full component and hook surface is declared in `~/.cursor/skills-cursor/canvas/sdk/index.d.ts` and its sibling `.d.ts` files — read them to discover exact exports and prop shapes rather than guessing. ## Gather the source material Accept any of: a directory of markdown files, a single doc URL, an inline outline, or a question to answer from the codebase. Collect headings, code blocks, diagrams, and any cross-references between documents. ## Plan the canvas layout Decide the top-level structure before writing any components. A docs canvas usually has: 1. **Overview** — A short summary card with the purpose of the doc, scope, and audience. 2. **Table of contents** — Navigable list of sections, ideally pinned or sticky so the reader can jump around. 3. **Body sections** — One section per logical unit (architecture, API, examples, gotchas). Each section can mix prose, code blocks, diagrams, and callouts. 4. **References** — Links to related docs, source files, RFCs, and external material. ## Render with canvas primitives Prefer built-in canvas components over raw HTML: - Use cards/sections to group related content visually. - Use code blocks with syntax highlighting for snippets. - Use diagrams (DAG layout, mermaid) for architecture. - Use callouts for "Important", "Warning", "Note", "Deprecated". - Use tables for API parameter lists and option matrices. ## Tone and content Write reader-facing prose. Lead with the answer or the headline, then explain. Keep examples small and runnable. Cite source files with `code references` so readers can jump in. ## Be creative The sections above are a floor, not a ceiling. The goal is the fastest possible path for the reader to understand the topic — so look at the source material in front of you and ask what representation would actually help. A diagram, a sequence chart, a side-by-side comparison, a decision tree, a glossary, a curated FAQ, a single large worked example — whatever fits.