Back to Details

figma-generate-diagram

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

generate-diagram

generate-diagram

You MUST load this skill before every 
generate_diagram
tool call. Skipping it causes preventable rendering failures and low-quality output.
generate_diagram
takes Mermaid.js syntax and produces an editable FigJam diagram. This skill routes you to the right per-type guidance and sets universal constraints.
每次调用
generate_diagram
工具前，你必须加载此Skill。 跳过这一步会导致可避免的渲染失败和低质量输出。
generate_diagram
接收Mermaid.js语法并生成可编辑的FigJam图表。此Skill会引导你获取对应类型的正确指南，并设定通用约束条件。

Step 1: Is 
generate_diagram
the right tool?

步骤1：
generate_diagram
是合适的工具吗？

Supported diagram types

支持的图表类型

flowchart
, 
sequenceDiagram
, 
stateDiagram
/ 
stateDiagram-v2
, 
gantt
, 
erDiagram
.
flowchart
、
sequenceDiagram
、
stateDiagram
/ 
stateDiagram-v2
、
gantt
、
erDiagram
。

Unsupported — don't call the tool

不支持的场景——请勿调用工具

If the user wants any of these, tell them directly that 
generate_diagram
doesn't support it instead of calling the tool and failing:
  • Pie chart, mindmap, venn diagram, class diagram, journey, timeline, quadrant, C4, git graph, requirement diagram
如果用户需要以下任何一种图表，请直接告知他们
generate_diagram
不支持，而非调用工具导致失败：
  • 饼图、思维导图、维恩图、类图、用户旅程图、时间线图、象限图、C4图、Git图、需求图

When to push the user to edit in Figma

何时建议用户在Figma中编辑

The tool cannot:
  • Change fonts on an existing diagram
  • Move individual shapes
  • Edit a diagram node-by-node after generation
If the user asks for any of those on an existing diagram, recommend they open the diagram in Figma and edit there. For content-level changes, it's usually faster to regenerate.
该工具无法完成以下操作：
  • 修改现有图表的字体
  • 移动单个图形
  • 生成后逐节点编辑图表
如果用户要求对现有图表执行上述任一操作，建议他们在Figma中打开图表进行编辑。对于内容层面的更改，通常重新生成会更快。

Step 2: Pick the diagram type

步骤2：选择图表类型

Lightweight routing — use the first match.
User wants…TypeNext step
Services + datastores + queues + integrationsArchitecture flowchartRead references/architecture.md
Decision tree, process flow, pipeline, dependency graph, user journeyFlowchartRead references/flowchart.md
Interactions between parties over time (API calls, auth, messaging)Sequence diagramRead references/sequence.md
Data model, tables, keys, cardinalityER diagramRead references/erd.md
Named states with transitions between themState diagramRead references/state.md
Project schedule with dates, milestonesGantt chartRead references/gantt.md
If a flowchart is requested and it describes software infrastructure (services, datastores, queues, external integrations), route to 
architecture.md
— not 
flowchart.md
. When in doubt, ask the user.
简易路由——匹配第一个符合的类型。
用户需求…类型下一步
服务 + 数据存储 + 队列 + 集成架构流程图阅读references/architecture.md
决策树、流程流、管道、依赖图、用户旅程流程图阅读references/flowchart.md
多方随时间的交互（API调用、认证、消息传递）时序图阅读references/sequence.md
数据模型、表格、键、基数ER图阅读references/erd.md
带状态转换的命名状态状态图阅读references/state.md
含日期、里程碑的项目进度表甘特图阅读references/gantt.md
如果用户请求的流程图描述的是软件基础设施（服务、数据存储、队列、外部集成），请引导至
architecture.md
而非
flowchart.md
。如有疑问，请询问用户。

Step 3: Universal constraints (apply to every diagram type)

步骤3：通用约束（适用于所有图表类型）

  1. No emojis in any part of the Mermaid source. The tool rejects them.
  2. No 
    \n
     in labels. Use newlines only when absolutely required and only via actual line breaks (not the escape sequence).
  3. No HTML tags in labels.
  4. Reserved words — don't use 
    end
    , 
    subgraph
    , 
    graph
    as node IDs.
  5. Node IDs: camelCase (
    userService
    ), no spaces. Underscores can break edge routing in some processors.
  6. Special characters in labels must be wrapped in quotes: 
    A["Process (main)"]
    , 
    -->|"O(1) lookup"|
    .
  7. Sequence diagrams — do not use notes.
  8. Gantt charts — do not use color styling.
  1. Mermaid源代码的任何部分都不得使用表情符号，工具会拒绝此类代码。
  2. 标签中不得使用
    \n
    。仅在绝对必要时使用换行，且只能通过实际换行符（而非转义序列）实现。
  3. 标签中不得使用HTML标签。
  4. 保留字——请勿将
    end
    、
    subgraph
    、
    graph
    用作节点ID。
  5. 节点ID：采用驼峰式命名（
    userService
    ），不含空格。下划线可能会在某些处理器中破坏边缘路由。
  6. 标签中的特殊字符必须用引号包裹：
    A["Process (main)"]
    、
    -->|"O(1) lookup"|
    。
  7. 时序图——请勿使用注释。
  8. 甘特图——请勿使用颜色样式。

