Generate an architecture diagram from a Go project.
Go's package structure is unusually honest, which makes it one of the better languages to read architecture out of.
What it reads
go.mod for the module identity and external dependencies, the package layout, and then the import graph from each main package. Go's rules help here: imports are explicit, cycles are forbidden by the compiler, and the internal directory marks intended boundaries. That combination means the drawn graph is closer to the real dependency structure than in most languages.
How Go becomes components
Each main package is a deployable and gets its own tier position. Below it, packages become components grouped by responsibility, with interface definitions treated as the boundaries they are: a package that defines an interface which several others implement is a seam, and seams are the most useful thing on a Go architecture diagram. Handler registration identifies the API surface, and driver imports identify the data tier.
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.
Interfaces mark where the design is
In Go the interesting architectural decisions tend to be expressed as small interfaces at the consumer side, which is idiomatic and almost impossible to see by browsing files. Surfacing them as boundaries on the diagram shows where the code was designed for substitution and, by omission, where it was not.
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.
Go to diagram
| In the project | In the diagram |
|---|---|
| go.mod | Module identity and external dependencies |
| cmd/* main packages | Deployable services |
| internal/* | Components, with the boundary marked |
| Interface definitions | Seams between components |
| HTTP or gRPC handler registration | The API surface |
| database/sql and driver imports | Data tier edges |
| Channels and goroutine workers | Asynchronous components |
| *_test.go | Not drawn |
The prompt
Questions
Does it need the project to build?
No. It reads source files rather than invoking the toolchain, so a project with missing dependencies still diagrams.
Does it understand the standard project layout?
Yes, cmd, internal and pkg are recognised, and it does not assume them: plenty of good Go projects use a flatter structure and read fine.
Will it show goroutines and channels?
Where they form a real component boundary, such as a worker pool consuming from a channel, yes. Ordinary concurrency inside one function is an implementation detail and is not drawn.
What about gRPC services?
Proto definitions are read for the service interface, and the generated code is recognised as generated rather than drawn as components of its own.
Related
- Generate a Diagram from a Rust ProjectCargo already knows the crate graph, so a workspace diagram is mostly a rendering of something the build system computes anyway.
- Generate a Diagram from a Django ProjectDjango's conventions are strong enough that most of the architecture is declared rather than implied, which makes it one of the easiest sources to read accurately.
- Generate a Diagram from a Next.js ProjectThe interesting line in a Next.js app is the one between server and client, and it is invisible in the file tree.
- Generate a Diagram from a Prisma SchemaA Prisma schema states relationships explicitly, which makes it one of the most reliable sources for an entity diagram that exists.
Last updated