[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7CX0PBYQF4Q5WXFPMFCRHQ1":3,"skill-same:01M7CX0PBYQF4Q5WXFPMFCRHQ1":68},{"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":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":41,"commitSha":42,"skillDirectory":43,"forksCount":44,"repositoryHtmlUrl":45,"repositoryHomepageUrl":6,"ownerHtmlUrl":46,"ownerBlogUrl":6,"ownerDescription":47,"updatedAt":48,"install":49,"resources":61},"01M7CX0PBYQF4Q5WXFPMFCRHQ1","golang-troubleshooting",null,"Troubleshoot Golang programs systematically - find and fix the root cause. Use when encountering bugs, crashes, deadlocks, or unexpected behavior in Go code. Covers debugging methodology, common Go pitfalls, test-driven debugging, pprof setup and capture, Delve debugger, race detection, GODEBUG tracing, and production debugging. Start here for any 'something is wrong' situation. Not for interpreting profiles or benchmarking (→ See `samber\u002Fcc-skills-golang@golang-benchmark` skill) or applying optimization patterns (→ See `samber\u002Fcc-skills-golang@golang-performance` skill).","om-scogo\u002Fskillsh-scraper","om-scogo","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160466840?v=4","01M79AWB6DFVCQ7RK70CS34B96","Om Achrekar","01M79AWB6ZM9SKR8KDH1WSSM22",0,"MIT","https:\u002F\u002Fgithub.com\u002Fom-scogo\u002Fskillsh-scraper\u002Fblob\u002Fmain\u002Fdata\u002Fskills\u002Fsamber-cc-skills-golang\u002Fgolang-troubleshooting\u002FSkill.md",[],[],"2026-11-15 14:19:17",false,"---\nname: golang-troubleshooting\ndescription: \"Troubleshoot Golang programs systematically - find and fix the root cause. Use when encountering bugs, crashes, deadlocks, or unexpected behavior in Go code. Covers debugging methodology, common Go pitfalls, test-driven debugging, pprof setup and capture, Delve debugger, race detection, GODEBUG tracing, and production debugging. Start here for any 'something is wrong' situation. Not for interpreting profiles or benchmarking (→ See `samber\u002Fcc-skills-golang@golang-benchmark` skill) or applying optimization patterns (→ See `samber\u002Fcc-skills-golang@golang-performance` skill).\"\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.3\"\n  openclaw:\n    emoji: \"🔍\"\n    homepage: https:\u002F\u002Fgithub.com\u002Fsamber\u002Fcc-skills-golang\n    requires:\n      bins:\n        - go\n        - dlv\n    install:\n      - kind: go\n        package: github.com\u002Fgo-delve\u002Fdelve\u002Fcmd\u002Fdlv@latest\n        bins: [dlv]\nallowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Bash(dlv:*) Agent WebFetch WebSearch AskUserQuestion\n---\n\n**Persona:** You are a Go systems debugger. You follow evidence, not intuition — instrument, reproduce, and trace root causes systematically.\n\n**Thinking mode:** Use `ultrathink` for debugging and root cause analysis. Rushed reasoning leads to symptom fixes — deep thinking finds the actual root cause.\n\n**Orchestration mode:** Use `ultracode` for a codebase-wide bug hunt — orchestrate the five bug-category sub-agents described in Codebase bug hunt mode. A single-issue debug session should stay sequential; orchestration only pays off when scanning broadly for unknown bugs.\n\n**Modes:**\n\n- **Single-issue debug** (default): Follow the sequential Golden Rules — read the error, reproduce, one hypothesis at a time. Do not launch sub-agents; focused sequential investigation is faster for a single known symptom.\n- **Codebase bug hunt** (explicit audit of a large codebase): Launch up to 5 parallel sub-agents, one per bug category (nil\u002Finterface, resources, error handling, races, context\u002Fslice\u002Fmap). Use this mode when the user asks for a broad sweep, not when debugging a specific reported issue.\n\n**Dependencies:**\n\n- dlv: `go install github.com\u002Fgo-delve\u002Fdelve\u002Fcmd\u002Fdlv@latest`\n\n# Go Troubleshooting Guide\n\n**NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST.** Symptom fixes create new bugs and waste time. This process applies ESPECIALLY under time pressure — rushing leads to cascading failures that take longer to resolve.\n\nWhen the user reports a bug, crash, performance problem, or unexpected behavior in Go code:\n\n1. **Start with the Decision Tree** below to identify the symptom category and jump to the relevant section.\n2. **Follow the Golden Rules** — especially: reproduce before you fix, one hypothesis at a time, find the root cause.\n3. **Work through the General Debugging Methodology** step by step. Do not skip steps.\n4. **Watch for Red Flags** in your own reasoning. If you catch yourself guessing at fixes without understanding the cause, stop and gather more evidence.\n5. **Escalate tools incrementally.** Start with the simplest diagnostic (`fmt.Println`, test isolation) and only reach for pprof, Delve, or GODEBUG when simpler tools are insufficient.\n6. **Never propose a fix you cannot explain.** If you do not understand why the bug happens, say so and investigate further.\n\n## Quick Decision Tree\n\n```\nWHAT ARE YOU SEEING?\n\n\"Build won't compile\"\n  → go build .\u002F... 2>&1, go vet .\u002F...\n  → See [compilation.md](.\u002Freferences\u002Fcompilation.md)\n\n\"Wrong output \u002F logic bug\"\n  → Write a failing test → Check error handling, nil, off-by-one\n  → See [common-go-bugs.md](.\u002Freferences\u002Fcommon-go-bugs.md), [testing-debug.md](.\u002Freferences\u002Ftesting-debug.md)\n\n\"Random crashes \u002F panics\"\n  → GOTRACEBACK=all .\u002Fapp → go test -race .\u002F...\n  → See [common-go-bugs.md](.\u002Freferences\u002Fcommon-go-bugs.md), [diagnostic-tools.md](.\u002Freferences\u002Fdiagnostic-tools.md)\n\n\"Sometimes works, sometimes fails\"\n  → go test -race .\u002F...\n  → See [concurrency-debug.md](.\u002Freferences\u002Fconcurrency-debug.md), [testing-debug.md](.\u002Freferences\u002Ftesting-debug.md)\n\n\"Program hangs \u002F frozen\"\n  → curl localhost:6060\u002Fdebug\u002Fpprof\u002Fgoroutine?debug=2\n  → See [concurrency-debug.md](.\u002Freferences\u002Fconcurrency-debug.md), [pprof.md](.\u002Freferences\u002Fpprof.md)\n\n\"High CPU usage\"\n  → pprof CPU profiling\n  → See [performance-debug.md](.\u002Freferences\u002Fperformance-debug.md), [pprof.md](.\u002Freferences\u002Fpprof.md)\n\n\"Memory growing over time\"\n  → pprof heap profiling\n  → See [performance-debug.md](.\u002Freferences\u002Fperformance-debug.md), [concurrency-debug.md](.\u002Freferences\u002Fconcurrency-debug.md)\n\n\"Slow \u002F high latency \u002F p99 spikes\"\n  → CPU + mutex + block profiles\n  → See [performance-debug.md](.\u002Freferences\u002Fperformance-debug.md), [diagnostic-tools.md](.\u002Freferences\u002Fdiagnostic-tools.md)\n\n\"Simple bug, easy to reproduce\"\n  → Write a test, add fmt.Println \u002F log.Debug\n  → See [testing-debug.md](.\u002Freferences\u002Ftesting-debug.md)\n```\n\n**Remember:** Read the Error → Reproduce → Measure One Thing → Fix → Verify\n\nMost Go bugs are: missing error checks, nil pointers, forgotten context cancel, unclosed resources, race conditions, or silent error swallowing.\n\n## The Golden Rules\n\n### 1. Read the Error Message First\n\nGo error messages are precise. Read them fully before doing anything else:\n\n- **File and line number** → go directly there\n- **Type mismatch** → check function signatures, interface satisfaction\n- **\"undefined\"** → check imports, exported names, build tags\n- **\"cannot use X as Y\"** → check concrete types vs interfaces\n\n### 2. Reproduce Before You Fix\n\nNEVER debug by guessing — reproduce first. Always:\n\n- Write a failing test that captures the bug\n- Make it deterministic\n- Isolate the minimal failing example\n- Use `git bisect` to find the breaking commit\n\n### 3. If You Don't Measure It, You're Guessing\n\nNever rely on intuition for performance or concurrency bugs:\n\n- **pprof over intuition**\n- **race detector over reasoning**\n- **benchmarks over assumptions**\n\n### 4. One Hypothesis at a Time\n\nChange one thing, measure, confirm. If you change three things at once, you learn nothing.\n\n### 5. Find the Root Cause — No Workarounds\n\nA band-aid fix that masks the symptom IS NOT ACCEPTABLE. You MUST understand **why** the bug happens before writing a fix.\n\nWhen you don't understand the issue:\n\n- **Trace the data flow backwards** from the symptom to its origin.\n- **Question your assumptions.** The code you trust might be wrong.\n- **Ask \"why\" five times.** Keep going until you reach the actual root cause.\n- **Perform more troubleshooting checks.** More fmt.Println, more output inspection...\n\n### 6. Research the Codebase, Not Just the Diff\n\nBefore flagging a bug or proposing a fix, trace the data flow and check for upstream handling. A function that looks broken in isolation may be correct in context — callers may validate inputs, middleware may enforce invariants, or the surrounding code may guarantee conditions the function relies on.\n\n1. **Trace callers** — who calls this function and with what values? Call sites can be found with code search tools. → See `samber\u002Fcc-skills-golang@golang-gopls` skill to resolve the actual symbol through interfaces and embedding — it finds indirect call sites and skips unrelated same-named identifiers that plain grep would respectively miss or falsely match.\n2. **Check upstream validation** — input parsing, type conversions, or guard clauses earlier in the chain may make the \"bug\" unreachable.\n3. **Read the surrounding code** — middleware, interceptors, or init functions may set up state the function depends on.\n\n**When the context reduces severity but doesn't eliminate the issue:** still report it at reduced priority with a note explaining which upstream guarantees protect it. Add a brief inline comment (e.g., `\u002F\u002F note: safe because caller validates via parseID() which returns uint`) so the reasoning is documented for future reviewers.\n\n### 7. Start Simple\n\nSometimes `fmt.Println` IS the right tool for local debugging. Escalate tools only when simpler approaches fail. NEVER use `fmt.Println` for production debugging — use `slog`.\n\n## Red Flags: You're Debugging Wrong\n\nIf any of these are happening, stop and return to Step 1:\n\n- **\"Quick fix for now, investigate later\"** — There is no \"later\". Find the root cause.\n- **Multiple simultaneous changes** — One hypothesis at a time.\n- **Proposing fixes without understanding the cause** — \"Maybe if I add a nil check here...\" is guessing, not debugging.\n- **Each fix reveals a new problem** — You're treating symptoms. The real bug is elsewhere.\n- **3+ fix attempts on the same issue** — You have the wrong mental model. Re-read the code, trace the data flow from scratch.\n- **\"It works on my machine\"** — You haven't isolated the environmental difference.\n- **Blaming the framework\u002Fstdlib\u002Fcompiler** — It's almost never a Go bug. Verify your code first.\n\n## Reference Files\n\n- **[General Debugging Methodology](.\u002Freferences\u002Fmethodology.md)** — The systematic 10-step process: define symptoms, isolate reproduction, form one hypothesis, test it, verify the root cause, and defend against regressions. Escalation guide: when to escalate from `fmt.Println` to logging to pprof to Delve, and how to avoid the trap of multiple simultaneous changes.\n\n- **[Common Go Bugs](.\u002Freferences\u002Fcommon-go-bugs.md)** — The bugs that crash Go code: nil pointer dereferences, interface nil gotcha (typed nil ≠ nil), variable shadowing, slice\u002Fmap\u002Fdefer\u002Ferror\u002Fcontext pitfalls, race conditions, JSON unmarshaling surprises, unclosed resources. Each with reproduction patterns and fixes.\n\n- **[Test-Driven Debugging](.\u002Freferences\u002Ftesting-debug.md)** — Why writing a failing test is the first step of debugging. Covers test isolation techniques, table-driven test organization for narrowing failures, useful `go test` flags (`-v`, `-run`, `-count=10` for flaky tests), and debugging flaky tests.\n\n- **[Concurrency Debugging](.\u002Freferences\u002Fconcurrency-debug.md)** — Race conditions, deadlocks, goroutine leaks. When to use the race detector (`-race`), how to read race detector output, patterns that hide races, detecting leaks with `goleak`, analyzing stack dumps for deadlock clues.\n\n- **[Performance Troubleshooting](.\u002Freferences\u002Fperformance-debug.md)** — When your code is slow: CPU profiling workflow, memory analysis (heap vs alloc_objects profiles, finding leaks), lock contention (mutex profile), and I\u002FO blocking (goroutine profile). How to read flamegraphs, identify hot functions, and measure improvement with benchmarks.\n\n- **[pprof Reference](.\u002Freferences\u002Fpprof.md)** — Complete pprof manual. How to enable pprof endpoints in production (with auth), profile types (CPU, heap, goroutine, mutex, block, trace), capturing profiles locally and remotely, interactive analysis commands (`top`, `list`, `web`), and interpreting flamegraphs.\n\n- **[Diagnostic Tools](.\u002Freferences\u002Fdiagnostic-tools.md)** — Auxiliary tools for specific symptoms. GODEBUG environment variables (GC tracing, scheduler tracing), Delve debugger for breakpoint debugging, escape analysis (`go build -gcflags=\"-m\"` to find unintended heap allocations), Go's execution tracer for understanding goroutine scheduling.\n\n- **[Production Debugging](.\u002Freferences\u002Fproduction-debug.md)** — Debugging live production systems without stopping them. Production checklist, structuring logs for searchability, enabling pprof safely (auth, network isolation), capturing profiles from running services, network debugging (tcpdump, netstat), and HTTP request\u002Fresponse inspection.\n\n- **[Compilation Issues](.\u002Freferences\u002Fcompilation.md)** — Build failures: module version conflicts, CGO linking problems, version mismatch between `go.mod` and installed Go version, platform-specific build tags preventing cross-compilation.\n\n- **[Code Review Red Flags](.\u002Freferences\u002Fcode-review-flags.md)** — Patterns to watch during code review that signal potential bugs: unchecked errors, missing nil checks, concurrent map access, goroutines without clear exit, resource leaks from defer in loops.\n\n## Cross-References\n\n- → See `samber\u002Fcc-skills-golang@golang-performance` skill for optimization patterns after identifying bottlenecks\n- → See `samber\u002Fcc-skills-golang@golang-observability` skill for metrics, alerting, and Grafana dashboards for Go runtime monitoring\n- → See `samber\u002Fcc-skills@promql-cli` skill for querying Prometheus metrics during production incident investigation\n- → See `samber\u002Fcc-skills-golang@golang-concurrency`, `samber\u002Fcc-skills-golang@golang-safety`, `samber\u002Fcc-skills-golang@golang-error-handling` skills\n","**Persona:** You are a Go systems debugger. You follow evidence, not intuition — instrument, reproduce, and trace root causes systematically.\n\n**Thinking mode:** Use `ultrathink` for debugging and root cause analysis. Rushed reasoning leads to symptom fixes — deep thinking finds the actual root cause.\n\n**Orchestration mode:** Use `ultracode` for a codebase-wide bug hunt — orchestrate the five bug-category sub-agents described in Codebase bug hunt mode. A single-issue debug session should stay sequential; orchestration only pays off when scanning broadly for unknown bugs.\n\n**Modes:**\n\n- **Single-issue debug** (default): Follow the sequential Golden Rules — read the error, reproduce, one hypothesis at a time. Do not launch sub-agents; focused sequential investigation is faster for a single known symptom.\n- **Codebase bug hunt** (explicit audit of a large codebase): Launch up to 5 parallel sub-agents, one per bug category (nil\u002Finterface, resources, error handling, races, context\u002Fslice\u002Fmap). Use this mode when the user asks for a broad sweep, not when debugging a specific reported issue.\n\n**Dependencies:**\n\n- dlv: `go install github.com\u002Fgo-delve\u002Fdelve\u002Fcmd\u002Fdlv@latest`\n\n# Go Troubleshooting Guide\n\n**NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST.** Symptom fixes create new bugs and waste time. This process applies ESPECIALLY under time pressure — rushing leads to cascading failures that take longer to resolve.\n\nWhen the user reports a bug, crash, performance problem, or unexpected behavior in Go code:\n\n1. **Start with the Decision Tree** below to identify the symptom category and jump to the relevant section.\n2. **Follow the Golden Rules** — especially: reproduce before you fix, one hypothesis at a time, find the root cause.\n3. **Work through the General Debugging Methodology** step by step. Do not skip steps.\n4. **Watch for Red Flags** in your own reasoning. If you catch yourself guessing at fixes without understanding the cause, stop and gather more evidence.\n5. **Escalate tools incrementally.** Start with the simplest diagnostic (`fmt.Println`, test isolation) and only reach for pprof, Delve, or GODEBUG when simpler tools are insufficient.\n6. **Never propose a fix you cannot explain.** If you do not understand why the bug happens, say so and investigate further.\n\n## Quick Decision Tree\n\n```\nWHAT ARE YOU SEEING?\n\n\"Build won't compile\"\n  → go build .\u002F... 2>&1, go vet .\u002F...\n  → See [compilation.md](.\u002Freferences\u002Fcompilation.md)\n\n\"Wrong output \u002F logic bug\"\n  → Write a failing test → Check error handling, nil, off-by-one\n  → See [common-go-bugs.md](.\u002Freferences\u002Fcommon-go-bugs.md), [testing-debug.md](.\u002Freferences\u002Ftesting-debug.md)\n\n\"Random crashes \u002F panics\"\n  → GOTRACEBACK=all .\u002Fapp → go test -race .\u002F...\n  → See [common-go-bugs.md](.\u002Freferences\u002Fcommon-go-bugs.md), [diagnostic-tools.md](.\u002Freferences\u002Fdiagnostic-tools.md)\n\n\"Sometimes works, sometimes fails\"\n  → go test -race .\u002F...\n  → See [concurrency-debug.md](.\u002Freferences\u002Fconcurrency-debug.md), [testing-debug.md](.\u002Freferences\u002Ftesting-debug.md)\n\n\"Program hangs \u002F frozen\"\n  → curl localhost:6060\u002Fdebug\u002Fpprof\u002Fgoroutine?debug=2\n  → See [concurrency-debug.md](.\u002Freferences\u002Fconcurrency-debug.md), [pprof.md](.\u002Freferences\u002Fpprof.md)\n\n\"High CPU usage\"\n  → pprof CPU profiling\n  → See [performance-debug.md](.\u002Freferences\u002Fperformance-debug.md), [pprof.md](.\u002Freferences\u002Fpprof.md)\n\n\"Memory growing over time\"\n  → pprof heap profiling\n  → See [performance-debug.md](.\u002Freferences\u002Fperformance-debug.md), [concurrency-debug.md](.\u002Freferences\u002Fconcurrency-debug.md)\n\n\"Slow \u002F high latency \u002F p99 spikes\"\n  → CPU + mutex + block profiles\n  → See [performance-debug.md](.\u002Freferences\u002Fperformance-debug.md), [diagnostic-tools.md](.\u002Freferences\u002Fdiagnostic-tools.md)\n\n\"Simple bug, easy to reproduce\"\n  → Write a test, add fmt.Println \u002F log.Debug\n  → See [testing-debug.md](.\u002Freferences\u002Ftesting-debug.md)\n```\n\n**Remember:** Read the Error → Reproduce → Measure One Thing → Fix → Verify\n\nMost Go bugs are: missing error checks, nil pointers, forgotten context cancel, unclosed resources, race conditions, or silent error swallowing.\n\n## The Golden Rules\n\n### 1. Read the Error Message First\n\nGo error messages are precise. Read them fully before doing anything else:\n\n- **File and line number** → go directly there\n- **Type mismatch** → check function signatures, interface satisfaction\n- **\"undefined\"** → check imports, exported names, build tags\n- **\"cannot use X as Y\"** → check concrete types vs interfaces\n\n### 2. Reproduce Before You Fix\n\nNEVER debug by guessing — reproduce first. Always:\n\n- Write a failing test that captures the bug\n- Make it deterministic\n- Isolate the minimal failing example\n- Use `git bisect` to find the breaking commit\n\n### 3. If You Don't Measure It, You're Guessing\n\nNever rely on intuition for performance or concurrency bugs:\n\n- **pprof over intuition**\n- **race detector over reasoning**\n- **benchmarks over assumptions**\n\n### 4. One Hypothesis at a Time\n\nChange one thing, measure, confirm. If you change three things at once, you learn nothing.\n\n### 5. Find the Root Cause — No Workarounds\n\nA band-aid fix that masks the symptom IS NOT ACCEPTABLE. You MUST understand **why** the bug happens before writing a fix.\n\nWhen you don't understand the issue:\n\n- **Trace the data flow backwards** from the symptom to its origin.\n- **Question your assumptions.** The code you trust might be wrong.\n- **Ask \"why\" five times.** Keep going until you reach the actual root cause.\n- **Perform more troubleshooting checks.** More fmt.Println, more output inspection...\n\n### 6. Research the Codebase, Not Just the Diff\n\nBefore flagging a bug or proposing a fix, trace the data flow and check for upstream handling. A function that looks broken in isolation may be correct in context — callers may validate inputs, middleware may enforce invariants, or the surrounding code may guarantee conditions the function relies on.\n\n1. **Trace callers** — who calls this function and with what values? Call sites can be found with code search tools. → See `samber\u002Fcc-skills-golang@golang-gopls` skill to resolve the actual symbol through interfaces and embedding — it finds indirect call sites and skips unrelated same-named identifiers that plain grep would respectively miss or falsely match.\n2. **Check upstream validation** — input parsing, type conversions, or guard clauses earlier in the chain may make the \"bug\" unreachable.\n3. **Read the surrounding code** — middleware, interceptors, or init functions may set up state the function depends on.\n\n**When the context reduces severity but doesn't eliminate the issue:** still report it at reduced priority with a note explaining which upstream guarantees protect it. Add a brief inline comment (e.g., `\u002F\u002F note: safe because caller validates via parseID() which returns uint`) so the reasoning is documented for future reviewers.\n\n### 7. Start Simple\n\nSometimes `fmt.Println` IS the right tool for local debugging. Escalate tools only when simpler approaches fail. NEVER use `fmt.Println` for production debugging — use `slog`.\n\n## Red Flags: You're Debugging Wrong\n\nIf any of these are happening, stop and return to Step 1:\n\n- **\"Quick fix for now, investigate later\"** — There is no \"later\". Find the root cause.\n- **Multiple simultaneous changes** — One hypothesis at a time.\n- **Proposing fixes without understanding the cause** — \"Maybe if I add a nil check here...\" is guessing, not debugging.\n- **Each fix reveals a new problem** — You're treating symptoms. The real bug is elsewhere.\n- **3+ fix attempts on the same issue** — You have the wrong mental model. Re-read the code, trace the data flow from scratch.\n- **\"It works on my machine\"** — You haven't isolated the environmental difference.\n- **Blaming the framework\u002Fstdlib\u002Fcompiler** — It's almost never a Go bug. Verify your code first.\n\n## Reference Files\n\n- **[General Debugging Methodology](.\u002Freferences\u002Fmethodology.md)** — The systematic 10-step process: define symptoms, isolate reproduction, form one hypothesis, test it, verify the root cause, and defend against regressions. Escalation guide: when to escalate from `fmt.Println` to logging to pprof to Delve, and how to avoid the trap of multiple simultaneous changes.\n\n- **[Common Go Bugs](.\u002Freferences\u002Fcommon-go-bugs.md)** — The bugs that crash Go code: nil pointer dereferences, interface nil gotcha (typed nil ≠ nil), variable shadowing, slice\u002Fmap\u002Fdefer\u002Ferror\u002Fcontext pitfalls, race conditions, JSON unmarshaling surprises, unclosed resources. Each with reproduction patterns and fixes.\n\n- **[Test-Driven Debugging](.\u002Freferences\u002Ftesting-debug.md)** — Why writing a failing test is the first step of debugging. Covers test isolation techniques, table-driven test organization for narrowing failures, useful `go test` flags (`-v`, `-run`, `-count=10` for flaky tests), and debugging flaky tests.\n\n- **[Concurrency Debugging](.\u002Freferences\u002Fconcurrency-debug.md)** — Race conditions, deadlocks, goroutine leaks. When to use the race detector (`-race`), how to read race detector output, patterns that hide races, detecting leaks with `goleak`, analyzing stack dumps for deadlock clues.\n\n- **[Performance Troubleshooting](.\u002Freferences\u002Fperformance-debug.md)** — When your code is slow: CPU profiling workflow, memory analysis (heap vs alloc_objects profiles, finding leaks), lock contention (mutex profile), and I\u002FO blocking (goroutine profile). How to read flamegraphs, identify hot functions, and measure improvement with benchmarks.\n\n- **[pprof Reference](.\u002Freferences\u002Fpprof.md)** — Complete pprof manual. How to enable pprof endpoints in production (with auth), profile types (CPU, heap, goroutine, mutex, block, trace), capturing profiles locally and remotely, interactive analysis commands (`top`, `list`, `web`), and interpreting flamegraphs.\n\n- **[Diagnostic Tools](.\u002Freferences\u002Fdiagnostic-tools.md)** — Auxiliary tools for specific symptoms. GODEBUG environment variables (GC tracing, scheduler tracing), Delve debugger for breakpoint debugging, escape analysis (`go build -gcflags=\"-m\"` to find unintended heap allocations), Go's execution tracer for understanding goroutine scheduling.\n\n- **[Production Debugging](.\u002Freferences\u002Fproduction-debug.md)** — Debugging live production systems without stopping them. Production checklist, structuring logs for searchability, enabling pprof safely (auth, network isolation), capturing profiles from running services, network debugging (tcpdump, netstat), and HTTP request\u002Fresponse inspection.\n\n- **[Compilation Issues](.\u002Freferences\u002Fcompilation.md)** — Build failures: module version conflicts, CGO linking problems, version mismatch between `go.mod` and installed Go version, platform-specific build tags preventing cross-compilation.\n\n- **[Code Review Red Flags](.\u002Freferences\u002Fcode-review-flags.md)** — Patterns to watch during code review that signal potential bugs: unchecked errors, missing nil checks, concurrent map access, goroutines without clear exit, resource leaks from defer in loops.\n\n## Cross-References\n\n- → See `samber\u002Fcc-skills-golang@golang-performance` skill for optimization patterns after identifying bottlenecks\n- → See `samber\u002Fcc-skills-golang@golang-observability` skill for metrics, alerting, and Grafana dashboards for Go runtime monitoring\n- → See `samber\u002Fcc-skills@promql-cli` skill for querying Prometheus metrics during production incident investigation\n- → See `samber\u002Fcc-skills-golang@golang-concurrency`, `samber\u002Fcc-skills-golang@golang-safety`, `samber\u002Fcc-skills-golang@golang-error-handling` skills\n",{"name":5,"license":15,"metadata":24,"description":7,"allowed-tools":38,"compatibility":39,"user-invocable":40},{"author":25,"version":26,"openclaw":27},"samber","1.2.3",{"emoji":28,"install":29,"homepage":35,"requires":36},"🔍",[30],{"bins":31,"kind":33,"package":34},[32],"dlv","go","github.com\u002Fgo-delve\u002Fdelve\u002Fcmd\u002Fdlv@latest","https:\u002F\u002Fgithub.com\u002Fsamber\u002Fcc-skills-golang",{"bins":37},[33,32],"Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Bash(dlv:*) Agent WebFetch WebSearch AskUserQuestion","Designed for Claude Code or similar AI coding agents, and for projects using Golang.",true,"main","8859218955d9504cd18b59e7892100718039d3b4","data\u002Fskills\u002Fsamber-cc-skills-golang\u002Fgolang-troubleshooting",1,"https:\u002F\u002Fgithub.com\u002Fom-scogo\u002Fskillsh-scraper","https:\u002F\u002Fgithub.com\u002Fom-scogo","SDE-1 @ Scogo ","2026-07-18 12:22:46",{"source":8,"skillName":5,"commands":50,"prompt":60,"zipAvailable":40},[51,54,57],{"tool":52,"command":53},"npx","npx skills add om-scogo\u002Fskillsh-scraper --skill golang-troubleshooting",{"tool":55,"command":56},"bunx","bunx skills add om-scogo\u002Fskillsh-scraper --skill golang-troubleshooting",{"tool":58,"command":59},"pnpm","pnpm dlx skills add om-scogo\u002Fskillsh-scraper --skill golang-troubleshooting","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fom-scogo\u002Fskillsh-scraper\u002Fblob\u002Fmain\u002Fdata\u002Fskills\u002Fsamber-cc-skills-golang\u002Fgolang-troubleshooting\u002FSkill.md",[62],{"path":63,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":66,"sourceHtmlUrl":67},"metadata.json","REFERENCE","参考文档",489,"https:\u002F\u002Fgithub.com\u002Fom-scogo\u002Fskillsh-scraper\u002Fblob\u002Fmain\u002Fdata\u002Fskills\u002Fsamber-cc-skills-golang\u002Fgolang-troubleshooting\u002Fmetadata.json",[69,76,81,88,93,100],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":19},"01M7D6MC9FAAEV4CMNYX8W7JTG","arxiv-search","Search arXiv physics, math, and computer science preprints using natural language queries. Powered by Valyu semantic search.","https:\u002F\u002Fgithub.com\u002Fom-scogo\u002Fskillsh-scraper\u002Fblob\u002Fmain\u002Fdata\u002Fskills\u002Fyorkeccak-scientific-skills\u002Farxiv-search\u002Fskills\u002Farxiv-search\u002FSKILL.md",[],[],{"skillNo":77,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":19},"01M7D6M85CKKN87TA98VCQV4H7","https:\u002F\u002Fgithub.com\u002Fom-scogo\u002Fskillsh-scraper\u002Fblob\u002Fmain\u002Fdata\u002Fskills\u002Fyorkeccak-scientific-skills\u002Farxiv-search\u002FSkill.md",[],[],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":19},"01M7D4ZTCS4DR3CE4JY06X84T2","working-with-legacy-code","Safely change and test untested codebases using Feathers' \"Working Effectively with Legacy Code\". Use when the user mentions \"legacy code\", \"no tests\", \"untested codebase\", \"how do I test this\", \"seams\", \"characterization tests\", \"golden master\", \"sprout method\", \"afraid to change this code\", \"monster method\", \"dependency breaking\", or \"inherited a messy codebase\". Also trigger when changing code without tests safely, getting a class under test when constructors, statics, or singletons block it, adding features to tangled modules, or planning incremental test coverage for an old codebase. Covers the legacy-code change algorithm, seams, characterization tests, sprout\u002Fwrap, and dependency-breaking techniques. For refactoring code that already has tests, see refactoring-patterns. For day-to-day code quality, see clean-code.","https:\u002F\u002Fgithub.com\u002Fom-scogo\u002Fskillsh-scraper\u002Fblob\u002Fmain\u002Fdata\u002Fskills\u002Fwondelai-skills\u002Fworking-with-legacy-code\u002Fworking-with-legacy-code\u002FSKILL.md",[],[],{"skillNo":89,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":19},"01M7D4ZHZKJD2RSNGAF63V14P4","https:\u002F\u002Fgithub.com\u002Fom-scogo\u002Fskillsh-scraper\u002Fblob\u002Fmain\u002Fdata\u002Fskills\u002Fwondelai-skills\u002Fworking-with-legacy-code\u002FSkill.md",[],[],{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":19},"01M7D4ZB4CJBFW5JE67CPH2QRV","web-typography","Select, pair, and implement typefaces for web projects. Use when the user mentions \"font pairing\", \"which typeface\", \"line height\", \"responsive typography\", \"web font loading\", \"type hierarchy\", \"variable fonts\", \"FOUT\u002FFOIT\", \"typographic scale\", or \"the text is hard to read\". Also trigger when choosing between system fonts and web fonts, optimizing font-loading performance, or designing readable long-form content. Covers readability evaluation, CSS implementation, and performance optimization. For overall UI design systems, see refactoring-ui. For dramatic typographic experiences, see top-design.","https:\u002F\u002Fgithub.com\u002Fom-scogo\u002Fskillsh-scraper\u002Fblob\u002Fmain\u002Fdata\u002Fskills\u002Fwondelai-skills\u002Fweb-typography\u002Fweb-typography\u002FSKILL.md",[],[],{"skillNo":101,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":19},"01M7D4Z4MVYVY3NMJ18BNV6WNA","https:\u002F\u002Fgithub.com\u002Fom-scogo\u002Fskillsh-scraper\u002Fblob\u002Fmain\u002Fdata\u002Fskills\u002Fwondelai-skills\u002Fweb-typography\u002FSkill.md",[],[]]