---

name: golang-popular-libraries description: "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)." user-invocable: true license: MIT compatibility: Designed for Claude Code, Codex or similar harness, and for projects using Golang. metadata: author: samber version: "1.2.2" openclaw: emoji: "📚" homepage: https://github.com/samber/cc-skills-golang requires: bins: - go install: [] allowed-tools: Read Edit Write Glob Grep Bash(go:) Bash(golangci-lint:) Bash(git:) Agent WebFetch WebSearch AskUserQuestion mcp__context7__resolve-library-id mcp__context7__query-docs Bash(godig:) Bash(gopls:) LSP mcp__gopls__

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

• Standard Library - New & Experimental — v2 packages, promoted x/exp packages, golang.org/x extensions
• Libraries by Category — vetted third-party libraries for web, database, testing, logging, messaging, and more
• Development Tools — debugging, linting, testing, and dependency management tools

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

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:

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