compose-skill: an agent skill that makes AI coding tools check Jetpack Compose against real androidx source

The failure mode compose-skill was built around

AI coding tools produce Compose that compiles. The README frames the problem as details rather than syntax: incorrect `remember` usage, unstable recompositions, broken modifier ordering, deprecated navigation patterns, and APIs that do not exist. A model that has read a lot of Compose from mixed versions will happily suggest a string route in a codebase that has moved to type-safe routes, or reach for `remember { mutableStateOf() }` where `derivedStateOf` or `rememberSaveable` is the correct primitive. None of that breaks the build.

The intended user is an Android or Compose Multiplatform developer who already runs an agent inside their editor or terminal and wants its suggestions grounded in the actual library rather than in a plausible reconstruction of it. The README's own framing is blunt: "not vibes." That is the claim to evaluate, and it is testable, because the repository ships the source files the agent is supposed to check against.

What actually ships: 24 guides and 6 source files

The skill is two payloads. The first is 24 reference guides covering state management, view composition, performance, navigation, animation, lists and scrolling, side effects, modifiers, theming, accessibility, CompositionLocals, deprecated patterns, an experimental Styles API, design-to-code, a production crash playbook, Compose Multiplatform, platform specifics for Desktop, iOS and Web/WASM, TV Compose, Material 3 motion, atomic design, Paging 3, and a Nav 2 to Nav 3 migration.

The second payload is 6 source code files taken from `androidx/androidx` and `compose-multiplatform-core`. This is the part that distinguishes the project from a prompt library. A guide can be written from memory and be wrong; a source file is the library's own code, so the agent has something to check a suggested parameter list against.

The repository layout supports this: `skills/` holds the skill content, `docs/` holds installation and migration notes, and there is a `verify-claims/` directory alongside `scripts/` and a Gradle build (`build.gradle.kts`, `buildSrc/`, `gradlew`). The README does not describe what `verify-claims/` does, so treat the guides as the product and the build files as tooling you would have to read before relying on them.

Installing compose-skill and checking it loaded

The README points at `docs/INSTALL.md` for per-host instructions and says the skill is distributed as a plugin. For Claude Code the two commands are a marketplace add followed by a plugin install:

/plugin marketplace add aldefy/compose-skill
/plugin install compose-expert

The README states setup takes about five minutes. After the install, the skill registers as `compose-expert`, so the name to look for in your host's plugin list is not the repository name.

Copilot CLI uses a single command:

copilot plugin install aldefy/compose-skill

Codex CLI is listed as a manual install, with `docs/INSTALL.md` as the reference. The README does not reproduce those steps, so read the file rather than guessing at a command. If you already installed an earlier version by hand, `docs/MIGRATION.md` covers the move to the plugin layout.

Updates arrive as GitHub Releases with migration notes. The two documented update commands are:

/plugin update

copilot plugin update aldefy/compose-skill

For a first real use, open a file with a `LazyColumn` that lacks a `key {}` and ask the agent to review it. The README's comparison table claims the skill applies `key {}` on lists and picks the right state primitive per situation. That is the behaviour to check, and it is checkable in one prompt.

Where the skill is the wrong tool

The install surface is uneven, and that is the first real limitation. Claude Code and Copilot CLI get explicit commands in the README; Codex CLI is deferred to a document the README does not inline. If your team standardises on Codex CLI and you want a reproducible setup, you are reading `docs/INSTALL.md` before you can decide anything.

The second limitation is scope. This is a Compose skill. Nothing in the README claims guidance for Gradle configuration beyond the build files in the repository, for Kotlin coroutines outside Compose effect handling, for XML view systems, or for server-side work. A team on a mixed XML and Compose codebase gets help with one half.

The third is the nature of the artefact. The README's comparison table is a set of claims about what the agent does with the skill installed. It is not a test report, and the repository does not publish one. The 6 source files are a sample of two large repositories, not a vendored copy of the libraries, so the agent can check against them and still be wrong about an API they do not cover. The README also does not document a rollback path if a new release changes behaviour you depended on, beyond the migration notes attached to releases.

Against a plain prompt or a general-purpose agent skill

The obvious alternative is a system prompt you write yourself: a paragraph telling the model to prefer `derivedStateOf`, to put `clickable` before `padding`, and to use type-safe routes. That costs nothing and needs no install. The difference is maintenance. A prompt you write drifts as Compose and Compose Multiplatform move; the README ties the skill to Jetpack Compose 1.7+, Compose Multiplatform 1.8+ and Kotlin 2.0+, and the project publishes versioned releases, with v2.4.0 on 2026-07-08, following v2.3.1 and v2.3.0 on 2026-05-03. You are trading your own upkeep for someone else's release cadence.

The second alternative is a general agent skill or MCP server for Android development that covers build, testing and Compose together. compose-skill is narrower and deeper on one library, which is the right shape if Compose correctness is the recurring problem and the wrong shape if your pain is elsewhere in the toolchain. The topic list points at the intended niche: `jetpack-compose`, `compose-multiplatform`, `androidx`, `material3`.

One honest note on the repository: the README badge says MIT while the repository metadata reports NOASSERTION. That mismatch is worth resolving before you redistribute anything.

Upgrade cost and licence position

The last push was on 2026-07-23, and the most recent release is v2.4.0 from 2026-07-08, so the project is not dormant. It is also not something you install once and forget: releases carry migration notes, which implies behaviour changes between versions, and the plugin update commands are the supported path. Budget a re-read of the release notes at each update, particularly if your team has tuned prompts around the skill's output.

The licence situation needs care. The README carries an MIT badge and links to a `LICENSE` file, but the repository metadata reports NOASSERTION rather than MIT. NOASSERTION means the automated classifier could not confirm a standard licence from the files it inspected. That is a signal to open `LICENSE` and read it, not a statement that the project is unlicensed. If you vendor the skill into an internal tool or redistribute it, resolve that discrepancy first. Nothing here is legal advice.

Editorial conclusion

Adopt compose-skill if your AI tool already writes Compose and you keep correcting state primitives, modifier order and navigation APIs by hand, and if you work in Claude Code or Copilot CLI where the plugin commands are published. Skip it if you need a documented Codex CLI install path today, or if you expect the skill to fix code you have not reviewed. Before trusting it, open the skills/ directory and read one reference guide against the androidx source file it cites.

Frequently asked questions

Official sources

1. aldefy/compose-skill on GitHub
2. Issues
3. README
4. Releases