Data Structure Review
Review the work just completed for cleanup opportunities where a better data structure or organizing model would make the code simpler, safer, or easier to extend.
Consider whether accidental complexity could be reduced by:
- A state machine instead of scattered booleans, phases, or lifecycle checks.
- A typed object or model instead of loose parameters or repeated shape assumptions.
- A map, registry, lookup table, or discriminated union instead of branching spread across files.
- A reducer or command/event model instead of ad hoc state mutations.
- A small module boundary that gathers repeated behavior, ownership, or invariants.
- A queue, cache, index, graph/tree, or normalized collection where the access pattern calls for it.
Do not force an abstraction. Prefer boring code when the current shape is clear, local, and unlikely to grow. Reject abstractions that add indirection without removing branches, duplicated rules, invalid states, or lifecycle risk.
Evaluate
- Complexity revealed by the work: repeated conditionals, mirrored state, unclear ownership, invalid intermediate states, awkward data flow, fragile ordering, or duplicated transformations.
- Whether a data structure or organizing model would encode the domain more directly.
- The smallest useful cleanup that improves the code without changing behavior.
- Risk: files touched, behavior affected, test impact, and whether the cleanup should wait.
If a clear, low-risk cleanup fits the current task scope, implement it and run relevant checks. If it is larger, speculative, or distracting, do not implement it; return a concise recommendation instead.
Return
- Verdict:
implement, recommend, or skip.
- Opportunity: Concrete data structure or organizing model, or
none.
- Why: Complexity removed and invariants clarified.
- Scope: Smallest credible change.
- Validation: Checks run or needed.
1---2name: data-structure-review3description: Review recent spike or implementation work for data structures and organizing models that would materially simplify the code. Use after exploratory work, when asked to reconsider the design, or when scattered state, repeated branches, unclear ownership, invalid intermediate states, fragile ordering, or duplicated transformations appear.4---56# Data Structure Review78Review the work just completed for cleanup opportunities where a better data structure or organizing model would make the code simpler, safer, or easier to extend.910Consider whether accidental complexity could be reduced by:1112- A state machine instead of scattered booleans, phases, or lifecycle checks.13- A typed object or model instead of loose parameters or repeated shape assumptions.14- A map, registry, lookup table, or discriminated union instead of branching spread across files.15- A reducer or command/event model instead of ad hoc state mutations.16- A small module boundary that gathers repeated behavior, ownership, or invariants.17- A queue, cache, index, graph/tree, or normalized collection where the access pattern calls for it.1819Do not force an abstraction. Prefer boring code when the current shape is clear, local, and unlikely to grow. Reject abstractions that add indirection without removing branches, duplicated rules, invalid states, or lifecycle risk.2021## Evaluate22231. Complexity revealed by the work: repeated conditionals, mirrored state, unclear ownership, invalid intermediate states, awkward data flow, fragile ordering, or duplicated transformations.242. Whether a data structure or organizing model would encode the domain more directly.253. The smallest useful cleanup that improves the code without changing behavior.264. Risk: files touched, behavior affected, test impact, and whether the cleanup should wait.2728If a clear, low-risk cleanup fits the current task scope, implement it and run relevant checks. If it is larger, speculative, or distracting, do not implement it; return a concise recommendation instead.2930## Return31321. **Verdict:** `implement`, `recommend`, or `skip`.332. **Opportunity:** Concrete data structure or organizing model, or `none`.343. **Why:** Complexity removed and invariants clarified.354. **Scope:** Smallest credible change.365. **Validation:** Checks run or needed.
mikker