Anatomy Claude Code Skill: 6,500 Stars in 4 Days [2026]

Anatomy is a Claude Code skill that turns a one-line technical concept into a living, interactive isometric machine: a real object whose moving parts enact the idea, rendered as shaded SVG with optional WebGL effects. Ask most AI explainers to describe something and you get boxes, arrows, and a tidy stack of labelled bullets. Anatomy refuses to do that. It draws the thing itself, and every number on screen is driven by a live simulation, not hard-coded text.

I'm writing this during launch week on purpose. The wheresryan22/anatomy repo was created on October 8, 2026, and by October 12 it had already crossed 6,507 stars and 464 forks. Four days. That makes it one of the fastest-growing Claude Code skills on GitHub this year, and as far as I can tell this is the first substantive write-up of it anywhere. The latest release, v1.1.0, shipped the same day I'm typing this.

Key takeaways:

• Anatomy turns a single prompt like /anatomy explain how a mechanical watch keeps time, interactive into a draggable, physically coherent isometric machine built from hundreds of shaded SVG parts.
• Installation is one command: npx skills add wheresryan22/anatomy -g -a claude-code. It needs Node.js 20.10 or newer and has zero runtime dependencies.
• The same skill folder runs unmodified in Claude Code, OpenCode, and Codex because it is built on the open Agent Skills format. No vendor lock-in.
• A finished figure takes roughly two hours of active agent time, not two seconds. This is a batch-render tool, not a chat toy.
• It is a free, MIT-licensed community skill, not an official Anthropic product.

What is the Anatomy skill, and what problem does it solve?

Anatomy is a third-party, open-source skill for agentic coding tools. To understand it you first need to know what a Claude Code skill actually is, in plain terms: a skill is a folder containing a SKILL.md file (a Markdown instruction sheet with a name and description) plus optional scripts, reference docs, and assets. When your task matches the skill's description, the agent loads those instructions and follows them. That's the whole mechanism. Simon Willison called the pattern "maybe a bigger deal than MCP" when Anthropic shipped it, precisely because the simplicity is the point. A skill is mostly a well-written prompt plus a few files on disk.

The problem Anatomy attacks is that software explanations are almost always abstract. A rate limiter gets drawn as three rectangles and a clock icon. A cache is a box labelled "cache." You learn that the parts exist, but not what they do. The reader is left to imagine the motion the arrows stand in for.

Anatomy's answer is to make the motion real. You name an idea, Claude invents a machine that performs it, and you get something you can turn, press, and read. It sits alongside other skills-based projects I've covered, like the agent framework Superpowers and the mattpocock/skills set for understanding a vibe coding project. The difference: those operate on your codebase, Anatomy operates on concepts.

Objects, not diagrams: the design philosophy

The entire skill rests on one rule, written at the very top of its SKILL.md, above everything else: the object is the explanation.

An explainer you can grab, wind, and slow down beats a hundred boxes-and-arrows diagrams. The object is the explanation.

This is what separates Anatomy from the diagram-as-code tools engineers already use. Mermaid, draw.io, and PlantUML are schematic. They render relationships between abstract nodes. They're fantastic for architecture reviews and terrible for conveying mechanism, because a labelled box never shows you why the thing works. Anatomy inverts that. Its creator, Ryan, writes that a figure fails in two ways: "too abstract" (stacked plates, floating slabs, labelled boxes that don't read as anything) or "too flat" (one slab with a few lines and nothing to discover). The cure for both is the same. A recognisable machine built from many small parts that each do something.

Some concepts map onto physical objects almost by themselves. In Anatomy's own gallery, a queue becomes a marble run: two hoppers feed one sloping lane, marbles wait in order behind an escapement until a timer drum releases them. An LRU cache that forgets its oldest entry becomes a bookcase that physically ejects a book when a new one arrives. The metaphor isn't decoration. It's the explanation.

Anatomy vs Mermaid and diagram-as-code tools

