SeeCode: a diagram generator that agents drive from a short JSON spec

The output is one HTML file you can interact with

SeeCode turns a short spec into what the README calls an editorial-quality, animated, explorable diagram, and the format of the result is specified precisely: one HTML file you can hover, click and walk through, or export as SVG, PNG, GIF or MP4 for wherever it needs to go.

That single-file property is the design decision, and it explains the rest. A static PNG in a README is a dead end, since it cannot be updated without regenerating it and cannot be read at a different zoom level. An HTML file is both a document and a program, so the same artifact can highlight a path on hover, walk a message through a sequence diagram step by step, and be committed to a repository as a file rather than a binary blob.

The framing in the README is that these are diagrams that move, explain and export themselves, and the navigation links in the header line up with that: Install, Diagram types, See it in action, Themes and your brand, Bring what you already have, Export, and a CLI page under docs/cli.md.

The primary language is JavaScript, the licence is MIT, the last push was on 2026-10-17, and the releases are frequent, with v0.6.2 on 2026-10-17, v0.6.1 on 2026-10-09 and v0.6.0 the same day. The package.json gives the version as 0.6.2, requires Node 20 or later, and carries a badge for zero dependencies.

The audience is narrow and specific. The repository topics name claude-code, claude-skills, codex, agent-skills, coding-agents and developer-tools alongside the diagram vocabulary of architecture-diagram, sequence-diagram, flowchart, data-visualization, mermaid, drawio, svg and isometric. This is a tool for the age of coding agents, and it assumes you have one.

Installing as a plugin or as an agent skill

There are two install paths, and the difference is which agent host you use.

For Claude Code, which the README marks as recommended with the note that the plugin keeps you on the latest release, the installation is two commands entered into the agent.

/plugin marketplace add Aryanutkarsh/seecode
/plugin install seecode@seecode

For Cursor, Codex, OpenCode and other Agent Skills hosts, it is a single npx invocation.

npx skills add Aryanutkarsh/seecode -g

The repository layout explains the second path. There is a skills directory, a .claude-plugin directory, a .codex-plugin directory, a .factory-plugin directory, a .agents directory and a commands directory, so the same capability is packaged for several agent ecosystems rather than only for Claude Code. The skills/seecode/SKILL.md file is what the badge for Agent Skill points at, and it is where the spec format the agent reads is documented.

The package.json also lists the version as private, which is consistent with how the tool is distributed. It is not a library you add to a package.json dependencies block and import; it is a skill the agent loads. The scripts in it are all maintenance tools rather than a build, with test running node --test on the test files, and separate scripts for the gallery, a size budget check, a zip build, a version bump, README shots, feature gifs and a mark build.

The result is a distribution model with no npm install step in the usual sense. A user adds a plugin or a skill, and the agent acquires the tool.

Describing the system in prose and letting the agent write the spec

The workflow the README describes starts with a request in plain language. The example is a system description written as a sentence, naming the browser, the API, Postgres, Stripe and Kafka, and asking SeeCode to show how checkout works.

Use SeeCode to show how checkout works: the browser calls the API,
the API writes to Postgres, charges Stripe and publishes an event to Kafka.

Then the interaction stays in plain language, with the README listing the kinds of follow-up requests: highlight the payment path, make it dark, export it for my slides. That is the part of the design that distinguishes it from a diagram-as-code tool, where every change means editing a text description and re-rendering.

The subject of the sentences is the system, not the syntax. Nothing in the request names a diagram type, a layout algorithm or a colour. The agent reads the SKILL.md, writes the short JSON spec, and SeeCode renders it.

The one setup decision the user makes is about configuration scope. The first time you use it in a project, SeeCode asks once whether to use your global settings or create project-specific ones. That question is asked once, and the answer is remembered for the project, which is a sensible way to handle the fact that a team's brand and a personal machine's preferences usually differ.

The spec is where the model's output lands, and the README is careful about a related point for the chart types. Charts take their numbers from a CSV or JSON file, so the data never has to pass through the model. For anything with real numbers in it, the numbers come from a file the agent reads, not from a value the model wrote, which is a meaningful constraint on where the model can introduce errors.

Forty five diagram types, and the difference between animating and not

The diagram catalogue is large, and the README groups it in a way that explains the design better than a flat list would.

The stated principle is that every type animates its own way and every type can also be fully static. Systems trace their flows, sequences play message by message, charts grow. The animation is not decoration applied uniformly, it is a per-type behaviour that matches what the type means, and the static option exists for the cases where motion would be noise.

The visible portion of the table shows the vocabulary. Architecture for components and connections, and a High-level type described as a 4 to 7 box overview for non-engineers, which is a deliberate pair: the same system rendered at two levels of abstraction for two audiences. Deployment for where things run, hosts and regions. Dependency graph for what imports or depends on what. Architecture delta for what a change adds, removes or alters, which is a genuinely different idea from a diagram of the current state, and the IT current state type with health status.

Then the modelling types: UML class, ER and data model, database schema with tables and foreign key columns, Flowchart for decisions and branches, Sequence for messages between actors over time, State machine, Swimlane, Process for short linear numbered steps, and Data flow. The table continues past what the README excerpt shows, and the section is titled 45 diagram types.

The Architecture delta type is the one worth a second look, because it is the reason to use a generator rather than a static drawing. A before and after comparison, animated, is a review artefact, and asking an agent to produce it after a change is a workflow that no diagram-as-code format gives you for free.

Export targets, and importing what you already drew

Two features round out the tool, and they address the two things that usually go wrong with generated diagrams.

The first is export. The README names SVG, PNG, GIF and MP4 as the output formats, and the header of the documentation has a section for it. The GIF and MP4 targets matter because the animated behaviour is the point, so a static PNG throws away the thing that distinguishes the diagram. A GIF of a sequence diagram playing message by message is a document you can paste into a chat message, and an MP4 is what you put in a slide deck or a video walkthrough.

The second is import, under the heading Bring what you already have. The repository topics list mermaid and drawio, which are the two most common existing diagram formats, so the intent is that a diagram you already have in a text-based format or in a desktop tool can be brought in rather than redrawn from scratch. The README excerpt does not detail the import path, so the specifics are in the documentation rather than here, and the direction of the conversion is not stated.

Themes are the third area, under Themes and your brand, and the request you make is simply make it dark. The mention of your brand suggests a theme can carry more than a colour palette, which for a diagram in a documentation site means the diagram looks like it belongs to the product rather than to a tool.

The overall shape is worth noticing. The tool covers the entire life of a diagram, from describing it, to animating it, to branding it, to getting it into a format that suits the destination, and it does so as a single self-contained HTML file with no dependencies at all.

Editorial conclusion

SeeCode fits a developer who wants architecture and sequence diagrams that animate and can be walked through, and who is already working with a coding agent that can write the spec, and it does not fit someone who wants a deterministic diagram from a hand-written file with no model in the loop, or who needs the output to be diffable in version control, since the animated viewer output is a single HTML file. Before using it in a repository, check the skills/seecode/SKILL.md file for the spec format, and note that the package is marked private in package.json, so it is installed as an agent skill rather than as a library dependency.

Frequently asked questions

Official sources

1. Aryanutkarsh/SeeCode on GitHub
2. Issues
3. License: MIT
4. README
5. Releases