This week's #1 trending repository on GitHub isn't a framework. It isn't a database, a runtime, or an agent harness. It's cathrynlavery/diagram-design, a collection of markdown instructions and SVG templates that teaches Claude Code how to draw diagrams that don't look like they came out of an AI. It picked up over 16,000 stars in a single week, more than PrimeIntellect's self-improving coding agent, more than Cactus Compute's 14MB edge model, more than any of the actual pieces of infrastructure sitting next to it on the trending page.
There's no backend. No API. No build step. If you clone it, you don't get an application — you get a SKILL.md file, a folder of type references, some Python linting scripts, and 81 example HTML files. The entire product is a set of instructions for how an LLM should decide what a diagram needs, what it doesn't, and where the border-radius should stop.
That's worth sitting with for a second, because it's a genuinely new shape of "software going viral," and the repo itself is a useful specimen for what's actually happening in the Claude Code and Anthropic Agent Skills ecosystem right now.
What actually happened
The repo was created by Cathryn Lavery, founder of the productivity company BestSelf.co and a writer, not a developer-tools founder. Somewhere in the last few weeks it went from a personal utility to the most-starred thing on GitHub for the week, sitting at 21,000+ stars and 1,300+ forks at the time of writing, distributed under MIT with bundled icon sets from Tabler Icons and Simple Icons (CC0).
The pitch, in the README's own words, is close to a complaint: creators needed diagrams that matched their brand, and the alternative was "spending 30 minutes fighting Figma or accepting bland rounded-box renderings from AI." Anyone who has asked an LLM for an architecture diagram recently knows the rounded-box problem. You get boxes, arrows, a default sans-serif font, and drop shadows nobody asked for — technically correct, visually indistinguishable from every other AI-generated diagram on the internet. diagram-design is an attempt to fix that not by building a better renderer, but by giving the model a design system detailed enough that it stops making its own aesthetic decisions.
What it actually does
Install it as a Claude Code plugin (/plugin marketplace add cathrynlavery/diagram-design, then /plugin install diagram-design@diagram-design), and it adds a Skill plus three slash commands — /diagram-design:import, /diagram-design:export, /diagram-design:profile. The core deliverable is 27 diagram types split into six families: flow/logic (flowchart, sequence, state machine, swimlane, process), structure (architecture, ER/data model, tree, org chart, nested hierarchy), analysis (quadrant, 2×2, Venn, radar, timeline), technical/data (IT landscape, stack, medallion, data flow, security matrix), data visualization (bar, line, Gantt, scatter), and domain-specific shapes (flywheel loops, pyramids/funnels, layer stacks).
Every diagram renders as self-contained HTML with inline SVG — no JavaScript dependency, no external asset requests beyond Google Fonts, and it ships in three variants: minimal light, minimal dark, and a "full-editorial" treatment. You can also feed it an existing Mermaid or draw.io diagram and have it redrawn in this system, or export the result to PNG or SVG at print, slide, or social-card dimensions.
None of that alone explains 16,000 stars in a week. The part that does is brand extraction. Point it at your website, and it fetches the page, pulls the dominant colors and font stack out of the body, headers, and code elements, maps them to semantic roles (paper, ink, muted, accent, link), checks the result against WCAG AA contrast, and writes the tokens to references/style-guide.md. From that point on, every diagram it generates for that project uses your colors and your type, not Claude's defaults. Multiple client brands are handled through saved profiles in ~/.diagram-design/profiles/, switched via a .diagram-design marker file per project — which is exactly the kind of detail that suggests this was built by someone doing client work, not someone building a dev tool.
How it works under the hood
The architecture is worth walking through because it's a decent case study in how you actually build something reliable on top of an LLM's instruction-following, rather than its judgment.
diagram-design/
├── skills/diagram-design/
│ ├── SKILL.md # philosophy + type-selection guide
│ ├── references/ # 27 type specs + semantic patterns
│ ├── scripts/ # draw.io/Mermaid extractors, self-check
│ └── assets/ # gallery + 81 example HTML files
├── commands/ # Claude Code export/import/profile
├── .claude-plugin/, .codex-plugin/ # marketplace manifests
Rather than dumping all 27 type specifications into context on every request, the skill uses progressive disclosure: a routine flowchart request loads SKILL.md plus type-flowchart.md and nothing else; the semantic-pattern and animation references only load when the request actually needs them. That's a meaningful design decision for anyone building their own Skills — it keeps token usage proportional to task complexity instead of front-loading the model with 27 specs it will use one of.
The design system itself is opinionated to the point of being prescriptive: three typefaces (Instrument Serif for titles, Geist Sans for node names, Geist Mono for technical sublabels), 1px hairline borders, a maximum 10px border-radius, no drop shadows, one accent color reserved for one or two focal elements, all coordinates snapped to a 4px grid specifically "to prevent an AI-generated appearance," and a target visual density of 4 out of 10. The stated philosophy — "the highest-quality move is usually deletion" — is enforced computationally, not just written down: verify-geometry.py checks for label overlap, lint-skin.py checks SVG structure against the design tokens, and verify-docs-sync.py catches broken links, all running in CI across Linux, Windows, and macOS.
Import from Mermaid or draw.io goes through what the docs call a four-dial interface — format, size, detail level (faithful/≤24 nodes, balanced/≤12, simplified/≤7), and audience (engineer, mixed, executive, which changes wording, not node count) — and produces a "fidelity ledger" showing what got merged, collapsed, or dropped in translation. Given a 40-node Mermaid diagram, that ledger is the difference between trusting the output and re-checking it against the source by hand.
Export to PNG uses Playwright for headless rasterization; SVG output injects the Google Fonts directly so a file opens correctly in a browser, Figma, or Illustrator without a missing-font fallback. Accessibility isn't an afterthought either — every diagram gets role="img", resolving aria-labelledby, and <title>/<desc> slots, with decorative icons hidden from assistive tech.
There's also a genuinely interesting layer for diagrams that need to show a process rather than a static structure: seven "semantic patterns" (fan-in queues, stage slots, transformation, policy traces, secure paths, governance catalogs, compensating layers) defined independently of visual type, so a queue pattern can be rendered as an architecture diagram, a flowchart, or a swimlane depending on what fits the surrounding content. Animation is opt-in across four modes (none, reveal, step, loop), always ships a complete static first frame, and reduced-motion preference collapses straight to the static diagram — with the motion controller pinned and reviewed rather than pulled from a CDN, which matters more than it sounds given the file is meant to be dropped into arbitrary docs and slide decks.
The rest of the trending page, for context
It's worth looking at what diagram-design beat, because the list says something about where attention is actually going in August 2026. The same trending week included PrimeIntellect's prime-agent, described as "a self-improving RLM agent for coding workflows and long-running autonomous tasks"; semantica-agi/semantica, pitched as graph-native infrastructure for context and accountable AI systems; vitali87/code-graph-rag, a RAG system built to query and edit multi-language monorepos; and TencentCloud/TencentDB-Agent-Memory, a team-level memory hub for agents. All four are real infrastructure, built by people whose day job is infrastructure, addressing problems — agent memory, monorepo comprehension, autonomous coding — that are objectively harder than "diagrams shouldn't look like AI made them."
None of them out-starred a design system. That's not a knock on their engineering; it's a reminder that GitHub star velocity measures something closer to "how many people had an immediate, personal use for this today" than "how technically significant is this." A memory layer for agents is infrastructure everyone will eventually depend on and almost nobody will star this week, because almost nobody is wiring up agent memory this week. Nearly everyone who uses Claude Code has, at some point, needed a diagram and been unhappy with what came out.
Why developers should actually care
Strip away the novelty and there are concrete, practical reasons this is worth more than a curiosity glance:
Cost. There's no hosting, no inference API beyond what you're already paying for through Claude Code itself, and no subscription. Compare that to a design tool subscription or paying a contractor for one-off diagrams — the marginal cost of a new diagram after installation is whatever tokens the generation request costs.
Latency and iteration speed. Generating a diagram is a single prompt-and-render cycle, typically faster than opening Figma, finding the right template, and manually laying out nodes — though slower than a human who already knows exactly what they want and can draw it directly in Excalidraw. Where it wins on speed is the first draft of something you'd otherwise avoid doing at all.
Developer experience. Everything stays in your existing terminal-based workflow — no context switch to a browser tool, no account creation, no separate app to keep updated. The output is a plain HTML file you can open, commit, or drop into a static site with zero additional tooling.
Lock-in. This is one of the more reassuring parts of the design: because output is static HTML and SVG with no runtime dependency, you're not locked into the tool at all. Uninstall the skill tomorrow and every diagram you've already generated keeps working exactly as it does today. That's a meaningfully different risk profile than adopting a hosted diagramming SaaS.
Security. The self-contained, no-external-assets design (aside from Google Fonts) matters here — a diagram meant to be embedded in docs or a deck isn't phoning home or pulling in a remote script each time it renders. The one place to actually pay attention is the brand-extraction step, which fetches an arbitrary URL you supply; treat that step the way you'd treat any tool that fetches external content on your behalf, and don't point it at anything you don't control.
Maintainability. This is the least settled question. A skill maintained by one person, however well the linting scripts are built, doesn't have the same organizational guarantees as a project backed by a company or a foundation. The CI-enforced constraints (geometry checks, contrast checks, docs-sync checks) are a genuinely good sign for near-term quality, but they don't substitute for a plan around what happens if the maintainer's priorities shift — worth weighing before you build a documentation pipeline that depends on it.
What the plugin marketplace mechanics look like in practice
One detail that's easy to skip past: installation isn't npm install or pip install, it's a git-backed plugin marketplace call — /plugin marketplace add cathrynlavery/diagram-design followed by /plugin install diagram-design@diagram-design. Updates, per the repo, come automatically if you enable auto-update in marketplace settings; the same mechanism is mirrored for Codex (codex plugin marketplace add ...). For an organization that wants central control rather than pulling updates from an individual's personal repo directly, the documented path is mirroring into an org-owned repo and wiring a GitHub webhook for sync — a reasonable middle ground between "trust random third-party skills" and "review and vendor every update yourself."
That distribution model — plugins pulled straight from GitHub repos rather than a centralized package registry — is still new enough that most teams haven't thought through their own policy for it yet. It's worth having that conversation before your team ends up with a dozen Claude Code skills installed from a dozen different individual maintainers with no update-review process at all.
What changed versus the alternatives
The interesting move here isn't "AI draws diagrams now" — that's been true since the first GPT-4 demo. It's that diagram-design explicitly optimizes for a different axis than the incumbents.
Mermaid optimizes for text-to-diagram portability: you write a small DSL, it renders consistently everywhere, and it's the default for anything embedded in markdown (GitHub, Notion, most static site generators support it natively). draw.io (diagrams.net) optimizes for manual, precise editing — drag-to-rearrange, layer control, the full toolkit for a human doing the drawing. Excalidraw optimizes for fast, collaborative, hand-drawn-style whiteboarding. None of them optimize for "make it look like a designer touched it without a designer touching it," and none of them have an opinion about your brand.
diagram-design gives up the thing all three of those tools are built around — easy manual re-editing — in exchange for editorial output on the first pass. The README is upfront about this trade: "output is write-only," no drag-to-rearrange. If the diagram is wrong, you don't fix it in a canvas, you re-prompt Claude and regenerate.
Why this matters beyond one repo
The reason this is worth a deep dive isn't really the diagrams. It's what the repo's success says about where value is accruing in the Claude Code plugin ecosystem right now.
Distribution cost is near zero. There's no server to run, no npm package to version, no API key to provision. The entire artifact is markdown and static HTML checked into a git repo, installed with one command through the Claude Code plugin marketplace mechanism. That's a fundamentally cheaper thing to ship and maintain than a SaaS product or even a CLI tool, and it shows in how fast this spread — a single person with no dev-tools background produced the most-starred repo of the week.
The differentiator is taste, encoded as constraint. Every LLM can already generate an SVG diagram. What it can't reliably do on its own is stop itself from adding a drop shadow, or decide that a 40-node import should collapse to 7. diagram-design's actual IP is the accumulated set of "don'ts" — no shadows, max 10px radius, 4px grid, one accent color — encoded specifically enough that Claude can enforce them, and verified by scripts rather than left to the model's discretion each time. That's a genuinely different skill than most people are building right now, and it's replicable: the same pattern (a style guide precise enough to survive contact with an LLM, plus automated checks that catch drift) generalizes to slide decks, docs sites, or any other output where "on brand" currently means "someone reviews it."
It's a leading indicator for the Skills ecosystem. Anthropic's Agent Skills format is still young, and most public skills so far skew toward developer workflows — code review, test generation, documentation. A design-system-as-skill topping the weekly trending chart, ahead of agent frameworks and RAG tooling, suggests the audience for these things is wider than "people building agents." It's anyone who currently pays a human or a SaaS subscription for consistent visual output.
Where the pitch runs ahead of the evidence
A few things the excitement glosses over:
- No license file, technically. The README references MIT-licensed icon sets bundled inside the repo, but there's no unambiguous top-level LICENSE statement visible in what the project publishes about itself — worth checking directly before you build a dependency on it in a commercial context, rather than assuming from the repo's general open-source framing.
-
Brand extraction is a heuristic, not a design audit. Pulling colors and fonts from
<body>,<h1>, and<code>elements works for sites with clean, consistent CSS. It's going to misfire on sites using CSS custom properties in non-obvious ways, heavy component libraries, or design tokens that don't surface in computed styles the way the extractor expects. There's no verification step described for whether the extracted palette is actually representative of the brand versus just whatever happened to be on the homepage that day. - "Write-only" output is a real constraint, not just a stylistic choice. If a generated diagram is 90% right, your options are re-prompting or hand-editing raw SVG — there's no visual editor. For quick iteration that's a genuine cost compared to draw.io or Excalidraw, and it's easy to undercount that cost when you're looking at polished example screenshots rather than your fifth regeneration attempt.
- Fetching arbitrary websites for brand extraction is a network dependency with failure modes the docs don't dwell on — paywalled sites, JS-rendered CSS-in-JS styling that doesn't resolve in a simple fetch, or sites that actively block scraping. None of this is disqualifying, but "point it at your website" undersells how much site variance exists in practice.
- Progressive disclosure helps, but 27 type specs plus semantic patterns is still a lot of reference material for a single skill. Anyone extending this for a 28th diagram type inherits real maintenance surface — the linting and geometry-verification scripts exist precisely because that surface is easy to drift out of spec.
Competitive comparison
| diagram-design | Mermaid | draw.io | Excalidraw | |
|---|---|---|---|---|
| Primary strength | Brand-matched, editorial-quality static output | Text-to-diagram, universal markdown embedding | Precise manual editing, enterprise features | Fast collaborative whiteboarding |
| Editing model | Regenerate via prompt ("write-only") | Edit source text | Full manual canvas | Full manual canvas |
| Brand/style customization | Automatic, extracted from your site | Manual theming | Manual theming | Manual theming |
| Runtime dependency | None (static HTML/SVG) | Rendering engine (JS or CLI) | Full app or embed | Full app or embed |
| Best for | One-off polished diagrams for docs/decks | Diagrams that live in version-controlled text | Detailed technical diagrams needing precision | Quick collaborative sketching |
| Distribution | Claude Code / Codex plugin | Native in GitHub, Notion, most SSGs | Desktop app, web, VS Code extension | Web app, embeddable, VS Code extension |
Practical use cases
Where this is genuinely useful: architecture diagrams for docs and READMEs that need to look intentional rather than auto-generated; investor or client decks where "on-brand" is a hard requirement and you don't have a designer on call; blog posts and technical writing where a flywheel or funnel diagram needs to match the site's existing visual language; and quick redraws of messy, over-detailed Mermaid diagrams into something presentable for a non-engineering audience, using the "simplified" detail dial and the fidelity ledger to confirm nothing load-bearing got cut.
Where it's the wrong tool: diagrams that need frequent manual tweaking by non-technical stakeholders (draw.io or Excalidraw still win there), diagrams that must stay in sync with code or config as a source of truth (Mermaid's text-based approach is more auditable in a diff), and real-time collaborative whiteboarding sessions, which this doesn't attempt to be.
Who should try it, and who should wait
If you already use Claude Code or Codex day to day and regularly need a diagram for a README, deck, or blog post, this is a low-cost thing to install and try on your next one — worst case it's an SVG you don't use. If you run a small studio or do client work and currently hand-roll brand-matched diagrams in Figma, the profile system for multiple client brands is worth a real evaluation.
If your diagrams need to be a collaboratively editable source of truth — architecture docs a whole team edits, runbooks that get tweaked in meetings — stick with Mermaid or draw.io; the write-only model works against you there. And if you're evaluating this for a commercial product where licensing clarity matters, confirm the license situation directly with the maintainer before you build on it, rather than assuming from the repo's general MIT framing.
The broader signal — that a design system precise enough to constrain an LLM can out-trend actual infrastructure on GitHub in a given week — is probably more durable than this specific repo. Worth watching what the next version of "a style guide as a skill" looks like once more of these show up outside diagrams: for docs sites, for slide decks, for UI component generation.
Discussion question: if the actual differentiator in an AI-generated artifact is a tightly-specified style guide plus automated linting against it, rather than the generation step itself, does that change how you'd think about building a "skill" for your own team's output — docs, slides, code style — versus building a traditional tool?
Sources:
Top comments (0)