System Atlas turns an architecture discussion into an interactive isometric map from one data file

The developer working under the inkboard account published System Atlas, an agent skill that renders a system's architecture as an interactive isometric map and a matching Markdown document from one shared data file. The GitHub repository has picked up 410 stars since it was opened on 20 August, and it is MIT-licensed.

What it draws

The map is a single self-contained HTML file. Hovering a structure reads its description, clicking pins it, and an arrow key steps inside to see that structure's own execution as a sub-map. Chapters reveal the system a few structures at a time so the first view is not a wall of boxes, and dots that travel between structures are real requests: click one and a panel shows its route and a representative JSON payload. Roles have their own isometric shapes so the reader can tell a store from a scheduled job without a key.

What the agent writes alongside it

The same data file also produces SYSTEM.md. It carries the decisions table with links to any architecture decision records, every structure's role and steps, the flow tables, and a question index. Every open question gets a stable identifier and a state: open, resolved with an answer and a date, or routed to a named next step. The map is what the skill puts in front of a person; the Markdown is what the repository and the next agent session read. Because both are built from data.mjs, updating the design is one edit and a rebuild.

How it installs

System Atlas is a skill package for the Vercel Labs skills CLI, which installs skills into Claude Code, Cursor, Copilot, Codex, Gemini, Cline and Amp. The skill file, the isometric renderer, the build script, a documented starter data file, a design-language reference, a process-and-lessons reference, and three evaluation prompts all ship in the repository. The build itself has no runtime dependencies, and the atlas is a plain HTML file that any static host or python3 -m http.server can serve.

Teams that already keep architecture decision records and a glossary can drop the atlas next to them under docs/<system>/atlas/. Teams that deliberately commit only decisions and a glossary can keep the atlas in an ignored scratch directory and attach the generated SYSTEM.md to the specification issue when it changes. The skill asks before committing anything.

An architecture drawn once and hand-maintained in a diagram tool falls out of sync with the code within a sprint. Two documents describing the same system, one for people and one for agents, fall out of sync faster. What System Atlas offers is one file that both are generated from, plus a process that walks the agent through reading the repository before drawing, discussing before building, and running feedback rounds against tracked question identifiers rather than a comment thread. That structure is worth more to a team than the isometric render on its own: it is the difference between an atlas that dates on the day it was drawn and one that survives a design change.

Source

Primary source: inkboard/system-atlas on GitHub.