project-layout

Codify Go file and directory naming conventions for project layout.

2|Updated Feb 6, 2026
One-click install
npx skills add https://github.com/air-gapped/cooked --skill project-layout
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: project-layout
Source: https://github.com/air-gapped/cooked/tree/main/.claude/skills/project-layout
Command: npx skills add https://github.com/air-gapped/cooked --skill project-layout

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill codifies file and directory naming conventions for this project to ensure consistency and reduce onboarding time for new contributors.

Core Features & Use Cases

  • Standardizes Go project layout: internal/, embed/, testdata/, and cmd/ components.
  • Enforces file naming conventions such as feature.go, feature_variant.go, feature_type.go, and feature_handlers.go to keep code organized.
  • Use Case: When adding a new feature, follow the documented patterns to place logic, tests, and assets predictably.

Quick Start

Review the naming rules in SKILL.md and apply them when creating new files or packages. Create files named feature.go, feature_variant.go, or feature_type.go under internal/ as appropriate; store assets in embed/ and tests in testdata/ with corresponding _test.go files.

Frequently Asked Questions about project-layout

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

FAQPage Schema
How do I structure a Go project to keep internal packages and assets organized?

Standardize your Go project layout by separating code into internal/, embed/, testdata/, and cmd/ directories. This ensures consistent placement of logic, tests, and assets, reducing onboarding time for new contributors.

What naming conventions should I use for Go files when adding a new feature?

Use feature.go, feature_variant.go, feature_type.go, and feature_handlers.go naming patterns for Go files. This keeps code organized and predictable when placing logic and tests under the internal/ directory.

Where should I store test data and embed assets in a Go application?

Store assets in the embed/ directory and test fixtures in testdata/ with corresponding _test.go files. This codifies file and directory naming conventions to ensure project consistency.

Does this Go project structure enforce rules for the internal package?

Yes, it guides proper internal/ organization for Go packages, ensuring consistent layout for code, tests, and assets. It follows documented patterns to place logic predictably when adding new features.

Why do I need defined file and directory naming conventions for my Go project?

Defined naming conventions reduce onboarding time for new contributors by ensuring a consistent project file structure. Standardizing components like internal/ and cmd/ keeps code organized and predictable.