golang-safety

Identify and prevent nil panics and runtime bugs in Go code.

5|1|Updated Apr 14, 2026
One-click install
npx skills add https://github.com/omarluq/og-template --skill golang-safety-omarluq
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: golang-safety
Source: https://github.com/omarluq/og-template/tree/main/.agents/skills/golang-safety
Command: npx skills add https://github.com/omarluq/og-template --skill golang-safety-omarluq

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Defensive patterns that prevent panics, silent data corruption, and subtle runtime bugs in Go.

Core Features & Use Cases

  • Nil safety: guard against nil interfaces, nil maps/slices, and nil receivers.
  • Slice/Map safety, defensive copying, and initialization safety.
  • Enforce with linters: how to detect and prevent common pitfalls.

Quick Start

Apply defensive Go patterns to your codebase to prevent panics and silent data corruption.

Frequently Asked Questions about golang-safety

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I prevent nil panics in Go when working with pointers and interfaces?

Prevent nil panics in Go by applying defensive patterns that guard against nil interfaces, nil receivers, and uninitialized maps or slices. This skill provides safe initialization practices and structural checks to avoid runtime crashes in pointer-heavy code.

What is the typed-nil interface trap in Go and how can I avoid it?

The typed-nil interface trap in Go occurs when an interface holding a nil concrete pointer evaluates as non-nil. You avoid this subtle runtime bug by applying defensive patterns that enforce explicit nil checks before interface assignment.

How do I safely handle Go map and slice initialization to prevent silent data corruption?

Safely handle Go map and slice initialization by enforcing defensive copying and strict initialization safety patterns. This prevents silent data corruption by ensuring you never write to unallocated memory or share underlying arrays unexpectedly.

Why does using defer inside a Go loop cause resource lifecycle bugs and how do I fix it?

Using defer inside a Go loop causes resource lifecycle bugs because deferred calls stack up until the function returns rather than the loop iteration. You fix this by applying correct defer usage patterns, like extracting the loop body into a separate function.

Can I use linters to detect and prevent common Go safety pitfalls like nil receivers and zero-value bugs?

Yes, you can use linters to detect and prevent common Go safety pitfalls. This skill provides lint-guidance to enforce defensive copying, safe initialization, and nil safety patterns across both standard library usage and application code.