Compose Skill
Seven skills that teach an agent to write Jetpack Compose and Compose Multiplatform in one architectural style
- 306 ★ on the repository
- Last commit
- MIT
Extended access
Why this level
- Following the skill, the agent runs shell check scripts and the new-feature scaffold script
- The check scripts can be installed into a project and wired into CI
Install
- Works in
Manual install
/plugin marketplace add Meet-Miyani/compose-skillThen run /plugin install compose-kit@compose-kit and restart Claude Code.
Access and checks
How we reviewExtended accessThe tool runs code or makes network calls and only reads external data.
- Following the skill, the agent runs shell check scripts and the new-feature scaffold script
- The check scripts can be installed into a project and wired into CI
This is third-party code. Review the repository files before installing.
What it does
Compose Skill, also called Compose Kit, is a set of seven skills for Jetpack Compose and Compose Multiplatform. The entry point is the compose skill with a short decision tree of about 1.3k tokens. It works out the kind of task and the area it touches, for example a new feature, a bug fix or a review. Then the agent opens only the reference files it needs. The other six skills split the areas. compose-architecture covers the module graph, the MVI contract on a shared BaseViewModel, Koin and Navigation 3. compose-feature takes a screen from contract to tests and can review. compose-ui collects rules for composables: the Route and Screen split, screen states, accessibility and adaptive layouts. compose-data owns the data layer on Ktor, Room and DataStore. compose-project sets up new projects, modules and CI. compose-platform handles shared code in commonMain, iOS interop and desktop and web targets. Project and feature templates ship with the skills, along with check scripts for CI.
Who it is for. For Android developers and Kotlin Multiplatform teams who build many screens with an agent and want one architecture.
Good fit when
- The agent writes a new Compose screen, and the MVI contract, navigation and tests must match the rest of the project
- You want a review of Compose code with findings split by severity and no file edits
- A Compose Multiplatform project is starting and needs modules, convention plugins, a version catalog and CI
- Shared code has to move into commonMain, with iOS wired through expect/actual
- Existing code needs to be brought in line with the kit's style without adding new screens or features
Not a fit when
- The work is Kotlin outside a Compose or Compose Multiplatform app: the compose skill states it is not meant for such code
- The team keeps another style, for example Hilt with MVVM, and does not plan to move: the kit will raise a migration as a separate item
- You only need a narrow Compose performance review: Compose Performance Skills in the catalog covers measurement and Baseline Profiles
- You need one short edit with no architecture decisions: seven skills and a decision tree are overkill for it
Example request
Add a profile settings screen in Compose: MVI contract, ViewModel, navigation and tests, in the style of the rest of the projectLimitations
The kit sets its own style: MVI on a shared BaseViewModel, Koin with annotations, Navigation 3. In a project with a different architecture you either accept that style or get only migration proposals from the kit.
The author tested the kit on five to seven models and found a weak spot himself. On conform tasks agents with the kit restructured code too much. In version 6.1 the rule "no new UI controls, screens or features" held in 8 of 10 checks, up from 2. Installing through npx skills needs Node 22.20 or newer, and gh skill needs GitHub CLI 2.90 or newer.
How to disable. Delete the seven skill folders from the project's .claude/skills/ or .agents/skills/, or from your agent's skills directory if you installed globally. The Claude Code plugin is disabled and removed through the /plugin command. Remove the compose line from AGENTS.md or CLAUDE.md too.
FAQ
How do I install Compose Skill in Claude Code?
For the plugin run `/plugin marketplace add Meet-Miyani/compose-skill`, then `/plugin install compose-kit@compose-kit` and restart Claude Code. The command from the agent instruction puts separate skills into the project's .claude/skills/, and with the `-g` flag it installs them globally.
How much context does the kit use?
The compose entry tree takes about 1.3k tokens and the whole kit about 127k. The agent reads one reference file per affected area, and in the v5 test 35 of 40 runs stayed under 20k tokens.
What happens if the project already uses Hilt and MVVM?
In a coherent codebase the kit follows your pattern: Hilt, MVVM, Navigation 2 or your own base class. It proposes a move to its own style separately, without mixing it into the current task.
Why does the kit include shell scripts?
They are 11 checks that catch style drift in CI, backed by 90 fixture tests. Install them into a project with `bash <skills dir>/compose-architecture/scripts/install-guards.sh <project>`.
Which agents does Compose Skill work with?
The author names Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, Gemini CLI and Antigravity. The project site has an install page for each, and the agent ID goes in the `-a` flag.
Discussion
No questions or reviews yet.
Related
SkillsDimillian Skills
Skills
A set of 16 engineering skills for agents: Apple platform work, macOS packaging, React performance, code review and refactoring
A skill set from the Kotlin team for agents: Java to Kotlin conversion, build migrations and correct use of backend frameworks
An agent reference for cross-platform desktop apps that feel native: eight tenets, four layers, a WebView survival guide and a 75-item ship audit
Official Unity skill set for agents: editor control, builds, 2D and 3D, UI, URP, audio, multiplayer and monetization
Builder Skills
Skills for agents
A set of small skills from Builder.io for agent work habits: visual plans and diff recaps, docs-first checks, cross-agent review and clean status updates
17 skills from MiniMax: frontend and backend, Android, iOS, Flutter, shaders, PDF, PPTX, XLSX and DOCX documents, plus music, voice and video generation
Comparison with similar tools
Entries that share the main search query, and how they differ.
| Entry | Official | Repository stars | Main difference |
|---|---|---|---|
| Compose Skill (this entry) | no | 306 | |
| Compose Performance Skills | no | 521 | 26 skills on Compose performance only, from measurement to Baseline Profiles |
| Awesome Android Agent Skills | no | 995 | a collection of skills for modern Android development without one architectural style |
README in short
The README opens with the author's test results and a list of the seven skills. It goes on to the flow from a request to the right files and install routes for different agents. The tables for v5, v6 and v6.1 rest on scores from two independent graders.
README badge
Original SKILL.md
--- name: compose description: >- Use this skill first for any Jetpack Compose or Compose Multiplatform task: a new feature or screen, a change to existing code, a bug fix, a review, making code follow the kit, project or build setup, or a question. It picks the task path and the exact kit files to read. Not for Kotlin work outside a Compose or CMP app. --- # Compose ## Every task - Verify before claiming done: run the checks named by the task path and report their result. - Make the smallest correct change; keep what works. - Explain the result in plain engineering reasons. - Build from the context you have; state assumptions. - Open only the files the tree names for your task kind and areas; open another reference only when a check fails or a named file sends you there. ## Question 0: Is the task clear enough to act? - Look in the prompt, then the code. - Clear enough: continue to Question 1. - A missing answer changes what gets built: ask at most 3 questions, each with a stated default. - No human can answer (CI or headless): proceed and list the assumptions. - In a kit project, never ask how the architecture should look. ## Question 1: What kind of task is it? - New feature or screen → 1. If adding to an existing project, use the `../compose-architecture/references/existing-projects.md` Choose tree; 2. read `../compose-feature/SKILL.md` as the main area; 3. scaffold with its new-feature script when applicable; 4. choose each area in Question 2; 5. run the feature checks and tests. - Change to existing code → 1. Find the affected code; 2. use the `../compose-architecture/references/existing-projects.md` Choose tree and keep its coherent pattern; 3. read the owning topic skill from Question 2; 4. make the smallest change; 5. run its checks and affected tests. Change only what the request names; list related gaps as follow-ups. - Bug fix → 1. Use the `../compose-architecture/references/existing-projects.md` Choose tree; 2. write a failing test that reproduces the bug using `../compose-feature/references/testing.md`; 3. read only the affected area in Question 2; 4. make the smallest fix; 5. show the test passing and run affected checks. - Review only → 1. Use the `../compose-architecture/references/existing-projects.md` Choose tree; 2. read `../compose-feature/references/review-mode.md` for severity; 3. inspect only the relevant area in Question 2; 4. report findings and what is sound; 5. make no edits. - Conform or fix after review → 1. Restructure only: keep behaviour, visible UI, navigation, persistence and public APIs exactly as they are; 2. do not add screens, controls, wiring, saved state or features the existing code lacks; list them as follow-ups in the answer; 3. when changing a constructor or signature, update every caller and test in the same change; 4. run the existing tests before and after; both runs must pass; 5. run the guards. Use the `../compose-architecture/references/existing-projects.md` Choose tree and `../compose-feature/references/review-mode.md` for severity. - Project, module or build setup → 1. For existing code, use the `../compose-architecture/references/existing-projects.md` Choose tree; 2. read `../compose-project/SKILL.md`; 3. choose the build area in Question 2; 4. make the change; 5. run project checks and affected build/tests. - Question or explanation → 1. For existing code, use the `../compose-architecture/references/existing-projects.md` Choose tree; 2. identify the area in Question 2; 3. read only the file holding the fact; 4. answer with evidence and state any uncertainty. ## Question 2: Which area does it touch? Read the area's SKILL.md only for the task's main area; for every other area, read only its one reference. - UI → `../compose-ui/references/ux-states.md`; if this is the task's main area, also `../compose-ui/SKILL.md`. - Adaptive layout (tablet, foldable, desktop or browser window, window size) → `../compose-ui/references/adaptive-layouts.md`; if this is the task's main area, also `../compose-ui/SKILL.md`. - State and lifetime → `../compose-architecture/references/state-ownership.md`; if this is the task's main area, also `../compose-architecture/SKILL.md`. - Errors → `../compose-architecture/references/error-handling.md`; if this is the task's main area, also `../compose-architecture/SKILL.md`. - Navigation → `../compose-architecture/references/navigation.md`; if this is the task's main area, also `../compose-architecture/SKILL.md`. - Data storage → `../compose-data/references/datastore.md`; if this is the task's main area, also `../compose-data/SKILL.md`. - Network → `../compose-data/references/networking-ktor.md`; if this is the task's main area, also `../compose-data/SKILL.md`.