# Anatomy 1.1 for Interactive Isometric Technical Illustrations

> Anatomy is an agent skill for Claude Code, Antigravity, OpenCode, and Codex that turns technical explanations into interactive SVG figures, with optional WebGL effects and beta 3D parts. It is aimed at teams that want a working mechanical model instead of a static diagram.

**wheresryan22/anatomy** — An agent skill for creating detailed, interactive isometric illustrations of real-world machines and complex systems. Generates polished SVGs with optional WebGL shaders and 3D effects.

- Repository: https://github.com/wheresryan22/anatomy
- Website: https://skills.wheresryan.sh/anatomy
- Stars: 19,599 · Forks: 1,530
- Language: JavaScript
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/wheresryan22-anatomy

## What Anatomy Models with Interactive Machines

Anatomy solves a specific explanatory problem: making an abstract software or systems concept visible as a physical mechanism. The README describes a cache key as a pin-tumbler lock that turns only when every pin matches, and a GPU context serving many canvases as a gantry plotter with one print head visiting multiple wells. The point is not to decorate an explanation with machinery. It is to give the reader an object whose operation represents the idea being explained.

The intended users are people working with technical ideas in Claude Code, Antigravity, OpenCode, or Codex. The repository calls the project an agent skill, and its examples cover a dial indicator, an arcade cabinet, a desk computer, a rocket engine test stand, a ripple tank, a spot plate, and a test rig. The examples are committed as HTML pages under `examples/`, so the README presents them as directly openable artifacts rather than only as generated source files.

The output is aimed at explanations that benefit from motion, inspection, and a visible cause-and-effect relationship. Anatomy places a live readout in the figure and keeps the displayed numbers tied to the same small model that moves the parts. That design is more useful for a concept such as a rate limiter or a measurement process than a decorative image would be. It also imposes a higher content cost because the generated object needs meaningful states, labels, and interactions.

## How SVG, WebGL, and 3D Layers Relate

Anatomy's core output is SVG. The README describes solid isometric parts with four-tone shading, painted from back to front, placed inside a framed card. A standalone result can be a standalone HTML page, a lone `.svg` file with embedded styles, or React and Next.js components. The SVG layer handles the structural explanation: housings, shafts, pipes, platforms, gauges, and other visible parts.

For effects that lines cannot adequately represent, Anatomy can insert a WebGL shader between SVG layers. The documented uses include fire, exhaust, water, caustics, lamp light, glow, and steam. The shader runs in the figure's own isometric camera, so the effect is positioned as part of the drawing rather than as an unrelated canvas. The README also states that the SVG remains readable without WebGL. That fallback is an important design constraint: shader effects can add atmosphere or motion without making the entire diagram depend on a WebGL render.

The optional 3D mode is marked beta in the README. Instead of merely flattening a pre-rendered object, it re-projects and re-shades moving parts each frame. The `turning-dial` example describes about 90 parts being reprojected and shaded as the dial is dragged. The `raptor-engine` example uses SVG for the engine and stand while a WebGL shader draws the exhaust plume. This layered architecture lets the project reserve expensive rendering for the parts that need it, but it also creates more implementation surface than a basic SVG generator.

## Installing Anatomy and Running the First Figure

The repository documents Node 20.10 or later as the requirement and states that the kit has no dependencies. The README says it uses only Node's built-in modules, so there is no API key requirement and no `npm install` step. The documented installation command adds the skill globally and lets the CLI ask which agents to configure.

```bash
npx skills add wheresryan22/anatomy -g
```

The CLI can prompt for Claude Code, Antigravity, OpenCode, or Codex. For a non-interactive selection, the README lists agent-specific `-a` values. This example targets Claude Code explicitly.

```bash
npx skills add wheresryan22/anatomy -g -a claude-code
```

After installation, the README gives this Claude Code command for an interactive explanation.

```text
/anatomy explain how a token bucket rate limiter works, interactive
```

The resulting figure is intended to explain the rate limiter through an object that moves as the model changes. For Antigravity and OpenCode, the README says to target those agents with `-a antigravity` or `-a opencode` and use the same `/anatomy` command. Codex uses `$anatomy` instead. The README does not document a separate build command for the examples, so users should not infer that one exists.

## Inspection, Motion, and Model Consistency

Anatomy treats generated figures as working objects rather than static exports. The README says the skill builds an object from dozens of small, shaded parts, places it in a framed card, and adds a title, hint, and live readout. Motion is described as calm and is driven by pointer and keyboard input. The important implementation constraint is that every number shown in the figure comes from the same small model that moves its parts.

