beautiful-feishu-whiteboard

name	beautiful-feishu-whiteboard
label	更美观的画板
version	1.1.1-game.2
description	生成美观、可编辑的飞书画板（Whiteboard），偏向技术/代码实现方向——代码架构、模块/类关系、调用链、协议消息结构、数据结构与存储、状态机、算法控制流等。内置 35 种精选配色风格，输入标题、主题即可自动匹配布局与配色，写入飞书云文档，支持风格切换。触发关键词：画板、whiteboard、飞书画板、架构图、类图、时序图、流程图、状态机、数据结构、协议图、思维导图。

Beautiful Feishu Whiteboard

A design system skill: 35 colour palette styles plus the verified hard rules of the Feishu SVG whiteboard medium, so you can build gorgeous, on brand, editable whiteboards.

This is not an auto layout chart generator. You compose the layout. A template gives you a palette and mood; RULES.md gives you the medium's hard limits. The board you produce is a real, editable Feishu whiteboard inside a doc, not a screenshot.

When to use

• The user wants a Feishu / Lark whiteboard, infographic, diagram, poster, or visual explainer that should look good, branded, or in a specific aesthetic.
• The user names a style, or points at one of the templates.
• The user gives content ("explain X as a whiteboard", "turn this into a board") and wants it visual and editable inside Feishu.

游戏项目（Game projects）

如果用户来自游戏项目，或要画的是一块技术 / 代码相关的板（代码架构、类关系、调用链、协议消息 结构、数据结构、存储表结构、状态机、算法控制流等），先读 GAME_GUIDE.md——它 把这些技术代码场景映射到「布局形态 + 推荐风格 + 实现注意点」。选风格仍用 CATALOG.md， 技术 / 代码场景优先参考 GAME_GUIDE.md 的速查表。

Step 0: prerequisites (check before doing anything)

Run scripts/preflight.sh, or check manually:

• Node 20 or newer.
• lark-cli (npm package @larksuite/cli), installed and authenticated. If missing: npm install -g @larksuite/cli, then lark-cli config init (scan the QR), then lark-cli auth login.
• @larksuite/whiteboard-cli, used via npx, auto downloads, no install needed.
• A Feishu / Lark account. The board is written to the user's own tenant.

If lark-cli is missing or not authenticated, tell the user exactly how to install and authenticate, then stop. You cannot write a board without it.

How to run the conversation

1. Understand the board. Find out what the user wants on it: the content, the purpose, the audience. If it is unclear, ask one short question before building.
2. Ask about the vibe. Ask the user what visual style they want, for example playful or professional, any colour or mood preference, or a brand to match. Offer to pick for them if they have no preference. If they already named a style, skip ahead.
3. Pick a style. Use CATALOG.md to match the content type and the requested vibe and formality to one of the 35 styles. The catalogue lists each style's palette signature, so choose from it alone — don't open several design.md files to compare. Tell the user which style you chose and why, in one line.
4. Build it. Read RULES.md and only the one chosen templates/<slug>/design.md, then:
   • Compose the SVG in a logical space about 1600 to 1700 wide, in that palette, with native shapes only (rect, rounded rect, circle, ellipse, connectors, text). Lay the content out however reads best. Every label is a <text>; never set font-family.
   • Only the content goes on the board, never the instruction behind it. Do not print the user's prompt, scope notes, source citations, the chosen style name, or any "summary of… / 来源… / 风格…" meta line onto the canvas — that looks like a homework header. Such context belongs in your chat reply. (See the "Never echo the user's instructions" rule in RULES.md.)
   • Render it, then look at the image and correct yourself: fix text overflow, tight margins or padding, numerals touching edges, accidental overlaps, and clipping. Iterate render, view, fix until it is clean. (Commands and the full checklist are in RULES.md.) When fixing, edit the .svg file in place with small targeted edits (move a box, widen a panel, rewrap a label) — do not regenerate the whole SVG each pass; and batch the fixes you see in one view into a single edit pass before re-rendering, rather than one fix per render.
   • Write it into a Feishu doc as an editable whiteboard, then view the live board image too and fix any remaining layout issues.
5. Give the user : the and the itself, so they can see it without opening the doc. Then tell them they can any time, and you will re render the same content in the new palette.

Files

• RULES.md: the hard rules and the exact build, write, and verify commands. Always read this.
• CATALOG.md: every style with its vibe, formality, and what it is good for. Use it to choose.
• GAME_GUIDE.md: 技术代码场景指南——代码架构 / 类关系 / 调用链 / 协议结构 / 数据结构 / 存储 / 状态机 / 算法控制流等场景的布局与风格映射。
• templates/<slug>/design.md: one per style, the colour palette and how to use it.
• scripts/preflight.sh: dependency and auth check.