lark-whiteboard

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Whiteboard Cli Skill

Whiteboard Cli Skill

[!NOTE] 环境依赖:绘制画板需要
@larksuite/whiteboard-cli
(画板 Node.js CLI 工具),以及
lark-cli
(LarkSuite CLI 工具)。 如果执行失败,手动安装后重试:
npm install -g @larksuite/whiteboard-cli@^0.1.0
[!IMPORTANT] 执行
npm install
安装新的依赖前,务必征得用户同意!
[!NOTE] Environment Dependencies: Drawing whiteboard requires
@larksuite/whiteboard-cli
(Whiteboard Node.js CLI tool) and
lark-cli
(LarkSuite CLI tool). If execution fails, install manually and retry:
npm install -g @larksuite/whiteboard-cli@^0.1.0
[!IMPORTANT] Be sure to obtain user consent before executing
npm install
to install new dependencies!

Workflow

Workflow

这是画板,不是网页。 画板是无限画布上自由放置元素,flex 布局是可选增强。
Step 1: 路由 & 读取知识
  - 判断渲染路径(见路由表):Mermaid 还是 DSL?
  - 读对应 scene 指南 — 了解结构特征和布局策略
  - 确定布局策略(见下方快速判断)和构建方式
  - 读 references/ 核心模块 — 语法、布局、配色、排版、连线

Step 2: 生成完整 DSL(含颜色)
  - 按 content.md 规划信息量和分组
  - 按 layout.md 选择布局模式和间距
  - 按 style.md 上色(用户没指定时用默认经典色板)
  - 按 schema.md 语法输出完整 JSON
  - 连线参考 connectors.md,排版参考 typography.md

  注意:部分图形(鱼骨/飞轮/柱状/折线等)等, 要按 scene 指南的脚本模板写 .js 脚本生成 JSON:
    - node xxx.js → 产出 JSON 文件
    - 用产出的 JSON 文件进入 Step 3

Step 3: 渲染 & 审查 → 交付
  - 渲染前自查(见下方检查清单)
  - 渲染 PNG,检查:
    · 信息完整?布局合理?配色协调?
    · 文字无截断?连线无交叉?
  - 有问题 → 按症状表修复 → 重新渲染(最多 2 轮)
  - 2 轮后仍有严重问题 → 考虑走 Mermaid 路径兜底
  - 没问题 → 交付:
    · 用户要求上传飞书 → 见下方”上传飞书画板”章节中的说明
    · 用户未指定 → 展示 PNG 图片给用户
布局策略快速判断(详见 layout.md):
判断条件布局策略构建方式
有明确上下层级(用户层→服务层→数据层)Flex 分层直接写 JSON
空间位置承载信息(地理、拓扑、角度)纯绝对定位写脚本算坐标(node xxx.js)
多个独立模块平级互联混合(岛屿式)直接写 JSON + 估高辅助
不确定默认 Flex(最安全)直接写 JSON
构建方式是强约束:当 scene 指南要求"脚本生成"时,必须先写脚本(.js)并用
node
执行来产出 JSON 文件。绝对定位场景(鱼骨图、飞轮图、柱状图、折线图等)的坐标需要数学计算,直接手写 JSON 极易导致节点重叠或连线穿模。

This is a whiteboard, not a web page. Whiteboard allows free placement of elements on an infinite canvas, and flex layout is an optional enhancement.
Step 1: Routing & Knowledge Reading
  - Determine rendering path (see routing table): Mermaid or DSL?
  - Read corresponding scene guide — understand structural features and layout strategies
  - Confirm layout strategy (see quick judgment below) and construction method
  - Read references/ core modules — syntax, layout, color scheme, typesetting, connections

Step 2: Generate Complete DSL (Including Colors)
  - Plan information volume and grouping according to content.md
  - Select layout mode and spacing according to layout.md
  - Apply colors according to style.md (use default classic color palette if not specified by user)
  - Output complete JSON according to schema.md syntax
  - Refer to connectors.md for connections and typography.md for typesetting

  Note: For some graphics (fishbone/flywheel/bar/line charts, etc.), write .js scripts according to scene guide templates to generate JSON:
    - node xxx.js → output JSON file
    - Use the generated JSON file to proceed to Step 3

