Optimizing Lazy Layouts — Keys, contentType, and animateItem()

Lazy layouts compose only what's visible, but two things still cost: re-composition of items that should have been reused (missing key), and per-item allocation that compounds with scroll velocity (missing contentType, modifier chains created inside items { }). Both have a one-line fix. This skill teaches Claude how to apply that fix correctly and to validate that item composables are themselves skippable. Prefetch tuning is a separate concern — see ../configuring-lazy-prefetch/SKILL.md.

When to use this skill

• The developer reports scroll jank, dropped frames, or stutter on a LazyColumn, LazyRow, LazyVerticalGrid, or LazyHorizontalGrid.
• Items lose scroll position, focus, or composition state on insert, remove, or reorder.
• A mixed-type feed (cards + headers + ads + carousels) feels sluggish even though each individual row is lightweight.
• Modifier.animateItem() was added but no animation runs on inserts or removals.
• The compiler report shows item composables as unstable/non-skippable, or @TraceRecomposition shows item composables recomposing on every scroll tick.

When NOT to use this skill

• The bottleneck is the prefetch window (heavy items, high-velocity scroll, want a wider ahead/behind window) → use ../configuring-lazy-prefetch/SKILL.md.
• The item composable itself takes an unstable parameter (List<Foo>, Flow<Foo>, a domain var) → first run ../../stability/diagnosing-compose-stability/SKILL.md and then ../../stability/stabilizing-compose-types/SKILL.md.
• An animation inside an item reads state.value in Composition phase, recomposing the row every frame → use ../../recomposition/deferring-state-reads/SKILL.md.
• Scroll position derivation (e.g. firstVisibleItemIndex == 0) is the hot path → use ../../recomposition/choosing-derivedstateof/SKILL.md.