Go project structure -- cmd/internal layout, handler/service/repository layers, Makefile, config from environment, domain error types, test placement, dependency injection
90
84%
Does it follow best practices?
Impact
100%
1.02xAverage score across 5 eval scenarios
Passed
No known issues
{
"instruction": "Use cmd/ for entry points and internal/ for private application packages",
"relevant_when": "Agent builds a Go web service or microservice with multiple packages",
"context": "Go projects must use cmd/<name>/main.go for entry points (no business logic) and internal/ for all private application code. The Go compiler enforces that internal/ packages cannot be imported by other modules, providing encapsulation. Application code should never live at the project root alongside go.mod.",
"sources": [
{
"type": "file",
"filename": "skills/go-project-structure/SKILL.md",
"tile": "tessl-labs/go-project-structure@0.2.0"
}
],
"checklist": [
{
"name": "cmd-entry-point",
"rule": "Entry point main.go is in cmd/<name>/ directory and contains only dependency wiring and server startup, no business logic",
"relevant_when": "Agent creates a Go project with multiple packages"
},
{
"name": "internal-packages",
"rule": "Application code is inside an internal/ directory to prevent external imports",
"relevant_when": "Agent creates a multi-package Go project"
},
{
"name": "no-root-application-code",
"rule": "Business logic files are not placed directly in the project root alongside go.mod",
"relevant_when": "Agent creates a Go project with cmd/ and internal/ layout"
}
]
}