golang-project-layout

Create Go project structures with directory layouts and module naming conventions.

Updated Mar 8, 2026
One-click install
npx skills add https://github.com/tamago0224/kuroshio-mta --skill golang-project-layout-tamago0224
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: golang-project-layout
Source: https://github.com/tamago0224/kuroshio-mta/tree/main/.agents/skills/golang-project-layout
Command: npx skills add https://github.com/tamago0224/kuroshio-mta --skill golang-project-layout-tamago0224

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes assets (resource) and references (resource) components.

What problem does it solve?

Many Go developers struggle to choose the right project layout, module naming, and packaging conventions, leading to confusing structures and maintenance challenges.

Core Features & Use Cases

  • Provides a decision checklist for architecture, dependency injection, and project scope.
  • Defines standard directory layouts for CLI tools, libraries, services, and monorepos.
  • Explains module naming rules, internal versus pkg usage, and when to use go.work workspaces.
  • Offers quick‑start templates for Makefiles and .gitignore files.

Quick Start

Ask the skill to generate a Go project structure for a CLI application named “myapp” using a clean architecture.

Frequently Asked Questions about golang-project-layout

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I structure a Go project for a CLI application or library?

You can structure a Go project by applying standard directory layouts for CLI tools, libraries, and services, ensuring proper module naming and separation of concerns. This approach uses decision checklists to define architecture and project scope efficiently.

What is the difference between internal and pkg directories in Go?

The internal directory restricts package imports to the module itself, enforcing encapsulation, while the pkg directory exposes reusable code to external modules. Choosing between them depends on whether the code needs strict access control or public availability.

When should I use go.work workspaces in a Go project?

Go workspaces, defined via go.work, are used for monorepos or when developing multiple interdependent modules simultaneously. They allow local module resolution across directories without modifying go.mod require directives for local development.

Can I use this Go project layout for monorepos and large-scale applications?

Yes, this layout applies to monorepos and large-scale applications by providing decision checklists for project scope, dependency injection, and standard directory structures. It helps manage complex architectures without executing code.

Do I need golangci-lint to organize my Go directory structure?

No, golangci-lint is optional, but the go toolchain is required. The layout conventions integrate with CI considerations and offer quick-start templates for Makefiles and .gitignore to streamline linting workflows.