How to install go-data-structures
npx skills add https://github.com/cxuu/golang-skills --skill go-data-structuresFull instructions (SKILL.md)
Source of truth, from cxuu/golang-skills.
name: go-data-structures description: Use when working with Go slices, maps, or arrays — choosing between new and make, using append, declaring empty slices (nil vs literal for JSON), implementing sets with maps, and copying data at boundaries. Also use when building or manipulating collections, even if the user doesn't ask about allocation idioms. Does not cover concurrent data structure safety (see go-concurrency).
Go Data Structures
Resource Routing
references/SLICES.md- Read when deciding nil versus empty slices, copying slices, or managing slice capacity and aliasing.
Choosing a Data Structure
What do you need?
├─ Ordered collection of items
│ ├─ Fixed size known at compile time → Array [N]T
│ └─ Dynamic size → Slice []T
│ ├─ Know approximate size? → make([]T, 0, capacity)
│ └─ Unknown size or nil-safe for JSON? → var s []T (nil)
├─ Key-value lookup
│ └─ Map map[K]V
│ ├─ Know approximate size? → make(map[K]V, capacity)
│ └─ Need a set? → map[T]struct{} (zero-size values)
└─ Need to pass to a function?
└─ Copy at the boundary if the caller might mutate it
When this skill does NOT apply: For concurrent access to data structures (mutexes, atomic operations), see go-concurrency. For defensive copying at API boundaries, see go-defensive. For pre-sizing capacity for performance, see go-performance.
Slices
The append Function
Always assign the result — the underlying array may change:
x := []int{1, 2, 3}
x = append(x, 4, 5, 6)
// Append a slice to a slice
x = append(x, y...) // Note the ...
Two-Dimensional Slices
Independent inner slices (can grow/shrink independently):
picture := make([][]uint8, YSize)
for i := range picture {
picture[i] = make([]uint8, XSize)
}
Single allocation (more efficient for fixed sizes):
picture := make([][]uint8, YSize)
pixels := make([]uint8, XSize*YSize)
for i := range picture {
picture[i], pixels = pixels[:XSize], pixels[XSize:]
}
Declaring Empty Slices
Prefer nil slices over empty literals:
// Good: nil slice
var t []string
// Avoid: non-nil but zero-length
t := []string{}
Both have len and cap of zero, but the nil slice is the preferred style.
Exception for JSON: A nil slice encodes to null, while []string{}
encodes to []. Use non-nil when you need a JSON array.
When designing interfaces, avoid distinguishing between nil and non-nil zero-length slices.
Maps
Implementing a Set
Use map[T]struct{} when the map is only a set. The empty struct takes no
storage and makes membership intent explicit:
attended := map[string]struct{}{"Ann": {}, "Joe": {}}
if _, ok := attended[person]; ok {
fmt.Println(person, "was at the meeting")
}
Use boolean map values only when the value carries a separate meaning beyond presence.
Copying
Be careful when copying a struct from another package. If the type has methods
on its pointer type (*T), copying the value can cause aliasing bugs.
General rule: Do not copy a value of type T if its methods are associated
with the pointer type *T. This applies to bytes.Buffer, sync.Mutex,
sync.WaitGroup, and types containing them.
// Bad: copying a mutex
var mu sync.Mutex
mu2 := mu // almost always a bug
// Good: pass by pointer
func increment(sc *SafeCounter) {
sc.mu.Lock()
sc.count++
sc.mu.Unlock()
}
Quick Reference
| Topic | Key Point |
|---|---|
| Slices | Always assign append result; nil slice preferred over []T{} |
| Sets | map[T]struct{} for membership-only sets |
| Copying | Don't copy T if methods are on *T; beware aliasing |
Related Skills
- Defensive copying: See go-defensive when copying slices or maps at API boundaries to prevent mutation
- Capacity hints: See go-performance when pre-sizing slices or maps for known workloads
- Iteration patterns: See go-control-flow when using range loops over slices, maps, or channels
- Declaration style: See go-declarations when choosing between
new,make,var, and composite literals
Related skills
More from cxuu/golang-skills and the wider catalog.
go-code-review
Use when reviewing Go code or checking code against community style standards. Also use proactively before submitting a Go PR or when reviewing any Go code changes, even if the user doesn't explicitly request a style review. Does not cover language-specific syntax — delegates to specialized skills.
go-testing
Use when writing, reviewing, or improving Go test code — including table-driven tests, subtests, parallel tests, test helpers, test doubles, and assertions with cmp.Diff. Also use when a user asks to write a test for a Go function, even if they don't mention specific patterns like table-driven tests or subtests. Does not cover benchmark performance testing (see go-performance).
go-linting
Use when setting up linting for a Go project, configuring golangci-lint, or adding Go checks to a CI/CD pipeline. Also use when starting a new Go project and deciding which linters to enable, even if the user only asks about "code quality" or "static analysis" without mentioning specific linter names. Does not cover code review process (see go-code-review).
go-documentation
Use when writing or reviewing documentation for Go packages, types, functions, or methods. Also use proactively when creating new exported types, functions, or packages, even if the user doesn't explicitly ask about documentation. Does not cover code comments for non-exported symbols (see go-style-core).
go-performance
Use when optimizing Go code, investigating slow performance, or writing performance-critical sections. Also use when a user mentions slow Go code, string concatenation in loops, or asks about benchmarking, even if the user doesn't explicitly mention performance patterns. Does not cover concurrent performance patterns (see go-concurrency).
go-error-handling
Use when writing Go code that returns, wraps, or handles errors — choosing between sentinel errors, custom types, and fmt.Errorf (%w vs %v), structuring error flow, or deciding whether to log or return. Also use when propagating errors across package boundaries or using errors.Is/As, even if the user doesn't ask about error strategy. Does not cover panic/recover patterns (see go-defensive).