agentleFS
JetBrainsKnown publisherJetBrains/compose-multiplatform-core/AGENTS.md

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
  1. Very specific:

    if modules exists only in settings-fork.gradle, but not in settings.gradle, it may just contain build.gradle without build-fork.gradle

    line 22
  2. Distinctive:

    Read these files when working in the corresponding project parts:

    line 33
  3. Distinctive:

    When delegating, refer the subagent to those files too.

    line 37
  4. Distinctive:

    Do not create git commits unless explicitly requested.

    line 43
  5. Very specific:

    When investigating a build failure, save the build output to a temporary file and then use grep.

    line 49
  6. Distinctive:

    When to run the tests: when working on the tests, or fixing the implementation, or when asked explicitly.

    line 57
  7. Very specific:

    When applicable, use platform-specific gradle tasks to run the tests: desktopTest, iosSimulatorArm64Test, wasmJsBrowserTest, jsBrowserTest.

    line 62

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
AGENTS.md

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 in build.gradle and build-fork.gradle files
    • 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 in settings.gradle, it may just contain build.gradle without build-fork.gradle
    • iOS, desktop, JS, and WasmJS source sets, their combinations, and their corresponding test source sets
  • AOSP-only code:
    • Independent build infrastructure: settings.gradle, buildSrc, build.gradle, and ./gradle/libs.versions.toml
    • androidMain and its corresponding test source sets
    • *StubsMain source sets - created in the upstream AOSP repo to ensure commonMain compilation on the all Kotlin targets
    • iOS, desktop, JS, and WasmJS source sets for libraries and targets developed in AOSP

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.

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 commonTest folder. When it's possible, we add multiplatform tests to skikoTest. 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).

Download now (ZIP)

  • 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.

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.