compose-component-design

Designs reusable Jetpack Compose component APIs with caller modifiers and slot-based content.

1.0k|46|Updated May 12, 2026
One-click install
npx skills add https://github.com/chrisbanes/skills --skill compose-component-design
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: compose-component-design
Source: https://github.com/chrisbanes/skills/tree/main/skills/compose-component-design
Command: npx skills add https://github.com/chrisbanes/skills --skill compose-component-design

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Reusable Compose components often end up with rigid APIs: missing root modifiers, proliferating primitive content parameters, and Boolean shape flags that callers cannot adapt. This Skill guides the design and review of component APIs so callers retain placement, content, and policy control while the component owns its invariant structure.

Core Features & Use Cases

  • Modifier and layout conventions: Apply a caller modifier at the component root, order modifier chains correctly, and decide when to hoist conditional layout wrappers.
  • Slot API design: Replace unconstrained primitive parameters and Boolean flags with named @Composable slots, nullable optional slots, and scoped receivers only when caller layout control is a public contract.
  • Use Case: When reviewing a SettingsRow composable, convert fixed title: String and showIcon: Boolean parameters into headlineContent and nullable leadingContent slots so callers supply variable content without a flag matrix.

Quick Start

Ask the assistant to review your Compose component's public API for modifier placement and slot design using the compose-component-design skill.

Frequently Asked Questions about compose-component-design

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I design a reusable Compose component API?

Give the component a `modifier: Modifier = Modifier` parameter applied at its root layout, and expose caller-variable visual regions as named `@Composable` slots. Keep semantic and design-system constraints as primitive parameters while the component owns its invariant structure.

When should I use slot APIs instead of parameters in Compose?

Use slots when a visual region's content varies by caller and is unconstrained, such as leading icons or trailing actions. Keep primitive parameters when every caller must share a fixed semantic contract, like a `checked` state, or in measured hot paths where slot allocation matters.

Where should the modifier parameter go in a Compose component?

Place `modifier: Modifier = Modifier` after required parameters and apply it first in the root layout's modifier chain, before intrinsic identity modifiers like `clip` or default sizing. Positioning, padding, and general size decisions belong to the caller.

Should I use RowScope receivers on Compose slot parameters?

Add a `RowScope`, `ColumnScope`, or `BoxScope` receiver only when caller control of that region's child layout is a deliberate public contract, such as top bar actions. An ordinary slot inside a component-owned Row stays `@Composable () -> Unit`.

When should a Compose component keep Boolean flags instead of slots?

Boolean shape flags should generally be replaced by slots, but keep primitives for true constrained values, fixed design-system contracts, single-use helpers, previews, and test fixtures. Do not add slots merely to anticipate hypothetical flexibility.