golang-popular-libraries
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
- Simplicity - Go's philosophy favors simple, idiomatic solutions
- Performance - Libraries that leverage Go's strengths (concurrency, compiled performance)
- 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. Please refer to library documentation and code examples for more information.
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
- 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-managementskill for adding, auditing, and managing dependencies - → See
samber/cc-skills-golang@golang-samber-doskill for samber/do dependency injection details - → See
samber/cc-skills-golang@golang-samber-oopsskill for samber/oops error handling details - → See
samber/cc-skills-golang@golang-stretchr-testifyskill for testify testing details - → See
samber/cc-skills-golang@golang-grpcskill for gRPC implementation details
More from adibfirman/dotfiles
js-ts-fp
Write TypeScript and JavaScript code like a top engineer using functional programming principles. Use when writing new code, reviewing existing code, or refactoring TS/JS projects. Applies pure functions, immutability, function composition, higher-order functions, declarative style, and avoiding shared state using native patterns only (no external libraries). Always analyzes the existing codebase first to understand patterns and conventions before making changes or suggestions.
17ui-engineer
Act as a UI engineer to iterate on design details and produce production-grade frontend interfaces. Use when the user provides a PRD (Product Requirements Document) or an existing concept app and wants to refine the UI through clarifying questions before implementation. Outputs HTML/CSS with Tailwind, optional vanilla JS. Focuses on minimalist aesthetics, semi-bold typography, responsive design, and avoids generic AI look, excessive icons, or emojis.
14grill-me
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
1golang-lint
Provides linting best practices and golangci-lint configuration for Go projects. Covers running linters, configuring .golangci.yml, suppressing warnings with nolint directives, interpreting lint output, and managing linter settings. Use this skill whenever the user runs linters, configures golangci-lint, asks about lint warnings or suppressions, sets up code quality tooling, or asks which linters to enable for a Go project. Also use when the user mentions golangci-lint, go vet, staticcheck, revive, or any Go linting tool.
1golang-benchmark
Golang benchmarking, profiling, and performance measurement. Use when writing, running, or comparing Go benchmarks, profiling hot paths with pprof, interpreting CPU/memory/trace profiles, analyzing results with benchstat, setting up CI benchmark regression detection, or investigating production performance with Prometheus runtime metrics. Also use when the developer needs deep analysis on a specific performance indicator - this skill provides the measurement methodology, while golang-performance provides the optimization patterns.
1golang-modernize
Continuously modernize Golang code to use the latest language features, standard library improvements, and idiomatic patterns. Use this skill whenever writing, reviewing, or refactoring Go code to ensure it leverages modern Go idioms. Also use when the user asks about Go upgrades, migration, modernization, deprecation, or when modernize linter reports issues. Also covers tooling modernization: linters, SAST, AI-powered code review in CI, and modern development practices. Trigger this skill proactively when you notice old-style Go patterns that have modern replacements.
1