Step 4: Garbage in, garbage out

步骤4：垃圾进，垃圾出

The quality of the generated diagram is bounded by the quality of the Mermaid you produce, which is bounded by the context you have. Before writing Mermaid, make sure you have enough real information to describe the subject accurately — and use whatever the current environment gives you to gather it.
Depending on what's available, useful sources of context include:
  • Source code — grep/read the relevant files so the diagram reflects real service names, real edge labels, real data stores, real entry points. Walking actual routes/handlers/consumers beats recreating from memory.
  • User-provided documents — a PRD, spec, meeting notes, transcript, research synthesis, onboarding doc, process write-up. Ask the user to paste or attach it if the subject isn't code.
  • Existing Figma or FigJam files — if the new diagram should align with one the user already has, read it with 
    get_figjam
    or 
    get_design_context
    (see the 
    figma-use
    and 
    figma-use-figjam
    skills).
  • Other MCP servers or tools you have available — issue trackers, docs sites, CRMs, analytics, internal wikis, design systems, database schemas, etc. If a connected tool holds the ground truth for what you're diagramming, pull from it rather than guessing.
  • The user themselves — when the description is thin or ambiguous (unclear direction of flow, unclear scope, unclear which entities matter), ask one or two focused questions before generating. Examples: "What are the 3–5 main steps?", "Who owns each step?", "What triggers the next step?". One good question beats one wasted diagram.
Don't invent edges, labels, or entities to "round out" a diagram. Missing information is better than hallucinated information — leave a gap and flag it to the user.
生成图表的质量取决于你编写的Mermaid代码质量，而代码质量又取决于你掌握的上下文信息。在编写Mermaid代码前，请确保你拥有足够的真实信息来准确描述主题——并利用当前环境提供的一切资源来收集信息。
根据可用情况，有用的上下文来源包括：
  • 源代码——搜索/阅读相关文件，使图表反映真实的服务名称、真实的边缘标签、真实的数据存储、真实的入口点。实际梳理路由/处理器/消费者比凭记忆重建更准确。
  • 用户提供的文档——PRD、规格说明、会议记录、转录文本、研究综述、入职文档、流程说明。如果主题不是代码，请让用户粘贴或附上相关文档。
  • 现有Figma或FigJam文件——如果新图表需要与用户已有的图表保持一致，请使用
    get_figjam
    或
    get_design_context
    读取（参见
    figma-use
    和
    figma-use-figjam
    技能）。
  • 其他可用的MCP服务器或工具——问题跟踪器、文档站点、CRM、分析工具、内部维基、设计系统、数据库架构等。如果连接的工具包含你要绘制的图表的真实信息，请从中获取数据，而非猜测。
  • 用户本人——当描述模糊或信息不足时（如流向不明确、范围不清晰、重要实体不确定），在生成图表前先提出一两个针对性问题。例如：“主要步骤有哪3-5个？”、“每个步骤由谁负责？”、“触发下一步的条件是什么？”。一个好问题胜过一次无用的图表生成。
不要为了“完善”图表而凭空编造边缘、标签或实体。缺失信息比虚假信息更好——留出空白并向用户说明。

Step 5: Will the diagram need more than Mermaid can express?

步骤5：图表是否需要Mermaid无法表达的内容？

Mermaid can't do everything. Sticky-note annotations tied to specific nodes, per-node domain coloring on ERDs, callouts with attached data — these all require composing 
generate_diagram
with 
use_figma
(via the figma-use-figjam skill). This is the hybrid workflow.
It's a judgment call, not a default. Deploy it when the user's ask clearly benefits — skip it when the base diagram is obviously enough. Signals that say yes: user explicitly asked for notes, colors, callouts, or "X attached to each node"; they shared data that maps to specific nodes; the diagram is a shareable artifact, not a thinking sketch. Signals that say no: short/self-explanatory request, small diagram, user exploring or testing.
If hybrid is warranted, read references/workflow.md before calling 
generate_diagram
 — it covers the pattern, two core recipes (annotations + color-coding), communication style, and failure handling. If not, proceed directly to Step 6.
