golang-architecture
Skill1 starsChanged 4 months agoMITView on GitHub
Golang application architecture covering package boundaries, dependency direction, manual dependency injection, constructors, lifecycle, project layout, workspaces, and pragmatic architectural patterns. Use when starting or restructuring a Go project, splitting packages or modules, wiring services, breaking import cycles, or choosing an application structure.
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 26
Ask about constraints that materially change the layout: library vs application, single binary vs multiple binaries, and monorepo vs …
- Distinctive: line 28
Prefer explicit constructors and manual wiring in main.
- Distinctive: line 29
Keep packages cohesive, break cycles at behavior boundaries, and avoid speculative interfaces.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Persona: You are a pragmatic Go architect. Introduce structure only when it protects a real boundary or makes change safer.
Go Architecture
Workflow
- Discover the executable entry points, modules, package graph, external boundaries, and deployment shape.
- Ask about constraints that materially change the layout: library vs application, single binary vs multiple binaries, and monorepo vs repository-per-service.
- Define dependency direction before naming directories.
- Prefer explicit constructors and manual wiring in
main; do not pass containers or service locators through business code. - Keep packages cohesive, break cycles at behavior boundaries, and avoid speculative interfaces.
- Validate with
go list ./...,go test ./..., and the existing build commands.
Conditional references
- Package and system architecture: architecture.md, clean-architecture.md, and hexagonal-architecture.md
- Domain modeling: ddd.md
- Manual constructor injection: manual-di.md
- Directory layouts and workspaces: directory-layouts.md and workspaces.md
- Project configuration and test placement: config.md and testing-layout.md
- Resource ownership and lifecycle: resource-management.md
- Streaming and large data: data-handling.md
→ See
golang-refactoringfor staged structural changes andgolang-projectfor CI and documentation.
In this repository14 other files it gives its agents.
- AGENTS.mdAGENTS.md
- golang-code-qualitySkill
- golang-concurrencySkill
- golang-databaseSkill
- golang-dependenciesSkill
- golang-goplsSkill
- golang-observabilitySkill
- golang-performanceSkill
- golang-projectSkill
- golang-refactoringSkill
- golang-securitySkill
- golang-testingSkill
- golang-toolingSkill
- golang-troubleshootingSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.