Generate an architecture diagram from a Rust project.
Cargo already knows the crate graph, so a workspace diagram is mostly a rendering of something the build system computes anyway.
What it reads
Cargo.toml for the crate and its dependencies, the workspace members list where there is one, and then the module tree from lib.rs or main.rs. Rust's module system is explicit, so the structure declared in the code is the structure, with none of the ambiguity that dynamic languages introduce.
How Rust becomes components
In a workspace, each crate is a component and the dependency edges come straight from Cargo. Within a crate, modules become components where they own something meaningful, and trait definitions are treated as boundaries in the same way Go interfaces are. Feature flags are read, because a crate whose shape changes substantially with features has more than one architecture and it is worth knowing which one is drawn.
Why the layout can be trusted
The agent reads the files listed above and emits a semantic graph: components, the tier each belongs to, and the edges between them, with no coordinates anywhere. The ELK layout engine then computes positions and orthogonal edge routing. This is why the output cannot come back with boxes overlapping or arrows crossing through cards, which is the usual failure when a language model is asked to place things on a canvas itself.
Async runtimes and task boundaries
Where a project spawns long-lived tasks, those are components in every practical sense: they have a lifetime, they own state and they communicate over channels. Drawing them alongside the module structure gives a more accurate picture of what runs than the module tree alone, which describes how the code is organised rather than how it executes.
Your code stays on your machine
It runs on your machine. With a local Ollama model nothing leaves the laptop at all, and with your own API key the file contents go to the provider you chose and never through us. For a source that is your actual codebase, that distinction is usually the deciding one.
Rust to diagram
| In the project | In the diagram |
|---|---|
| Cargo.toml | Crate identity and dependencies |
| Workspace members | Components, with edges from the crate graph |
| Module tree from lib.rs or main.rs | Internal structure |
| Trait definitions | Boundaries between components |
| Feature flags | Noted where they change the shape |
| Spawned async tasks | Long-lived components |
| Channels between tasks | Edges |
| #[cfg(test)] modules | Not drawn |
The prompt
Questions
Related
- Generate a Diagram from a CodebasePoint it at a repository and it surveys the code the way a new engineer would, then draws what it found.
- Generate a Diagram from TerraformTerraform already describes your infrastructure precisely. The diagram is a rendering of something you have written down, not a guess.
- Generate a Diagram from Kubernetes ManifestsKubernetes YAML contains the whole topology and presents it as several hundred lines in which none of it is visible.
- Generate a Diagram from Docker ComposeA Compose file is already a complete description of a small system. It is just written in a format that hides the shape.