[!NOTE]
Environment Dependencies: Drawing on the whiteboard requires
@larksuite/whiteboard-cli
(Whiteboard Node.js CLI tool) and
(LarkSuite CLI tool).
If execution fails, install manually and try again:
npm install -g @larksuite/whiteboard-cli@^0.2.0
[!IMPORTANT]
Be sure to get user consent before executing
to install new dependencies!
Workflow
This is a whiteboard, not a web page. Elements are placed freely on an infinite canvas, and flex layout is an optional enhancement.
Step 1: Routing & Knowledge Reading
- Determine the rendering path (see routing table): Mermaid or DSL?
- Read the corresponding scene guide — understand structural features and layout strategies
- Determine the layout strategy (see quick judgment below) and construction method
- Read references/ core modules — syntax, layout, color matching, typography, connectors
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
- It is recommended to use icons to make the chart more intuitive, run `npx -y @larksuite/whiteboard-cli@^0.2.0 --icons` to view available icons and select appropriate ones. Do not overuse icons or use them for all charts, choose whether to use icons according to chart type and content
- Color according to style.md (use the default classic color palette if not specified by the user)
- Output complete JSON according to schema.md syntax
- Refer to connectors.md for connections, refer to typography.md for typesetting
Note: For some graphics (fishbone, flywheel, bar chart, line chart, etc.), you need to write a .js script according to the script template in the scene guide to generate JSON:
1. Create output directory ./diagrams/YYYY-MM-DDTHHMMSS/
2. Save the script as diagram.gen.js, execute node diagram.gen.js to generate diagram.json
3. Use the generated diagram.json to enter Step 3
Step 3: Render & Review → Deliver
- Self-check before rendering (see checklist below)
- Render PNG, check:
· Is the information complete? Is the layout reasonable? Is the color matching coordinated?
· Is there no text truncation? No crossing connections?
- If there are problems → fix according to the symptom table → re-render (up to 2 rounds)
- If there are still serious problems after 2 rounds → consider using the Mermaid path as a fallback
- If no problem → deliver:
· User requests upload to LarkSuite Whiteboard → see the description in the "Upload to LarkSuite Whiteboard" section below
· User does not specify → show PNG image to user
Quick Judgment of Layout Strategy (see
for details):
First determine the main layout, then determine the sub-layout: structured information prefers Flex, relationship links prefer Dagre, flexible positioning uses absolute layout.
For the specific boundaries, dangerous modes, and mixed layout principles involving Dagre/Flex, uniformly refer to
; scene files only describe scene differences and do not repeat general layout rules.
The construction method is a strong constraint: When the scene guide requires "script generation", you must first write the script (.js) and execute it with
to generate the JSON file. The coordinates of absolute positioning scenarios (fishbone diagram, flywheel diagram, bar chart, line chart, etc.) require mathematical calculation, and directly writing JSON by hand can easily lead to node overlap or connection penetration.
Rendering Path Selection (DSL or Mermaid)
| Chart Type | Path | Reason |
|---|
| Mind Map | Mermaid | Automatic radial structure layout |
| Sequence Diagram | Mermaid | Automatic arrangement of participants and messages |
| Class Diagram | Mermaid | Automatic class relationship layout |
| Pie Chart | Mermaid | Native Mermaid support |
| All other types | DSL | Precise control of style and layout |
Routing Rules:
- Automatic Mermaid: Mind maps, sequence diagrams, class diagrams, pie charts → use Mermaid by default
- Explicit Mermaid: User input contains Mermaid syntax → use Mermaid
- DSL Path: All other types → read core modules first, then read the corresponding scene guide
Mermaid Path: Refer to
to write
files, skip DSL modules.
DSL Path: Execute according to the 3 steps of Workflow.
Module Index
Core References (Required for DSL Path)
| Module | File | Description |
|---|
| DSL Syntax | | Node types, attributes, size values |
| Content Planning | | Information extraction, density decision, connection prediction |
| Layout System | | Grid methodology, Flex mapping, spacing rules |
| Typography Rules | | Font size hierarchy, alignment, line spacing |
| Connection System | | Topology planning, anchor point selection |
| Color Matching System | | Multi-color palettes, visual hierarchy |
Scene Guides (Select one according to type)
| Chart Type | File | Applicable Scenarios |
|---|
| Architecture Diagram | | Layered architecture, microservice architecture |
| Organizational Chart | | Company organization, tree hierarchy |
| Swimlane Diagram | | Cross-role processes, cross-system interaction processes, end-to-end links |
| Comparison Chart | | Solution comparison, function matrix |
| Fishbone Diagram | | Cause and effect analysis, root cause analysis |
| Bar Chart | | Bar chart, horizontal bar chart |
| Line Chart | | Line chart, trend chart |
| Treemap | | Rectangular treemap, hierarchical proportion |
| Funnel Chart | | Conversion funnel, sales funnel |
| Pyramid Chart | | Hierarchical structure, hierarchy of needs |
| Loop/Flywheel Diagram | | Growth flywheel, closed-loop link |
| Milestone | | Timeline, version evolution |
| Flowchart | | Business flow, state machine, links with conditional judgment |
| Mermaid | | Mind map, sequence diagram, class diagram, pie chart |
File Output Specification
Each drawing creates a subdirectory under
according to the current time (format
), and the file names in the directory are fixed. If the user specifies a save path, follow the user's specification.
./diagrams/
2026-03-27T143000/ ← Automatically created by time, no need to name
diagram.json ← DSL (CLI input)
diagram.gen.js ← Coordinate calculation script (only for script construction method)
diagram.png ← Final image
diagram.mmd ← Mermaid source code (only for Mermaid path)
CLI Commands
View available icons:
bash
npx -y @larksuite/whiteboard-cli@^0.2.0 --icons
Render:
bash
npx -y @larksuite/whiteboard-cli@^0.2.0 -i ./diagrams/2026-03-27T143000/diagram.json -o ./diagrams/2026-03-27T143000/diagram.png # DSL
npx -y @larksuite/whiteboard-cli@^0.2.0 -i ./diagrams/2026-03-27T143000/diagram.mmd -o ./diagrams/2026-03-27T143000/diagram.png # Mermaid
Upload to LarkSuite Whiteboard:
Upload requires LarkSuite authentication. When encountering authentication or permission errors, read
to learn about login and permission handling.
Step 1: Get Whiteboard Token
| What the user provides | How to get the Token |
|---|
| Whiteboard Token () | Use directly |
| Document URL or doc_id, whiteboard already exists in the document | lark-cli docs +fetch --doc <URL> --as user
, extract token from the returned <whiteboard token=”XXX”/>
|
| Document URL or doc_id, need to create a new whiteboard | lark-cli docs +update --doc <doc_id> --mode append --markdown '<whiteboard type=”blank”></whiteboard>' --as user
, get token from in the response |
For more operations such as creating and reading LarkSuite documents, please refer to the lark-doc skill
.
Step 2: Upload
[!CAUTION]
MANDATORY PRE-FLIGHT CHECK
When you want to write content to an
existing whiteboard Token, it is
absolutely forbidden to execute the upload command directly! You must strictly follow the two steps below:
Mandatory Dry Run (status detection)
You must first add the
parameter to the command to detect the current status of the whiteboard. Example command:
bash
npx -y @larksuite/whiteboard-cli@^0.2.0 --to openapi -i <input file> --format json | lark-cli whiteboard +update --whiteboard-token <Token> --source - --overwrite --dry-run --as user
Parse results and intercept
- Read the output log of Dry Run carefully.
- 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 through the tool (or direct reply): "The target whiteboard is not empty currently, continuing the update will clear the original XX nodes, do you confirm to overwrite?"
- Only after the user explicitly authorizes "agree to overwrite" can you remove and actually perform the upload.
- The user may ask you not to overwrite and update the whiteboard content, in this case, remove the and parameters before uploading.
bash
npx -y @larksuite/whiteboard-cli@^0.2.0 --to openapi -i <input file> --format json | lark-cli whiteboard +update --whiteboard-token <Whiteboard Token> --source - --yes --as user
The whiteboard cannot be modified once uploaded. If you need to upload as an application identity, replace
with
.
If the whiteboard is not empty, first add
to check the number of nodes to be deleted, and remove
to execute after confirming with the user.
You can also output the layout in native OpenAPI json format, and then import it into LarkSuite Whiteboard through lark-cli. For more ways to operate the whiteboard with lark-cli, please refer to ../lark-whiteboard/SKILL.md
Symptom → Fix Table (refer to when problems are found during visual review):
| Observed Problem | What to modify |
|---|
| Text is truncated | Change height to fit-content |
| Text overflows the right side of the container | Increase width, or shorten text |
| Nodes overlap or stick together | Increase gap |
| Nodes are crowded together | Increase padding and gap |
| Connection passes through the node | Adjust fromAnchor/toAnchor or increase spacing |
| Large area of blank space | Reduce the width of the outer frame |
| Text and background color are too close | Adjust fillColor or textColor |
| The overall layout is left/right-aligned | Adjust the x coordinate of absolute positioning to center the content |
Pre-rendering Self-check
After generating DSL and before rendering, check quickly:
Key Constraints Quick Check
The most frequently error-prone rules that must be followed even if you do not read the sub-module files.
- The height of nodes containing text must use — fixed values will truncate text
- only takes effect in flex parent containers — width degenerates to 0 under
- Containers with must have fixed width and height — do not use
- connector must be placed in the top-level nodes array — cannot be nested in frame children
- Layer order — array order = drawing order. Elements defined later have higher layers and will overwrite those defined first. Overlay/floating/annotation elements must be placed at the end of the array.
- x/y in flex containers will be completely ignored — use or place in top-level nodes when free positioning is required
- Dagre sub-containers are opaque nodes by default — outer connections cannot address their internal child nodes (the engine will automatically redirect to the shell). When penetration is required, declare +
layoutOptions: { isCluster: true }
❌ Fatal error: Setting x/y in a 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": "成都" },
{ "type": "rect", "x": 540, "y": 0, "text": "康定" }
]}
✅ Correct: Use
or place in top-level nodes for x/y positioning.
❌ Fatal error:
container itself writes
width: "fit-content", height: "fit-content"
, then places absolute coordinate nodes inside
✅ Correct: Set fixed width and height for absolute positioning container first, then place child nodes with x/y inside.