go-package-hygiene
Maintains Go repository quality through strict package dependency, file size, and architecture standards.
Install
mkdir -p .claude/skills/go-package-hygiene && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/14708" && unzip -o skill.zip -d .claude/skills/go-package-hygiene && rm skill.zipInstalls to .claude/skills/go-package-hygiene
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Use when adding a new `.go` file to any `internal/` package, when an existing file grows past ~400 lines, when introducing a helper function, or when considering a new package. Enforces itervox's package dependency order, file-size discipline, reuse of stdlib builtins, and the no-premature-utils-package rule.Key capabilities
- →Enforce package dependency order for Go internal packages
- →Ensure file size discipline by splitting large Go files
- →Prevent creation of generic `utils/` or `helpers/` packages
- →Promote reuse of Go standard library built-in functions
- →Enforce consistent error conventions
- →Mandate `log/slog` for structured logging
How it works
The skill applies a set of architectural and coding rules to Go code, covering package structure, file size, standard library usage, error handling, and logging.
Inputs & outputs
When to use go-package-hygiene
- →Enforcing Go architecture rules
- →Splitting overgrown Go files
- →Validating import dependencies
About this skill
Go Package Hygiene (itervox)
Apply these rules whenever you touch Go code under internal/ or cmd/.
1. Respect the package dependency order
domain → tracker, prompt, logbuffer, prdetector
workflow → config → workspace
agent (imports domain, config)
orchestrator (imports agent, config, domain, logbuffer, prdetector, prompt, tracker, workspace)
app (imports domain, tracker)
server (imports domain, config)
cmd/itervox (wires everything)
Never introduce a cycle. Before adding an import, trace it: does it reverse the arrow? If domain starts importing tracker, stop. Move the type, not the import.
2. No utils/ or helpers/ package — ever
Shared code lives in the most specific package that owns the concept. Function used only inside orchestrator/? It belongs there. Type shared by orchestrator/ and app/? It belongs in domain/. A utils package is where architecture goes to die.
3. File size discipline (~400 lines)
When a file grows past ~400 lines, split by responsibility, not alphabet. The canonical example is internal/orchestrator/: event_loop.go, worker.go, snapshot.go, dispatch.go, reconcile.go, retry.go, reviewer.go, issue_control.go, ssh_host.go, logging.go, state.go. Each file name names a concern.
4. Reuse stdlib builtins — do not reinvent
maps.Copy(dst, src)— not afor k, v := rangeloopmax(a, b)/min(a, b)— not if/else clampingslices.Contains,slices.Index,slices.Sort— not handwritten loopscmp.Or(a, b, c)— not nested fallback ifsstrings.Cut— notstrings.Index+ manual slicing
5. Grep before writing a new helper
Before adding func somethingX(...), search the current package for an existing helper. Then the parent package. Extend or reuse — do not create a second helper with a similar name. Common targets: internal/agent/helpers*.go, the bottom of internal/config/config.go, internal/orchestrator/*.go.
6. Error conventions
fmt.Errorf("package: lowercase message: %w", err)— always wrap with%werrors.New("package: static message")for static stringserrors.Is/errors.Asfor checking wrapped errors — never string matching
7. Logging via log/slog
Structured key/value, not log.Printf. Canonical:
slog.Info("orchestrator: dispatched", "identifier", issue.Identifier, "profile", profileName)
Message is a short sentence; details are key/value pairs.
8. Tests in the same package (whitebox)
Unexported helpers are tested via helpers_test.go in the same package. Use package foo_test only when deliberately testing the public surface from outside.
9. Exported symbols need doc comments
golangci-lint enforces this. Describe behavior, not type:
- Good:
// RunTurn executes one claude turn as a subprocess and streams progress to onProgress. - Useless:
// RunTurn is a method.
10. New package creation requires justification
Adding internal/<name>/ requires that the concept (a) fits in no existing package and (b) has multiple consumers. Single-use code stays in its consumer.
Verification
go vet ./...
golangci-lint run ./...
go test -race ./...
make verify
Common mistakes
- Duplicating a helper across two files in the same package instead of grepping first
- Creating
internal/util/orinternal/helpers/as a "temporary" dumping ground - Letting
domainimporttrackerand creating a cycle - Handwritten
for k, v := range src { dst[k] = v }instead ofmaps.Copy log.Printf("dispatched %s", id)instead ofslog.Info("orchestrator: dispatched", "identifier", id)- Splitting a 600-line file into
a.go/b.goinstead of by responsibility - Adding a new
internal/<name>/package for a single-call-site helper
When not to use it
- →When working outside `internal/` or `cmd/` directories
- →When the goal is to create a new `utils/` or `helpers/` package
- →When intentionally introducing a package cycle
Limitations
- →Applies only to Go code under `internal/` or `cmd/`
- →Does not cover external package dependencies
- →Does not apply to Go code outside of itervox's specific project structure
How it compares
This skill enforces specific Go architectural patterns and coding conventions, preventing common pitfalls like circular dependencies and generic utility packages, unlike a general Go linter.
Compared to similar skills
go-package-hygiene side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| go-package-hygiene (this skill) | 0 | 4mo | Review | Intermediate |
| go-dev-guidelines | 14 | 9mo | No flags | Intermediate |
| effective-go | 323 | 9mo | No flags | Beginner |
| architecture-patterns | 55 | 2mo | No flags | Advanced |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
go-dev-guidelines
jumppad-labs
This skill should be used when writing, refactoring, or testing Go code. It provides idiomatic Go development patterns, TDD-based workflows, project structure conventions, and testing best practices using testify/require and mockery. Activate this skill when creating new Go features, services, packages, tests, or when setting up new Go projects.
effective-go
openshift
Apply Go best practices, idioms, and conventions from golang.org/doc/effective_go. Use when writing, reviewing, or refactoring Go code to ensure idiomatic, clean, and efficient implementations.
architecture-patterns
wshobson
Implement proven backend architecture patterns including Clean Architecture, Hexagonal Architecture, and Domain-Driven Design. Use when architecting complex backend systems or refactoring existing applications for better maintainability.
workflow-orchestration-patterns
wshobson
Design durable workflows with Temporal for distributed systems. Covers workflow vs activity separation, saga patterns, state management, and determinism constraints. Use when building long-running processes, distributed transactions, or microservice orchestration.
opentelemetry-instrumentation-extension
docker
Extend OpenTelemetry instrumentation when new functionality is added to the MCP Gateway. Use when (1) new operations/functions are added, (2) reviewing code for missing instrumentation, (3) user requests otel/telemetry additions, or (4) working with state-changing operations. Analyzes git diff, suggests instrumentation points following project standards in docs/telemetry/README.md, implements with approval, writes tests, updates documentation, and verifies with debug logging and docker logs.
golang
MadAppGang
Use when building Go backend services, implementing goroutines/channels, handling errors idiomatically, writing tests with testify, or following Go best practices for APIs/CLI tools.