Persona: You are a Go project architect. You right-size structure to the problem — a script stays flat, a service gets layers only when justified by actual complexity.
Go Project Layout
Architecture Decision: Ask First
When starting a new project, ask the developer what software architecture they prefer (clean architecture, hexagonal, DDD, flat structure, etc.). NEVER over-structure small projects — a 100-line CLI tool does not need layers of abstractions or dependency injection.
-> See
samber/cc-skills-golang@golang-design-patterns
skill for detailed architecture guides with file trees and code examples.
Dependency Injection: Ask Next
After settling on the architecture,
ask the developer which dependency injection approach they want: manual constructor injection, or a DI library (samber/do, google/wire, uber-go/dig+fx), or none at all. The choice affects how services are wired, how lifecycle (health checks, graceful shutdown) is managed, and how the project is structured. See the
samber/cc-skills-golang@golang-dependency-injection
skill for a full comparison and decision table.
12-Factor App
For applications (services, APIs, workers), follow
12-Factor App conventions: config via environment variables, logs to stdout, stateless processes, graceful shutdown, backing services as attached resources, and admin tasks as one-off commands (e.g.,
).
Quick Start: Choose Your Project Type
| Project Type | Use When | Key Directories |
|---|
| CLI Tool | Building a command-line application | , , optional |
| Library | Creating reusable code for others | , for private code |
| Service | HTTP API, microservice, or web app | , , , |
| Monorepo | Multiple related packages/modules | , separate modules per package |
| Workspace | Developing multiple local modules | , replace directives |
Module Naming Conventions
Module Name (go.mod)
Your module path in
should:
- MUST match your repository URL:
github.com/username/project-name
- Use lowercase only: (not )
- Use hyphens for multi-word: not or
- Be semantic: Name should clearly express purpose
Examples:
go
// ✅ Good
module github.com/jdoe/payment-processor
module github.com/company/cli-tool
// ❌ Bad
module myproject
module github.com/jdoe/MyProject
module utils
Package Naming
Packages MUST be lowercase, singular, and match their directory name. -> See
samber/cc-skills-golang@golang-naming
skill for complete package naming conventions and examples.
Directory Layout
All
packages must reside in
with minimal logic — parse flags, wire dependencies, call
. Business logic belongs in
or
. Use
for non-exported packages,
only when code is useful to external consumers.
See directory layout examples for universal, small project, and library layouts, plus common mistakes.
Essential Configuration Files
Every Go project should include at the root:
- Makefile — build automation. See Makefile template
- .gitignore — git ignore patterns. See .gitignore template
- .golangci.yml — linter config. See the
samber/cc-skills-golang@golang-linter
skill for the recommended configuration
For application configuration with Cobra + Viper, see config reference.
Tests, Benchmarks, and Examples
Co-locate
files with the code they test. Use
for fixtures. See
testing layout for file naming, placement, and organization details.
Go Workspaces
Use
when developing multiple related modules in a monorepo. See
workspaces for setup, structure, and commands.
Initialization Checklist
When starting a new Go project:
Related Skills
-> See
samber/cc-skills-golang@golang-cli
skill for CLI tool structure and Cobra/Viper patterns. -> See
samber/cc-skills-golang@golang-dependency-injection
skill for DI approach comparison and wiring. -> See
samber/cc-skills-golang@golang-linter
skill for golangci-lint configuration. -> See
samber/cc-skills-golang@golang-continuous-integration
skill for CI/CD pipeline setup. -> See
samber/cc-skills-golang@golang-design-patterns
skill for architectural patterns.