# Golang Safety

Defensive Golang coding against accidental bugs, nil panics, typed-nil interfaces...

- Repository: https://github.com/samber/cc-skills-golang (3750 stars)
- Category: Design
- License: MIT
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add samber/cc-skills-golang --skill golang-safety -g -a claude-code -y`
Codex: `npx skills add samber/cc-skills-golang --skill golang-safety -g -a codex -y`
Cursor: `npx skills add samber/cc-skills-golang --skill golang-safety -g -a cursor -y`
Gemini CLI: `npx skills add samber/cc-skills-golang --skill golang-safety -g -a gemini-cli -y`

## Description

Defensive Golang coding against accidental bugs, nil panics, typed-nil interfaces, `append` backing-array aliasing, silent int64-to-int32 truncation, float `==` comparison, `defer` inside loops, defensive copies of slices and maps, and usable zero values. Use when a Go program panics on a nil map write or nil pointer dereference, when reviewing code for nil-safety, numeric conversion overflow, or resource lifecycle, or when designing a type whose zero value must be safe. Not for designing concurrent access with goroutines, channels, or sync primitives (→ See `samber/cc-skills-golang@golang-concurrency` skill), not for exploitable vulnerabilities such as injection, weak crypto, or leaked secrets (→ See `samber/cc-skills-golang@golang-security` skill), and not for debugging an already-failing program (→ See `samber/cc-skills-golang@golang-troubleshooting` skill).

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

**Persona:** You are a defensive Go engineer. You treat every untested assumption about nil, capacity, and numeric range as a latent crash waiting to happen.

# Go Safety: Correctness & Defensive Coding

Prevents programmer mistakes, bugs, panics, and silent data corruption in normal (non-adversarial) code. Security handles attackers; safety handles ourselves.

## Best Practices Summary

1. **Prefer generics over `any`** when the type set is known, compiler catches mismatches instead of runtime panics
2. **Always use safe type assertions**, for normal interfaces use comma-ok (`v, ok := x.(T)`); for reflection in Go 1.25+ prefer `reflect.TypeAssert[T](value)` over `value.Interface().(T)`.
3. **Typed nil pointer in an interface is not `== nil`**, the type descriptor makes it non-nil
4. **Writing to a nil map panics**, always initialize before use
5. **`append` may reuse the backing array**, both slices share memory if capacity allows, silently corrupting each other
6. **Return defensive copies** from exported functions, otherwise callers mutate your internals
7. **`defer` runs at function exit, not loop iteration**, extract loop body to a function
8. **Integer conversions truncate silently**, `int64` to `int32` wraps without error
9. **Float arithmetic is not exact**, use epsilon comparison or `math/big`
10. **Design useful zero values**, nil map fields panic on first write; use lazy init
11. **Use `sync.Once` for lazy init**, guarantees exactly-once even under concurrency

## Nil Safety

Nil-related panics are the most common crash in Go.

### The nil interface trap

Interfaces store (type, value). An interface is `nil` only when both are nil. Returning a typed nil pointer sets the type descriptor, making it non-nil:

The rest: https://github.com/samber/cc-skills-golang/blob/HEAD/skills/golang-safety/SKILL.md