Back to Details

melech-idea-to-canvas

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Turn @<input> into a standalone Cursor Canvas that helps the team quickly understand and align on how we are going to build this.
Accept any starting point: a rough idea, a shower thought, a Slack thread dump, meeting notes, a decision log, a product brief, a PRD fragment, a design doc, an RFC, or a tech spec. The less structured the input, the more the skill must do the structuring work.
This is primarily a knowledge-transfer artifact — not an approval workflow, debate space, or prettier copy of the input.
Core objective: Make what the author knows as easy as humanly possible for the team to absorb without losing important meaning, decisions, constraints, or implementation direction.
Before building the canvas, identify:
  • The problem and why it matters
  • The intended outcome
  • The core mental model
  • The proposed system and how its parts work together
  • The key flows, states, boundaries, and ownership
  • Important decisions and their reasoning
  • Constraints, risks, assumptions, and explicit non-goals
  • The implementation sequence and what each team or component owns
  • Details needed for alignment versus details that can be progressively disclosed
If the input is rough or unstructured, make reasonable inferences to fill gaps, clearly mark them as inferred or assumed, and surface anything the canvas exposes that the author may not have considered.
Presentation principles:
  • Less is more. Do not reproduce the input section by section.
  • Prefer showing over explaining.
  • Use short, direct text only where visuals cannot carry the meaning.
  • Compartmentalize information into independently understandable views.
  • Establish a strong hierarchy: essential understanding first, implementation detail second.
  • Optimize for a reader with 5–10 minutes while allowing deeper exploration.
  • Keep important decisions visible.
  • Put minor mechanics and exhaustive detail in expandable sections or a compact technical appendix.
  • Do not hide uncertainty, meaningful trade-offs, dependencies, or unresolved risks.
  • Do not give every detail equal visual weight.
  • Do not add decorative charts, generic cards, fake metrics, or visuals that explain nothing.
  • Do not overemphasize sign-off, approval status, stakeholder debate, or governance.
Drawings:
  • Use drawings whenever they communicate a point faster or more clearly than prose.
  • Treat drawings as explanatory tools, not decoration.
  • Use them to explain relationships, flows, boundaries, states, timing, ownership, and cause-and-effect.
  • When a drawing carries the idea, keep its supporting text minimal.
  • Every drawing should answer a specific question and be understandable without narration.
  • Do not force a visual when a sentence or short list is clearer.
Choose only visual forms that genuinely clarify the idea, such as:
  • A system or component map
  • A user-to-system journey
  • A sequence or data-flow diagram
  • A lifecycle or state model
  • Responsibility and ownership boundaries
  • A phased implementation path
  • A focused comparison for a meaningful trade-off
Suggested narrative:
  1. What we are building and why
  2. The one-minute mental model
  3. How the system works end to end
  4. The main building blocks and their responsibilities
  5. Critical flows, states, and edge cases
  6. Decisions that shape the implementation
  7. How we will build and roll it out
  8. Risks, assumptions, and intentionally deferred details
  9. Compact technical reference for readers who need depth
Accuracy requirements:
  • Preserve the source's intent.
  • Do not invent requirements, decisions, or certainty beyond what can be reasonably inferred.
  • Clearly distinguish decided, assumed, proposed, and unresolved items.
  • Preserve important terminology from the source.
  • If the input contains contradictions or gaps, surface them quietly and precisely without turning the canvas into a review report.
Canvas requirements:
  • Create an actual 
    .canvas.tsx
    artifact using the Cursor Canvas skill.
  • Make it useful as a standalone artifact without requiring the source input beside it.
  • Use strong visual hierarchy and varied composition — not a wall of identical cards.
  • Use progressive disclosure for secondary details.
  • Keep every view purposeful and scannable.
  • Include no placeholders or empty sections.
  • Before finishing, remove anything that does not improve understanding or implementation alignment.
Final test: For every section, ask:
  1. What must the reader understand here?
  2. Can it be shown more clearly than written?
  3. What can be removed without losing meaning?