If you already reach for Mermaid or PlantUML when you need a picture, it helps to see exactly where Anatomy fits and where it doesn't. They solve different problems, and treating them as competitors misses the point. Here's the quick-reference I'd give a teammate deciding which to open:

The row that matters most is reproducibility. Mermaid is text-to-diagram: the same source always renders the same picture, which is why it belongs in version control next to your code. Anatomy is a one-shot generative render. Feed it the same prompt twice and you get two different machines. That's a feature when you want the best possible explanation of a concept, and a liability when you need a canonical system diagram your team references for months. Pick Anatomy when the goal is understanding. Pick the schematic tools when the goal is a stable artifact.

How to install and run Anatomy in Claude Code, OpenCode, and Codex

Setup is genuinely a one-liner, which is a big part of why the repo spread so fast. Here's the full pipeline, start to finish:

1. Install Node.js 20.10 or newer. Anatomy uses only Node's built-in modules, so there are zero third-party runtime dependencies. That keeps the supply-chain surface tiny.
2. Add the skill globally to Claude Code: npx skills add wheresryan22/anatomy -g -a claude-code. The -g installs it globally so it's available in every project.
3. For OpenCode, run the same command with -a opencode. The skill folder is identical; only the target agent flag changes.
4. For Codex, install it the same way and invoke it as $anatomy instead of a slash command.
5. Prompt it inside your agent: /anatomy explain how X works, interactive. Replace X with any mechanism, data structure, or physical process.
6. Wait and open the output. Claude works largely unattended, then hands you a self-contained interactive figure you open in a browser.

That cross-agent portability is not an accident, and it matters if you worry about agent lock-in. Because Anatomy conforms to the Agent Skills open standard, the exact same folder runs across Claude Code, OpenCode, Codex, Gemini CLI, Junie from JetBrains, and ZeroClaw. You are not betting on one vendor's ecosystem.

What Claude actually does when you run /anatomy

When the skill activates, Claude doesn't fetch a template. It designs. First it invents the real machine, not copied from a reference image, whose working embodies your concept. Then it builds the figure as dozens to hundreds of individually shaded SVG parts in isometric projection, and writes a small simulation model that animates them. Here's the crucial detail: every number the UI displays comes from that model. When the watch's power reserve climbs as you wind the crown, that figure is computed live, not printed as static text.

The base layer is plain SVG: scalable, inspectable, lightweight. Each part is its own shaded shape, which is why the figures have real volume instead of looking like flat clip art. On top of that, Anatomy drops in WebGL shaders for effects SVG can't do well, like the glow and turbulence of a rocket engine's exhaust plume.

The heavy lifting comes from Claude Code's own mechanics. Skills load through progressive disclosure, a three-stage process documented in Claude Code's skills documentation: only a skill's name and description load at startup (discovery), the full SKILL.md loads when a task matches (activation), and bundled code loads only as needed (execution). So each installed skill costs a few dozen tokens until it's actually used. Running the seven-agent pipeline that publishes this blog taught me context budget is the real constraint in agent systems. The 4.7x token-overhead gap I measured between OpenCode and Claude Code comes almost entirely from how much a harness loads before it does any useful work. Progressive disclosure is the pattern that lets a skill as ambitious as Anatomy coexist with fifty others in your toolbox.

Here's a demo of the skill generating ten different machines from single-line prompts:

Anatomy of a figure: how the SVG and WebGL output is built

The mechanical watch example makes the two-layer design concrete. Press S to slow time to a twentieth, then a hundredth, and you can watch the pallet fork release a fifteen-tooth escape wheel half a tooth at a time. Press E and the bridges lift to reveal the gear train beneath, its wheels cut to true ratios: the fourth wheel turning once a minute, the centre wheel once an hour. That is not a video. It's a running model you're inspecting.

The figure stays interactive the whole time. You drag to rotate, press keys to slow the simulation down, and lift components apart to see what's underneath. SVG carries the structure and volume; WebGL handles the things SVG can't fake, like heat shimmer or an exhaust plume that actually billows. Nothing about it is a rendered loop you play back. You're poking at the thing while it runs.

