Update to Go: Production Engineering

{
  "description": "Use for measured Go CPU, memory, allocation, contention, latency, and benchmarks. Do not use speculatively.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 260
    },
    {
      "relative_path": "evals.json",
      "size_in_bytes": 5916
    },
    {
      "relative_path": "references/diagnostic-tree.md",
      "size_in_bytes": 655
    },
    {
      "relative_path": "references/memory-and-gc.md",
      "size_in_bytes": 2652
    },
    {
      "relative_path": "references/production-profiling.md",
      "size_in_bytes": 3289
    },
    {
      "relative_path": "skill.json",
      "size_in_bytes": 3016
    }
  ],
  "name": "go-performance-and-diagnostics",
  "skill_md_contents": "---\nname: go-performance-and-diagnostics\ndescription: \"Use for measured Go CPU, memory, allocation, contention, latency, and benchmarks. Do not use speculatively.\"\nlicense: Apache-2.0\ncompatibility: \"Go 1.24 or newer; runtime profiles and tool output are version-sensitive.\"\n---\n\n# Go performance and diagnostics\n\nOptimize a measured constraint, not a code pattern.\n\n## Establish the workload\n\nRecord input distribution, offered arrival rate, open- versus closed-loop generation, concurrency, duration, warmup, dependencies, hardware, Go version, `GOMAXPROCS`, achieved throughput, dropped/deadline-expired work, allocations, and error rate. Measure latency from intended arrival when production queueing matters; closed-loop generators can hide stalls through coordinated omission. Reproduce the symptom before changing code.\n\n## Follow the dominant resource\n\n- CPU profile: inspect cumulative and flat cost, then verify inlining and call context.\n- Heap/allocation profile: distinguish live memory from allocation churn and retained ownership.\n- Mutex/block profiles: find contention and waiting, not merely hot functions.\n- Goroutine profile: inspect leaks, fan-out, and blocked resource owners.\n- Trace: diagnose scheduler latency, GC interaction, network blocking, and critical paths.\n- Database/network evidence: local CPU profiles cannot explain remote queueing alone.\n\n## Change one causal mechanism\n\nCommon valid moves include capacity hints for known sizes, avoiding repeated conversions, batching within latency bounds, reducing contention scope, changing algorithms, and removing avoidable reflection or formatting from hot paths. Preserve ownership and correctness; pooling can retain memory or create races.\n\nCompare before and after with repeated benchmarks and confidence-aware tooling. Report effect size, allocations, variance, and costs transferred to memory, tail latency, complexity, or dependencies.\n\nRead [references/diagnostic-tree.md](references/diagnostic-tree.md) for profile selection and benchmark traps. For rising RSS, container OOMs, GC pressure, or `GOMEMLIMIT` changes, read [references/memory-and-gc.md](references/memory-and-gc.md). Before exposing or collecting live diagnostics, read [references/production-profiling.md](references/production-profiling.md) for access, sampling, interference, cohort, and artifact controls.\n\n## Output contract\n\nLead with the measured bottleneck and evidence. Do not claim improvement from code appearance or one noisy benchmark run.\n"
}