choose-data-structures

Select data structures from workload operations, invariants, ownership, and storage constraints.

5|Updated Jan 31, 2026
One-click install
npx skills add https://github.com/nuggocto/dotfiles --skill choose-data-structures-nuggocto
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: choose-data-structures
Source: https://github.com/nuggocto/dotfiles/tree/main/opencode/skills/choose-data-structures
Command: npx skills add https://github.com/nuggocto/dotfiles --skill choose-data-structures-nuggocto

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Choosing the wrong data representation leads to lockstep mutations, repeated conversions, defensive checks, and hidden performance costs. This Skill guides you through analyzing actual operations, scale, relationships, and invariants before committing to a data structure, so the representation fits the workload instead of fighting it. ## Core Features & Use Cases - Workload-Driven Selection: Analyze operation frequency, cardinality, ownership, concurrency, and persistence requirements before comparing candidate representations. - Invariant and Source-of-Truth Modeling: Define uniqueness, ordering, and referential integrity rules, with explicit update or invalidation rules for every index and cache. - Warning-Sign Detection: Identify representations that cause synchronized collections, repeated regrouping, or scattered defensive checks, and know when to fix them. - Use Case: When designing a new core entity model, use this Skill to compare an array of structs against a keyed map with secondary indexes, record the dominant operations and invariants, and verify the choice with boundary and mutation tests. ## Quick Start Ask the AI to review the data structures in your core state module and recommend a representation based on the actual operations, scale, and invariants.

Frequently Asked Questions about choose-data-structures

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

FAQPage Schema
How do I choose the right data structure for my application?

Start by describing the workload: expected counts, common operations and their frequency, relationships, ownership, and persistence needs. Then compare the simplest plausible representation against one credible alternative on correctness, operation costs, memory, and migration cost, and pick the least complicated option that satisfies known bounds.

When should I use an array of structs instead of a map or index?

Use an array, slice, or list of cohesive structs when the collection is bounded or modest, iteration and serialization are common, records share ownership and lifetime, and no keyed lookup dominates. Add a map, set, or secondary index only when repeated keyed membership or lookup justifies its synchronization cost.

What are the warning signs of a poor data representation?

Warning signs include several mutable collections changing in lockstep, common operations repeatedly scanning or regrouping data, defensive checks for invalid combinations, unclear ownership or source of truth, and small behavior changes touching many adapters. Fix the representation only when evidence supports it.

How do I keep secondary indexes and caches consistent?

Name one source of truth and give every secondary index or cache an explicit update, invalidation, or rebuild rule. Never keep two mutable sources of truth, and never add an index or denormalized copy without naming the operation that pays for its synchronization cost.

When should I not redesign an existing data model?

Do not redesign stable, unrelated code based on general warning signs alone. Revisit the model only when simple behavior requires repeated conversions, synchronized collections, or defensive repair code, and preserve public and persistent contracts unless the change explicitly includes a migration.