That model connection reduces one common failure in explanatory graphics: a readout that is visually plausible but disconnected from the mechanism. In a rate limiter illustration, for example, the moving parts and the numeric display should reflect the same state. The README does not specify the schema for that model or a public API for defining custom figures, so those details remain implementation territory rather than documented extension points.

The project also describes a checking process in which the skill zooms in on every joint. Its `raptor-engine` example includes an audit that checks whether pipes pass through other objects at rest, apart, and during every frame. This is a narrower claim than saying the project verifies every possible rendering error. It shows that Anatomy can inspect geometry and animation states, especially during disassembly or movement, but the documentation does not promise formal visual regression testing for all generated output.

For evaluation, open one of the committed `.html` files in `examples/` and inspect its interaction rather than judging only the screenshot. The README identifies `scripts/capture.mjs` and `scripts/drive.mjs` as the scripts used to capture the gallery images. Those scripts indicate a repeatable capture and interaction workflow, but the documentation does not expose their command-line interfaces.

## Limits of the Beta 3D and Shader Paths

The clearest limitation is the explicit beta status of the 3D mode. The README describes it as suitable for parts that turn in true 3D, including a spinning dial, flexing fingers, and a piece that breaks off and falls. That is a different rendering problem from an SVG assembly whose parts move in a fixed isometric projection. Projects that require mature 3D behavior should treat this as an experimental path and verify the output in the browsers and contexts where it will be used.

WebGL introduces another dependency on rendering support. Anatomy's documented fallback is that the SVG still reads without WebGL, which is useful for static readability, but the optional effects will not be equivalent to the shader version. A figure that depends on fire, caustics, or water should therefore be evaluated in both its SVG-only and shader-backed forms if that distinction matters.

There is also a content-generation burden. A detailed machine requires meaningful part relationships, state transitions, labels, and a readout. A request for an interactive figure can fail through unclear domain modeling even when the SVG itself renders correctly. The README does not claim that Anatomy can produce a validated engineering drawing or a numerically authoritative simulation. It describes an explanatory agent skill that builds a real working object, with a model driving the visible parts and values.

## Anatomy Versus a Conventional Diagram

The real alternative is a conventional static diagram built directly in SVG or exported from a diagramming tool. That approach usually gives the author direct control over labels, layout, dimensions, and the final document. It is easier to review when the goal is to communicate a fixed architecture, sequence, or dependency graph. It does not require designing an object, an interaction model, or a live state just to explain a concept.

Anatomy takes a different approach. Its object is intended to embody the concept through movement. A dial indicator can slide a carriage across gauge blocks and move a needle; a ripple tank can combine SVG apparatus with WebGL layers for light and caustics; a rocket engine can separate into assemblies. This approach is more appropriate when the reader should see how a mechanism changes state or when the explanation depends on cause and effect. The cost is a larger generated artifact and more assumptions about how the physical metaphor maps to the underlying technical subject.

The MIT License permits reuse and modification under its terms. That is a repository-level licensing fact, not legal advice. Review the `LICENSE` file and any dependency or generated-asset terms separately if the illustration will ship in a product. The repository is not archived, and its last push was on 2026-10-15, so the available maintenance signal is recent rather than inactive. The recent releases are v1.1.0 on 2026-10-12 and v1.0.0 on 2026-10-10.

## Conclusion

Anatomy fits developers, educators, and technical writers who need an interactive isometric figure tied to a small working model. It is a poor fit when a static chart, conventional diagram, or non-interactive asset is sufficient. Check the generated SVG structure, model-driven readouts, interaction behavior, browser compatibility, and whether the optional WebGL or beta 3D layer is required before adopting it. The project had its last push on 2026-10-15 and uses the MIT License.

## FAQ

### What is Anatomy used for?

Anatomy is an agent skill for creating detailed, interactive isometric illustrations of technical ideas as working machines or systems. The README says the output can use SVG, WebGL shaders, and beta 3D effects.

### Which agents can run Anatomy?

The README lists Claude Code, Antigravity, OpenCode, and Codex as supported targets. It gives `/anatomy` as the command for Claude Code, Antigravity, and OpenCode, and `$anatomy` for Codex.

### Does Anatomy require dependencies or an API key?

The README states that Node 20.10 or later is required, the kit has no dependencies, and it uses only Node's built-in modules. It also says no API keys are needed.

## Sources

- [License: MIT](https://github.com/wheresryan22/anatomy/blob/main/LICENSE)
- [Project website](https://skills.wheresryan.sh/anatomy)
- [README](https://github.com/wheresryan22/anatomy/blob/main/README.md)
- [Releases](https://github.com/wheresryan22/anatomy/releases)
- [wheresryan22/anatomy on GitHub](https://github.com/wheresryan22/anatomy)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wheresryan22-anatomy