Skip to main content
← Skills
Skill · Code repo

Anatomy: Interactive Mechanical Diagrams Anatomy

Explain technical concepts with interactive isometric SVG diagrams. Add WebGL effects or experimental 3D for documentation, articles and product pages.

  • svg
  • interactive
  • webgl
  • agent-skill

Works with Claude Code · Codex · Antigravity · opencode

Requirements

  • Node.js >=20.10
  • skills CLI 1.7.1: Node.js >=22.20
  • Chrome / Chromium
  • React >=18

Overview

What you get

  • Editable isometric SVG figures as standalone HTML, SVG files or React/Next.js components.
  • Interactive mechanisms whose motion and live readouts share the same model.
  • Optional WebGL effects for fire, water and light, plus experimental 3D motion.

Good fit

  • Explaining a technical concept through a recognizable physical mechanism.
  • Technical documentation, articles and interactive product pages.
  • Adapting bundled examples to your own parameters, labels and controls.

Not for

  • Engineering CAD or applications that require validated physics.
  • Statistical charts, maps or character illustrations.
  • Quickly generating entire vehicles or factories with many moving systems.

Tutorial

Turn an idea into an interactive diagram

After watching Anatomy’s demos, you may want a diagram with detailed parts, responsive movement and changing readouts. The first design question is how to turn your subject into a mechanism that explains something.

This tutorial starts with an official example. You will then describe a diagram, request a first version, revise it and adapt the process to your own subject. The goal is to give your coding agent a useful brief, beyond asking for something that looks like the demo.

Anatomy uses mechanical structures to explain concepts. SVG draws the parts, interaction code updates motion and readouts, and optional WebGL or experimental 3D adds effects. The result is editable code, delivered as standalone HTML, SVG or React/Next.js components.

About the examples: Installation and build commands come from the official repository. The dial-indicator build command has been run for this tutorial. The editorial prompts below show how to organize a brief. Each prompt has not been tested by generating a figure, and does not guarantee a result matching the creator’s demos.

1. Learn to read a finished diagram

Open the official Anatomy gallery and choose a figure. Leave the code aside for now. Look for three things: what the drawing represents, what your action changes, and what that change explains.

In the bundled dial-indicator example, a carriage moves gauge blocks of different heights under a plunger. The needle responds to the change. Parts, movement and numbers together show how height becomes a measurement.

Use this format to record what you observe:

Subject: A dial indicator measuring gauge-block height.
Main parts: Gauge blocks, carriage, plunger and needle.
Action: Move the carriage to bring different blocks under the plunger.
Response: Plunger position and needle reading change together.
Reader takeaway: The relationship between block height and the measurement.

Choose another figure and fill in the same five lines. If your description only says that it looks detailed, try its controls again. Your own brief will need this connection between action and meaning.

2. Install Anatomy and run an editable example

Install the skill in your coding agent before asking it to follow Anatomy’s workflow. The toolkit needs Node.js 20.10+. The official README lists Node.js 22.20+ for skills CLI 1.7.1, so use Node.js 22.20 or later for the installation command below.

Browser checks need Chrome or Chromium. React 18+ is needed only for React output.

  1. Install the skill in a terminal. Select your coding agent when prompted.

    # Check Node, then install Anatomy globally
    node --version
    npx skills add wheresryan22/anatomy -g

    Add -a claude-code, -a codex, -a antigravity or -a opencode to target one agent. Omit -g for a project installation.

  2. Download and build the official example. Run this where you want to keep the working copy:

    # Download a working copy and build the light-theme dial indicator
    git clone https://github.com/wheresryan22/anatomy.git anatomy-demo
    cd anatomy-demo
    node examples/dial-indicator/build.mjs --light

    The toolkit uses Node built-ins, so no repository npm install is needed. The terminal should print wrote dial-indicator-light.html.

  3. Open the file in Chrome or Chromium. Find this file:

    anatomy-demo/examples/dial-indicator/dial-indicator-light.html

    Move the pointer and watch the carriage and needle. Press Tab to focus the diagram, then try the arrow keys. When you can see the response, your first preview is complete. Without --light, the output is named dial-indicator.html.

Keep this working copy. It lets you inspect the result and gives your agent an example of the files behind a finished figure.

3. Turn an idea into a design brief

Suppose you want to explain database connection pools in developer documentation. “Draw a connection pool” leaves important choices open. Do you want to explain reuse, queueing or performance monitoring? Choose one thing readers should understand first.

For this exercise, choose limited capacity: requests borrow connections, return them, and wait when the pool is busy. Add the information that determines behavior and presentation:

Brief itemExampleWhy it matters
AudienceDevelopers new to connection poolsSets the depth and terminology
Core ideaBorrowing, returning and waitingDefines the process to show
Rules10 connections, first-in-first-out queueGives counts and movement a basis
Reader actionAdd a request, finish a requestLets readers explore state changes
DestinationStandalone HTML in documentationDetermines delivery format and layout

With these details, Anatomy can propose a mechanism. You do not need to place every pipe or screw, but you need to say what the drawing should express.

Send this prompt to Claude Code, Antigravity or OpenCode. In Codex, replace /anatomy with $anatomy. The keyword interactive requests interaction.

/anatomy
Make an interactive diagram for developers new to database connection pools.
Explain limited capacity: requests borrow connections, return them, and wait when all are busy.

Use teaching parameters: 10 connections and a first-in-first-out waiting queue.
Provide controls to add a request, finish one request and reset.
Use one state model for busy, idle and waiting counts and for moving parts.

First propose an understandable mechanism and explain what each part represents.
Only provide the design at this stage. Wait for my confirmation before generating code.
Plan a first version with SVG, a light theme and standalone HTML, without WebGL or 3D.