将@<input>转换为独立的Cursor Canvas，帮助团队快速理解并就构建方案达成共识。
支持任意起始素材：粗略想法、突发灵感、Slack对话记录、会议纪要、决策日志、产品简报、PRD片段、设计文档、RFC或技术规范。输入的结构化程度越低，本工具需要完成的结构化工作就越多。
这主要是一个知识传递载体——而非审批流程、辩论空间或输入内容的美化副本。
核心目标： 让作者所掌握的知识尽可能易于团队吸收，同时不丢失重要信息、决策、约束条件或实施方向。
在构建画布之前，需明确：
  • 问题是什么，以及其重要性
  • 预期成果
  • 核心思维模型
  • 拟议系统及其各部分的协作方式
  • 关键流程、状态、边界和权责归属
  • 重要决策及其背后的理由
  • 约束条件、风险、假设以及明确的非目标
  • 实施顺序，以及各团队或组件的负责范围
  • 对齐所需的细节与可逐步披露的细节
如果输入内容粗略或非结构化，需合理推断以填补空白，并明确标记这些内容为推断或假设，同时指出画布揭示的、作者可能未考虑到的问题。
呈现原则：
  • 少即是多。不要逐段复制输入内容。
  • 优先可视化展示，而非文字解释。
  • 仅在视觉无法传达含义时使用简短、直接的文字。
  • 将信息划分为可独立理解的模块。
  • 建立清晰的层级结构：先传递核心认知，再展示实施细节。
  • 针对阅读时间为5–10分钟的读者进行优化，同时允许深入探索。
  • 确保重要决策清晰可见。
  • 将次要机制和详尽细节放在可展开的章节或紧凑的技术附录中。
  • 不要隐藏不确定性、有意义的权衡、依赖关系或未解决的风险。
  • 不要给所有细节同等的视觉权重。
  • 不要添加装饰性图表、通用卡片、虚假指标或无实际解释作用的视觉元素。
  • 不要过度强调签署、审批状态、利益相关者争论或治理流程。
绘图原则：
  • 只要绘图比文字能更快或更清晰地传达观点，就使用绘图。
  • 将绘图视为解释工具，而非装饰。
  • 用绘图解释关系、流程、边界、状态、时序、权责归属以及因果关系。
  • 当绘图已经承载核心观点时，配套文字应尽量精简。
  • 每一幅绘图都应回答特定问题，且无需旁白即可理解。
  • 如果一句话或简短列表更清晰，不要强行使用视觉元素。
仅选择能真正阐明观点的视觉形式，例如：
  • 系统或组件映射图
  • 用户-系统交互旅程图
  • 序列或数据流图
  • 生命周期或状态模型
  • 职责与权责边界图
  • 分阶段实施路径图
  • 针对重大权衡的聚焦对比图
建议叙事结构：
  1. 我们要构建什么，以及为什么
  2. 一分钟核心思维模型
  3. 系统端到端的工作原理
  4. 主要构建模块及其职责
  5. 关键流程、状态和边缘情况
  6. 影响实施的决策
  7. 我们将如何构建与推出
  8. 风险、假设以及有意推迟的细节
  9. 供需要深入了解的读者使用的紧凑技术参考
准确性要求：
  • 保留源内容的意图。
  • 不要编造超出合理推断范围的需求、决策或确定性结论。
  • 清晰区分已确定、假设、提议和未解决的内容。
  • 保留源内容中的重要术语。
  • 如果输入内容存在矛盾或空白，应精准、低调地指出，但不要将画布变成审查报告。
画布要求：
  • 使用Cursor Canvas工具创建实际的
    .canvas.tsx
    文件。
  • 确保画布可作为独立工具使用，无需附带源输入内容。
  • 采用清晰的视觉层级和多样化的布局——不要使用千篇一律的卡片堆砌。
  • 对次要细节采用渐进式披露方式。
  • 确保每个视图都有明确目的且易于扫描。
  • 不包含占位符或空白章节。
  • 完成前，移除所有无助于提升理解或实施对齐的内容。
最终测试： 对于每个章节，需自问：
  1. 读者必须在这里理解什么？
  2. 是否可以通过可视化展示比文字更清晰？
  3. 哪些内容可以移除而不丢失核心含义？