What problem does it solve? Deciding where Go code should live is a recurring source of inconsistency: main packages scattered at the repo root, business logic mixed into entry points, and over-engineered folder hierarchies for small tools. This Skill provides a disciplined, scope-appropriate layout process for new and existing Go projects. ## Core Features & Use Cases - New project scaffolding: Choose the right structure for CLI tools, libraries, services, monorepos, and workspaces, with correct go.mod naming and thin cmd/ entry points. - Restructuring existing codebases: Relocate main packages under cmd/{name}/, separate internal/ from pkg/, and right-size abstraction layers to actual complexity. - Testing and workspace layout: Co-locate _test.go files, use testdata/ fixtures, and set up go.work for multi-module monorepos. - Use Case: You are starting a new Go microservice and need to decide the module path, directory tree, Makefile, linter config, and test placement before writing the first handler. ## Quick Start Ask the assistant to set up a standard Go project layout for a new CLI tool or restructure an existing repository so all main packages live under cmd/ with business logic in internal/.
