Compose Performance Skills

---
name: auditing-compose-performance
description: Use this skill to run an end-to-end Jetpack Compose performance audit when the symptom is broad ("the app feels sluggish", "scroll is rough everywhere", "we're starting a perf sprint", "what should we fix first?"). Orchestrates the four-phase Measure → Diagnose → Fix → Verify loop by sequencing the 25 focused skills (release-mode setup, R8, Baseline Profiles, Compose Compiler reports, stability inference, Layout Inspector, `@TraceRecomposition`, stabilization, strong skipping, phase-deferral, derivedStateOf, lazy layouts, lazy prefetch, Modifier.Node, modifier ordering, flow collection, effects, CI gates, hot-reload) and produces a written audit report with Before/After Macrobenchmark numbers. Use when the developer wants a perf sprint kickoff, a pre-release perf gate, onboarding to a perf-troubled codebase, or a written deliverable. Use when the user mentions "audit", "perf review", "perf sprint", "where do I start", or has no specific symptom yet.
license: Apache-2.0. See LICENSE for complete terms.
metadata:
  author: Jaewoong Eum (skydoves)
  keywords:
  - jetpack-compose
  - performance
  - audit
  - orchestrator
  - perf-sprint
  - measure-diagnose-fix-verify
  - baseline-profile
  - macrobenchmark
  - compose-compiler-reports
  - stability
---

# Auditing Compose Performance — the Measure → Diagnose → Fix → Verify orchestrator

This is the highest-level entry point in the `compose-performance-skills` library. When the developer's symptom is broad — "the app feels sluggish", "scroll is rough everywhere", "we're starting a perf sprint", "where do we even start?" — Claude enters here. The orchestrator does **NOT** replace the 25 focused skills; it sequences them through a four-phase loop and produces a written audit report at the end.

The phases are **Measure → Diagnose → Fix → Verify**, run in order, never skipped. Phase 1 establishes baseline numbers from a release + R8 build on a real device, because anything else is fiction. Phase 2 turns symptoms into named causes from the Compose Compiler reports, Layout Inspector, and runtime tracing. Phase 3 applies one targeted fix at a time, re-measuring between fixes so the delta of each change is provable. Phase 4 regenerates the Baseline Profile, locks in a CI stability gate, and commits the baseline files so regressions cannot slip back.

Perf work without measurement is guessing. Skydoves hot take #1 applies throughout: **DO NOT** chase 100% skippability — that is a diagnostic on a compiler report, not the goal. The goal is `FrameTimingMetric` and `StartupTimingMetric` improvement on a real device.

## When to use this skill

- The developer reports broad sluggishness with no specific surface ("the app feels heavy", "everything is slow").
- A team is kicking off a performance sprint and wants a structured plan.
- A new team member needs onboarding to a perf-troubled codebase.
- A pre-release perf gate is required before shipping.
- The user asks for an "audit", "perf review", or a written deliverable.
- The user has no idea where to start and wants Claude to triage.

## When NOT to use this skill

- A specific symptom is already named (scroll jank in `LazyColumn`, `derivedStateOf` not firing, custom modifier recomposing). Go straight to the focused skill. See `../../INDEX.md` for the symptom→skill map.
- The developer only wants to fix one issue and does not want a written report. Pick the focused skill from `../../INDEX.md`.
- No release build is possible (e.g. broken signing config). Resolve that first; this audit MUST measure release.

## Prerequisites

- Project builds the release variant successfully (`./gradlew assembleRelease`).