Kotlin prompts for Android, coroutines and Compose

The best Kotlin prompts state your Kotlin version and platform (Android, JVM server or Multiplatform), paste the real code and Gradle or compiler output, and ask for one specific change. Below are 12 Kotlin prompts for ChatGPT, Claude, Claude Code and Codex covering idiomatic Kotlin, coroutines and Flow, Jetpack Compose, tests and builds.

For general jobs such as explaining code or writing a regex, see the coding prompts. For JVM code you are keeping in Java, see the Java prompts. The prompts here are specific to Kotlin and Android.

How to use these prompts

Copy a prompt, replace each blank in double braces, or keep the default after the colon. {{kotlin_version:2.4}} means the model should assume Kotlin 2.4 unless you change it.

Three habits make the answers better:

• State versions. The Kotlin releases page lists 2.4.21 as the latest release, from 8 October 2026. Compose and AndroidX versions matter too, because APIs move between releases.
• Paste the real error. Gradle and compiler errors carry module names, file paths and line numbers the model can work from.
• Ask how coroutines stop. For any coroutine the model starts, ask which scope owns it and what cancels it.

In an agent, let it run the Gradle tasks itself and report the output.

How do you write idiomatic Kotlin with AI?

1. Review code for Kotlin idioms

For Kotlin that reads like Java with different syntax.

Review this Kotlin code for idiomatic style, targeting Kotlin {{kotlin_version:2.4}}.

Check: val over var, data classes for plain data, null handling with ?. ?: and let instead of !!, when expressions instead of if/else chains, extension functions where they make call sites clearer, scope functions used only where they help readability, and collection operations instead of manual loops.

For each issue, show before and after with one sentence on why. Do not change public API signatures unless I agree.

{{code}}

2. Convert Java to Kotlin with correct nullability

For moving a class from Java. The Kotlin Java interop docs explain that Java types become platform types: "Null-checks are relaxed for such types, so that safety guarantees for them are the same as in Java."

Convert this Java class to idiomatic Kotlin.

{{code}}

- For every field, parameter and return type, decide nullable or non-null based on how the code actually uses it, and list each decision with a one-line reason.
- Keep the public API callable from Java: add @JvmStatic, @JvmOverloads or @JvmField only where Java callers need them, and say which.
- Use a data class only if equals and hashCode semantics stay the same.
- Do not use !! anywhere. If a value can really be null, handle it.

Point out any Java behavior that changes in Kotlin, such as checked exceptions or default visibility.

3. Model UI state with a sealed interface

For a screen tracked with several nullable fields and Bool flags that can contradict each other.

This Kotlin code tracks {{feature:a search screen}} with separate nullable fields and Boolean flags:

{{code}}

Redesign it with a sealed interface so impossible states cannot be represented, for example Loading, Success with data, Empty and Error with a message.

Show the sealed type, how the ViewModel produces it, and how a Compose screen renders each case with an exhaustive when. Explain any state you added or merged.

How do you use coroutines and Flow correctly?

4. Make a repository main-safe

For data code that blocks or hardcodes dispatchers. Android's coroutine best practices say: "Suspend functions should be main-safe, meaning they're safe to call from the main thread."

Refactor this Kotlin repository so every suspend function is safe to call from the main thread.

{{code}}

- Inject the CoroutineDispatcher through the constructor instead of hardcoding Dispatchers.IO or Dispatchers.Default, with a sensible default value.
- Move blocking work inside withContext with the injected dispatcher.
- Expose immutable types to callers (StateFlow, not MutableStateFlow).
- Keep the public function signatures the same unless a change is needed, and say why.

Add a unit test that injects a test dispatcher.

5. Fix leaking or uncancellable coroutines

For work that keeps running after a screen closes, or a GlobalScope you inherited. The same Android guide says cancellation is cooperative and warns: "don't consume exceptions of type CancellationException".

Review this Kotlin coroutine code for leaks and cancellation bugs.

{{code}}

Check for:
- GlobalScope or scopes created and never cancelled.
- Loops or long work that never check for cancellation (ensureActive, yield, or a suspending call).
- catch blocks that catch Exception or Throwable and swallow CancellationException.
- Work that should outlive the screen but is launched in viewModelScope or lifecycleScope.

For each problem, explain what happens at runtime and show the fix. For every coroutine in the fixed code, name the scope that owns it and what cancels it.

6. Expose screen state from a ViewModel with StateFlow

For a ViewModel that exposes suspend functions or mutable state to the UI. Android's guidance is that the ViewModel should create coroutines rather than expose suspend functions for business logic.

Rewrite this Android ViewModel so it exposes one StateFlow of UI state and plain functions for user events.

{{code}}

- Keep a private MutableStateFlow and expose it as StateFlow.
- Launch work in viewModelScope inside the event functions.
- Catch expected exceptions such as {{expected_errors:IOException}} inside the coroutine and map them to an error state; rethrow CancellationException.
- Combine the repository flows with {{flows:the user flow and the settings flow}} if the screen needs both.

Show how a Compose screen collects the state with collectAsStateWithLifecycle.