Step 3: Rendering & Review → Delivery
  - Self-check before rendering (see checklist below)
  - Render PNG and check:
    · Is information complete? Is layout reasonable? Is color scheme coordinated?
    · Is text not truncated? Are connections not crossing?
  - If there are issues → fix according to symptom table → re-render (max 2 rounds)
  - If serious issues remain after 2 rounds → consider using Mermaid path as fallback
  - If no issues → deliver:
    · If user requests upload to Feishu → follow instructions in "Upload to Feishu Whiteboard" section below
    · If user doesn't specify → display PNG image to user
Quick Layout Strategy Judgment (see layout.md for details):
Judgment ConditionLayout StrategyConstruction Method
Clear hierarchical structure (user layer → service layer → data layer)Flex LayeredWrite JSON directly
Spatial position carries information (geography, topology, angle)Pure Absolute PositioningWrite script to calculate coordinates (node xxx.js)
Multiple independent modules connected in parallelHybrid (Island-style)Write JSON directly + height estimation assistance
UncertainDefault Flex (most secure)Write JSON directly
Construction method is a strong constraint: When the scene guide requires "script generation", you must first write a script (.js) and execute it with
node
to output the JSON file. Coordinates for absolute positioning scenarios (fishbone diagrams, flywheel diagrams, bar charts, line charts, etc.) require mathematical calculation; manually writing JSON can easily lead to node overlap or connection penetration.

渲染路径选择(DSL or Mermaid)

Rendering Path Selection (DSL or Mermaid)

图表类型路径理由
思维导图Mermaid辐射结构自动布局
时序图Mermaid参与方+消息自动排列
类图Mermaid类关系自动布局
饼图MermaidMermaid 原生支持
流程图Mermaid通过 Mermaid 语法稳定生成结构
其他所有类型DSL精确控制样式和布局
路由规则
  1. 自动 Mermaid:思维导图、时序图、类图、饼图、流程图 → 默认走 Mermaid
  2. 显式 Mermaid:用户输入包含 Mermaid 语法 → 走 Mermaid
  3. DSL 路径:其他所有类型 → 先读核心模块,再读对应场景指南
Mermaid 路径:参考
scenes/mermaid.md
编写
.mmd
文件,跳过 DSL 模块。 DSL 路径:按 Workflow 3 步执行。

Chart TypePathReason
Mind MapMermaidAutomatic layout for radial structure
Sequence DiagramMermaidAutomatic arrangement of participants + messages
Class DiagramMermaidAutomatic layout for class relationships
Pie ChartMermaidNatively supported by Mermaid
FlowchartMermaidStable structure generation via Mermaid syntax
All other typesDSLPrecise control over style and layout
Routing Rules:
  1. Automatic Mermaid: Mind map, sequence diagram, class diagram, pie chart, flowchart → default to Mermaid
  2. Explicit Mermaid: User input contains Mermaid syntax → use Mermaid
  3. DSL Path: All other types → first read core modules, then read corresponding scene guide
Mermaid Path: Refer to
scenes/mermaid.md
to write
.mmd
file, skip DSL modules. DSL Path: Execute according to 3-step Workflow.

模块索引

Module Index

核心参考(DSL 路径必读)

Core References (Required for DSL Path)

模块文件说明
DSL 语法
references/schema.md
节点类型、属性、尺寸值
内容规划
references/content.md
信息提取、密度决策、连线预判
布局系统
references/layout.md
网格方法论、Flex 映射、间距规则
排版规则
references/typography.md
字号层级、对齐、行距
连线系统
references/connectors.md
拓扑规划、锚点选择
配色系统
references/style.md
多色板、视觉层级
ModuleFileDescription
DSL Syntax
references/schema.md
Node types, attributes, size values
Content Planning
references/content.md
Information extraction, density decision, connection prediction
Layout System
references/layout.md
Grid methodology, Flex mapping, spacing rules
Typesetting Rules
references/typography.md
Font size hierarchy, alignment, line spacing
Connection System
references/connectors.md
Topology planning, anchor point selection
Color Scheme System
references/style.md
Multiple color palettes, visual hierarchy

