28 skills published by eduardo-sl across 1 repository. Together they weigh 55 246 tokens — that is what loading all of them at once would cost you in context.
28 skills 55 246 tokens total
> Structured git commit messages following Conventional Commits format for Go projects. Generates well-scoped, atomic commits with clear descriptions. Use when committing changes, writing commit messages, preparing PRs, or reviewing commit history quality. "prepare PR", "squash commits". Do NOT use for changelog generation (use changelog-generator) or code review (use go-code-review).
> REST and gRPC API design patterns for Go services. Covers HTTP handlers, middleware, routing, request/response patterns, versioning, pagination, graceful shutdown, and OpenAPI documentation. Use when designing APIs, writing HTTP handlers, implementing middleware, structuring REST endpoints, or setting up gRPC services. "middleware pattern", "graceful shutdown", "gRPC service", "API versioning". Do NOT use for general architecture (use go-architecture-review) or concurrency in handlers (use go-concurrency-review).
> layering, separation of concerns, domain modeling, and module boundaries. Use when reviewing architecture, designing package layout, evaluating dependency graphs, or refactoring monoliths into modules. "dependency direction", "clean architecture Go", "module boundaries". Do NOT use for code-level style (use go-coding-standards) or API endpoint design (use go-api-design).
> golangci-lint setup, test/coverage gates, vulnerability scanning, build matrices, and Makefile targets. "CI is slow", "coverage gate", "build matrix", "write a Makefile", "run govulncheck in CI". auditing dependencies (use go-dependency-audit), or writing the tests themselves (use go-test-quality).
> discipline, exit codes, signal handling, and when Cobra/Viper earn their weight over the standard library. "handle Ctrl+C", "cobra command", "read from stdin", "CLI UX". in general (use go-project-layout), or configuration of services (use go-architecture-review).
> Comprehensive code review checklist for Go projects. Evaluates code quality, idiomatic patterns, error handling, naming, package structure, and test coverage. Use when reviewing Go code, PRs, or before merging changes. Do NOT use for security-specific audits (use go-security-audit) or performance-specific analysis (use go-performance-review).
> Go coding standards and style conventions grounded in Effective Go, Go Code Review Comments, and production-proven idioms. Use when writing or reviewing Go code, enforcing naming conventions, import ordering, variable declarations, struct initialization, or formatting rules. Do NOT use for architecture decisions, concurrency patterns, or performance tuning — use go-architecture-review, go-concurrency-review, or go-performance-review instead.
> sync primitives, context propagation, and goroutine lifecycle management. Use when writing concurrent code, reviewing async patterns, checking thread safety, debugging race conditions, or designing producer/consumer pipelines. "channel patterns", "sync.Mutex", "context cancellation", "goroutine leak". Do NOT use for general code style (use go-coding-standards) or HTTP handler patterns (use go-api-design).
> deadlines, values, and common anti-patterns. "context.WithTimeout", "context.WithCancel", "context values", "context propagation". HTTP middleware context (use go-api-design), or error handling (use go-error-handling).
> migrations, query builders, and ORM usage (sqlc, GORM, ent). "database migration", "sqlc", "GORM", "ent", "prepared statement", "repository pattern". security aspects of SQL (use go-security-audit), or performance profiling of queries (use go-performance-review).
> semantics, aliasing, preallocation), maps (comma-ok, sets, iteration order), arrays, and choosing between them. "map iteration", "use a set in Go", "slice aliasing", "append gotcha", "copy a slice", "sync.Map or mutex". (use go-concurrency-review), allocation profiling (use go-performance-review), or generic container design (use go-design-patterns).
> vulnerabilities, review go.mod hygiene, identify unused or redundant deps, and evaluate dependency quality. Use when auditing dependencies, checking for CVEs, cleaning up go.mod, upgrading modules, or evaluating third-party packages. "update modules", "vulnerability scan", "govulncheck". Do NOT use for code-level security issues (use go-security-audit) or architecture review (use go-architecture-review).
> global state, and when frameworks (wire, fx, dig) earn their complexity. "remove global state", "singleton in Go", "use google/wire", "uber fx", "make this testable". project directory structure (use go-project-layout), or test doubles and mocks (use go-test-quality).
> middleware chain, pub/sub, and other patterns adapted for Go's type system. "factory pattern", "strategy pattern", "middleware chain", "option pattern", "how to structure this". package layout (use go-architecture-review), or concurrency patterns (use go-concurrency-review).
> Example functions, deprecation notices, and doc links. "add examples to docs", "deprecate a function", "package documentation", "improve the docs". guides (plain writing task), or code style rules (use go-coding-standards).
> Go error handling patterns, wrapping, sentinel errors, custom error types, and the errors package. Grounded in Effective Go, Go Code Review Comments, and production-proven idioms. Use when implementing error handling, designing error types, debugging error chains, or reviewing error handling patterns. "sentinel errors", "errors.Is", "errors.As". Do NOT use for panic/recover patterns in middleware (use go-api-design) or test assertion errors (use go-test-quality).
> details, interceptors, deadlines, streaming, health checks, and graceful shutdown. "interceptor", "gRPC streaming", "gRPC deadline", "grpc health check", "gRPC status codes". API layering (use go-architecture-review), or TLS hardening details (use go-security-audit).
> interface compliance verification, composition, the accept-interfaces-return-structs principle, and common pitfalls. Use when designing interfaces, decoupling packages, defining contracts, reviewing interface usage, or refactoring for testability. "interface compliance", "consumer-side interface", "interface composition". Do NOT use for HTTP handler patterns (use go-api-design) or general code review (use go-code-review).
> Modernize Go code to use current language features and standard library additions. Covers generics, log/slog, errors.Join, slices/maps packages, range-over-func, and iterators introduced in Go 1.21-1.23+. "upgrade Go version", "slog", "errors.Join", "range over func", "iterators". error handling philosophy (use go-error-handling), or logging architecture (use go-observability).
> Structured logging, distributed tracing, metrics, and health checks for Go services. Covers slog, OpenTelemetry, Prometheus, and observability best practices. "add metrics", "Prometheus", "observability", "instrument this code". error handling patterns (use go-error-handling), or health check endpoints (use go-api-design).
> Detect performance anti-patterns and apply optimization techniques in Go. Covers allocations, string handling, slice/map preallocation, sync.Pool, benchmarking, and profiling with pprof. Use when checking performance, finding slow code, reducing allocations, profiling, or reviewing hot paths. "benchmark this", "profile", "optimize Go code". Do NOT use for concurrency correctness (use go-concurrency-review) or general code style (use go-coding-standards).
> conventions, when to use a flat layout, module naming, and main package wiring. "start a Go module", "how do I organize a new service", "set up folder structure". dependency injection wiring details (use go-dependency-injection), or CI pipeline setup (use go-ci).
> renames, extracting packages, breaking circular dependencies, and strangler migrations — always behind green tests. "break this circular dependency", "split this god package", "migrate callers", "clean up without changing behavior". adopting new language features (use go-modernize), or performance rewrites (use go-performance-review).
> authentication/authorization, secrets management, TLS, OWASP Top 10, and secure coding patterns. Use when performing security reviews, checking for vulnerabilities, hardening Go services, or reviewing auth implementations. "SQL injection", "input validation", "secrets management", "auth review". Do NOT use for dependency CVE scanning (use go-dependency-audit) or concurrency safety (use go-concurrency-review).
> Navigate and analyze Go codebases semantically with the toolchain instead of go list for the dependency graph, and go doc for APIs. used", "trace the dependency graph", "explore this codebase", "find usages before changing", "map the module". judging the architecture found (use go-architecture-review), or documentation writing (use go-documentation).
> golden files, httptest, testcontainers, property-based testing, and fuzz testing. Covers mocking strategies, test isolation, coverage analysis, and test design philosophy. Use when writing tests, improving coverage, reviewing test quality, setting up test infrastructure, or choosing a testing approach. "test helpers", "mock this dependency", "integration test", "fuzz test". Do NOT use for performance benchmarking methodology (use go-performance-review), security testing (use go-security-audit), or table-driven test patterns specifically (use go-test-table-driven).
> struct design, subtest naming, advanced patterns like test matrices and shared setup, and refactoring bloated tables into clean ones. Use when writing table-driven tests, refactoring test tables, reviewing table test structure, or deciding whether table-driven is the right approach. "test matrix", "parametrize tests", "data-driven test", "refactor test table". Do NOT use for general test strategy, mocking, golden files, or fuzz testing (use go-test-quality). Do NOT use for benchmarks (use go-performance-review).
> goroutine leaks, memory leaks, OOM kills, race reports, and debugging with delve and pprof. leak", "goroutine count growing", "OOM", "program hangs", "race detector output", "use delve". writing new concurrent code (use go-concurrency-review), or failing test design (use go-test-quality).