Back to Details

docs-canvas

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

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.
构建一个以交互式可导航界面展示文档的画布——涵盖架构笔记、API参考、设计文档、运行手册或代码库操作指南——而非以扁平化的Markdown文件形式呈现。
状态： 占位符。技能结构已搭建完成，因此画布欢迎页面可通过市场查询展示此插件，但完整的技能主体仍需编写。请将以下步骤视为初始大纲，并随着文档画布模式的成熟进行优化。

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.
请先阅读
~/.cursor/skills-cursor/canvas/SKILL.md
。其中包含你必须遵循的生成规则、设计指南、容错规则、自检要求和文件路径约定。完整的组件与钩子接口声明在
~/.cursor/skills-cursor/canvas/sdk/index.d.ts
及其同级
.d.ts
文件中——请阅读这些文件以了解确切的导出内容和属性形状，而非自行猜测。

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.
接受以下任意形式的源材料：Markdown文件目录、单个文档URL、内联大纲，或针对代码库的待解答问题。收集标题、代码块、图表以及文档之间的所有交叉引用。

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.
在编写任何组件之前，先确定顶层结构。文档画布通常包含：
  1. 概览——一张简短的摘要卡片，包含文档目的、范围和受众。
  2. 目录——可导航的章节列表，最好固定或悬浮，以便读者跳转。
  3. 主体章节——每个逻辑单元对应一个章节（架构、API、示例、注意事项）。每个章节可混合使用散文、代码块、图表和提示框。
  4. 参考资料——指向相关文档、源文件、RFC和外部资料的链接。

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.
优先使用内置画布组件而非原生HTML：
  • 使用卡片/章节将相关内容进行视觉分组。
  • 使用带语法高亮的代码块展示代码片段。
  • 使用图表（DAG布局、mermaid）展示架构。
  • 使用提示框标注“重要”“警告”“注意”“已弃用”。
  • 使用表格展示API参数列表和选项矩阵。

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.
以上章节是基础而非上限。目标是让读者以最快速度理解主题——因此，请审视眼前的源材料，思考哪种呈现方式真正有用。可以是图表、序列图、对比展示、决策树、术语表、精选FAQ、完整的实战示例——任何合适的形式均可。