场景指南(按类型选读一个)

Scene Guides (Read one according to type)

图表类型文件适用场景
架构图
scenes/architecture.md
分层架构、微服务架构
组织架构图
scenes/organization.md
公司组织、树形层级
对比图
scenes/comparison.md
方案对比、功能矩阵
鱼骨图
scenes/fishbone.md
因果分析、根因分析
柱状图
scenes/bar-chart.md
柱状图、条形图
折线图
scenes/line-chart.md
折线图、趋势图
树状图
scenes/treemap.md
矩形树图、层级占比
漏斗图
scenes/funnel.md
转化漏斗、销售漏斗
金字塔图
scenes/pyramid.md
层级结构、需求层次
循环/飞轮图
scenes/flywheel.md
增长飞轮、闭环链路
里程碑
scenes/milestone.md
时间线、版本演进
Mermaid
scenes/mermaid.md
思维导图、时序图、类图、饼图、流程图

Chart TypeFileApplicable Scenario
Architecture Diagram
scenes/architecture.md
Layered architecture, microservice architecture
Organizational Chart
scenes/organization.md
Company organization, tree hierarchy
Comparison Chart
scenes/comparison.md
Solution comparison, feature matrix
Fishbone Diagram
scenes/fishbone.md
Causal analysis, root cause analysis
Bar Chart
scenes/bar-chart.md
Bar chart, horizontal bar chart
Line Chart
scenes/line-chart.md
Line chart, trend chart
Treemap
scenes/treemap.md
Rectangular treemap, hierarchical proportion
Funnel Chart
scenes/funnel.md
Conversion funnel, sales funnel
Pyramid Chart
scenes/pyramid.md
Hierarchical structure, demand hierarchy
Cycle/Flywheel Chart
scenes/flywheel.md
Growth flywheel, closed-loop link
Milestone
scenes/milestone.md
Timeline, version evolution
Mermaid
scenes/mermaid.md
Mind map, sequence diagram, class diagram, pie chart, flowchart

CLI 命令

CLI Commands

