kotlin-ui-adaptive-resources

Name: kotlin-ui-adaptive-resources
Author: mmiani

56stars5forks

How to install kotlin-ui-adaptive-resources?

mmiani/kotlin-kmp-claude-agent-skills/kotlin-ui-adaptive-resources

$npx -y skills add mmiani/kotlin-kmp-claude-agent-skills --skill kotlin-ui-adaptive-resources

Installs into the current project.

Summary

Use when designing, implementing, or reviewing adaptive Compose UI for KMP or Android projects — window-size layouts, adaptive navigation, canonical layouts, multi-window support, and resource strategy.

Files · 1

View on GitHub

SKILL.md

1	# Adaptive UI and Resource Strategy
2
3	Use this skill when designing, implementing, or reviewing adaptive UI in a Compose-based project.
4
5	This skill is intentionally strict. Its purpose is to keep layouts resilient across display sizes, window sizes, orientations, fold states, and resizable environments while preserving clear UI architecture and avoiding fragile one-device assumptions.
6
7	## Primary goals
8
9	The adaptive strategy should optimize for:
10
11	- support for a wide range of display and window sizes
12	- structured layout changes rather than ad hoc breakpoints
13	- navigation chrome that adapts with available space
14	- correct use of canonical multi-pane layouts where appropriate
15	- resilience in split-screen, freeform, and desktop-style windowing
16	- resource and presentation decisions that stay configurable
17	- Compose layouts that remain understandable under adaptation pressure
18	- previewability and testability across adaptive states
19
20	Do not treat “works on my phone” as sufficient.
21	Adaptive UI should remain coherent when the window changes shape, size, or posture.
22
23	---
24
25	## Official defaults to prefer
26
27	Unless the project has a strong reason not to, prefer:
28
29	- responsive and adaptive UI that supports a wide range of screens and app window sizes
30	- window size classes as the primary high-level breakpoint system
31	- canonical layouts such as list-detail, feed, and supporting-pane when they fit the use case
32	- adaptive navigation patterns that switch chrome based on available space
33	- layouts that remain usable in multi-window mode and desktop-style windowing
34	- resource and presentation values that stay configurable rather than hard-coded
35	- Compose layouts whose modifier chains and measurement behavior remain explainable
36
37	---
38
39	## Review dimensions
40
41	### 1. Adaptive mindset and target environments
42
43	Check whether the design explicitly supports:
44
45	- phones
46	- tablets
47	- foldables
48	- ChromeOS / large-screen environments
49	- portrait and landscape
50	- resizable windows
51	- split-screen mode
52	- desktop windowing / freeform windows where applicable
53
54	Flag as a concern when:
55	- the design assumes one full-screen phone window shape
56	- large-screen behavior is just stretched phone UI
57	- resizable environments are ignored
58	- adaptation is deferred until after feature implementation
59
60	### 2. Window size class strategy
61
62	Window size classes are the default high-level tool for adaptive decisions. In Compose, `WindowWidthSizeClass` and `WindowHeightSizeClass` (from the `androidx.compose.material3.adaptive` or `androidx.window` artifact) classify the current window into compact, medium, or expanded buckets. `rememberWindowAdaptiveInfo()` (from `androidx.compose.material3.adaptive`) is the current recommended API for querying the full adaptive context including window size and posture.
63
64	Check whether:
65	- major layout decisions are driven by window size classes rather than raw dp breakpoints
66	- `rememberWindowAdaptiveInfo()` or equivalent structured APIs are used at the root shell level
67	- breakpoints are not reinvented casually without reason
68	- navigation chrome and pane layout decisions are tied to structured size input
69	- fine-grained layout work sits underneath, rather than replacing, size-class strategy
70
71	Flag as a concern when:
72	- arbitrary pixel/dp thresholds replace standard size-class reasoning
73	- different parts of the app use incompatible breakpoint logic
74	- layout changes are too ad hoc to scale consistently
75	- window-size queries are scattered across many composables instead of hoisted to the shell
76
77	### 3. Navigation adaptation
78
79	Adaptive navigation should change with available space.
80
81	Check whether:
82	- bottom navigation, navigation rail, drawer, or other shell chrome are chosen intentionally based on window size
83	- current destination tracking remains stable while the chrome changes
84	- navigation adaptation is a shell concern rather than duplicated in every feature
85
86	Flag as a concern when:
87	- phone navigation chrome is forced onto large layouts without reason
88	- large-screen navigation is bolted on with special cases
89	- shell adaptation and route state are tightly tangled
90
91	### 4. Canonical layout choice
92
93	Android’s canonical layouts are proven patterns for common use cases.
94
95	Check whether the design should use:
96	- list-detail
97	- supporting pane
98	- feed-like or other canonical structures
99
100	Prefer canonical layouts when the product problem matches them.
101
102	Flag as a concern when:
103	- bespoke layouts re-solve a standard list-detail or supporting-pane problem poorly
104	- large-screen UI is over-customized without product value
105	- canonical multi-pane opportunities are missed
106
107	### 5. List-detail behavior
108
109	For master-detail style problems, review whether lis

