Ordering Modifier Chains — Why padding(8.dp).background(Red) ≠ background(Red).padding(8.dp)

Modifier order matters because each modifier wraps the next as a function. Modifier.padding(8.dp).background(Red) shrinks constraints first, so the background paints INSIDE the padded region — the surrounding 8 dp margin has no red. Conversely, Modifier.background(Red).padding(8.dp) paints red across the parent's full bounds before insetting the content. Wrong order is the most common Compose UI bug after missing keys. This skill teaches Claude how to read a chain top-to-bottom and reorder it correctly.

When to use this skill

• The developer asks "why does the click area extend past the visible button?", "why is my ripple bouncing on the wrong shape?", "why is the background painted in the wrong area?", or "does Modifier order matter?".
• A code review shows a chain like Modifier.padding(...).clickable { }, Modifier.background(...).clip(...), or Modifier.alpha(state.value).graphicsLayer { }.
• A button's tap target leaks into the surrounding padding, or the corner radius is not honored on the background.
• A clip on a parent is failing to mask a child draw, or graphicsLayer { alpha = 0.5f } is half-applying to siblings.
• The developer is considering hoisting a Modifier chain via remember { Modifier.… } "for perf".

When NOT to use this skill

• The chain order is correct and the symptom is elsewhere (state read in the wrong phase, missing keys in a lazy layout). Diagnose with ../../recomposition/deferring-state-reads/SKILL.md or ../../lists/optimizing-lazy-layouts/SKILL.md first.
• The custom modifier itself is the problem (composed { } legacy, missing diff) → see ../migrating-to-modifier-node/SKILL.md.
• The question is whether to make a custom modifier — this skill assumes you already have a chain of built-ins and need to order them right.

Prerequisites