beautiful-feishu-whiteboard: palette styles for editable Feishu whiteboards

What beautiful-feishu-whiteboard actually solves

Most agent-generated diagrams fail in a specific way. The agent can reason about structure, but it has no taste for colour, and it has no memory of what the target renderer refuses to draw. You get boxes in default blue, cramped spacing, and text that disappears on export. beautiful-feishu-whiteboard attacks the second and third problems, not the first. The README is explicit that this is "an agent skill (for Claude Code and other agents that read SKILL.md)" and that "it is not an auto layout chart tool." Your agent still composes the layout. What the skill supplies is a curated palette plus the rendering rules of the Feishu SVG whiteboard medium.

The audience is narrow and identifiable: people who generate whiteboards inside Feishu / Lark docs through an agent and want the result to be a real, editable whiteboard rather than an image. The README stresses that word, editable, twice. That distinction matters because a screenshot is trivial to produce and useless to a colleague who wants to move a box.

The repository ships 35 styles, grouped from restrained to bold, and every gallery entry renders the same content (the three stages of LLM training) so palettes can be compared directly. That is a sensible curation decision: it removes content as a variable.

How the skill steers an agent: SKILL.md, RULES.md, templates

The mechanism is file-based, which is what makes it portable across agents. The top level of the repository holds SKILL.md, which is the entry point agents read, and RULES.md, described in the README as "hard won, on board verified knowledge of what the Feishu SVG whiteboard renderer can and cannot do (native shapes only, no opacity, the text colour export quirk, and more)." A templates/ directory holds one folder per style, and assets/ holds the preview images used in the gallery. CATALOG.md appears to be the index across the 35 styles.

So the data flow is: the agent reads SKILL.md, picks or is given a style, reads the corresponding template under templates/, and then applies the constraints in RULES.md while emitting whiteboard shapes. The palette comes from the template. The correctness comes from RULES.md. The layout comes from the agent.

That split is the interesting design choice. Encoding renderer limits as prose rules rather than as a validator means the skill cannot catch a violation. It can only inform the model that the violation exists. If your agent ignores RULES.md, nothing in the repository stops it. The README frames the rules as verified on board, which is a claim about provenance, not a runtime guarantee.

The constraints named in the README are worth reading twice. Native shapes only rules out arbitrary SVG paths. No opacity removes a whole class of subtle layering effects that designers reach for by default. The text colour export quirk is named but not explained in the README, so the detail lives in RULES.md.

Installing the skill and rendering a first whiteboard

The README does not give an install command. It points at SKILL.md as the file agents read, and links a Feishu doc version of the introduction that carries usage-scenario showcases. The practical route is to clone the repository and point your agent at it. Cloning is the only step the repository layout clearly supports:

git clone https://github.com/zarazhangrui/beautiful-feishu-whiteboard.git
cd beautiful-feishu-whiteboard

After that you should be sitting in a directory containing SKILL.md, RULES.md, CATALOG.md, README.md and the templates and assets folders, which is what the repository layout lists at the top level. If SKILL.md is missing, you cloned the wrong branch.

For the first real use, pick one style rather than browsing all 35. The restrained group is the safer starting point because its palettes leave less room for a bad layout to look worse. Each style has its own folder under templates/, so the path is predictable. The README links templates/avocado-press/ as one of the restrained styles, alongside grove, jade-lens, long-table, macchiato, monochrome, papier-bleu, reading-room and salmon-stamp. Open the files in that folder, hand SKILL.md, RULES.md and the chosen template to your agent, and ask it to produce the whiteboard for your own content. The README's gallery uses the three stages of LLM training as the shared demo content, which is a reasonable prompt to adapt.

The scripts/ directory at the top level is not described in the README, so do not assume it automates the render. Read it before you wire it into anything.

The renderer limits are the real product

Palettes are easy to copy. The reason this repository exists in this form is the Feishu SVG whiteboard renderer's constraints, and those constraints are where the value and the risk both sit.

Native shapes only means your agent cannot draw a custom icon, a curved connector with a hand-tuned path, or an irregular blob. It has to express the design with the primitives the renderer supports. No opacity means every overlap is opaque, so a palette has to create hierarchy through colour and spacing rather than through translucency. Those two rules together explain why the gallery is organised around flat, poster-like styles rather than soft layered ones. The restrained group leans on paper tones and thin rules; the bold group leans on blocks and wedges. Neither depends on alpha.

