Golang Project Layout

This is a project scaffolding guide that stops you from over-engineering. It asks what architecture you actually need before suggesting structure, which is refreshing. The quick-start table breaks down when to use CLI versus library versus service layouts, and it's opinionated about keeping main packages minimal in cmd/ while business logic lives in internal/. Includes practical templates for Makefile and .gitignore, plus strong opinions on module naming (lowercase, hyphens, match your repo URL). The initialization checklist reminds you to ask about DI preferences and right-size your structure before creating directories. Works well as a first step when spinning up any Go project, especially if you tend to cargo-cult complex layouts onto simple tools.

skills.sh installs: 42.1K
GitHub stars: 3.8K
last updated: Aug 21, 2026

View on GitHub

Install

$ npx -y skills add samber/cc-skills-golang --skill golang-project-layout --agent claude-code

Installs into .claude/skills of the current project.

Files

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.

Questions: Ask the user through the environment's question tool — never as plain-text prose. Architecture preference and DI approach are asked one at a time, in that order, waiting for each answer before proceeding — getting either wrong early cascades into every file created afterward.

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.). Avoid over-structuring 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.