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
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.