The text colour export quirk is the one I would want documented most clearly, because text colour is exactly the thing that looks right in the editor and wrong after export. The README names it and defers to RULES.md. That deferral is honest, but it means anyone evaluating the project should read RULES.md before trusting the output in a shared doc.

There is a maintenance consequence here too. Renderer behaviour is owned by Feishu, not by this repository. The rules were verified at some point and the last push was on 2026-06-11. If the renderer changes, RULES.md does not update itself.

Where it is the wrong tool

The README's own disclaimer is the first limitation, and it is a big one: this is not an auto layout chart tool. If you want a library that takes a graph and computes node positions, edge routing and spacing for you, this repository does not do that. It hands your agent a palette and a rulebook and expects the agent to place everything. On a complex architecture diagram with thirty nodes, that expectation is doing a lot of work, and the quality of the result tracks the model's spatial reasoning more than it tracks anything in this repository.

The second limitation is platform lock-in. The rules encode the Feishu SVG whiteboard renderer specifically. Nothing here transfers to a different canvas product, because the whole point is the quirks of one renderer. If you are not on Feishu / Lark, the repository is still readable as a set of palettes, but the RULES.md half is dead weight.

The third is that constraints are advisory. There is no build step, no schema, no validator that rejects an opacity value before it reaches the whiteboard. A skill file is a prompt artefact. It raises the floor on the model's output; it does not enforce a ceiling on its mistakes. If you need a guarantee that the emitted whiteboard is valid, this repository does not provide one, and the README does not claim to.

Compared with hand-built Feishu whiteboard templates

The obvious alternative is not another open source project. It is a human-made template inside Feishu itself: someone on the team builds a good-looking whiteboard once, duplicates it, and pastes new content into the copy. That approach has real advantages. A person can use opacity, custom shapes and whatever the editor allows, because a human is not constrained by what an agent can reliably emit. The template is also immediately editable by anyone on the team without an agent in the loop.

The difference in approach is where the intelligence sits. A duplicated template puts the design decisions in a fixed artefact and asks the human to fit content into it. beautiful-feishu-whiteboard puts the design decisions in a palette plus a rulebook and asks an agent to generate structure that fits the content. The template wins on fidelity and on zero setup. The skill wins when the content varies a lot and you want the agent to produce the whole thing, and when you want the output to survive a round trip through the renderer rather than degrade on export.

A second, weaker alternative is letting the agent freestyle with no palette at all. That is what most people already do, and the result is the default blue. The skill's contribution over freestyling is bounded but real: a fixed set of 35 vetted colour combinations and an explicit list of things not to attempt.

Licence and what maintenance costs you

The repository is MIT licensed, with a LICENSE file at the top level. MIT is permissive: you can use the palettes and templates in commercial work, modify them, and redistribute them, provided the copyright notice and permission notice are preserved. The templates are colour and layout data rather than code, so there is no linking question to think about. This is not legal advice; read LICENSE and, if the whiteboards go into a product, have someone check how the notice should travel with the assets.

Maintenance is the part to watch. The last push to the repository was on 2026-06-11. There are no releases retrieved for the project, so there is no version to pin and no changelog to read. Upgrading means pulling the branch and diffing SKILL.md, RULES.md and the templates yourself.

That is manageable precisely because the repository is small and mostly data. The palettes will not rot. RULES.md is the file that can go stale, because it describes the behaviour of a renderer that this project does not control. When Feishu changes how the whiteboard renderer handles shapes or text colour, the rules become a description of the past, and no signal in the repository will tell you. Budget for re-verifying RULES.md against a real whiteboard whenever you notice output that looks wrong after export.

Editorial conclusion

Adopt it if your agent already writes Feishu whiteboards and you want the output to look deliberate rather than default, and if you are willing to let the agent own layout while the skill owns palette and renderer constraints. Skip it if you want an auto layout chart tool, because the README says plainly that it is not one, or if you are not on Feishu / Lark at all. Before you rely on it, open RULES.md and check which renderer limits it encodes, then render one template end to end and confirm you can still edit every shape and text block in the resulting whiteboard. The last push to the repository was on 2026-06-11, so treat the renderer rules as a snapshot rather than a live feed.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. zarazhangrui/beautiful-feishu-whiteboard on GitHub