# Ordering Modifier Chains

Use this skill to diagnose and fix Jetpack Compose Modifier ordering bugs, wrong paint...

- Repository: https://github.com/skydoves/compose-performance-skills (524 stars)
- Category: Engineering
- License: Apache-2.0
- Last updated: 2026-06-16
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add skydoves/compose-performance-skills --skill ordering-modifier-chains -g -a claude-code -y`
Codex: `npx skills add skydoves/compose-performance-skills --skill ordering-modifier-chains -g -a codex -y`
Cursor: `npx skills add skydoves/compose-performance-skills --skill ordering-modifier-chains -g -a cursor -y`
Gemini CLI: `npx skills add skydoves/compose-performance-skills --skill ordering-modifier-chains -g -a gemini-cli -y`

## Description

Use this skill to diagnose and fix Jetpack Compose Modifier ordering bugs, wrong paint region for background, wrong click area for clickable, wrong clipping for clip, wrong measurement for padding/size, surprising graphicsLayer scope. Covers the wrap-the-next-modifier mental model, the canonical pitfalls (padding vs background, clickable placement, clip before background, graphicsLayer placement), and why hoisting an entire Modifier chain via remember { Modifier.… } is rarely a real perf win because Compose already interns identical chains. Use when the developer asks "why does the click area extend past the visible button", "why is my background painted in the wrong place", "does Modifier order matter", "should I cache my Modifier chain", or reviews a diff that reorders modifiers.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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

The rest: https://github.com/skydoves/compose-performance-skills/blob/HEAD/modifiers/ordering-modifier-chains/SKILL.md