golang-popular-libraries

by samber

Recommends production-ready Golang libraries and frameworks. Apply when the user explicitly 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.

npx skills add https://github.com/samber/cc-skills-golang --skill golang-popular-libraries
Download ZIPGitHub

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:

  1. Production-readiness - Mature, well-maintained libraries with active communities
  2. Simplicity - Go's philosophy favors simple, idiomatic solutions
  3. Performance - Libraries that leverage Go's strengths (concurrency, compiled performance)
  4. Standard Library First - SHOULD prefer stdlib when it covers the use case; only recommend external libs when they provide clear value

Reference Catalogs

Find more libraries here: https://github.com/avelino/awesome-go

This skill is not exhaustive. Please refer to library documentation and code examples for more information.

General Guidelines

When recommending libraries:

  1. Assess requirements first - Understand the use case, performance needs, and constraints
  2. Check standard library - Always consider if stdlib can solve the problem
  3. Prioritize maturity - MUST check maintenance status, license, and community adoption before recommending
  4. Consider complexity - Simpler solutions are usually better in Go
  5. 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-samber-do skill for samber/do dependency injection 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

More skills from samber

golang-code-style
samber
Golang 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).
developmentcode-review
golang-testing
samber
Production-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...
developmenttestingcode-review
golang-design-patterns
samber
Idiomatic Golang design patterns — functional options, constructors, error flow and cascading, resource management and lifecycle, graceful shutdown, resilience, architecture, dependency injection, data handling, streaming, and more. Apply when explicitly 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.
developmentdesigncode-review
golang-error-handling
samber
Idiomatic 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`...
developmentcode-review
golang-performance
samber
Golang performance optimization patterns and methodology - if X bottleneck, then apply Y. Covers allocation reduction, CPU efficiency, memory layout, GC tuning, pooling, caching, and hot-path optimization. Use when profiling or benchmarks have identified a bottleneck and you need the right optimization pattern to fix it. Also use when performing performance code review to suggest improvements or benchmarks that could help identify quick performance gains. Not for measurement methodology (→...
developmentcode-review
golang-security
samber
Security best practices and vulnerability prevention for Golang. Covers injection (SQL, command, XSS), cryptography, filesystem safety, network security, cookies, secrets management, memory safety, and logging. Apply when writing, reviewing, or auditing Go code for security, or when working on any risky code involving crypto, I/O, secrets management, user input handling, or authentication. Includes configuration of security tools.
securitycode-reviewdevelopment
golang-database
samber
Comprehensive guide for Go database access — parameterized queries, struct scanning, NULLable columns, transactions, isolation levels, SELECT FOR UPDATE, connection pool, batch processing, context propagation, and migration tooling. Use when writing, reviewing, or debugging Golang code that interacts with PostgreSQL, MariaDB, MySQL, or SQLite; for database testing; or for questions about database/sql, sqlx, or pgx. Does NOT generate database schemas or migration SQL.
developmentdatabase
golang-lint
samber
Linting best practices and golangci-lint configuration for Golang projects — running linters, configuring .golangci.yml, suppressing warnings with nolint directives, interpreting lint output, and selecting linters. Use when configuring golangci-lint, asking about lint warnings or nolint suppressions, setting up code quality tooling, or choosing linters. Also use when the user mentions golangci-lint, go vet, staticcheck, or revive.
developmentcode-reviewtesting