go-dev

Generate and run Go benchmarks with profiling and optimization analysis

Auto-detect build system, parse errors, and fix until clean

Cancel any active persistent loop

Deep-dive explanation of Go code with diagrams

Auto-fix Go linting issues with golangci-lint

Profile Go code, identify bottlenecks, optimize, and verify improvements

Find and remove dead Go code, orphaned tests, and complexity issues

Generate comprehensive Go tests with table-driven patterns

Validate bash code blocks in markdown command and skill files

Run full pre-push verification: build, test, lint, vet, dev-server checks

WHEN: User is writing Go code, asking about Go patterns, reviewing Go code, asking "what's the best way to...", "how should I structure...", "is this idiomatic?", or any general Go development question. Trigger this skill liberally for ANY Go-related development work as a routing hub to specialized skills. WHEN NOT: Non-Go languages, questions entirely unrelated to programming

WHEN: User is organizing Go code, asking about package structure, naming conventions, project layout, import organization, file organization, or asking "where should I put this?", "how should I name this package?", "should I split this file?". Also when reviewing code organization in PRs or refactoring package boundaries. WHEN NOT: Non-Go languages. Interface design specifics (use go-interfaces). Concurrency patterns (use go-concurrency).

WHEN: User is writing or reviewing concurrent Go code involving goroutines, channels, select, locks, sync primitives, errgroup, singleflight, worker pools, or fan-out/fan-in pipelines. Also when detecting goroutine leaks, race conditions, channel ownership issues, or choosing between channels and mutexes. WHEN NOT: Non-Go languages. Sequential code with no concurrency needs. Performance profiling (use go-profiling-optimization). Debugging race conditions (use systematic-debugging).

WHEN: User is creating, wrapping, inspecting, or logging errors in Go code. Also when reviewing error handling in PRs, asking about error patterns, using fmt.Errorf, errors.Is, errors.As, errors.Join, sentinel errors, custom error types, or panic/recover. WHEN NOT: Non-Go languages. Performance profiling (use go-profiling-optimization). General debugging (use systematic-debugging).

WHEN: User is designing interfaces, asking about interface patterns, implementing interfaces, working with type assertions, type switches, embedding, or asking "should this be an interface?", "where should I define this interface?", "how many methods should my interface have?". Also activate when reviewing interface design in PRs or refactoring toward interfaces. Trigger when user mentions io.Reader, io.Writer, fmt.Stringer, sort.Interface, interface composition, interface embedding, type assertion, type switch, implicit satisfaction, decorator pattern, middleware pattern, or any question about Go interface design. Trigger this skill liberally for ANY Go interface-related work. WHEN NOT: Non-Go languages. Concurrency primitives (use go-concurrency). Error handling specifics (use go-error-handling).

WHEN: User is analyzing Go performance, asking about profiling, optimization, benchmarking strategy, memory allocations, CPU hotspots, pprof, flame graphs, escape analysis, or "why is this slow". Also activate when user mentions PGO, GOGC, GOMEMLIMIT, runtime/trace, net/http/pprof, gcflags, benchstat, sync.Pool, buffer pooling, preallocation, or is interpreting benchmark results, profiling output, or trace data. Trigger when user asks "how do I profile", "where is the bottleneck", "how to reduce allocations", "is this allocation on heap or stack", or any question about Go runtime performance tuning. Trigger this skill liberally for ANY Go performance-related work. WHEN NOT: Non-Go languages, general debugging without performance focus (use systematic-debugging instead), writing new benchmarks from scratch (suggest /bench command), questions entirely unrelated to performance or optimization

WHEN: User is writing tests, asking about testing patterns, using table-driven tests, subtests, t.Parallel, t.Helper, t.Cleanup, testify, mocks, stubs, integration tests, benchmarks, fuzzing, or test organization. Also when reviewing test code in PRs or asking "how should I test this?", "what should I test?", or "is this test good enough?". WHEN NOT: Non-Go languages. Debugging test failures (use systematic-debugging). Performance benchmarking methodology (use go-profiling-optimization).

WHEN: User is debugging Go code, investigating bugs, analyzing test failures, encountering unexpected behavior, reading stack traces, diagnosing race conditions, fixing flaky tests, or saying "why is this broken", "this doesn't work", "test is failing", "getting an error". Also activate when investigating panics, goroutine deadlocks, data corruption, or any situation where the root cause is not immediately obvious. Trigger this skill liberally for ANY debugging or bug investigation work in Go. WHEN NOT: Writing new features from scratch, code review without a specific bug, questions entirely unrelated to debugging or troubleshooting

WHEN: User is editing .md files in commands/ or skills/ directories, creating new slash commands or skills, modifying fenced bash/shell code blocks in markdown plugin files, asking about validating command files, or discussing shell code correctness in plugin markdown. Also activate when user mentions "shellcheck", "bash -n", "code block validation", "portability check", or has just finished writing/editing a command or skill markdown file. WHEN NOT: Editing Go source code, working with non-markdown files, writing general documentation or README files, questions unrelated to plugin command/skill development