Golang Project Layout
Bootstrap a Go service repo with standard `cmd/` layout, Makefile targets, gitignore, and test/coverage habits.
Overview
golang-project-layout is an agent skill for the Build phase that standardizes Go repo layout with `cmd/` binaries, Makefile build-test-lint targets, and gitignore conventions.
Install
npx skills add https://github.com/samber/cc-skills-golang --skill golang-project-layoutWhat is this skill?
- Makefile workflow: `build`, `build-all`, `clean`, `test`, `test-short`, `benchmark`
- Version injection via `git describe` and `LDFLAGS` on `main.Version`
- Coverage pipeline: `go test -race -coverprofile` plus HTML cover report
- Standard ignore rules for binaries, vendor, IDE, `.env`, and Air hot-reload `tmp/`
- Phony target families including `lint`, `watch-test`, `watch-build`, and `watch-run`
- Makefile documents build, build-all, clean, test, test-short, and benchmark targets
- Phony groups reference lint, watch-test, watch-build, and watch-run targets
Adoption & trust: 3.7k installs on skills.sh; 2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You start a Go service from a blank folder and waste cycles on Makefile, coverage, and directory conventions before writing business logic.
Who is it for?
Indie builders creating a new Go API or CLI who want Makefile-driven build, test, race, and coverage defaults.
Skip if: Mature monorepos with existing Bazel or custom layout standards, or frontend-only projects with no Go backend.
When should I use this skill?
Starting a new Go backend or CLI and you need standard cmd layout, Makefile build/test/coverage flow, and gitignore defaults.
What do I get? / Deliverables
You get a consistent Go tree with buildable `cmd/server`, test and coverage commands, and ignore rules ready for local dev and CI.
- Makefile with build, test, coverage, and auxiliary dev targets
- Root `.gitignore` tuned for Go binaries, vendor, and secrets
- Suggested `cmd/` binary layout (e.g. `cmd/server`)
Recommended Skills
Journey fit
Project layout and build/test scaffolding happen when you are actively constructing the Go backend, not during marketing or ops phases. Content centers on compiling `cmd/server`, multi-binary `cmd/...`, tests, benchmarks, and hygiene for Go backends.
How it compares
Opinionated starter scaffold—not a full framework like Buffalo or a production observability kit.
Common Questions / FAQ
Who is golang-project-layout for?
Solo and small-team Go developers who want agent help applying standard `cmd/` layout and Makefile rituals on new backend repos.
When should I use golang-project-layout?
At the start of Build backend work when initializing a Go service or CLI—before you wire CI and before you accumulate inconsistent bin, test, and env artifacts.
Is golang-project-layout safe to install?
Use the Security Audits panel on this Prism page; the skill content is mostly templates (Makefile, gitignore) but generated projects may later add shell and network code you write yourself.
SKILL.md
READMESKILL.md - Golang Project Layout
# Binaries for programs and plugins *.exe *.exe~ *.dll *.so *.dylib bin/ dist/ # Test binary, built with `go test -c` *.test # Output of the go coverage tool *.out coverage.out coverage.html # Dependency directories vendor/ # Go workspace file go.work.sum # IDE specific files .idea/ .vscode/ *.swp *.swo *~ .DS_Store # Environment files .env .env.local .env.*.local # Build artifacts /tmp/ # Air hot reload tmp/ # Variables BINARY_NAME=myapp GO=go GOFLAGS=-v # Build variables VERSION?=$(shell git describe --tags --always --dirty) LDFLAGS=-ldflags "-X main.Version=$(VERSION)" .PHONY: all build clean test lint run install help .PHONY: benchmark lint-fix outdated weight audit .PHONY: watch-test watch-build watch-run all: clean lint test build ## build: Build the application build: @echo "Building $(BINARY_NAME)..." $(GO) build $(GOFLAGS) $(LDFLAGS) -o bin/$(BINARY_NAME) ./cmd/server ## build-all: Build all binaries in cmd/ build-all: @echo "Building all binaries..." $(GO) build $(GOFLAGS) $(LDFLAGS) -o bin/ ./cmd/... ## clean: Clean build artifacts clean: @echo "Cleaning..." rm -rf bin/ rm -f coverage.out ## test: Run all tests test: @echo "Running tests..." $(GO) test -v -race -coverprofile=coverage.out ./... $(GO) tool cover -html=coverage.out -o coverage.html ## test-short: Run tests without long-running ones test-short: $(GO) test -v -short ./... ## benchmark: Run benchmarks benchmark: @echo "Running benchmarks..." $(GO) test -bench=. -benchmem ./... ## lint: Run linter lint: @echo "Running linter..." golangci-lint run ./... ## lint-fix: Run linter and auto-fix issues lint-fix: @echo "Running linter with auto-fix..." golangci-lint run --fix ./... ## fmt: Format code fmt: $(GO) fmt ./... $(GO) vet ./... ## outdated: Check for outdated dependencies outdated: @echo "Checking for outdated dependencies..." go list -u -m -json all | go-mod-outdated -update -direct ## weight: Analyze package dependencies weight: @echo "Analyzing package weight..." goweight ## audit: Audit dependencies for security vulnerabilities audit: @echo "Auditing dependencies..." govulncheck ./... ## run: Build and run the application run: build @echo "Running $(BINARY_NAME)..." ./bin/$(BINARY_NAME) ## install: Install dependencies install: $(GO) mod download $(GO) mod tidy ## deps-update: Update dependencies (patch only for safety) deps-update: $(GO) get -u=patch ./... $(GO) mod tidy ## watch-test: Run tests on file changes (requires air) watch-test: @echo "Watching for changes to run tests..." air -test ## watch-build: Rebuild on file changes (requires air) watch-build: @echo "Watching for changes to rebuild..." air -build ## watch-run: Rebuild and run on file changes (requires air) watch-run: @echo "Watching for changes to run..." air ## help: Show this help message help: @echo "Usage: make [target]" @sed -n 's/^##//p' $(MAKEFILE_LIST) | column -t -s ':' | sed -e 's/^/ /' [ { "id": 1, "name": "ask-architecture-before-structuring", "description": "Tests whether the model asks the developer about architecture preference before imposing one", "prompt": "I'm starting a new Go web service project. Set up the directory structure for me.", "trap": "Without the skill, the model immediately generates a directory structure without asking. The skill says to ASK the developer what architecture they prefer before structuring.", "assertions": [ {"id": "1.1", "text": "Asks the developer which software architecture they prefer (clean, hexagonal, DDD, flat, etc.)"}, {"id": "1.2", "text": "Asks about the project scope/size to right-size the structure"}, {"id": "1.3", "text": "Does NOT immediately impose a specific architecture without asking"}, {"id": "1.4", "text": "Mentions dependency injection approach as a follow-up question"}, {"id": "1.5", "text": "Mentions that small projects should not be over-structured"} ] }, { "id": 2, "name