auditing-compose-performance
installsforks
How to install auditing-compose-performance?
skydoves/compose-performance-skills/auditing-compose-performance
$npx -y skills add skydoves/compose-performance-skills --skill auditing-compose-performanceUse 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 loo
SKILL.md
| 1 | # Auditing Compose Performance — the Measure → Diagnose → Fix → Verify orchestrator |
| 2 | |
| 3 | 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. |
| 4 | |
| 5 | 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. |
| 6 | |
| 7 | 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. |
| 8 | |
| 9 | ## When to use this skill |
| 10 | |
| 11 | - The developer reports broad sluggishness with no specific surface ("the app feels heavy", "everything is slow"). |
| 12 | - A team is kicking off a performance sprint and wants a structured plan. |
| 13 | - A new team member needs onboarding to a perf-troubled codebase. |
| 14 | - A pre-release perf gate is required before shipping. |
| 15 | - The user asks for an "audit", "perf review", or a written deliverable. |
| 16 | - The user has no idea where to start and wants Claude to triage. |
| 17 | |
| 18 | ## When NOT to use this skill |
| 19 | |
| 20 | - 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. |
| 21 | - The developer only wants to fix one issue and does not want a written report. Pick the focused skill from `../../INDEX.md`. |
| 22 | - No release build is possible (e.g. broken signing config). Resolve that first; this audit MUST measure release. |
| 23 | |
| 24 | ## Prerequisites |
| 25 | |
| 26 | - Project builds the release variant successfully (`./gradlew assembleRelease`). |
| 27 | - At least one physical Android device for measurement. Emulator numbers are not representative. |
| 28 | - A Macrobenchmark module is present, or willingness to add one (see `../../measurement/generating-baseline-profiles/SKILL.md`). |
| 29 | - Willingness to commit Baseline Profile and stability baseline files to the repo. |
| 30 | - Compose Compiler 1.5.5+ for `stabilityConfigurationFile`. Kotlin 2.0.20+ for Strong Skipping default. AGP 8.2+ for the Baseline Profile Generator template. |
| 31 | - Optional but recommended: a feature branch to land each fix as its own PR. |
| 32 | |
| 33 | ## Workflow |
| 34 | |
| 35 | Run all four phases in order. **DO NOT** skip ahead. After each Phase 3 fix, return to Phase 1 to re-measure and Phase 2 to re-diagnose before applying the next fix. |
| 36 | |
| 37 | ### Phase 1 — Measure (establish baseline numbers BEFORE changing any code) |
| 38 | |
| 39 | - [ ] Confirm the release variant builds and is the measurement target. Cross-link `../../measurement/testing-compose-in-release-mode/SKILL.md`. |
| 40 | - [ ] Confirm R8 is enabled correctly (full mode, `proguard-android-optimize.txt`, resource shrinking on). Cross-link `../../build/configuring-r8-for-compose/SKILL.md`. |
| 41 | - [ ] Generate or refresh the Baseline Profile via the Baseline Profile Generator module. Cross-link `../../measurement/generating-baseline-profiles/SKILL.md`. |
| 42 | - [ ] Capture ** |
People who liked this also viewed
6 picksType
- tddSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- test-driven-developmentUse when implementing any feature or bugfix, before writing implementation codeSkillsJul 2026
- qaSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- verification-before-completionUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidenceSkillsJul 2026
- webapp-testingToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser lSkillsJul 2026
- playwright-best-practicesUse when writing Playwright tests, fixing flaky tests, debugging failures, implementing Page Object Model, configuring CI/CD, optimizing performance, mocking APIs, handling authentication or OAuth, teSkillsJul 2026
