[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71N66XZ8513PC725FRFHD8J":3,"skill-same:01M71N66XZ8513PC725FRFHD8J":135},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":34,"publishedAt":55,"linkOnly":56,"markdownContent":57,"markdownBody":58,"frontMatter":59,"refName":77,"commitSha":78,"skillDirectory":79,"forksCount":14,"repositoryHtmlUrl":80,"repositoryHomepageUrl":81,"ownerHtmlUrl":82,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":83,"install":84,"resources":96},"01M71N66XZ8513PC725FRFHD8J","golang-benchmark",null,"Golang benchmarking, profiling, and performance measurement. Use when writing, running, or comparing Go benchmarks, profiling hot paths with pprof, interpreting CPU\u002Fmemory\u002Ftrace 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 `samber\u002Fcc-skills-golang@golang-performance` provides the optimization patterns.","pattanation\u002FNorvik","pattanation","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F235419268?v=4","01M71M5THHYYB15ME8R2E4FCZG","Patta","01M71M5TJM1NDM992M8PDKYR2K",0,"MIT","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgolang-benchmark\u002FSKILL.md",[18,23,26,31],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":32,"categoryName":33,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000036","内容创作者",[35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54],"golang","golang benchmark","benchmark","deep analysis","websearch","code","analysis","Bash","query","when","writing","MCP","ci","up","performance","regression","memory","projects","deep","ai coding agents","2026-11-10 10:56:23",false,"---\nname: golang-benchmark\ndescription: \"Golang benchmarking, profiling, and performance measurement. Use when writing, running, or comparing Go benchmarks, profiling hot paths with pprof, interpreting CPU\u002Fmemory\u002Ftrace 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 `samber\u002Fcc-skills-golang@golang-performance` provides the optimization patterns.\"\nuser-invocable: true\nlicense: MIT\ncompatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.\nmetadata:\n  author: samber\n  version: \"1.2.5\"\n  openclaw:\n    emoji: \"📊\"\n    homepage: https:\u002F\u002Fgithub.com\u002Fsamber\u002Fcc-skills-golang\n    requires:\n      bins:\n        - go\n        - benchstat\n    install:\n      - kind: go\n        package: golang.org\u002Fx\u002Fperf\u002Fcmd\u002Fbenchstat@latest\n        bins: [benchstat]\nallowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch Bash(benchstat:*) Bash(benchdiff:*) Bash(cob:*) Bash(gobenchdata:*) Bash(curl:*) mcp__context7__resolve-library-id mcp__context7__query-docs WebSearch AskUserQuestion EnterWorktree ExitWorktree\n---\n\n**Persona:** You are a Go performance measurement engineer. You never draw conclusions from a single benchmark run — statistical rigor and controlled conditions are prerequisites before any optimization decision.\n\n**Thinking mode:** Use `ultrathink` for benchmark analysis, profile interpretation, and performance comparison tasks. Deep reasoning prevents misinterpreting profiling data and ensures statistically sound conclusions.\n\n**Dependencies:**\n\n- benchstat: `go install golang.org\u002Fx\u002Fperf\u002Fcmd\u002Fbenchstat@latest`\n\n# Go Benchmarking & Performance Measurement\n\nPerformance improvement does not exist without measures — if you can measure it, you can improve it.\n\nThis skill covers the full measurement workflow: write a benchmark, run it, profile the result, compare before\u002Fafter with statistical rigor, and track regressions in CI. For optimization patterns to apply after measurement, → See `samber\u002Fcc-skills-golang@golang-performance` skill. For pprof setup on running services, → See `samber\u002Fcc-skills-golang@golang-troubleshooting` skill.\n\n## Writing Benchmarks\n\n### `b.Loop()` (Go 1.24+) — preferred\n\nFor Go 1.24+, prefer `b.Loop()` for new benchmarks. It times only the loop body and keeps function arguments\u002Fresults alive, which reduces dead-code-elimination mistakes.\n\n```go\nfunc BenchmarkParse(b *testing.B) {\n    data := loadFixture(\"large.json\") \u002F\u002F setup — excluded from timing\n    for b.Loop() {\n        Parse(data)  \u002F\u002F compiler cannot eliminate this call\n    }\n}\n```\n\nLegacy `b.N` loops still compile and are fine to keep when preserving existing benchmarks or supporting Go \u003C1.24. They are easier to get wrong: setup may need `b.ResetTimer()`, and results may need a sink if the compiler can eliminate the work. Go 1.26 fixed an earlier `b.Loop()` inlining limitation — benchmarks on 1.24–1.25 already benefit from `b.Loop()` but may miss inlining optimizations that 1.26 delivers.\n\n### Memory tracking\n\n```go\nfunc BenchmarkAlloc(b *testing.B) {\n    b.ReportAllocs() \u002F\u002F or run with -benchmem flag\n    var sink []byte\n    for b.Loop() {\n        sink = make([]byte, 1024)\n    }\n    _ = sink\n}\n```\n\n`b.ReportMetric()` adds custom metrics (e.g., throughput):\n\n```go\nb.ReportMetric(float64(totalBytes)\u002Fb.Elapsed().Seconds(), \"bytes\u002Fs\") \u002F\u002F b.Elapsed() is only valid inside b.Loop()\n```\n\n### Sub-benchmarks and table-driven\n\n```go\nfunc BenchmarkEncode(b *testing.B) {\n    for _, size := range []int{64, 256, 4096} {\n        b.Run(fmt.Sprintf(\"size=%d\", size), func(b *testing.B) {\n            data := make([]byte, size)\n            for b.Loop() {\n                Encode(data)\n            }\n        })\n    }\n}\n```\n\n## Running Benchmarks\n\n```bash\ngo test -bench=BenchmarkEncode -benchmem -count=10 .\u002Fpkg\u002F... | tee bench.txt\n```\n\n| Flag                   | Purpose                                   |\n| ---------------------- | ----------------------------------------- |\n| `-bench=.`             | Run all benchmarks (regexp filter)        |\n| `-benchmem`            | Report allocations (B\u002Fop, allocs\u002Fop)      |\n| `-count=10`            | Run 10 times for statistical significance |\n| `-benchtime=3s`        | Minimum time per benchmark (default 1s)   |\n| `-cpu=1,2,4`           | Run with different GOMAXPROCS values      |\n| `-cpuprofile=cpu.prof` | Write CPU profile                         |\n| `-memprofile=mem.prof` | Write memory profile                      |\n| `-trace=trace.out`     | Write execution trace                     |\n\n**Output format:** `BenchmarkEncode\u002Fsize=64-8  5000000  230.5 ns\u002Fop  128 B\u002Fop  2 allocs\u002Fop` — the `-8` suffix is GOMAXPROCS, `ns\u002Fop` is time per operation, `B\u002Fop` is bytes allocated per op, `allocs\u002Fop` is heap allocation count per op.\n\n## Comparing Optimization Variants in Parallel\n\nWhen several competing optimization hypotheses exist for the same bottleneck, implement each variant in its own isolated worktree (`EnterWorktree`) via a separate sub-agent, so their code changes never collide in the shared working tree.\n\n**Run the benchmarks serially, not concurrently.** Concurrent benchmark runs share the same CPU — the noisy-neighbor effect contaminates `ns\u002Fop` and reintroduces the exact statistical noise `-count` and `benchstat` exist to eliminate. Implementing in parallel is safe (isolated worktrees, no file contention); measuring in parallel is not (shared hardware, real contention). Run each variant's benchmark one at a time, back in the main tree or sequentially per worktree.\n\nCompare every variant's `benchstat` output against the **same** baseline report, keep the winner, and `ExitWorktree` (remove) the rest.\n\n## Documenting Results in Commits\n\nPaste benchstat output in the commit body when the change has a measurable performance impact. This documents _why_ an optimization was made, prevents future readers from reverting it, and lets reviewers verify the claim without re-running benchmarks.\n\nCommit format:\n\n```\nperf(parser): reduce Parse allocations 50% with sync.Pool\n\nReplace per-call []byte allocation with a pooled buffer.\n\ngoos: linux \u002F goarch: amd64 \u002F cpu: AMD Ryzen 9 5950X\n          │    old     │              new               │\n          │  sec\u002Fop    │  sec\u002Fop     vs base            │\nParse-32    4.592µ ± 2%  3.041µ ± 1%  -33.78% (p=0.000 n=10)\n\n          │   old    │             new              │\n          │   B\u002Fop   │   B\u002Fop     vs base           │\nParse-32   1.024Ki ± 0%  0.512Ki ± 0%  -50.00% (p=0.000 n=10)\n\n          │ old  │            new             │\n          │ allocs\u002Fop │ allocs\u002Fop  vs base    │\nParse-32   12.00 ± 0%   6.000 ± 0%  -50.00% (p=0.000 n=10)\n```\n\n**Rules:**\n\n- Only include benchmarks directly affected by the change — strip unrelated rows\n- Never paste results with `~` (no statistical significance) — the improvement cannot be claimed\n- Include the hardware context line (`goos\u002Fgoarch\u002Fcpu`) so results are reproducible\n- Use `perf(scope):` commit type for performance-only changes\n\n## Profiling from Benchmarks\n\nGenerate profiles directly from benchmark runs — no HTTP server needed:\n\n```bash\n# CPU profile\ngo test -bench=BenchmarkParse -cpuprofile=cpu.prof .\u002Fpkg\u002Fparser\ngo tool pprof cpu.prof\n\n# Memory profile (alloc_objects shows GC churn, inuse_space shows leaks)\ngo test -bench=BenchmarkParse -memprofile=mem.prof .\u002Fpkg\u002Fparser\ngo tool pprof -alloc_objects mem.prof\n\n# Execution trace\ngo test -bench=BenchmarkParse -trace=trace.out .\u002Fpkg\u002Fparser\ngo tool trace trace.out\n```\n\nFor full pprof CLI reference (all commands, non-interactive mode, profile interpretation), see [pprof Reference](.\u002Freferences\u002Fpprof.md). For execution trace interpretation, see [Trace Reference](.\u002Freferences\u002Ftrace.md). For statistical comparison, see [benchstat Reference](.\u002Freferences\u002Fbenchstat.md).\n\n## Reference Files\n\n- **[pprof Reference](.\u002Freferences\u002Fpprof.md)** — Interactive and non-interactive analysis of CPU, memory, and goroutine profiles. Full CLI commands, profile types (CPU vs alloc*objects vs inuse_space), web UI navigation, and interpretation patterns. Use this to dive deep into \\_where* time and memory are being spent in your code.\n\n- **[benchstat Reference](.\u002Freferences\u002Fbenchstat.md)** — Statistical comparison of benchmark runs with rigorous confidence intervals and p-value tests. Covers output reading, filtering old benchmarks, interleaving results for visual clarity, and regression detection. Use this when you need to prove a change made a meaningful performance difference, not just a lucky run.\n\n- **[Trace Reference](.\u002Freferences\u002Ftrace.md)** — Execution tracer for understanding _when_ and _why_ code runs. Visualizes goroutine scheduling, garbage collection phases, network blocking, and custom span annotations. Use this when pprof (which shows _where_ CPU goes) isn't enough — you need to see the timeline of what happened.\n\n- **[Diagnostic Tools](.\u002Freferences\u002Ftools.md)** — Quick reference for ancillary tools: fieldalignment (struct padding waste), GODEBUG (runtime logging flags), fgprof (frame graph profiles), race detector (concurrency bugs), and others. Use this when you have a specific symptom and need a focused diagnostic — don't reach for pprof if a simpler tool already answers your question.\n\n- **[Compiler Analysis](.\u002Freferences\u002Fcompiler-analysis.md)** — Low-level compiler optimization insights: escape analysis (when values move to the heap), inlining decisions (which function calls are eliminated), SSA dump (intermediate representation), and assembly output. Use this when benchmarks show allocations you didn't expect, or when you want to verify the compiler did what you intended.\n\n- **[CI Regression Detection](.\u002Freferences\u002Fci-regression.md)** — Automated performance regression gating in CI pipelines. Covers three tools (benchdiff for quick PR comparisons, cob for strict threshold-based gating, gobenchdata for long-term trend dashboards), noisy neighbor mitigation strategies (why cloud CI benchmarks vary 5-10% even on quiet machines), and self-hosted runner tuning to make benchmarks reproducible. Use this when you want to ensure pull requests don't silently slow down your codebase — detecting regressions early prevents shipping performance debt.\n\n- **[Investigation Session](.\u002Freferences\u002Finvestigation-session.md)** — Production performance troubleshooting workflow combining Prometheus runtime metrics (heap size, GC frequency, goroutine counts), PromQL queries to correlate metrics with code changes, runtime configuration flags (GODEBUG env vars to enable GC logging), and cost warnings (when you're hitting performance tax). Use this when production benchmarks look good but real traffic behaves differently.\n\n- **[Prometheus Go Metrics Reference](.\u002Freferences\u002Fprometheus-go-metrics.md)** — Complete listing of Go runtime metrics actually exposed as Prometheus metrics by `prometheus\u002Fclient_golang`. Covers 30 default metrics, 40+ optional metrics (Go 1.17+), process metrics, and common PromQL queries. Distinguishes between `runtime\u002Fmetrics` (Go internal data) and Prometheus metrics (what you scrape from `\u002Fmetrics`). Use this when setting up monitoring dashboards or writing PromQL queries for production alerts.\n\n## Cross-References\n\n- → See `samber\u002Fcc-skills-golang@golang-performance` skill for optimization patterns to apply after measuring (\"if X bottleneck, apply Y\")\n- → See `samber\u002Fcc-skills-golang@golang-troubleshooting` skill for pprof setup on running services (enable, secure, capture), Delve debugger, GODEBUG flags, root cause methodology\n- → See `samber\u002Fcc-skills-golang@golang-observability` skill for everyday always-on monitoring, continuous profiling (Pyroscope), distributed tracing (OpenTelemetry)\n- → See `samber\u002Fcc-skills-golang@golang-testing` skill for general testing practices\n- → See `samber\u002Fcc-skills@promql-cli` skill for querying Prometheus runtime metrics in production to validate benchmark findings\n","**Persona:** You are a Go performance measurement engineer. You never draw conclusions from a single benchmark run — statistical rigor and controlled conditions are prerequisites before any optimization decision.\n\n**Thinking mode:** Use `ultrathink` for benchmark analysis, profile interpretation, and performance comparison tasks. Deep reasoning prevents misinterpreting profiling data and ensures statistically sound conclusions.\n\n**Dependencies:**\n\n- benchstat: `go install golang.org\u002Fx\u002Fperf\u002Fcmd\u002Fbenchstat@latest`\n\n# Go Benchmarking & Performance Measurement\n\nPerformance improvement does not exist without measures — if you can measure it, you can improve it.\n\nThis skill covers the full measurement workflow: write a benchmark, run it, profile the result, compare before\u002Fafter with statistical rigor, and track regressions in CI. For optimization patterns to apply after measurement, → See `samber\u002Fcc-skills-golang@golang-performance` skill. For pprof setup on running services, → See `samber\u002Fcc-skills-golang@golang-troubleshooting` skill.\n\n## Writing Benchmarks\n\n### `b.Loop()` (Go 1.24+) — preferred\n\nFor Go 1.24+, prefer `b.Loop()` for new benchmarks. It times only the loop body and keeps function arguments\u002Fresults alive, which reduces dead-code-elimination mistakes.\n\n```go\nfunc BenchmarkParse(b *testing.B) {\n    data := loadFixture(\"large.json\") \u002F\u002F setup — excluded from timing\n    for b.Loop() {\n        Parse(data)  \u002F\u002F compiler cannot eliminate this call\n    }\n}\n```\n\nLegacy `b.N` loops still compile and are fine to keep when preserving existing benchmarks or supporting Go \u003C1.24. They are easier to get wrong: setup may need `b.ResetTimer()`, and results may need a sink if the compiler can eliminate the work. Go 1.26 fixed an earlier `b.Loop()` inlining limitation — benchmarks on 1.24–1.25 already benefit from `b.Loop()` but may miss inlining optimizations that 1.26 delivers.\n\n### Memory tracking\n\n```go\nfunc BenchmarkAlloc(b *testing.B) {\n    b.ReportAllocs() \u002F\u002F or run with -benchmem flag\n    var sink []byte\n    for b.Loop() {\n        sink = make([]byte, 1024)\n    }\n    _ = sink\n}\n```\n\n`b.ReportMetric()` adds custom metrics (e.g., throughput):\n\n```go\nb.ReportMetric(float64(totalBytes)\u002Fb.Elapsed().Seconds(), \"bytes\u002Fs\") \u002F\u002F b.Elapsed() is only valid inside b.Loop()\n```\n\n### Sub-benchmarks and table-driven\n\n```go\nfunc BenchmarkEncode(b *testing.B) {\n    for _, size := range []int{64, 256, 4096} {\n        b.Run(fmt.Sprintf(\"size=%d\", size), func(b *testing.B) {\n            data := make([]byte, size)\n            for b.Loop() {\n                Encode(data)\n            }\n        })\n    }\n}\n```\n\n## Running Benchmarks\n\n```bash\ngo test -bench=BenchmarkEncode -benchmem -count=10 .\u002Fpkg\u002F... | tee bench.txt\n```\n\n| Flag                   | Purpose                                   |\n| ---------------------- | ----------------------------------------- |\n| `-bench=.`             | Run all benchmarks (regexp filter)        |\n| `-benchmem`            | Report allocations (B\u002Fop, allocs\u002Fop)      |\n| `-count=10`            | Run 10 times for statistical significance |\n| `-benchtime=3s`        | Minimum time per benchmark (default 1s)   |\n| `-cpu=1,2,4`           | Run with different GOMAXPROCS values      |\n| `-cpuprofile=cpu.prof` | Write CPU profile                         |\n| `-memprofile=mem.prof` | Write memory profile                      |\n| `-trace=trace.out`     | Write execution trace                     |\n\n**Output format:** `BenchmarkEncode\u002Fsize=64-8  5000000  230.5 ns\u002Fop  128 B\u002Fop  2 allocs\u002Fop` — the `-8` suffix is GOMAXPROCS, `ns\u002Fop` is time per operation, `B\u002Fop` is bytes allocated per op, `allocs\u002Fop` is heap allocation count per op.\n\n## Comparing Optimization Variants in Parallel\n\nWhen several competing optimization hypotheses exist for the same bottleneck, implement each variant in its own isolated worktree (`EnterWorktree`) via a separate sub-agent, so their code changes never collide in the shared working tree.\n\n**Run the benchmarks serially, not concurrently.** Concurrent benchmark runs share the same CPU — the noisy-neighbor effect contaminates `ns\u002Fop` and reintroduces the exact statistical noise `-count` and `benchstat` exist to eliminate. Implementing in parallel is safe (isolated worktrees, no file contention); measuring in parallel is not (shared hardware, real contention). Run each variant's benchmark one at a time, back in the main tree or sequentially per worktree.\n\nCompare every variant's `benchstat` output against the **same** baseline report, keep the winner, and `ExitWorktree` (remove) the rest.\n\n## Documenting Results in Commits\n\nPaste benchstat output in the commit body when the change has a measurable performance impact. This documents _why_ an optimization was made, prevents future readers from reverting it, and lets reviewers verify the claim without re-running benchmarks.\n\nCommit format:\n\n```\nperf(parser): reduce Parse allocations 50% with sync.Pool\n\nReplace per-call []byte allocation with a pooled buffer.\n\ngoos: linux \u002F goarch: amd64 \u002F cpu: AMD Ryzen 9 5950X\n          │    old     │              new               │\n          │  sec\u002Fop    │  sec\u002Fop     vs base            │\nParse-32    4.592µ ± 2%  3.041µ ± 1%  -33.78% (p=0.000 n=10)\n\n          │   old    │             new              │\n          │   B\u002Fop   │   B\u002Fop     vs base           │\nParse-32   1.024Ki ± 0%  0.512Ki ± 0%  -50.00% (p=0.000 n=10)\n\n          │ old  │            new             │\n          │ allocs\u002Fop │ allocs\u002Fop  vs base    │\nParse-32   12.00 ± 0%   6.000 ± 0%  -50.00% (p=0.000 n=10)\n```\n\n**Rules:**\n\n- Only include benchmarks directly affected by the change — strip unrelated rows\n- Never paste results with `~` (no statistical significance) — the improvement cannot be claimed\n- Include the hardware context line (`goos\u002Fgoarch\u002Fcpu`) so results are reproducible\n- Use `perf(scope):` commit type for performance-only changes\n\n## Profiling from Benchmarks\n\nGenerate profiles directly from benchmark runs — no HTTP server needed:\n\n```bash\n# CPU profile\ngo test -bench=BenchmarkParse -cpuprofile=cpu.prof .\u002Fpkg\u002Fparser\ngo tool pprof cpu.prof\n\n# Memory profile (alloc_objects shows GC churn, inuse_space shows leaks)\ngo test -bench=BenchmarkParse -memprofile=mem.prof .\u002Fpkg\u002Fparser\ngo tool pprof -alloc_objects mem.prof\n\n# Execution trace\ngo test -bench=BenchmarkParse -trace=trace.out .\u002Fpkg\u002Fparser\ngo tool trace trace.out\n```\n\nFor full pprof CLI reference (all commands, non-interactive mode, profile interpretation), see [pprof Reference](.\u002Freferences\u002Fpprof.md). For execution trace interpretation, see [Trace Reference](.\u002Freferences\u002Ftrace.md). For statistical comparison, see [benchstat Reference](.\u002Freferences\u002Fbenchstat.md).\n\n## Reference Files\n\n- **[pprof Reference](.\u002Freferences\u002Fpprof.md)** — Interactive and non-interactive analysis of CPU, memory, and goroutine profiles. Full CLI commands, profile types (CPU vs alloc*objects vs inuse_space), web UI navigation, and interpretation patterns. Use this to dive deep into \\_where* time and memory are being spent in your code.\n\n- **[benchstat Reference](.\u002Freferences\u002Fbenchstat.md)** — Statistical comparison of benchmark runs with rigorous confidence intervals and p-value tests. Covers output reading, filtering old benchmarks, interleaving results for visual clarity, and regression detection. Use this when you need to prove a change made a meaningful performance difference, not just a lucky run.\n\n- **[Trace Reference](.\u002Freferences\u002Ftrace.md)** — Execution tracer for understanding _when_ and _why_ code runs. Visualizes goroutine scheduling, garbage collection phases, network blocking, and custom span annotations. Use this when pprof (which shows _where_ CPU goes) isn't enough — you need to see the timeline of what happened.\n\n- **[Diagnostic Tools](.\u002Freferences\u002Ftools.md)** — Quick reference for ancillary tools: fieldalignment (struct padding waste), GODEBUG (runtime logging flags), fgprof (frame graph profiles), race detector (concurrency bugs), and others. Use this when you have a specific symptom and need a focused diagnostic — don't reach for pprof if a simpler tool already answers your question.\n\n- **[Compiler Analysis](.\u002Freferences\u002Fcompiler-analysis.md)** — Low-level compiler optimization insights: escape analysis (when values move to the heap), inlining decisions (which function calls are eliminated), SSA dump (intermediate representation), and assembly output. Use this when benchmarks show allocations you didn't expect, or when you want to verify the compiler did what you intended.\n\n- **[CI Regression Detection](.\u002Freferences\u002Fci-regression.md)** — Automated performance regression gating in CI pipelines. Covers three tools (benchdiff for quick PR comparisons, cob for strict threshold-based gating, gobenchdata for long-term trend dashboards), noisy neighbor mitigation strategies (why cloud CI benchmarks vary 5-10% even on quiet machines), and self-hosted runner tuning to make benchmarks reproducible. Use this when you want to ensure pull requests don't silently slow down your codebase — detecting regressions early prevents shipping performance debt.\n\n- **[Investigation Session](.\u002Freferences\u002Finvestigation-session.md)** — Production performance troubleshooting workflow combining Prometheus runtime metrics (heap size, GC frequency, goroutine counts), PromQL queries to correlate metrics with code changes, runtime configuration flags (GODEBUG env vars to enable GC logging), and cost warnings (when you're hitting performance tax). Use this when production benchmarks look good but real traffic behaves differently.\n\n- **[Prometheus Go Metrics Reference](.\u002Freferences\u002Fprometheus-go-metrics.md)** — Complete listing of Go runtime metrics actually exposed as Prometheus metrics by `prometheus\u002Fclient_golang`. Covers 30 default metrics, 40+ optional metrics (Go 1.17+), process metrics, and common PromQL queries. Distinguishes between `runtime\u002Fmetrics` (Go internal data) and Prometheus metrics (what you scrape from `\u002Fmetrics`). Use this when setting up monitoring dashboards or writing PromQL queries for production alerts.\n\n## Cross-References\n\n- → See `samber\u002Fcc-skills-golang@golang-performance` skill for optimization patterns to apply after measuring (\"if X bottleneck, apply Y\")\n- → See `samber\u002Fcc-skills-golang@golang-troubleshooting` skill for pprof setup on running services (enable, secure, capture), Delve debugger, GODEBUG flags, root cause methodology\n- → See `samber\u002Fcc-skills-golang@golang-observability` skill for everyday always-on monitoring, continuous profiling (Pyroscope), distributed tracing (OpenTelemetry)\n- → See `samber\u002Fcc-skills-golang@golang-testing` skill for general testing practices\n- → See `samber\u002Fcc-skills@promql-cli` skill for querying Prometheus runtime metrics in production to validate benchmark findings\n",{"name":5,"license":15,"metadata":60,"description":7,"allowed-tools":74,"compatibility":75,"user-invocable":76},{"author":61,"version":62,"openclaw":63},"samber","1.2.5",{"emoji":64,"install":65,"homepage":71,"requires":72},"📊",[66],{"bins":67,"kind":69,"package":70},[68],"benchstat","go","golang.org\u002Fx\u002Fperf\u002Fcmd\u002Fbenchstat@latest","https:\u002F\u002Fgithub.com\u002Fsamber\u002Fcc-skills-golang",{"bins":73},[69,68],"Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch Bash(benchstat:*) Bash(benchdiff:*) Bash(cob:*) Bash(gobenchdata:*) Bash(curl:*) mcp__context7__resolve-library-id mcp__context7__query-docs WebSearch AskUserQuestion EnterWorktree ExitWorktree","Designed for Claude Code or similar AI coding agents, and for projects using Golang.",true,"claude\u002Finstall-gsd-build-foQdV","d86cd127f527124b5fd0fd0bc679a4d79b7d01d7",".agents\u002Fskills\u002Fgolang-benchmark","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik","https:\u002F\u002Fnorvik-orpin.vercel.app","https:\u002F\u002Fgithub.com\u002Fpattanation","2026-07-17 11:17:04",{"source":8,"skillName":5,"commands":85,"prompt":95,"zipAvailable":76},[86,89,92],{"tool":87,"command":88},"npx","npx skills add pattanation\u002FNorvik --skill golang-benchmark",{"tool":90,"command":91},"bunx","bunx skills add pattanation\u002FNorvik --skill golang-benchmark",{"tool":93,"command":94},"pnpm","pnpm dlx skills add pattanation\u002FNorvik --skill golang-benchmark","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgolang-benchmark\u002FSKILL.md",[97,103,107,111,115,119,123,127,131],{"path":98,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":101,"sourceHtmlUrl":102},"evals\u002Fevals.json","REFERENCE","参考文档",85040,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgolang-benchmark\u002Fevals\u002Fevals.json",{"path":104,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":105,"sourceHtmlUrl":106},"references\u002Fbenchstat.md",14540,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgolang-benchmark\u002Freferences\u002Fbenchstat.md",{"path":108,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":109,"sourceHtmlUrl":110},"references\u002Fci-regression.md",10659,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgolang-benchmark\u002Freferences\u002Fci-regression.md",{"path":112,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":113,"sourceHtmlUrl":114},"references\u002Fcompiler-analysis.md",10972,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgolang-benchmark\u002Freferences\u002Fcompiler-analysis.md",{"path":116,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":117,"sourceHtmlUrl":118},"references\u002Finvestigation-session.md",7265,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgolang-benchmark\u002Freferences\u002Finvestigation-session.md",{"path":120,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":121,"sourceHtmlUrl":122},"references\u002Fpprof.md",33951,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgolang-benchmark\u002Freferences\u002Fpprof.md",{"path":124,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":125,"sourceHtmlUrl":126},"references\u002Fprometheus-go-metrics.md",11623,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgolang-benchmark\u002Freferences\u002Fprometheus-go-metrics.md",{"path":128,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":129,"sourceHtmlUrl":130},"references\u002Ftools.md",4031,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgolang-benchmark\u002Freferences\u002Ftools.md",{"path":132,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":133,"sourceHtmlUrl":134},"references\u002Ftrace.md",18472,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgolang-benchmark\u002Freferences\u002Ftrace.md",[136,169,195,218,240,255],{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":140,"licenseFileUrl":141,"sourceHtmlUrl":142,"categories":143,"keywords":150,"publishedAt":168},"01M71QDV4DM8T19HEHWATEF1K4","webapp-testing","Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fwebapp-testing\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fwebapp-testing\u002FSKILL.md",[144,147],{"categoryNo":145,"categoryName":146,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":148,"categoryName":149,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167],"webapp","testing","webapp testing","for","applications","local","frontend","debugging","toolkit","logs","browser","with","playwright","web","behavior","ui","screenshots","2026-11-10 13:02:02",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":140,"licenseFileUrl":173,"sourceHtmlUrl":174,"categories":175,"keywords":177,"publishedAt":168},"01M71QDH2GGMXGA9105C9W1N7B","web-artifacts-builder","Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn\u002Fui). Use for complex artifacts requiring state management, routing, or shadcn\u002Fui components - not for simple single-file HTML\u002FJSX artifacts.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fweb-artifacts-builder\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fweb-artifacts-builder\u002FSKILL.md",[176],{"categoryNo":148,"categoryName":149,"taxonomyType":21,"taxonomyTypeDesc":22},[178,179,180,164,181,182,183,154,184,185,157,186,187,188,189,190,191,192,193,194],"builder","artifacts builder","artifacts","web artifacts builder","single-file","css","Tailwind","ui components","single","use","file","components","react","multi","state","routing","state management",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":199,"sourceHtmlUrl":200,"categories":201,"keywords":203,"publishedAt":168},"01M71QD9T2XC3EWMQNN9ACNWQ1","vueuse-functions","Apply VueUse composables where appropriate to build concise, maintainable Vue.js \u002F Nuxt features.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvueuse-functions\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvueuse-functions\u002FSKILL.md",[202],{"categoryNo":148,"categoryName":149,"taxonomyType":21,"taxonomyTypeDesc":22},[204,205,206,207,208,209,210,211,212,213,214,215,216,217],"functions","vueuse","vueuse functions","project","nuxt","apply","github","concise","build","https","features","vue","js","composables",{"skillNo":219,"name":220,"nameZh":6,"description":221,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":222,"sourceHtmlUrl":223,"categories":224,"keywords":227,"publishedAt":168},"01M71QD51HWSGYMCMB7RW7PGK8","vue-testing-best-practices","Use for Vue.js testing. Covers Vitest, Vue Test Utils, component testing, mocking, testing patterns, and Playwright for E2E testing.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-testing-best-practices\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-testing-best-practices\u002FSKILL.md",[225,226],{"categoryNo":145,"categoryName":146,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":148,"categoryName":149,"taxonomyType":21,"taxonomyTypeDesc":22},[228,152,229,215,230,163,231,232,233,210,234,154,235,236,237,187,238,216,239],"vue testing best practices","testing best practices","best practices","test","testing patterns","component","vitest","mocking","e2e","utils","patterns","e2e testing",{"skillNo":241,"name":242,"nameZh":6,"description":243,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":244,"sourceHtmlUrl":245,"categories":246,"keywords":248,"publishedAt":168},"01M71QD358H2DJ9THJRBP77T3T","vue-router-best-practices","Vue Router 4 patterns, navigation guards, route params, and route-component lifecycle interactions.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-router-best-practices\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-router-best-practices\u002FSKILL.md",[247],{"categoryNo":148,"categoryName":149,"taxonomyType":21,"taxonomyTypeDesc":22},[249,215,250,230,251,233,252,210,238,253,254],"router","vue router best practices","route","guards","navigation","lifecycle",{"skillNo":256,"name":257,"nameZh":6,"description":258,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":259,"sourceHtmlUrl":260,"categories":261,"keywords":263,"publishedAt":168},"01M71QCYPNWDE2MQZ1TF3ED5S4","vue-best-practices","MUST be used for Vue.js tasks. Strongly recommends Composition API with `\u003Cscript setup>` and TypeScript as the standard approach. Covers Vue 3, SSR, Volar, vue-tsc. Load for any Vue, .vue files, Vue Router, Pinia, or Vite with Vue work. ALWAYS use Composition API unless the project explicitly requires Options API.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-best-practices\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-best-practices\u002FSKILL.md",[262],{"categoryNo":148,"categoryName":149,"taxonomyType":21,"taxonomyTypeDesc":22},[264,215,230,265,207,266,267,268,249,269,270,271,272,273,274,154,275,187,276,277],"vue best practices","Composition","files","tasks","api","pinia","work","options","ssr","typescript","as","vite","load","standard"]