GO

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.zip

Installs 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.
310 chars✓ has a “when” triggerlonger than Claude Code's old 250-char listing cap (fine on current versions)
Intermediate

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

You give it
Go code under `internal/` or `cmd/`
You get back
Go code adhering to itervox's package hygiene rules

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 a for k, v := range loop
  • max(a, b) / min(a, b) — not if/else clamping
  • slices.Contains, slices.Index, slices.Sort — not handwritten loops
  • cmp.Or(a, b, c) — not nested fallback ifs
  • strings.Cut — not strings.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 %w
  • errors.New("package: static message") for static strings
  • errors.Is / errors.As for 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/ or internal/helpers/ as a "temporary" dumping ground
  • Letting domain import tracker and creating a cycle
  • Handwritten for k, v := range src { dst[k] = v } instead of maps.Copy
  • log.Printf("dispatched %s", id) instead of slog.Info("orchestrator: dispatched", "identifier", id)
  • Splitting a 600-line file into a.go / b.go instead 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.

SkillInstallsUpdatedSafetyDifficulty
go-package-hygiene (this skill)04moReviewIntermediate
go-dev-guidelines149moNo flagsIntermediate
effective-go3239moNo flagsBeginner
architecture-patterns552moNo flagsAdvanced

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.

1495

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.

323536

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.

55214

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.

10117

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.

326

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.

313

Search skills

Search the agent skills registry