What problem does it solve? Composable functions often hardcode layout decisions like fillMaxWidth on their root, omit the modifier parameter entirely, or build modifier chains through stepwise var reassignments, making components hard to reuse and review. This Skill provides concrete rules and before/after Kotlin examples for writing and reviewing Compose layout APIs so callers retain control over placement, sizing, and padding. ## Core Features & Use Cases - Modifier parameter conventions: Declare a modifier parameter with a Modifier default, apply it to the root layout first, and avoid hardcoding fillMaxWidth or padding that belongs to the caller. - Fluent chain construction: Replace var-based stepwise modifier reassignment with a single chained expression, including conditional segments via .then(if (c) Modifier.x() else Modifier), and format chains of three or more calls multiline. - Conditional layout hoisting: Move single if conditions outside layout wrappers when the layout carries no container semantics, with explicit carve-outs for Box with modifiers, siblings, and if/else branches. - Measure-phase constraint decoration: Use a Modifier.layout-based decorateMeasureConstraints helper so sibling composables match a measured size without composition-time coupling. - Use Case: While reviewing a pull request, you find a PrimaryButton with modifier.fillMaxWidth() hardcoded on its root and a Column whose only content is one if. Apply the rules to move layout decisions to the caller and hoist the conditional. ## Quick Start Review this Compose file and fix any modifier parameter, modifier chain, or conditional layout issues according to the compose modifier and layout style rules.