How do you build Jetpack Compose screens with AI?

7. Build a Compose screen with state hoisting

For a new screen. The Compose state docs describe hoisting as replacing a state variable with a value parameter and an onValueChange event, and call the result "unidirectional data flow".

Build a Jetpack Compose screen for {{feature:editing a user profile}}.

- Split it into a stateful screen composable that talks to the ViewModel and stateless composables that take values and event lambdas.
- Hoist each piece of state to the lowest common parent that reads it and the highest level that changes it.
- Use rememberSaveable for UI-only state that must survive rotation, such as text being typed.
- Use Material 3 components and typography from MaterialTheme.
- Add a @Preview for each stateless composable with sample data.

Do not add libraries beyond Compose and the AndroidX lifecycle libraries. List any assumption about the data model.

8. Fix recomposition performance

For a list that janks or a screen that recomposes on every frame. The Compose performance best practices cover remember with keys, stable lazy list keys, derived state, deferring reads and avoiding backwards writes.

This Compose screen {{symptom:stutters when scrolling a long list}}.

{{code}}

Check, in this order:
1. Expensive work in the composable body that should be cached with remember and the right keys.
2. LazyColumn or LazyRow items without a stable, unique key, or keys based on index or hashCode.
3. State that changes often but only matters past a threshold, which should use derived state.
4. Frequently changing state read during composition that could be read in a lambda modifier instead (layout or draw phase).
5. Writes to state after it was read in the same composition.

For each finding, show the fix and explain how I can measure whether recompositions actually dropped.

9. Fix state that is lost on rotation or process death

For a form that clears when the device rotates or the app comes back from the background.

In my Compose app, {{symptom:the form clears when I rotate the device}}.

{{code}}

Explain where each piece of state lives (remember, rememberSaveable, ViewModel, SavedStateHandle, or persistent storage) and what survives a recomposition, a configuration change and process death.

Move each piece of state to the right place, show the change, and tell me how to test process death on an emulator.

How do you test Kotlin code with AI?

10. Test a ViewModel that uses coroutines

For ViewModel and repository tests. The Android coroutine testing guide says runTest "will automatically skip any delays in coroutines," and that local unit tests should replace the Main dispatcher with Dispatchers.setMain.

Write unit tests for this ViewModel using kotlinx-coroutines-test and {{framework:JUnit 4}}.

{{code}}

- Wrap tests in runTest.
- Replace Dispatchers.Main with a test dispatcher in a reusable JUnit rule, and reset it after each test.
- Use a fake repository, not a mocking library, unless I say otherwise.
- Cover: initial state, success, each error path, and cancellation.
- Assert on the StateFlow values in order.

Explain when you chose StandardTestDispatcher or UnconfinedTestDispatcher and why.

How do you keep a Kotlin build healthy?

11. Migrate from kapt to KSP

For slow builds that still use kapt. Android's KSP migration guide says KSP is "up to 2x faster" and that "Kapt is now in maintenance mode."

Migrate this Android project from kapt to KSP.

Top-level build.gradle.kts:
{{root_build_file}}

Module build.gradle.kts files that use kapt:
{{module_build_files}}

1. Add the com.google.devtools.ksp plugin with a KSP release that supports my Kotlin version, {{kotlin_version:2.4.21}}, and say where you checked compatibility.
2. For each kapt dependency, say whether the library ships a KSP processor in the same artifact, a different artifact, or none.
3. Show the changed build files.
4. Remove the kapt plugin only from modules with no kapt dependencies left, and flag modules that must keep it (for example, Data Binding).

12. Fix a Gradle build error

For a red build after a dependency or Kotlin version bump.

My Android build fails after {{change:upgrading Kotlin and Compose}}.

Error output (the first error and its cause, not the whole log):
{{error}}

Relevant build files and the version catalog (libs.versions.toml if I use one):
{{build_files}}

Explain what the error means, which dependency or plugin causes it, and the smallest version change or configuration fix. If two libraries need incompatible versions, say so and give the options. Do not suggest disabling checks to make the build pass.

What should you check before you accept the answer?

AI-written Kotlin tends to fail in the same few places:

• !! and platform types. Search the diff for !! and for Java calls whose result is used without a null decision.
• Swallowed cancellation. Look for catch (e: Exception) around suspending calls that does not rethrow CancellationException.
• Unowned coroutines. Every launch should sit in a scope with a clear owner. GlobalScope should not appear.
• Real builds. Run the tests and the build yourself, or have an agent run them and paste the output.

How do you keep your best Kotlin prompts?

Once a prompt becomes a habit, turn it into a skill so Claude Code or Codex uses it without being asked. The coroutine leak review and the Compose performance prompts are good first candidates. Paste one into the free SKILL.md generator, which runs in the browser with no sign-up, and it becomes a valid SKILL.md. For tests in general, see the unit test prompts.

To keep prompts like these close, save them in Kipt. Your library lives as Markdown in a private GitHub repo you own, each blank stays fillable when you copy, and Cmd+K finds any prompt by name or tag. If you build the iOS side too, see the Swift prompts, or the Flutter prompts for one codebase on both platforms.