渲染
bash
npx -y @larksuite/whiteboard-cli@^0.1.0 -i my-diagram.json -o ./images/my-diagram.png        # DSL 路径
npx -y @larksuite/whiteboard-cli@^0.1.0 -i diagram.mmd -o ./images/diagram.png               # Mermaid 路径
npx -y @larksuite/whiteboard-cli@^0.1.0 -i skeleton.json -o ./images/step1.png -l coords.json  # 两阶段(提取坐标)
上传飞书画板
上传需要飞书认证。遇到认证或权限错误时,阅读
../lark-shared/SKILL.md
了解登录和权限处理。
第一步:获取画板 Token
用户给了什么怎么获取 Token
画板 Token(
XXX
直接使用
文档 URL 或 doc_id,文档中已有画板
lark-cli docs +fetch --doc <URL> --as user
,从返回的
<whiteboard token=”XXX”/>
中提取 token
文档 URL 或 doc_id,需要新建画板
lark-cli docs +update --doc <doc_id> --mode append --markdown '<whiteboard type=”blank”></whiteboard>' --as user
,从响应的
data.board_tokens[0]
获取 token
关于飞书文档的创建,读取等更多操作,请参考 lark-doc skill
../lark-doc/SKILL.md
第二步:上传
[!CAUTION] MANDATORY PRE-FLIGHT CHECK (上传前强制拦截检查) 当你要向一个已存在的画板 Token 写入内容时,绝对禁止直接执行上传命令!你必须严格遵守以下两步: 强制执行 Dry Run(状态探测) 必须先在命令中添加
--overwrite --dry-run
参数来探测画板当前状态。示例命令:
bash
npx -y @larksuite/whiteboard-cli@^0.1.0 --to openapi -i <输入文件> --format json | lark-cli docs +whiteboard-update --whiteboard-token <Token> --overwrite --dry-run --as user
解析结果并拦截
  • 仔细阅读 Dry Run 的输出日志。
  • 如果日志包含
    XX whiteboard nodes will be deleted
    :这说明画板非空,当前操作会覆盖并摧毁用户的原有图表!
  • 你必须立即停止操作,并通过
    AskUserQuestion
    工具(或直接回复)向用户确认:”目标画板当前非空,继续更新将清空原有的 XX 个节点,是否确认覆盖?”
  • 只有在用户明确授权”同意覆盖”后,你才能移除
    --dry-run
    真正执行上传。
  • 用户可能会要求你不覆盖更新画板内容,在这种情况下,移除
    --overwrite
    --dry-run
    参数再上传。
bash
npx -y @larksuite/whiteboard-cli@^0.1.0 --to openapi -i <输入文件> --format json | lark-cli docs +whiteboard-update --whiteboard-token <画板Token> --yes --as user
画板一经上传不可修改。如需应用身份上传,将
--as user
替换为
--as bot
。 如果画板非空,先加
--overwrite --dry-run
检查待删除节点数,向用户确认后去掉
--dry-run
执行。
症状→修复表(视觉审查发现问题时参照):
看到的问题改什么
文字被截断height 改为 fit-content
文字溢出容器右侧增大 width,或缩短文字
节点重叠粘连增大 gap
节点挤成一团增大 padding 和 gap
连线穿过节点调整 fromAnchor/toAnchor 或增大间距
大面积空白缩小外层 frame 宽度
文字和背景色太接近调整 fillColor 或 textColor
布局整体偏左/偏右调整绝对定位的 x 坐标使内容居中

Rendering:
bash
npx -y @larksuite/whiteboard-cli@^0.1.0 -i my-diagram.json -o ./images/my-diagram.png        # DSL Path
npx -y @larksuite/whiteboard-cli@^0.1.0 -i diagram.mmd -o ./images/diagram.png               # Mermaid Path
npx -y @larksuite/whiteboard-cli@^0.1.0 -i skeleton.json -o ./images/step1.png -l coords.json  # Two-stage (extract coordinates)
Upload to Feishu Whiteboard:
Upload requires Feishu authentication. When encountering authentication or permission errors, read
../lark-shared/SKILL.md
to learn about login and permission handling.
Step 1: Obtain Whiteboard Token
What User ProvidedHow to Obtain Token
Whiteboard Token (
XXX
)
Use directly
Document URL or doc_id, with existing whiteboard in document
lark-cli docs +fetch --doc <URL> --as user
, extract token from returned
<whiteboard token=”XXX”/>
Document URL or doc_id, need to create new whiteboard
lark-cli docs +update --doc <doc_id> --mode append --markdown '<whiteboard type=”blank”></whiteboard>' --as user
, get token from
data.board_tokens[0]
in response
For more operations such as Feishu document creation and reading, refer to lark-doc skill
../lark-doc/SKILL.md
.
Step 2: Upload
[!CAUTION] MANDATORY PRE-FLIGHT CHECK When you want to write content to an existing whiteboard Token, never execute the upload command directly! You must strictly follow these two steps: Enforce Dry Run (Status Detection) You must first add
--overwrite --dry-run
parameters to the command to detect the current state of the whiteboard. Example command:
bash
npx -y @larksuite/whiteboard-cli@^0.1.0 --to openapi -i <input file> --format json | lark-cli docs +whiteboard-update --whiteboard-token <Token> --overwrite --dry-run --as user
Parse Results and Intercept
  • Carefully read the Dry Run output logs.
  • If the log contains
    XX whiteboard nodes will be deleted
    : This means the whiteboard is not empty, and the current operation will overwrite and destroy the user's original chart!
  • You must stop the operation immediately, and confirm with the user via the
    AskUserQuestion
    tool (or directly reply): "The target whiteboard is currently not empty. Continuing the update will clear the original XX nodes. Are you sure you want to overwrite?"
  • Only after the user explicitly authorizes "agree to overwrite" can you remove
    --dry-run
    and execute the upload.
  • The user may request you to update the whiteboard content without overwriting; in this case, remove the
    --overwrite
    and
    --dry-run
    parameters before uploading.
bash
npx -y @larksuite/whiteboard-cli@^0.1.0 --to openapi -i <input file> --format json | lark-cli docs +whiteboard-update --whiteboard-token <Whiteboard Token> --yes --as user
Once uploaded, the whiteboard cannot be modified. To upload as an application identity, replace
--as user
with
--as bot
. If the whiteboard is not empty, first add
--overwrite --dry-run
to check the number of nodes to be deleted, confirm with the user, then remove
--dry-run
to execute.
Symptom → Fix Table (refer to when visual review finds issues):
Observed IssueWhat to Modify
Text truncatedChange height to fit-content
Text overflows container right sideIncrease width, or shorten text
Nodes overlap and stick togetherIncrease gap
Nodes are crowded togetherIncrease padding and gap
Connections pass through nodesAdjust fromAnchor/toAnchor or increase spacing
Large blank areasReduce outer frame width
Text and background color are too similarAdjust fillColor or textColor
Overall layout is left/right biasedAdjust x coordinate of absolute positioning to center content

渲染前自查

Pre-Rendering Self-Check

生成 DSL 后、渲染前,快速检查:
  • 不同分组用了不同颜色?同组节点样式完全一致?
  • 外层浅色背景、内层白色节点?(外重内轻)
  • 所有节点有边框(borderWidth=2)?文字在背景上清晰可读?
  • 连线用灰色(#BBBFC4),不用彩色?
  • frame 都写了 layout 属性?gap 和 padding 都显式设置了?
  • 含文字节点 height 用 fit-content?connector 在顶层 nodes 数组?

After generating DSL and before rendering, perform a quick check:
  • Different groups use different colors? Nodes in the same group have exactly the same style?
  • Light outer background, white inner nodes? (Heavy outer, light inner)
  • All nodes have borders (borderWidth=2)? Text is clearly readable on the background?
  • Connections use gray (#BBBFC4), not colored?
  • All frames have layout attribute? gap and padding are explicitly set?
  • Height of text-containing nodes uses fit-content? connector is in top-level nodes array?

关键约束速查

Key Constraint Quick Reference

最高频出错的规则,即使不读子模块文件也必须遵守。
  1. 含文字节点的 height 必须用
    'fit-content'
    — 写死数值会截断文字
  2. fill-container
    仅在 flex 父容器中生效
    layout: 'none'
    下宽度退化为 0
  3. connector 必须放在顶层 nodes 数组 — 不能嵌套在 frame children 里
  4. 图层顺序 — 数组顺序 = 绘制顺序。后定义的元素层级越高,会覆盖先定义的。重叠/浮层/标注元素务必放在数组末尾。
  5. flex 容器内的 x/y 会被完全忽略 — 需要自由定位时用
    layout: 'none'
    或放在顶层 nodes
❌ 致命错误:flex 容器内设 x/y,坐标不生效,节点按顺序排列
json
{ "type": "frame", "layout": "vertical", "children": [
  { "type": "rect", "x": 100, "y": 0, "text": "成都" },
  { "type": "rect", "x": 540, "y": 0, "text": "康定" }
]}
✅ 正确:用
layout: "none"
或放在顶层 nodes 用 x/y 定位。
Most frequently violated rules that must be followed even without reading sub-module files.
  1. Height of text-containing nodes must use
    'fit-content'
    — hardcoding values will truncate text
  2. fill-container
    only takes effect in flex parent containers
    — width degenerates to 0 under
    layout: 'none'
  3. connector must be placed in the top-level nodes array — cannot be nested in frame children
  4. Layer order — array order = drawing order. Later-defined elements have higher layers and will cover earlier-defined ones. Overlapping/floating/annotation elements must be placed at the end of the array.
  5. x/y in flex containers are completely ignored — use
    layout: 'none'
    or place in top-level nodes for free positioning
❌ Fatal Error: Setting x/y in flex container, coordinates do not take effect, nodes are arranged in order
json
{ "type": "frame", "layout": "vertical", "children": [
  { "type": "rect", "x": 100, "y": 0, "text": "Chengdu" },
  { "type": "rect", "x": 540, "y": 0, "text": "Kangding" }
]}
✅ Correct: Use
layout: "none"
or place in top-level nodes and use x/y positioning.