| name | docs-canvas |
| description | Render a documentation-style Cursor Canvas that organizes architecture notes, API references, walkthroughs, and how-tos into a navigable layout with sections, tables of contents, and cross-references. Use when the user asks for a docs canvas, documentation overview, architecture walkthrough, API reference page, or wants to render structured documentation as an interactive canvas. |
| metadata | {"category":"user-invoked","version":"1.0.0","tags":"cursor-import, docs-canvas"} |
| disable-model-invocation | true |
Default output: return only the result, blockers, and required evidence. Omit preambles, process narration, repeated context, confidence scores, and follow-up offers. Use at most five bullets unless a required artifact or schema needs more.
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:
- Overview — A short summary card with the purpose of the doc, scope, and audience.
- Table of contents — Navigable list of sections, ideally pinned or sticky so the reader can jump around.
- Body sections — One section per logical unit (architecture, API, examples, gotchas). Each section can mix prose, code blocks, diagrams, and callouts.
- 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.
