Golang library and framework selection — vetted production-ready options by category (web, database, testing, logging, messaging), new and experimental stdlib packages, standard-library-first tradeoffs, and maturity signals (maintenance, license, importer counts). Apply when the user asks for library suggestions, wants to compare alternatives, needs to choose a library for a specific task, or when a new dependency is being added to the project. Not for a specific library's API once chosen (→ See that library's dedicated skill, e.g. `samber/cc-skills-golang@golang-samber-lo`), nor for go.mod mechanics, upgrades, or vulnerability audits (→ See `samber/cc-skills-golang@golang-dependency-management` skill).
Persona: You are a Go ecosystem expert. You know the library landscape well enough to recommend the simplest production-ready option — and to tell the developer when the standard library is already enough.
Go Libraries and Frameworks Recommendations
Core Philosophy
When recommending libraries, prioritize:
Production-readiness - Mature, well-maintained libraries with active communities
This skill is not exhaustive — refer to library documentation and code examples for more information:
When exploring a candidate library, → See samber/cc-skills-golang@golang-pkg-go-dev skill (godig) for docs, symbols, versions, importers, and known vulnerabilities — prefer it over Context7 for Go package facts.
Once a candidate is added to your build, → See samber/cc-skills-golang@golang-gopls skill (gopls) to browse its actual resolved source and compare candidates side by side.
Context7 remains a fallback for docs not indexed on pkg.go.dev.
General Guidelines
When recommending libraries:
Assess requirements first - Understand the use case, performance needs, and constraints
Check standard library - Always consider if stdlib can solve the problem
Prioritize maturity - MUST check maintenance status, license, and community adoption before recommending. Use a module's imported-by count on pkg.go.dev as a popularity and indirect quality signal — widely-imported libraries are more battle-tested and have stronger backward-compatibility pressure; → See samber/cc-skills-golang@golang-pkg-go-dev skill to count importers and compare alternatives
Consider complexity - Simpler solutions are usually better in Go
Think about dependencies - More dependencies = more attack surface and maintenance burden
Remember: The best library is often no library at all. Go's standard library is excellent and sufficient for many use cases.
Anti-Patterns to Avoid
Over-engineering simple problems with complex libraries
Using libraries that wrap standard library functionality without adding value
Abandoned or unmaintained libraries: ask the developer before recommending these
Suggesting libraries with large dependency footprints for simple needs
Ignoring standard library alternatives
Cross-References
→ See samber/cc-skills-golang@golang-dependency-management skill for adding, auditing, and managing dependencies
→ See samber/cc-skills-golang@golang-pkg-go-dev skill to vet a candidate library on pkg.go.dev — versions, importers, licenses, and known vulnerabilities — before adopting it
→ See samber/cc-skills-golang@golang-samber-do skill for samber/do dependency injection details
→ See samber/cc-skills-golang@golang-samber-hot skill for samber/hot in-memory caching details
→ See samber/cc-skills-golang@golang-samber-oops skill for samber/oops error handling details
→ See samber/cc-skills-golang@golang-stretchr-testify skill for testify testing details
→ See samber/cc-skills-golang@golang-grpc skill for gRPC implementation details
golang-code-stylesamberGolang code style conventions — line length and breaking, variable declarations, control flow clarity, when comments help vs hurt. Use when writing or reviewing Go code, asking about style or clarity, or establishing project coding standards. Not for naming conventions (→ See `samber/cc-skills-golang@golang-naming` skill), linter configuration (→ See `samber/cc-skills-golang@golang-lint` skill), or doc comments (→ See `samber/cc-skills-golang@golang-documentation` skill).40.1 k40.1 k instalaciones en skills.sh0
golang-error-handlingsamberIdiomatic Golang error handling — creation, wrapping with %w, errors.Is/As, errors.Join, custom error types, sentinel errors, panic/recover, the single handling rule, structured logging with slog, HTTP request logging middleware, and samber/oops for production errors. Built to make logs usable at scale with log aggregation 3rd-party tools. Apply when creating, wrapping, inspecting, or logging errors in Go code. For samber/oops specifics → See `samber/cc-skills-golang@golang-samber-oops` skill; for slog handler ecosystem → See `samber/cc-skills-golang@golang-samber-slog` skill.39.4 k39.4 k instalaciones en skills.sh0
golang-testingsamberProduction-ready Golang tests — table-driven tests, testify suites and mocks, parallel tests, fuzzing, fixtures, goroutine leak detection with goleak, snapshot testing, code coverage, integration tests, idiomatic test naming. Use when writing or reviewing Go tests, choosing a testing approach, setting up Go test CI, or debugging flaky/slow tests. For testify-specific APIs see `samber/cc-skills-golang@golang-stretchr-testify`; for measurement methodology see `samber/cc-skills-golang@golang-benchmark`.39.4 k39.4 k instalaciones en skills.sh0
golang-design-patternssamberIdiomatic Golang design patterns — functional options, constructor APIs, `init()` and global-state avoidance, enums, panic vs error decisions, resource management and lifecycle, graceful shutdown, timeouts and retries, streaming and iterators, and architecture styles (clean, hexagonal, DDD, flat). Apply when choosing between architectural patterns, implementing functional options, designing constructor APIs, setting up graceful shutdown, applying resilience patterns, or asking which idiomatic Go pattern fits a specific problem. Not for wiring a DI container or comparing DI libraries (→ See `samber/cc-skills-golang@golang-dependency-injection` skill), nor for error wrapping, `errors.Is`/`As`, or logging mechanics (→ See `samber/cc-skills-golang@golang-error-handling` skill).38.3 k38.3 k instalaciones en skills.sh0
golang-securitysamberSecurity best practices and vulnerability prevention for Golang — injection (SQL, command, XSS), cryptography, path traversal, SSRF and HTTP security headers, cookies, secrets management, memory safety, PII in logs, STRIDE/DREAD threat modeling, plus `gosec` SAST, race detection, and fuzz testing. Apply when writing, reviewing, or auditing Go code for security, or when touching crypto, file or network I/O, secrets, user input, or authentication. Not for non-exploitable defensive bugs such as nil panics or slice aliasing (→ See `samber/cc-skills-golang@golang-safety` skill), dependency vulnerability scanning with govulncheck (→ See `samber/cc-skills-golang@golang-dependency-management` skill), or wiring security scanners into CI pipelines (→ See `samber/cc-skills-golang@golang-continuous-integration` skill).38.3 k38.3 k instalaciones en skills.sh0