Review the mapping before approving it. Can readers distinguish a connection from a request? Where does waiting happen? Can an action demonstrate borrowing or returning? Revise the design first if these relationships are unclear.

4. Make a first version that explains the idea

After approving the mechanism, continue with this request:

Build the first version using the approved design.
Complete the core parts, interaction and necessary English labels before refining detail.
Support keyboard controls and respect the system’s reduced-motion preference.
Deliver standalone HTML, source files and actual preview instructions.
Identify which checks were performed and which were not.

Open the result and try a complete sequence: add requests, fill the pool, add another, then finish one. Watch whether the waiting request receives the released connection. This tests whether the drawing communicates queueing and reuse.

Correct numbers alone are not enough. If the readout says “1 waiting” but every request appears inside the same machine, readers may not distinguish waiting from active use. Revise the visual explanation.

For example:

The readout shows waiting requests, but the drawing does not show which request is waiting.
Separate the waiting area from the area where requests use connections. Add short labels.
When a request receives a connection, move it from the waiting area to the corresponding position.
Keep capacity and queue rules unchanged. Only revise this part of the presentation.

Describe what is unclear and what readers should notice. That gives the agent a more useful target than “make it more intuitive.”

5. Learn to control the result with one small change

Save the working HTML and source files first. Then choose one change and observe what it affects. Here, change capacity from 10 to 6:

Keep the mechanism, camera and colors.
Change capacity from 10 to 6 and the title to “Connection reuse”.
Update state calculations, corresponding parts, control ranges and explanatory copy together.
Do not only replace the displayed number.
Provide updated preview instructions and list the changed files.

Open the new version and add 7 requests. Expect 6 busy connections and 1 waiting request. Finish one request; the waiting request should receive its connection. Compare the drawing with the readouts, then check for old capacity references in the copy.

The lesson is that one parameter can affect the model, drawing and text. When you use your own data, specify which parts must change together.

If the result is wrong, report the action, actual result and expected result:

After resetting, I added 7 requests.
Actual: busy is 7 and waiting is 0.
Expected: with capacity 6, busy should be 6 and waiting should be 1.
Check the capacity condition. Keep the layout and colors.

6. Adapt the process to your own subject and product

Leave the connection-pool exercise behind and write your own brief. Fill in these five lines before sending it to the agent. Replace all bracketed text.

Audience: [Who will read this, and what do they already know?]
Subject: [The concept or machine to explain]
Process: [What enters, what changes, and what comes out?]
Interaction and feedback: [What does the reader do, and how do parts and readouts respond?]
Destination and output: [Where will it appear? HTML, SVG or React components?]

If you have product materials, provide actual parameters, terminology, structural descriptions and brand colors. Reference images help explain finish and layout, but text still needs to explain relationships between parts. Do not rely on the agent to infer a machine’s behavior from an image alone.

ChangeMaterial to provideWhat to check again
Subject or machineCore idea, parts and relationshipsDoes the mechanism explain the new subject?
Count, rate or thresholdActual values, units and rulesDo model, movement and readouts agree?
BrandingColors, background and final copyAre text and parts distinguishable?
DestinationPage width, framework and static/interactive needsDo mobile layout, code and styles work?

Ask for the mapping between parts and concepts before requesting a build. Approve it, then use the same preview and focused-revision process.

To assess your brief, ask: without reading the title, what can a reader discover through interaction? If the answer is only “the parts move,” specify what that movement means.

7. Choose effects and delivery for the intended use

Once the basic diagram works, decide whether an effect helps readers understand something.

Behavior to showOptionOfficial reference
Moving parts, exploded views and readoutsSVG with interactiondial-indicator
Fire, water or lightSVG + WebGLraptor-engine, ripple-tank
Parts rotating in three dimensionsExperimental 3Dturning-dial

A flame can help explain combustion. A connection-pool diagram may need only SVG interaction. WebGL effects must align with the drawing’s perspective and placement. The base figure should remain understandable without WebGL.

Specify delivery too. Standalone HTML suits independent previews, SVG suits static article illustrations, and components suit existing React/Next.js sites. An SVG file alone does not include an HTML example’s controls and interaction logic.

For Next.js, try the request below. The component name is an example, not a built-in Anatomy API.

Integrate the approved diagram into my Next.js documentation page as AnatomyFigure.
Keep the existing model and interaction.
Follow Anatomy’s React guide for geometry, static art and client interaction. Copy required kit modules.
Fit the content column. Support keyboard controls and the system’s reduced-motion preference.
Provide this project’s preview command, check desktop and phone sizes, and report the results.

Troubleshooting and official references

Why is Anatomy missing after installation?

Check the selected agent and installation scope. Use a project installation inside the matching project. Claude Code can try /reload-skills; restart Antigravity, OpenCode or Codex if necessary. Codex lists skills under /skills and invokes Anatomy with $anatomy.

Why do browser checks fail after HTML is generated?

Check that Chrome or Chromium runs. Use CHROME_PATH if the tools cannot find the executable. Local-port or temporary-profile restrictions can also block checks. Try running them in a local terminal and inspecting the screenshots.

What if generation takes too long?

Reduce the first version to one core mechanism. Complex pipework, multiple WebGL layers and 3D increase build and checking time. Confirm that the explanation works before adding detail.

What if the drawing looks good but explains little?

Revisit the mapping between parts and concepts. Identify which action is unclear and what readers should see. Adjust structure, movement and labels before colors and decoration.

Can I use the readouts for engineering calculations?

Not without validation. Check parameters, units, formulas and rules. Geometry audits address intersections, endpoints and depth ordering; they do not validate machine safety or physical accuracy.

For further work, see the README and examples, skill instructions, React guide, WebGL guide and 3D guide. See the creator’s results in the launch demonstration.