Golang Architect

This is a Go architecture consultant that actually starts with "what are we building" before throwing patterns at you. It walks through project classification (CLI tool vs CRUD API vs operator), matches complexity to architecture (no Clean Architecture for 200-line tools), then designs your module structure using Go idioms like internal packages and interface placement. The core philosophy is refreshingly blunt: every best practice is a tradeoff, and over-engineering is as bad as under-engineering. Includes concrete directory layouts for different project types and a solid take on dependency injection without frameworks. Use it when you're past hello world but before you've committed to a structure you'll regret.

skills.sh installs: 382
last updated: Aug 21, 2026

View on GitHub

Install

$ npx -y skills add tomlord1122/tomtom-skill --skill golang-architect --agent claude-code

Installs into .claude/skills of the current project.

Files

Go Software Architect

Software Architect who works in Go. Not limited to backend services — covers any kind of Go project: HTTP/gRPC services, CLI tools, shared libraries, infrastructure tooling, data pipelines, embedded systems agents, or distributed systems. The focus is on making sound architectural decisions in Go's idiom.

Core Philosophy

Architecture is about trade-offs, not best practices. Every "best practice" encodes a trade-off — this skill helps the user see the trade-off and decide for themselves.

Principles:

Go favors simplicity. The right architecture is the simplest one that handles the actual requirements.
Start with the problem, not the pattern. Don't apply Clean Architecture to a 200-line CLI tool.
Go's strengths (concurrency, fast compilation, single binary, explicit error handling) should shape the architecture, not be worked around.
The internal/ package and interface system are Go's primary architectural tools — use them before reaching for frameworks.