compose-multiplatform-core
AGENTS.md674 starsChanged 47 days agoApache-2.0View on GitHub
This is a fork of androidx monorepo dedicated for Compose Multiplatform (CMP) work. The purpose of the fork is to provide missing Kotlin targets for modules registered in JetBrainsPublication.kt (mainly Compose-related). Generally we add support for iOS, Web and Desktop. and we do not validate, build and test Android. The full list of which targets are not maintained is defined in the associated build-fork.gradle, in the redirect block. The primary focus of Compose Multiplatform is the ./compose directory. Most often,…
We split this AGENTS.md into the rules it gives an agent
7 rules. About 0 are common, 4 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 22
if modules exists only in settings-fork.gradle, but not in settings.gradle, it may just contain build.gradle without build-fork.gradle
- Distinctive: line 33
Read these files when working in the corresponding project parts:
- Distinctive: line 37
When delegating, refer the subagent to those files too.
- Distinctive: line 43
Do not create git commits unless explicitly requested.
- Very specific: line 49
When investigating a build failure, save the build output to a temporary file and then use grep.
- Distinctive: line 57
When to run the tests: when working on the tests, or fixing the implementation, or when asked explicitly.
- Very specific: line 62
When applicable, use platform-specific gradle tasks to run the tests: desktopTest, iosSimulatorArm64Test, wasmJsBrowserTest, jsBrowserTest.
≈ “Common” is an estimate: at least 1 in 5 of the 36,368 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Repository guidance
This is a fork of androidx monorepo dedicated for Compose Multiplatform (CMP) work.
The purpose of the fork is to provide missing Kotlin targets for modules registered in JetBrainsPublication.kt (mainly Compose-related).
Generally we add support for iOS, Web and Desktop. and we do not validate, build and test Android. The full list of which targets are not maintained is defined in the associated build-fork.gradle, in the redirect block.
The primary focus of Compose Multiplatform is the ./compose directory.
Most often, we work in ./compose/ui/ui and ./compose/foundation/foundation.
Also, we publish klibs for some other libraries: ./navigation, ./navigation3.
The repo contains both the original AOSP code and additional fork-only code.
The repo supports two modes:
- The original AOSP mode (
aospComposeProject.sh), with the original set of modules, and fork mode, with a much smaller set of modules and its own build infrastructure. - Fork mode is the primary mode and is used by default; AOSP mode is rarely needed.
- Common code, used by both modes:
commonMain,commonTest, and other source sets defined both inbuild.gradleandbuild-fork.gradlefiles- Received from the upstream AOSP repo
- Fork-only code:
- Independent build infrastructure:
settings-fork.gradle,buildSrc-fork,build-fork.gradle, and./gradle/libs-fork.versions.toml - if modules exists only in
settings-fork.gradle, but not insettings.gradle, it may just containbuild.gradlewithoutbuild-fork.gradle - iOS, desktop, JS, and WasmJS source sets, their combinations, and their corresponding test source sets
- Independent build infrastructure:
- AOSP-only code:
- Independent build infrastructure:
settings.gradle,buildSrc,build.gradle, and./gradle/libs.versions.toml androidMainand its corresponding test source sets*StubsMainsource sets - created in the upstream AOSP repo to ensurecommonMaincompilation on the all Kotlin targets- iOS, desktop, JS, and WasmJS source sets for libraries and targets developed in AOSP
- Independent build infrastructure:
Instruction files
A session may not automatically load instructions in descendant directories. Read these files when working in the corresponding project parts:
./compose/AGENTS.md./compose/material3/material3/AGENTS.md
When delegating, refer the subagent to those files too. Note: Since this a fork, new instruction files might get merged from the upstream. Ignore AOSP-specific instructions / gradle tasks / checks / verifications (majority of them are about Android)
General instructions
Git
- Do not create git commits unless explicitly requested.
Gradle
- Running Gradle tasks:
- The output is usually very large and most of it is irrelevant. Unless it's necessary, avoid reading a full output by using
grep,tail, etc. - Also, use
--console=plain - When investigating a build failure, save the build output to a temporary file and then use
grep.
- The output is usually very large and most of it is irrelevant. Unless it's necessary, avoid reading a full output by using
Introducing new changes
- In this fork we avoid introducing code changes in the common code (see above). Before changing any code in them, notify and request an approval when such a change is necessary.
- API: Unless a feature is intended for GA, avoid introduction of public API changes.
Changes Verification
- Running the tests every time might take too long. Compile the tests before running. Choose the relevant task:
compileTestKotlinIosArm64,compileTestDevelopmentExecutableKotlinJs,compileTestDevelopmentExecutableKotlinWasmJs,desktopTestClasses - When to run the tests: when working on the tests, or fixing the implementation, or when asked explicitly.
- Which tests to run: for platform-specific changes run only platform tests. Otherwise, run the tests for all affected platforms.
Testing
- We do not add tests in the
commonTestfolder. When it's possible, we add multiplatform tests toskikoTest. Platform-specific tests should be added in the corresponding folder:webTest,desktopTest,jvmTest,iosTest,iosInstrumentedTest. - When applicable, use platform-specific gradle tasks to run the tests:
desktopTest,iosSimulatorArm64Test,wasmJsBrowserTest,jsBrowserTest. Also clean the tests results before running. Example:./gradlew :compose:ui:ui:cleanAllTests :compose:ui:ui:desktopTest --no-build-cache | tail -n 10. Allow a reasonable timeout (at least 5 minutes).
Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.
Of the AGENTS.md files we read, the 28,693 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository4 other files it gives its agents.
- compose/AGENTS.mdAGENTS.md
- navigation3/AGENTS.mdAGENTS.md
- navigation/AGENTS.mdAGENTS.md
- room3/AGENTS.mdAGENTS.md
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

