Anatomy in 2026: Interactive Isometric Diagrams for Documentation
Hello HaWkers, explaining a technical system with an attractive image is relatively easy; explaining what changes when someone interacts with it is another matter. The open source Anatomy project proposes turning an idea into an interactive isometric machine, built primarily with SVG. The repository also describes WebGL options and a still experimental 3D mode. Instead of treating the drawing as decoration, it tries to make each part correspond to a part of the explanation.
Have you ever published a diagram that seemed obvious to its creator but left readers unsure where to begin? Here you will learn how to write a useful request for Anatomy, choose an output format, review the interaction, and build a small SVG version to understand the principles behind the result. The goal is a repeatable method for visual documentation.
What Anatomy does and where it fits
Anatomy is a skill for a coding agent. According to the project documentation, you describe a concept or object, specify where the illustration will be used, and receive source code for an interactive illustration. Its core uses shaded isometric SVG pieces; effects such as water, light, and smoke can use WebGL. The README labels the mode with rotating 3D parts as beta. This differs from asking an image generator for a static picture: there is state, behavior, and a relationship that must make sense between a displayed value and the movement of its parts.
The repository offers outputs such as a standalone HTML page, an isolated SVG, or components for React and Next.js. It also includes examples and capture and audit scripts. In an API guide, a readable and well-labeled SVG may communicate more than a scene full of particles. WebGL helps when the visual phenomenon is itself part of the explanation, such as flow, glow, or refraction.
Think about the reader before you think about the camera. Someone arriving from a search result wants to identify the main part, recognize a change of state, and learn what to do with that information. If an animation does not show a causal relationship, it uses space and attention without teaching. The same applies to a diagram that reveals its content only on hover: on a phone or with a keyboard, that information may disappear.
Choose a question the diagram can answer
A good starting point is a narrow question: “Why does a request wait when all connections are busy?” That gives the agent an observable event. “Draw a modern architecture,” on the other hand, invites generic boxes, arbitrary arrows, and no way to check correctness. The Anatomy README recommends naming the idea, providing real numbers when they exist, and saying which format you want delivered. If you do not know the production numbers, label values as teaching examples; do not turn an assumption into a metric for your system.
Imagine a pool with three fictional connections and a queue. The diagram should answer: which connection is available, what happens when a fourth request arrives, and when does the queue move? There are clear states to represent: available, busy, and waiting. A workshop with workbenches could be a useful metaphor, provided it does not hide the rule: a connection returns to the pool only after it is released. The text beside the diagram should repeat that rule plainly.
Write a short specification first: audience, question, visible objects, states, transitions, and expected output. Only then ask for geometry, colors, and movement. This order keeps an aesthetic detail from deciding how the system works. It also makes generated code easier to review: every movement should correspond to a defined transition, and you can reject pieces that serve only as ornament.
If your documentation already uses animated SVG, see the article about animating SVG with CSS. It helps distinguish a simple visual transition from an interaction that needs JavaScript and explicit state.
Installation and the first request
The official README shows installation through the skills catalog or Git. The first option below installs the skill for Claude Code at user scope. Inspect the repository and its instructions before running third-party code in your environment; installation copies project files into the skills directory.
# Install the skill for Claude Code in the user's profile.
npx skills add wheresryan22/anatomy -g -a claude-code
# Local alternative for a project: read the repository before adopting it.
git clone https://github.com/wheresryan22/anatomy.git .claude/skills/anatomyYour request should then specify the explanation, the interaction, and the destination. A useful example is: “Create a diagram of a connection pool with three illustrative connections; show a request waiting when all are busy, let readers advance with a button and a keyboard, deliver standalone HTML, and keep a text summary visible at all times.” The three connections are values for the demonstration, not a recommendation for real database capacity. Also ask for an initial state that communicates something without movement, because some readers reduce animation or use assistive technology.
When reviewing the first delivery, check whether the project supplied code you can maintain. Find the state model, the isometric projection, the labels, and the event handlers. Do not accept a result where changing a sentence requires editing coordinates scattered across dozens of files. Anatomy documentation says the illustrations can include a build script and a generated page; treat the script as the source and the page as the artifact you publish.
A minimal example to understand state and interaction
Before evaluating a complex diagram, it helps to build a small one by hand. The following example is not output from Anatomy: it is a standalone HTML page created here to show the rule you should demand from any interactive illustration. A button switches one connection between available and busy. The visible status and the text announced to assistive technology are updated by the same function that changes the color. Save the content as pool.html and open it in a browser.
<!doctype html>
<html lang="en">
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Connection state</title>
<h1>Connection pool: teaching example</h1>
<p id="estado" role="status">The connection is available.</p>
<svg viewBox="0 0 320 180" width="320" role="img" aria-labelledby="titulo descricao">
<title id="titulo">One connection in the pool</title>
<desc id="descricao">The block changes color when the connection becomes busy.</desc>
<polygon points="70,70 160,25 250,70 160,115" fill="#a7d8c9" />
<polygon id="bloco" points="70,70 160,115 160,155 70,110" fill="#28745d" />
<polygon points="160,115 250,70 250,110 160,155" fill="#1e5848" />
</svg>
<p><button id="alternar" type="button">Use connection</button></p>
<script>
// One state drives the shape, the label, and the next action.
let ocupada = false;
const bloco = document.querySelector('#bloco');
const estado = document.querySelector('#estado');
const botao = document.querySelector('#alternar');
botao.addEventListener('click', () => {
ocupada = !ocupada;
bloco.setAttribute('fill', ocupada ? '#b85342' : '#28745d');
estado.textContent = ocupada
? 'The connection is busy; new requests must wait.'
: 'The connection is available.';
botao.textContent = ocupada ? 'Release connection' : 'Use connection';
});
</script>
</html>The native button already responds to keyboard and touch. The MDN reference for SVG <title> explains that it supplies a short accessible description; a longer description can go in <desc>. Together, those elements make the graphic easier to understand, but they do not replace the status text outside it. Someone who cannot perceive the color change still needs to know what happened. In a real diagram, you would also check contrast, focus, zoom, motion preferences, and reading on a narrow screen.
Notice that the polygon makes a simplified isometric shape without a library. For a system with many parts, Anatomy's value is building and checking a composition that would take much longer to create manually. The principle remains the same, though: the data and the movement must come from the same state. If a display says “available” while the machine shows “busy,” the illustration teaches the opposite of what it promises.
How to review a generated diagram beyond its appearance
Start with the original question. Complete the interaction and try to answer without reading the code: is the initial state clear? Does each action have a predictable effect? Does the text confirm the change? An animation that makes you guess what is clickable may work in a demonstration but fails as documentation. Put short instructions near the control and test the path with a keyboard, touch, and pointer. If a state appears only on hover, add an explicit alternative that stays available long enough to read.
Next, inspect the model. Look for values copied manually into labels, movements, and panels. Anatomy describes its aim as deriving readings and movement from the same small model. That is a useful standard for any tool: if you change the example's capacity, every representation should update together. Also confirm whether published values match the actual product or are identified as demonstration values. An illustration can be mechanically consistent and still be factually wrong if it starts from invented data.
Finally, compare the outputs. An isolated SVG may suit a lightweight page with no interaction. A standalone HTML page makes a prototype easy to share. A React component may integrate better with existing documentation, but it introduces decisions about rendering, state, and bundling. Choose the format according to the infrastructure where the diagram will live. A beta 3D output calls for even more attention to performance and support, particularly on modest devices. Test the chosen output in the same environment that readers will use.
The repository has capture and audit scripts for some examples. They can help uncover geometric defects, but they do not certify that the concept is correct or that the experience is accessible. Human review remains necessary: compare states with the initial specification, ask another person to explain the diagram, and record where they hesitate.
Publishing, maintenance, and artifact safety
An interactive diagram becomes part of the documentation maintenance cycle. Keep the prompt or specification, the source code, and a capture of each important state in the repository. When a product rule changes, update the model and the text first; then adjust the geometry. This reduces the risk of publishing a technically beautiful panel that still shows an outdated business rule.
Add a basic check to the review process. The following command does not replace browser testing: it merely confirms that the file exists, includes the expected controls, and contains an HTML document. It can prevent you from accidentally publishing an empty capture or a version with no interaction. Run it in the directory where you saved pool.html.
# Check for the essential elements in the example.
test -s pool.html
python3 - <<'PY'
from pathlib import Path
pagina = Path('pool.html').read_text(encoding='utf-8')
for trecho in ('id="estado"', 'id="alternar"', 'aria-labelledby', "addEventListener('click'"):
assert trecho in pagina, f'Missing element: {trecho}'
print('Basic structure found; review the interaction in a browser.')
PYBecause Anatomy consists of local instructions and scripts, read its code and commands before running them on a machine with sensitive data. The project security policy says some capture scripts start Chrome in headless mode and one executes user-provided JavaScript on the page. Use those scripts only with pages you trust. If you embed generated HTML on a public site, review dependencies, external references, content policy, and what the script tries to load. Generated code should receive the same review as any other code you plan to publish.
This care also applies to the page's links and images. An artifact that works locally may rely on an absolute path, a font that is not licensed for redistribution, or an API available only in the author's environment. Open the output in a clean session and follow the same sequence of interactions a reader would. That way the test covers the published experience, not only the script that produced it.
When to use Anatomy and when to simplify
Use Anatomy when a spatial relationship helps explain a process: flow between parts, resource occupancy, changes of state, or how a machine works. It seems especially suited to explanations where readers need to discover what moves and why. A diagram about a cache, a connection pool, or the stages of an operation has a concrete question to guide the animation. In each case, the motion should expose a rule that would otherwise be hard to picture.
Simplify when the answer fits in a table, a code snippet, or a sentence. A price comparison, a list of API parameters, and a configuration decision usually do not become clearer when projected into isometric space. The cost of maintaining the diagram is justified only if it reveals something static text hides. To start, make a small prototype and ask someone to explain the concept after interacting with it. If the prototype does not improve their explanation, revise the question or choose a simpler form.
Consider the audience, too. On a reference page people consult quickly, a static image with captions may be better. In a concept tutorial, interaction lets readers try states and build intuition. One specification can produce a static SVG for quick reading and an interactive version for closer exploration.
The outlook for visual documentation in 2026
The promising part of Anatomy is that it offers code and a model for an explanation rather than only a finished image. That can bring illustration, documentation, and testing closer together: when the system changes, the diagram can change with it. The promise still depends on careful review. An attractive scene cannot repair an invented figure, an inconsistent state, or an inaccessible control. Treat the source as something to maintain and the visual as an explanation you must be able to defend.
If you try the tool, start with one question users ask frequently. Define that question, write down the states, and request a simple diagram. Test it with a keyboard and phone, inspect the delivered code, and ask for feedback from someone who did not create it. The best illustration is the one that makes the mechanism easier to explain after the animation ends. You should be able to tell its story in plain words, even when the screen is still.
Let's go! 🦅
📚 Want to Keep Up With What Is Coming?
This article covered isometric diagrams with Anatomy, but the ecosystem changes every week, and not every development becomes an article here.
On X, I share what I am testing, behind-the-scenes notes from my projects, and news that appears before it becomes a blog post.
Follow Me There
💡 Daily content about development, careers, and the tools I actually use