design-to-canvas 是一个把设计文档转化为独立 Cursor Canvas 的技能，目标是帮助团队快速理解并对齐“我们将如何构建这个东西”。它主要是一个知识传递产物，而不是审批工作流、辩论空间，也不是文档的漂亮副本。
核心目标：让作者已知的内容尽可能容易被团队吸收，同时不丢失重要含义、决策、约束或实现方向。
在构建 Canvas 之前，需要识别以下内容：
- 问题是什么以及为什么重要
- 预期结果
- 核心心智模型
- 提议的系统及其各部分如何协同工作
- 关键流程、状态、边界和归属
- 重要决策及其理由
- 约束、风险、假设和明确的非目标
- 实施顺序以及每个团队或组件负责什么
- 哪些细节用于对齐，哪些细节可以渐进式披露
呈现原则：
- 少即是多，不要逐节复制文档。
- 优先展示而非解释。
- 仅在视觉无法承载含义时使用简短直接的文字。
- 将信息分隔为可独立理解的视图。
- 建立强层次：先核心理解，后实现细节。
- 面向 5–10 分钟的读者优化，同时允许深入探索。
- 让重要决策保持可见。
- 将次要机制和详尽细节放入可展开区域或紧凑的技术附录。
- 不要隐藏不确定性、有意义的权衡、依赖或未解决的风险。
- 不要给每个细节相同的视觉权重。
- 不要添加装饰性图表、通用卡片、虚假指标或无法解释任何内容的视觉元素。
- 不要过度强调签署、审批状态、利益相关者辩论或治理。
绘图：
- 当绘图比文字更快或更清晰地传达观点时使用绘图。
- 将绘图视为解释工具，而非装饰。
- 用它们解释关系、流程、边界、状态、时序、归属和因果关系。
- 当绘图承载想法时，保持其支持文字最少。
- 每张图都应回答一个具体问题，并且无需旁白即可理解。
- 当一句话或短列表更清晰时，不要强行使用视觉。
- 只选择真正能阐明设计的视觉形式，例如：系统或组件图、用户到系统的旅程、序列或数据流图、生命周期或状态模型、职责与归属边界、分阶段实施路径、针对有意义权衡的聚焦对比。
建议的叙述结构：
- 我们在构建什么以及为什么
- 一分钟心智模型
- 系统如何端到端工作
- 主要构建块及其职责
- 关键流程、状态和边缘情况
- 影响实现的决策
- 我们将如何构建和推出
- 风险、假设和有意推迟的细节
- 面向需要深度读者的紧凑技术参考
准确性要求：
- 保留源文档的意图。
- 不要编造需求、决策或确定性。
- 清楚区分已决定、假设、提议和未解决的事项。
- 保留源文档中的重要术语。
- 如果文档包含矛盾或缺口，安静而精确地呈现它们，不要将 Canvas 变成审查报告。
Canvas 要求：
- 使用 Cursor Canvas 技能创建实际的 .canvas.tsx 工件。
- 使其作为独立工件有用，无需源文档在旁边。
- 使用强视觉层次和多样化的构图——不是一堵相同的卡片墙。
- 对次要细节使用渐进式披露。
- 保持每个视图有目的且可扫描。
- 不包含占位符或空章节。
- 完成前，移除任何不能提升理解或实现对齐的内容。
最终测试：对每个章节问：读者在这里必须理解什么？它能比文字更清晰地展示吗？移除什么可以不丢失含义？