People who liked this also viewed

6 picks

Type

kotlin-ui-adaptive-resources

56stars5forks

View on GitHub

How to install kotlin-ui-adaptive-resources?

mmiani/kotlin-kmp-claude-agent-skills/kotlin-ui-adaptive-resources

$npx -y skills add mmiani/kotlin-kmp-claude-agent-skills --skill kotlin-ui-adaptive-resources

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Adaptive UI and Resource Strategy
2
3	Use this skill when designing, implementing, or reviewing adaptive UI in a Compose-based project.
4
5	This skill is intentionally strict. Its purpose is to keep layouts resilient across display sizes, window sizes, orientations, fold states, and resizable environments while preserving clear UI architecture and avoiding fragile one-device assumptions.
6
7	## Primary goals
8
9	The adaptive strategy should optimize for:
10
11	- support for a wide range of display and window sizes
12	- structured layout changes rather than ad hoc breakpoints
13	- navigation chrome that adapts with available space
14	- correct use of canonical multi-pane layouts where appropriate
15	- resilience in split-screen, freeform, and desktop-style windowing
16	- resource and presentation decisions that stay configurable
17	- Compose layouts that remain understandable under adaptation pressure
18	- previewability and testability across adaptive states
19
20	Do not treat “works on my phone” as sufficient.
21	Adaptive UI should remain coherent when the window changes shape, size, or posture.
22
23	---
24
25	## Official defaults to prefer
26
27	Unless the project has a strong reason not to, prefer:
28
29	- responsive and adaptive UI that supports a wide range of screens and app window sizes
30	- window size classes as the primary high-level breakpoint system
31	- canonical layouts such as list-detail, feed, and supporting-pane when they fit the use case
32	- adaptive navigation patterns that switch chrome based on available space
33	- layouts that remain usable in multi-window mode and desktop-style windowing
34	- resource and presentation values that stay configurable rather than hard-coded
35	- Compose layouts whose modifier chains and measurement behavior remain explainable
36
37	---
38
39	## Review dimensions
40
41	### 1. Adaptive mindset and target environments
42
43	Check whether the design explicitly supports:
44
45	- phones
46	- tablets
47	- foldables
48	- ChromeOS / large-screen environments
49	- portrait and landscape
50	- resizable windows
51	- split-screen mode
52	- desktop windowing / freeform windows where applicable
53
54	Flag as a concern when:
55	- the design assumes one full-screen phone window shape
56	- large-screen behavior is just stretched phone UI
57	- resizable environments are ignored
58	- adaptation is deferred until after feature implementation
59
60	### 2. Window size class strategy
61
62	Window size classes are the default high-level tool for adaptive decisions. In Compose, `WindowWidthSizeClass` and `WindowHeightSizeClass` (from the `androidx.compose.material3.adaptive` or `androidx.window` artifact) classify the current window into compact, medium, or expanded buckets. `rememberWindowAdaptiveInfo()` (from `androidx.compose.material3.adaptive`) is the current recommended API for querying the full adaptive context including window size and posture.
63
64	Check whether:
65	- major layout decisions are driven by window size classes rather than raw dp breakpoints
66	- `rememberWindowAdaptiveInfo()` or equivalent structured APIs are used at the root shell level
67	- breakpoints are not reinvented casually without reason
68	- navigation chrome and pane layout decisions are tied to structured size input
69	- fine-grained layout work sits underneath, rather than replacing, size-class strategy
70
71	Flag as a concern when:
72	- arbitrary pixel/dp thresholds replace standard size-class reasoning
73	- different parts of the app use incompatible breakpoint logic
74	- layout changes are too ad hoc to scale consistently
75	- window-size queries are scattered across many composables instead of hoisted to the shell
76
77	### 3. Navigation adaptation
78
79	Adaptive navigation should change with available space.
80
81	Check whether:
82	- bottom navigation, navigation rail, drawer, or other shell chrome are chosen intentionally based on window size
83	- current destination tracking remains stable while the chrome changes
84	- navigation adaptation is a shell concern rather than duplicated in every feature
85
86	Flag as a concern when:
87	- phone navigation chrome is forced onto large layouts without reason
88	- large-screen navigation is bolted on with special cases
89	- shell adaptation and route state are tightly tangled
90
91	### 4. Canonical layout choice
92
93	Android’s canonical layouts are proven patterns for common use cases.
94
95	Check whether the design should use:
96	- list-detail
97	- supporting pane
98	- feed-like or other canonical structures
99
100	Prefer canonical layouts when the product problem matches them.
101
102	Flag as a concern when:
103	- bespoke layouts re-solve a standard list-detail or supporting-pane problem poorly
104	- large-screen UI is over-customized without product value
105	- canonical multi-pane opportunities are missed
106
107	### 5. List-detail behavior
108
109	For master-detail style problems, review whether lis

People who liked this also viewed

6 picks

Type