debugging-recompositions

Installation
SKILL.md

Debugging Recompositions — make the invisible visible, then map status to action

Recomposition is invisible by default. A composable that re-runs sixty times a second to redraw an animation looks identical in source to one that should re-run zero times when its parent ticks. Three layers of instrumentation make it visible: Layout Inspector recomposition counts and skip counts (Android Studio, debug build), Layout Inspector Argument Change Reasons (Hedgehog and later, per-parameter Changed / Unchanged / Uncertain / Static / Unknown classifications), and runtime @TraceRecomposition from compose-stability-analyzer for release / R8 / real-device measurement.

This skill is the diagnostic layer. It does not fix recompositions; it tells the developer which composable is recomposing and which parameter is responsible. Once the param is named, the fix lives in a sibling skill — stability for unstable types, strong skipping for lambda capture, or phase deferral for state reads in the wrong phase.

When to use this skill

  • The developer says "this should be skipping but it's not" or "this re-runs every time the parent ticks".
  • The developer wants to count recompositions of a specific composable to confirm a fix worked.
  • The developer asks what "Uncertain", "Unknown", "Static", or "Unchanged" means in the Layout Inspector recomposition reasons panel.
  • A PR claims a stability or strong-skipping fix; the reviewer needs to confirm the recomposition actually went away in release.
  • The user mentions "recomposition count", "Layout Inspector", "Argument Change Reasons", "Hedgehog", "@TraceRecomposition", or "why is this recomposing".

When NOT to use this skill

Related skills

More from skydoves/compose-performance-skills

Installs
10
GitHub Stars
377
First Seen
Apr 29, 2026