GitHub - BESSER-PEARL/uml-drawing-skill: Agent Skill: draw a correct UML class diagram via BESSER B-UML and generate SVG/PNG outputs in one call — no browser. For READMEs, design docs, wikis, and slides. · GitHub
/" data-turbo-transient="true" />
Skip to content
Search or jump to...
Search code, repositories, users, issues, pull requests...
-->
Search
Clear
Search syntax tips
Provide feedback
--><br>We read every piece of feedback, and take your input very seriously.
Include my email address so I can be contacted
Cancel
Submit feedback
Saved searches
Use saved searches to filter your results more quickly
-->
Name
Query
To see all available qualifiers, see our documentation.
Cancel
Create saved search
Sign in
/;ref_cta:Sign up;ref_loc:header logged out"}"<br>Sign up
Appearance settings
Resetting focus
You signed in with another tab or window. Reload to refresh your session.<br>You signed out in another tab or window. Reload to refresh your session.<br>You switched accounts on another tab or window. Reload to refresh your session.
Dismiss alert
{{ message }}
Uh oh!
There was an error while loading. Please reload this page.
BESSER-PEARL
uml-drawing-skill
Public
Notifications<br>You must be signed in to change notification settings
Fork
Star
main
BranchesTags
Go to file
CodeOpen more actions menu
Folders and files<br>NameNameLast commit message<br>Last commit date<br>Latest commit
History<br>15 Commits<br>15 Commits
.github/workflows
.github/workflows
examples
examples
uml-drawing
uml-drawing
.gitignore
.gitignore
CHANGELOG.md
CHANGELOG.md
LICENSE
LICENSE
README.md
README.md
View all files
Repository files navigation
UML Drawing — diagrams as code, for your docs
An Agent Skill by BESSER that gives your AI coding agent one<br>job and makes it do it right: put a correct UML class diagram — as a real,<br>rendered image — into your docs.
This skill supports two common workflows:
1. Design a system from a description . Describe your domain in natural language, and the agent creates a B-UML model and renders the corresponding UML class diagram.
You: "Add a class diagram of our vehicle fleet to the README."<br>Agent: ‣ models Vehicle · Car · Truck · ElectricCar with correct inheritance<br>‣ renders it to a real SVG itself — one call, no browser<br>‣ embeds 
2. Document an existing codebase . Point the agent to your source code, and it extracts the classes and relationships, creates the B-UML model, and generates the diagram.
You: "Diagram the classes in src/fleet/ for the docs."<br>Agent: ‣ reads your existing code, recovers the classes and how they relate<br>‣ builds the same validated B-UML model and renders the SVG
The result is a diagram generated from a validated model that can be included directly in README files, design documents, wikis, and presentations.
The agent's actual output — rendered from examples/vehicles.py in a single call, no browser or plugin. Whether you describe the model or the agent reads it from your own source, the diagram comes from real, validated code. That's the skill at work.
Why you need it
Models are a powerful way to quickly understand your codebase. A class diagram, for example,<br>provides a compact view of a software system by showing its classes, attributes, and relationships.<br>It is often used in documentation, README files, and design discussions because it allows developers<br>to understand the structure of a system without reading the complete source code.
But when you ask an AI agent to create one, things can easily go wrong in two ways:
A wrong diagram — reversed arrows, invalid multiplicities, inheritance<br>backwards. It looks fine until someone who knows the domain reads it.
A block of text that never becomes a picture — pseudocode or ASCII<br>"explaining" a diagram inside a code fence that no viewer actually renders.
This skill fixes both: a structurally-correct model, delivered as an image that<br>really renders — on GitHub, GitLab, wikis, and slides, no plugin.
Why it's different
Most "diagram" tools give you a picture or a model. This gives you both, and<br>keeps them in sync:
Correct by construction. The diagram is always built as a<br>structurally-validated BESSER<br>B-UML model — not freehand ASCII the model guessed at. Multiplicities,<br>associations, and inheritance are right.
Start from a description or your code. Describe the domain, or point<br>the agent at existing source and let it model the structure.
Two ways to embed — and the agent renders the image itself. Drop the<br>B-UML code straight into your .md, or get a real SVG/PNG : the agent<br>renders it with a single call to BESSER's headless B-UML → SVG endpoint —<br>no browser, no Mermaid plugin, no rendering service. (Want to hand-place the<br>layout? Export from editor.besser-pearl.org<br>instead — same model.)
It doesn't drift. Both come from one model you keep in the repo. Change<br>the model, re-deliver, commit — the doc never goes stale.
The diagram can become the system. The...