Golang Performance
Speed up a slow Go API by profiling first, then tuning allocations, GC, and production alerts instead of guessing optimizations.
Overview
golang-performance is an agent skill most often used in Ship (also Build, Operate) that teaches profile-first Go optimization plus GC, goroutine, and memory alert patterns.
Install
npx skills add https://github.com/samber/cc-skills-golang --skill golang-performanceWhat is this skill?
- Encourages profile-before-optimizing: measure with pprof or metrics before rewriting handlers
- Prometheus-style alerts for high average GC pause (>10ms over 5m), goroutine leaks (>10K), and RSS nearing container lim
- Operational guidance tied to `go_gc_duration_seconds`, `go_goroutines`, and memory limit prediction
- Includes eval scenario for a 800ms Go HTTP list handler to test disciplined diagnosis vs blind micro-optimizations
- Spans coding fixes (allocations, string work) and runtime observability in one performance lens
- Example alert: average GC pause >10ms over 5 minutes
- Example alert: `go_goroutines` > 10,000 for 5 minutes
- Eval case: 800ms average response on a sample Go HTTP list handler
Adoption & trust: 4.3k installs on skills.sh; 2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your Go service is slow or flaky in production and every optimization suggestion feels like a guess without profiles, GC context, or leak signals.
Who is it for?
Solo builders with Go APIs exporting Prometheus metrics who want agent help that refuses to optimize blind.
Skip if: Greenfield tutorials with no latency symptoms, or stacks where Go runtime metrics and profiling are unavailable.
When should I use this skill?
Go APIs are slow, GC pauses spike, goroutine counts climb, or you need Prometheus alerts before changing performance-critical code.
What do I get? / Deliverables
You get a measurement-first plan, targeted code fixes where data supports them, and alert rules that surface GC pauses, goroutine leaks, and memory pressure early.
- Profiling-first optimization checklist for hot handlers
- Adaptable Prometheus alert snippets for GC, goroutines, and memory
- Root-cause hypotheses separating allocations, GC, and I/O
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship / perf because the skill centers on latency, GC pause, and allocation discipline after the service exists and shows measurable slowness. Perf subphase matches profile-before-optimize workflows, GOGC tuning, and handler-level bottlenecks rather than greenfield scaffolding.
Where it fits
Shape a list handler to avoid per-request allocations before it becomes a GC-heavy hot path.
Profile an 800ms endpoint and decide whether DB fetch, JSON encode, or string transforms dominate latency.
Wire GC pause and goroutine alerts so leaks surface before users feel sustained slowdowns.
How it compares
Use for Go runtime performance and SRE-style alerts, not generic JavaScript bundle or Next.js dev-speed skills.
Common Questions / FAQ
Who is golang-performance for?
Indie backend developers shipping Go HTTP services or workers who need profiling discipline and production-ready GC, goroutine, and memory alerts.
When should I use golang-performance?
Use it in Ship when response times or GC pauses regress; in Build when writing allocation-heavy handlers; in Operate when tuning Prometheus alerts on `go_*` metrics and investigating goroutine or memory leaks.
Is golang-performance safe to install?
Review the Security Audits panel on this Prism page before enabling agent changes to prod alert rules, GOGC, or deployment limits.
SKILL.md
READMESKILL.md - Golang Performance
# GC taking too much time per cycle - alert: HighGCPauseTime expr: rate(go_gc_duration_seconds_sum[5m]) / rate(go_gc_duration_seconds_count[5m]) > 0.01 for: 10m annotations: summary: "Average GC pause >10ms — reduce allocations or tune GOGC" # Goroutine leak - alert: GoroutineLeak expr: go_goroutines > 10000 for: 5m annotations: summary: "Goroutine count >10K — check for leaked goroutines" # Memory approaching container limit - alert: MemoryNearLimit expr: predict_linear(process_resident_memory_bytes[1h], 3600) > <container_limit_bytes> for: 15m annotations: summary: "RSS projected to exceed container limit within 1h" [ { "id": 1, "name": "profile-before-optimizing", "description": "Tests whether the model insists on profiling before applying optimizations, rather than jumping straight to code changes", "prompt": "Our Go HTTP API is slow. Average response time is 800ms. Here's the handler:\n\n```go\npackage api\n\nimport (\n \"encoding/json\"\n \"net/http\"\n \"strings\"\n)\n\ntype Response struct {\n Items []Item `json:\"items\"`\n}\n\ntype Item struct {\n ID int `json:\"id\"`\n Name string `json:\"name\"`\n Tags string `json:\"tags\"`\n}\n\nfunc HandleList(w http.ResponseWriter, r *http.Request) {\n items := fetchFromDB(r.Context())\n for i := range items {\n items[i].Tags = strings.ToUpper(items[i].Tags)\n }\n json.NewEncoder(w).Encode(Response{Items: items})\n}\n```\n\nOptimize this code to reduce the 800ms response time.", "trap": "The 800ms latency is almost certainly from fetchFromDB (external bottleneck), not from strings.ToUpper or JSON encoding. Without the skill, the model will micro-optimize the Go code (use strings.Builder, preallocate, etc.) instead of pointing out that profiling is needed first and the bottleneck is likely external.", "assertions": [ {"id": "1.1", "text": "Recommends profiling (pprof, fgprof, or tracing) before making code changes"}, {"id": "1.2", "text": "Identifies fetchFromDB as the likely bottleneck (external I/O, not Go code)"}, {"id": "1.3", "text": "Mentions that intuition about bottlenecks is often wrong (~80% of the time)"}, {"id": "1.4", "text": "Does NOT primarily focus on micro-optimizing strings.ToUpper or JSON encoding"}, {"id": "1.5", "text": "Suggests investigating the database query (query tuning, caching, connection pool)"} ] }, { "id": 2, "name": "fgprof-off-cpu-bottleneck", "description": "Tests whether the model recommends fgprof for off-CPU bottlenecks instead of only standard CPU profiling", "prompt": "Our Go service has high latency (p99 = 2s) but CPU usage is only 5%. Standard pprof CPU profile shows almost nothing — the hot functions consume negligible CPU time. What profiling approach should we use to find the bottleneck?", "trap": "Standard CPU profiling only captures on-CPU time. When CPU usage is low but latency is high, the bottleneck is off-CPU (I/O wait, network, blocked goroutines). The skill specifically recommends fgprof for this. Without the skill, the model may suggest heap profiles, goroutine dumps, or other approaches that miss the key tool.", "assertions": [ {"id": "2.1", "text": "Recommends fgprof as the primary tool for capturing off-CPU wait time"}, {"id": "2.2", "text": "Explains that standard pprof CPU profile only captures on-CPU time, which is why it shows nothing"}, {"id": "2.3", "text": "Suggests the bottleneck is likely I/O wait (network, database, filesystem)"}, {"id": "2.4", "text": "Mentions goroutine profile as a complementary diagnostic (blocked goroutines in net.Read or database/sql)"}, {"id": "2.5", "text": "Suggests distributed tracing (OpenTelemetry) for identifying slow upstream services"} ] }, { "id": 3, "name": "iterative-benchmark-methodology", "description": "Tests whether the model follows the iterative benchmark meth