Anatomy is an open-source agent skill by Ryan (@wheresryan22) for turning technical ideas into isometric illustrations with moving parts. It works with Claude Code and several other coding agents, including Codex. Its output can combine SVG, WebGL effects and optional 3D motion. Anatomy repository

I would evaluate Anatomy by asking which technical decision an interactive explanation helps a reader understand. A reader can watch a queue fill or change an input and inspect the result. That can make a useful teaching aid, provided the behaviour matches the system being explained.

This guide covers installation, a practical first prompt and how to decide whether an Anatomy figure belongs in your documentation.

What the Anatomy skill does

An agent skill gives a coding assistant instructions and resources for a particular task. Anatomy combines those instructions with a drawing kit and local scripts. Its workflow starts with the behaviour to explain, then builds an object around it. The instructions call for the animation and displayed values to share a model, with checks for visual and geometric problems. Framework-free HTML and SVG output and React integration are supported. Skill specification

Think of the result as a small learning interface. The reader changes something, watches a consequence and connects that consequence to the underlying rule. The quality of that connection matters more than the number of moving parts.

Install Anatomy for your coding agent

The documented command installs the skill for your user and lets you choose an agent:

shell
npx skills add wheresryan22/anatomy -g

For Claude Code specifically:

shell
npx skills add wheresryan22/anatomy -g -a claude-code

For Codex:

shell
npx skills add wheresryan22/anatomy -g -a codex

The README distinguishes the installer's Node requirement from the kit itself: it says skills CLI 1.7.1 requires Node 22.20 or later. Check the requirement for the CLI version you use. Installation instructions

The skill specification lists Node 20.10+ for the kit and Chrome or Chromium for its checks. Using the installer therefore may require a newer Node version than running the kit. Compatibility requirements

In Claude Code, invoke the skill with /anatomy; in Codex, use $anatomy. Usage instructions

Start with one behaviour the reader needs to understand

A useful first brief names the concept, the input the reader controls and the outcome they should notice. Avoid starting with a request for an impressive animation of an entire platform.

Here is an illustrative prompt for a deliberately simplified rate limiter. The numbers are example inputs, not production settings:

text
/anatomy explain a token bucket rate limiter, interactive.
Start with a full bucket of 5 tokens and cap it at 5.
Refill continuously at 1 token per second of simulated time.
Each accepted request consumes 1 token. Reject requests when fewer than
1 token is available. Do not queue rejected requests.
Provide pause, advance 1 second and reset controls.
Start paused; reset restores 5 tokens and clears the request counts.
Let the reader send one request or a burst of 6 at the same instant.
Show the available tokens and accepted and rejected request counts.
Make the controls usable with a keyboard and explain the model in text.

For Codex, replace the command prefix with $anatomy.

This brief gives the generated model something concrete to demonstrate. Pausing the simulation matters: clicking six times while a clock runs could allow extra tokens to arrive between requests. A burst at one simulated instant removes that ambiguity.

Check the rate limiter before reviewing the artwork

Use these expected outcomes to review the proposed example. They follow from the illustrative rules above; they are not results from a tested Anatomy output.

  1. Reset the figure. It should show five tokens and zero accepted or rejected requests.
  2. Send a burst of six while paused. Five requests should be accepted, one rejected and no tokens left.
  3. Advance one second, then send one request. The totals should become six accepted and one rejected, with no tokens left again.
  4. Advance ten seconds without sending requests. The bucket should stop at five tokens. Extra waiting must not create extra capacity.
  5. Reset again. Both request counters should return to zero and the bucket should be full.

I would use this sequence as the first review gate. If the displayed counts disagree with the stated rules, the figure needs correction before it can teach the concept. The same approach works for other subjects: write a small set of predictable states and compare the output against them.

The creator's guide says interactive requests input controls, WebGL adds shader effects and 3D requests motion in depth. Start with the interaction you need; add rendering complexity when it explains something the simpler version cannot. Prompt guidance

Where it could help a software team

Explaining a constraint to stakeholders

An interactive example could help a founder understand why a system accepts a short burst of work but rejects sustained overload. Let them change the incoming demand and observe the result. Keep the explanation close to the actual decision, such as whether the product should reject, retry or queue work.

A simplified example needs an explicit boundary. A single bucket does not explain every concern in a distributed rate limiter. Readers should know which part of the system they are looking at.

Helping developers learn a mechanism

Consider a cache tutorial where the reader requests items in different orders and sees which entry is removed. The learning objective should be specific: after using the example, can the reader predict the next eviction?

Ask a teammate to make that prediction before and after using the figure. Their answer is more useful feedback than a general comment that the animation looks polished.

Making a technical article more useful

A figure could support a tutorial when readers benefit from changing an input. Keep the written explanation, assumptions and worked example alongside it so the article remains useful without interaction.

For help deciding which workflows deserve an AI pilot, see practical AI adoption for startups and SMEs.

What to review before putting a figure on your site

Treat the first output as a draft. The creator explicitly describes visual review as necessary and identifies 3D as beta. The published examples also show that detailed work can take hours. Those examples are observations from the creator, not delivery estimates for your project. Creator's limitations and timing notes

Review the figure against these questions:

  • Does every control have a clear purpose, and does each readout agree with the model?
  • Do empty, full, minimum and maximum states behave as the explanation says?
  • Can a reader use it with a keyboard and understand the result without relying on colour?
  • Does it remain readable on a phone and with reduced motion enabled?
  • Is the surrounding explanation complete if the interactive part fails?
  • Does the page remain responsive on the devices your audience uses?

These are acceptance criteria for your implementation. A feature described in a project's documentation still needs checking in the figure you actually ship.

Also decide who will maintain the example. If the written explanation changes, someone needs to update the model, controls and expected outcomes together. For a first trial, I would choose a narrow concept with stable rules and a reviewer who can judge whether the demonstration is correct.

Choosing between a figure and a simpler explanation

Use a short paragraph when the reader needs a definition. Use a conventional diagram when the main question is which systems connect. Consider an interactive figure when changing an input and seeing the consequence is central to understanding.

Before committing to one, write the sentence: “After using this figure, the reader should be able to explain ___.” If the blank is hard to fill, narrow the subject first.

For an architecture decision, the illustration should support the evidence: system boundaries, failure behaviour, operational constraints and trade-offs. An architecture review can help identify the decision that needs explaining before a team invests in presentation work.

Frequently asked questions

Is Anatomy free to use?

The repository uses the MIT licence. Access to the coding agent and its model can have separate costs. Keep the applicable licence notice when reusing the project's software. Project licence

Do you need React?

No. The skill supports standalone output as well as React. Choose the format that fits the destination. Output formats

Will an Anatomy illustration improve SEO?

There is no automatic ranking benefit to assume. Give the article a clear question, a useful answer and an explanation that readers can understand. Add an interactive figure when it serves that explanation, then assess the published page with actual search and user data.