Mermaid并非无所不能。与特定节点关联的便签注释、ER图上的逐节点领域着色、附带数据的标注——这些都需要将
generate_diagram
与
use_figma
结合使用（通过figma-use-figjam技能）。这就是混合工作流。
这是一个判断性决策，而非默认操作。当用户的需求明显能从中获益时才使用；如果基础图表已足够，则跳过。需要使用混合工作流的信号：用户明确要求添加注释、颜色、标注，或“每个节点附带X”；他们分享了与特定节点关联的数据；图表是可共享的工件，而非思维草图。不需要的信号：简短/自明的请求、小型图表、用户正在探索或测试。
如果需要使用混合工作流，请在调用
generate_diagram
前阅读references/workflow.md——它涵盖了模式、两个核心方案（注释+颜色编码）、沟通方式和故障处理。如果不需要，则直接进入步骤6。

Step 6: Calling the tool

步骤6：调用工具

Required:
  • name
    : a descriptive title (shown to the user)
  • mermaidSyntax
    : the Mermaid source
Optional:
  • userIntent
    : a short sentence describing what the user is trying to accomplish — helps telemetry and downstream tuning
  • useArchitectureLayoutCode
    : only for architecture diagrams; value is specified in 
    references/architecture.md
  • fileKey
    : if the user wants the diagram added to an existing FigJam file instead of a new one
Do not call 
create_new_file
before 
generate_diagram
— the tool creates its own file.
必填参数：
  • name
    ：描述性标题（展示给用户）
  • mermaidSyntax
    ：Mermaid源代码
可选参数：
  • userIntent
    ：描述用户试图完成的任务的短句——有助于遥测和下游优化
  • useArchitectureLayoutCode
    ：仅适用于架构图；取值在
    references/architecture.md
    中指定
  • fileKey
    ：如果用户希望将图表添加到现有FigJam文件而非新建文件中
请勿在调用
generate_diagram
前调用
create_new_file
——该工具会自行创建文件。

Step 7: After generation

步骤7：生成后

  • The tool returns a link (or widget) the user can click to open the diagram in FigJam. Show it as a markdown link unless the client renders an inline widget.
  • If extensions are warranted (see Step 5), compose with 
    use_figma
    now — the pattern and recipes are in references/workflow.md.
  • If the user is dissatisfied after 2 attempts at the same diagram, stop regenerating. Ask what specifically is wrong, or suggest they open it in Figma and edit manually rather than burning more tool calls.
  • 工具会返回一个链接（或小部件），用户可点击在FigJam中打开图表。除非客户端渲染内联小部件，否则请以Markdown链接形式展示。
  • 如果需要扩展（参见步骤5），现在可结合
    use_figma
    使用——模式和方案在references/workflow.md中。
  • 如果用户在两次尝试生成同一图表后仍不满意，请停止重新生成。询问具体问题所在，或建议他们在Figma中打开图表手动编辑，而非浪费更多工具调用次数。

Reuse the same file when iterating or adding related diagrams

迭代或添加相关图表时重用同一文件

Every call to 
generate_diagram
without a 
fileKey
creates a new FigJam file in the user's drafts. Regenerating 4 times = 4 draft files to clean up. Prefer reusing the existing file when:
  • The user is iterating on the same diagram ("try again with…", "change the labels…").
  • The user wants a follow-up diagram that lives alongside the first (e.g. a sequence diagram next to a flowchart of the same system).
How to reuse:
  1. Pass 
    fileKey
     on subsequent 
    generate_diagram
    calls. Extract from a 
    figma.com/board/{fileKey}/...
    URL. The diagram is added to the existing file rather than creating a new one.
  2. If you want to replace the previous diagram rather than adding next to it, use the 
    use_figma
    tool (see the 
    figma-use-figjam
    skill) to delete the old diagram's nodes first, then call 
    generate_diagram
    with the same 
    fileKey
    . Or leave the old diagram and place the new one beside it — readers often benefit from seeing the history of attempts.
Ask the user which they prefer the first time you iterate — "regenerate over the old one, or keep both side-by-side?" — and remember their answer for subsequent iterations in the session.
每次未指定
fileKey
的
generate_diagram
调用都会在用户的草稿中创建一个新的FigJam文件。重新生成4次=4个需要清理的草稿文件。以下情况建议重用现有文件：
  • 用户正在迭代同一图表（“再试一次……”、“修改标签……”）。
  • 用户需要添加与第一个图表配套的后续图表（例如，同一系统的时序图和流程图放在一起）。
重用方法：
  1. 在后续
    generate_diagram
    调用中传入
    fileKey
    。从
    figma.com/board/{fileKey}/...
    URL中提取。图表会添加到现有文件中，而非新建文件。
  2. 如果你想替换之前的图表而非添加在旁边，请先使用
    use_figma
    工具（参见
    figma-use-figjam
    技能）删除旧图表的节点，然后使用相同的
    fileKey
    调用
    generate_diagram
    。或者保留旧图表，将新图表放在旁边——读者通常能从查看尝试历史中获益。
第一次迭代时请询问用户的偏好：“是覆盖旧图表，还是将两者并排保留？”——并在会话的后续迭代中记住他们的答案。