Real examples: mechanical watch, Raptor engine, rate limiter

At launch the official showcase listed 33 example figures, spanning engines, clocks and watches, caches, queues, and rate limiters. Three stand out as a good tour of the range.

The mechanical watch is the flagship. From the single prompt /anatomy explain how a mechanical watch keeps time, interactive, Claude produced a full movement (mainspring, ratchet, escapement, gear train) that winds and ticks when you drag the crown.

The rocket engine (think SpaceX Raptor-class) is where WebGL earns its place. A full-bell liquid engine with turbopumps feeding the combustion chamber, and an exhaust plume rendered with shaders rather than flat SVG fills. This is the kind of output that makes an isometric diagram AI generator feel less like a toy and more like a teaching instrument.

The rate limiter is the one that should interest backend engineers. A concept that's usually three boxes and a hand-wave about token buckets becomes an actual mechanical token bucket you can watch fill, drain, and reject requests when it runs dry. This is the category where I think Anatomy could genuinely replace a slide. It's the same reason I keep coming back to tools that reverse-engineer a system into something you can inspect.

How long generation takes, and what it costs in agent time

This is the part that resets expectations. That mechanical watch took one hour and fifty-four minutes of active Claude Code time, built in one pass and self-checked by the same agent. Ryan documents the figure as "just under two hours of Claude working on its own."

Two hours per figure isn't chatbot latency. It's a render job. You fire the prompt, walk away, and come back to something finished. For a one-off explainer you'll embed in docs or a talk and reuse for years, that's a reasonable trade. For throwaway questions, it's absurd, and you should know which one you're doing before you run it.

The real cost is tokens, and it's substantial given the agent reasons across potentially hundreds of parts and a simulation model. This is exactly the kind of workload where model selection dominates the bill. Running my own pipeline, I've found model-per-job-shape beats one-model-everywhere on both cost and quality, and the same logic applies here: if you're generating these at volume, do the agent cost-per-task math before you queue up fifty of them.

Limits and known failure modes

Anatomy is four days old, so temper expectations. The creator is candid that figures fail when they drift too abstract or too flat, and the "object is the explanation" rule exists precisely because he watched it fail both ways repeatedly before codifying it.

The harder limit is conceptual. Ideas with a clean physical analogue (clocks, engines, pumps, queues, caches) map beautifully. Ideas that are inherently abstract, with no natural machine behind them, are a much worse fit. A statistical distribution, a legal concept, a purely mathematical proof. Force a mechanism onto something that has none and you get exactly the "labelled boxes that don't read as anything" failure the skill is trying to avoid.

And it is not instant, not free, and not deterministic. Two runs of the same prompt will give you two different machines. For an explainer that's a feature; for anything needing a canonical, reproducible diagram, reach for Mermaid instead. Treat Anatomy as a collaborator that occasionally needs a second pass, the same discipline I'd apply to any AI agents in a real workflow.

Why this matters: the Agent Skills ecosystem beyond Claude

The bigger story isn't one viral repo. It's the format underneath it. Agent Skills is an open, vendor-neutral standard: a skill is just a folder with a SKILL.md plus optional scripts, references, and assets, and it already runs across OpenCode, Codex, Gemini CLI, Junie, and ZeroClaw alongside Claude Code. A skill author writes once and ships everywhere, and a developer adopting agentic AI isn't locked into a single vendor's plugin store.

Anatomy is the vivid proof-of-concept for that standard. It's the figure that makes people install a skill for the first time, the same way the slack-gif-creator did when skills launched. I expect the next wave of agent-generated explainers to look a lot more like Anatomy and a lot less like another bullet-point blog post: interactive artifacts an agent builds in one pass, portable across every developer tools stack that speaks the format.

If you build developer education, documentation, or internal training, install it this week and point it at the one concept your team always struggles to explain. The novelty will fade. The pattern, agents producing inspectable objects instead of static diagrams, won't. That's the shift worth watching, and it's moving faster than the Claude Code alternatives debate makes the field look.

Photo by Alicia Christin Gerald on Unsplash.