Developing With Compose Previews — Preview-Driven Development

@Preview is the cheapest verification loop in Compose: edit, see the render in ~1 s, no build/install/navigate cycle. It only pays off if composables are structured so previews stay alive — hoisted state, no ViewModel in the signature, realistic sample data. This skill encodes that structure and the anti-patterns that cause teams to abandon previews. For taking those previews as on-device screenshots in CI, see ../capturing-preview-screenshots-in-ci/SKILL.md.

When to use this skill

• A @Preview "fails to render" or crashes because the composable takes a ViewModel, repository, or Context-bound dependency.
• The user wants to see loading / empty / error / overflow-text / RTL states without running the app — @PreviewParameter territory.
• A composable loads images with Coil/Glide and the preview shows nothing — needs LocalInspectionMode.
• The user asks "how should I structure Compose previews so they don't keep breaking" or mentions "preview-driven development".
• Previews exist but drift out of date / show the "out of date" banner constantly and the team is about to delete them.

When NOT to use this skill

• The user wants to capture previews as screenshots on a device or in CI (HotSwan captureAllPreviews, GitHub Pages catalog) — use ../capturing-preview-screenshots-in-ci/SKILL.md.
• The user wants pixel-diff golden-image regression tests (Paparazzi / Roborazzi) — that is a different tool; see ../capturing-preview-screenshots-in-ci/SKILL.md for where it fits relative to device rendering.
• The user is writing behavioral UI tests (ComposeTestRule, finders, assertions) — start at ../../setup/configuring-test-dependencies/SKILL.md and ../../finders/finding-nodes-by-tag-text-content/SKILL.md.

Prerequisites