Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/ashtanko/compose-android-template/compose-state-hoistingnpx skills add ashtanko/compose-android-template --skill compose-state-hoistinggit clone --depth 1 https://github.com/ashtanko/compose-android-templateWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/ashtanko/compose-android-template/compose-state-hoisting)<a href="https://agentmods.dev/skills/ashtanko/compose-android-template/compose-state-hoisting"><img src="https://agentmods.dev/badge/skills/ashtanko/compose-android-template/compose-state-hoisting.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00045 | $0.01345 |
| Opus 5 | $0.00023 | $0.00673 |
| Sonnet 5 | $0.00009 | $0.00269 |
| Haiku 4.5 | $0.00005 | $0.00135 |
Grade A, and why
compose-state-hoisting scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 5d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 136 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Compose state hoisting
Core principle
Hoist state only as far as the logic needs it. Keep simple UI element state local, move shared UI element state to the lowest common composable owner, extract a plain state holder when UI-only behavior becomes a concept, and use a screen state holder when business logic or app data is involved.
Decision guide
| Situation | Owner |
|---|---|
| One composable reads/writes simple state | Keep local with remember / rememberSaveable |
| Sibling or parent composables need to read/write it | Hoist state and events to their lowest common composable ancestor |
| Related UI element state plus UI logic is making a composable hard to read, preview, or test | Extract a plain state holder class remembered in composition |
| Repository calls, persistence, business rules, or screen UI state production are involved | Use a screen-level state holder such as a ViewModel or component |
UI element state includes things like expansion, sheet visibility, scroll position, focus, text field editing state, selection, and animation/interaction state. Screen UI state is app data prepared for display.
If UI element state is an input to business logic, it may need to live in the screen state holder too. For example, text used to query repository-backed suggestions belongs with the state holder that produces those suggestions.
Plain state holder trigger
Extract a plain state holder when several of these are true:
- Multiple related
remembervalues are coordinated by the same callbacks. - Scroll, focus, text, selection, or sheet state needs named operations such as
clear,submit,jumpToTop, oropenFilters. - Derived UI flags are scattered through the composable.
- Child composables receive mechanics they do not conceptually own.
- Previews or tests must drive a long sequence of UI details to check one behavior.
- Helper functions need many state parameters just to keep the composable readable.
Do not extract for one boolean, one text field, or trivial show/hide logic. Ceremony is not separation of concerns.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 5d ago First seen · 136 lines · 45 tokens per session scan A b2bde7087704
compose-state-hoisting is a skill published in the GitHub repository ashtanko/compose-android-template (10 stars, last pushed yesterday), licensed MIT. It adds 45 tokens to every session and 1,345 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
sceneview-ios
Build 3D and AR apps on Apple platforms (iOS, macOS, visionOS) with SceneViewSwift — the SwiftUI wrapper around RealityKit. Use whenever the user asks for "3D in SwiftUI", "AR with ARKit in SwiftUI", a model viewer for iOS, or any Apple-platform 3D/AR app where the dependency is the SceneViewSwift Swift Package from…
sceneview
Build 3D and AR apps with the SceneView SDK in Jetpack Compose, SwiftUI (iOS/macOS/visionOS via SceneViewSwift), Web (Filament.js), Flutter and React Native. Use whenever the user asks for "3D in Compose", "AR with ARCore in Compose", a model viewer, or any cross-platform 3D/AR app where the dependency is…
compose-animations
Use when writing or reviewing Jetpack Compose motion: visibility enter/exit, animating one property toward a target, color or size transitions, multiple properties from one state, switching composable content, or choosing between AnimatedVisibility, animateAsState, rememberTransition, AnimatedContent, and Crossfade.
compose-focus-navigation
Use when writing or reviewing Jetpack Compose UI for TV, keyboard, desktop, accessibility focus, D-pad navigation, FocusRequester, focusProperties, key events, or initial focus behavior.
compose-state-and-effects
Use when writing or reviewing Jetpack Compose state ownership, remember state, state hoisting, screen state holders, LaunchedEffect, DisposableEffect, SideEffect, Flow collection, navigation, snackbar, analytics, or focus requests.
compose-component-design
Use when designing or reviewing reusable Jetpack Compose component APIs with modifier parameters, root layout placement, caller-provided variable content, primitive content parameters, optional content, or boolean shape flags.