How do I install the Compose Recomposition Performance skill?

Run npx skillmds add om-scogo/compose-recomposition-performance in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Compose Recomposition Performance safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Compose Recomposition Performance?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Compose Recomposition Performance free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Compose Recomposition Performance?

om-scogo (@om-scogo) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Compose Recomposition Performance by om-scogo

Name: Compose Recomposition Performance
Rating: 4.5 (4 reviews)
Author: om-scogo

Compose Recomposition Performance

Use when investigating Jetpack Compose recomposition performance, skippable/restartable composables, composables.txt or compiler reports, Layout Inspector recomposition counts, back-writing snapshot state across phases, or frame-rate State reads in composition vs layout/draw, and it is not yet clear whether the cause is parameter stability, deferred reads, or cross-phase back-writing.

om-scogo 9b7ab1d 4 files · 10.3 KB Updated Sep 8, 2026 0 repo stars

File contents

Compose recomposition performance

Router only — deep fixes live in focused skills below.

Three axes

Parameter stability / skipping — can Compose skip this restartable composable; are arguments stable and comparable?
Where State is read — is frame-rate State read during composition vs layout/draw?
Back-writing across phases — does a later phase write snapshot state that invalidates an earlier phase? Examples: map/list mutation during composition that re-invalidates the same composition; onSizeChanged (layout phase) writing state read by a sibling in composition.

Axes 2 and 3 often overlap (a sibling reading measured size in composition is both a deferred-read violation and a layout → composition back-write). Axis 1 is independent.

Route here → focused skill

Primary suspicion	Next skill
Skipping, unstable params, compiler/`composables.txt` churn	`compose-stability-diagnostics`
Frame-rate `State` read phase (composition vs layout/draw)	`compose-state-deferred-reads`
`putAll` / map rebuild / cross-row `height(state)` during composition	`compose-state-deferred-reads` — § back-writing
Focus-driven side work in composable body	`compose-side-effects` — `snapshotFlow`
Evidence for multiple axes	Apply matching skills in parallel

Review order

Reproduce one transition (focus move, insertion, scroll) and note which composables recompose.
If counts spike on unchanged lazy items, check back-writing (composition mutations and cross-row measurement) before blaming stability.
If counts climb every frame during scroll/animation, check deferred reads.
If skipping fails despite stable data, check parameter stability and compiler reports.
Re-measure after each fix.

False leads

These changes often do not reduce recomposition count:

Attempt	Why it fails
`remember(index) { isFirstRow(index) }` instead of inline `when (index)`	Same inputs; no skipping benefit
Identity cache for read-only derived maps	Can serve stale overlays; `remember(keys)` is enough
`mutableIntStateOf` + layout modifier on both measured and sibling rows	Sibling still reads size in composition unless measure-only
Forcing `Exactly(1)` on both rows in focus-move tests	One row often correctly recomposes 0 times
Hoisting without stabilizing lambda captures	New lambda instance each frame still defeats skipping

When NOT to apply

Recomposition tracks real data changes, or the bug is correctness not cost.
No profiler / compiler signal suggests a problem.

compose-state-authoring — authoring mutableState* safely.

---name: compose-recomposition-performancedescription: Use when investigating Jetpack Compose recomposition performance, skippable/restartable composables, composables.txt or compiler reports, Layout Inspector recomposition counts, back-writing snapshot state across phases, or frame-rate State reads in composition vs layout/draw, and it is not yet clear whether the cause is parameter stability, deferred reads, or cross-phase back-writing.---# Compose recomposition performanceRouter only — deep fixes live in focused skills below.## Three axes1. **Parameter stability / skipping** — can Compose skip this restartable composable; are arguments stable and comparable?2. **Where `State` is read** — is frame-rate `State` read during composition vs layout/draw?3. **Back-writing across phases** — does a later phase write snapshot state that invalidates an earlier phase? Examples: map/list mutation during composition that re-invalidates the same composition; `onSizeChanged` (layout phase) writing state read by a sibling in composition.Axes 2 and 3 often overlap (a sibling reading measured size in composition is both a deferred-read violation and a layout → composition back-write). Axis 1 is independent.## Route here → focused skill| Primary suspicion | Next skill ||---|---|| Skipping, unstable params, compiler/`composables.txt` churn | [`compose-stability-diagnostics`](../compose-stability-diagnostics/SKILL.md) || Frame-rate `State` read phase (composition vs layout/draw) | [`compose-state-deferred-reads`](../compose-state-deferred-reads/SKILL.md) || `putAll` / map rebuild / cross-row `height(state)` during composition | [`compose-state-deferred-reads`](../compose-state-deferred-reads/SKILL.md) — § back-writing || Focus-driven side work in composable body | [`compose-side-effects`](../compose-side-effects/SKILL.md) — `snapshotFlow` || Evidence for multiple axes | Apply matching skills in parallel |## Review order1. Reproduce one transition (focus move, insertion, scroll) and note which composables recompose.2. If counts spike on unchanged lazy items, check back-writing (composition mutations and cross-row measurement) before blaming stability.3. If counts climb every frame during scroll/animation, check deferred reads.4. If skipping fails despite stable data, check parameter stability and compiler reports.5. Re-measure after each fix.## False leadsThese changes often **do not** reduce recomposition count:| Attempt | Why it fails ||---|---|| `remember(index) { isFirstRow(index) }` instead of inline `when (index)` | Same inputs; no skipping benefit || Identity cache for read-only derived maps | Can serve stale overlays; `remember(keys)` is enough || `mutableIntStateOf` + layout modifier on **both** measured and sibling rows | Sibling still reads size in composition unless measure-only || Forcing `Exactly(1)` on both rows in focus-move tests | One row often correctly recomposes 0 times || Hoisting without stabilizing lambda captures | New lambda instance each frame still defeats skipping |## When NOT to apply- Recomposition tracks real data changes, or the bug is correctness not cost.- No profiler / compiler signal suggests a problem.## Related- [`compose-state-authoring`](../compose-state-authoring/SKILL.md) — authoring `mutableState*` safely.

Frequently asked questions