Stabilizing Compose Types — Three Tiers, In Order

Once a diagnosis (see ../diagnosing-compose-stability/SKILL.md) has named the unstable types, this skill walks Claude through fixing them. The strategy is a strict three-tier waterfall: (1) make the type truly stable by structural rewrite (val + immutable fields) — no annotation needed; (2) annotate with @Immutable or @Stable when the source is owned and the contract is honored; (3) use stabilityConfigurationFile for third-party or Java types. DO NOT invert this order — annotations are a contract, not a magic spell.

When to use this skill

• The compiler report (composables.txt / classes.txt) shows one or more unstable parameters.
• The developer asks how to stabilize a domain class, a List<Foo> parameter, java.time.LocalDateTime, or a third-party type.
• The developer mentions @Immutable, @Stable, compose-stable-marker, compose-runtime-annotation, kotlinx.collections.immutable, stabilityConfigurationFiles, or stability_config.conf.
• A @TraceRecomposition log shows recomposition happening because an argument is allocated fresh every recomposition.