
Kotlin Concurrency Expert
- 553 installs
- 910 repo stars
- Updated July 27, 2026
- new-silvermoon/awesome-android-agent-skills
kotlin-concurrency-expert is an Android concurrency review skill that diagnoses and fixes Kotlin coroutines, flows, channels, and thread-safety issues for developers building concurrent mobile features.
About
kotlin-concurrency-expert is a skill from new-silvermoon/awesome-android-agent-skills for reviewing and remediating Kotlin Coroutines usage in Android codebases. It triages crashes, ANRs, memory leaks, race conditions, and incorrect state tied to coroutine scope or lifecycle handling. The workflow checks project setup including kotlinx-coroutines-android version and lifecycle integration, then applies structured concurrency, proper scoping, and modern best practices with minimal behavior changes. Developers reach for kotlin-concurrency-expert when asked to review concurrency, fix coroutine-related bugs, improve thread safety, or resolve lifecycle issues in Kotlin Android code. It targets production Android apps where async UI updates, Flow collectors, and Channel communication must stay lifecycle-safe.
- Specialized in Kotlin concurrency primitives including coroutines, Flow, and Channel patterns
- Helps avoid common pitfalls like context leaks, improper dispatchers, and race conditions
- Provides production-grade patterns used in modern Android apps
- Works seamlessly with Cursor, Claude Code, and other Android-focused agents
Kotlin Concurrency Expert by the numbers
- 553 all-time installs (skills.sh)
- +15 installs in the week ending Aug 4, 2026 (Skillselion tracking)
- Ranked #1,666 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
- Data as of Aug 4, 2026 (Skillselion catalog sync)
npx skills add https://github.com/new-silvermoon/awesome-android-agent-skills --skill kotlin-concurrency-expertAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 553 |
|---|---|
| repo stars | ★ 910 |
| Last updated | July 27, 2026 |
| Repository | new-silvermoon/awesome-android-agent-skills ↗ |
How do you fix Kotlin coroutine bugs in Android?
Get expert guidance on Kotlin coroutines, flows, channels, and thread-safe patterns when building concurrent Android features.
Who is it for?
Android developers debugging coroutine crashes, ANRs, lifecycle leaks, or thread-safety issues in Kotlin mobile codebases.
Skip if: Server-side Kotlin without Android lifecycle concerns, or projects not using kotlinx-coroutines for async work.
When should I use this skill?
A developer asks to review Kotlin concurrency, fix coroutine bugs, improve thread safety, or resolve Android lifecycle issues with flows or channels.
What you get
Remediated Android concurrency code with structured coroutine scopes, lifecycle-safe collectors, and resolved thread-safety or state bugs.
- Concurrency review findings
- Remediated coroutine and flow code
Files
Kotlin Concurrency Expert
Overview
Review and fix Kotlin Coroutines issues in Android codebases by applying structured concurrency, lifecycle safety, proper scoping, and modern best practices with minimal behavior changes.
Workflow
1. Triage the Issue
- Capture the exact error, crash, or symptom (ANR, memory leak, race condition, incorrect state).
- Check project coroutines setup:
kotlinx-coroutines-androidversion,lifecycle-runtime-ktxversion. - Identify the current scope context (
viewModelScope,lifecycleScope, custom scope, or none). - Confirm whether the code is UI-bound (
Dispatchers.Main) or intended to run off the main thread (Dispatchers.IO,Dispatchers.Default). - Verify Dispatcher injection patterns for testability.
2. Apply the Smallest Safe Fix
Prefer edits that preserve existing behavior while satisfying structured concurrency and lifecycle safety.
Common fixes:
- ANR / Main thread blocking: Move heavy work to
withContext(Dispatchers.IO)orDispatchers.Default; ensure suspend functions are main-safe. - Memory leaks / zombie coroutines: Replace
GlobalScopewith a lifecycle-bound scope (viewModelScope,lifecycleScope, or injectedapplicationScope). - Lifecycle collection issues: Replace deprecated
launchWhenStartedwithrepeatOnLifecycle(Lifecycle.State.STARTED). - State exposure: Encapsulate
MutableStateFlow/MutableSharedFlow; expose read-onlyStateFloworFlow. - CancellationException swallowing: Ensure generic
catch (e: Exception)blocks rethrowCancellationException. - Non-cooperative cancellation: Add
ensureActive()oryield()in tight loops for cooperative cancellation. - Callback APIs: Convert listeners to
callbackFlowwith properawaitClosecleanup. - Hardcoded Dispatchers: Inject
CoroutineDispatchervia constructor for testability.
Critical Rules
Dispatcher Injection (Testability)
// CORRECT: Inject dispatcher
class UserRepository(
private val ioDispatcher: CoroutineDispatcher = Dispatchers.IO
) {
suspend fun fetchUser() = withContext(ioDispatcher) { ... }
}
// INCORRECT: Hardcoded dispatcher
class UserRepository {
suspend fun fetchUser() = withContext(Dispatchers.IO) { ... }
}Lifecycle-Aware Collection
// CORRECT: Use repeatOnLifecycle
viewLifecycleOwner.lifecycleScope.launch {
viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
viewModel.uiState.collect { state -> updateUI(state) }
}
}
// INCORRECT: Direct collection (unsafe, deprecated)
lifecycleScope.launchWhenStarted {
viewModel.uiState.collect { state -> updateUI(state) }
}State Encapsulation
// CORRECT: Expose read-only StateFlow
class MyViewModel : ViewModel() {
private val _uiState = MutableStateFlow(UiState())
val uiState: StateFlow<UiState> = _uiState.asStateFlow()
}
// INCORRECT: Exposed mutable state
class MyViewModel : ViewModel() {
val uiState = MutableStateFlow(UiState()) // Leaks mutability
}Exception Handling
// CORRECT: Rethrow CancellationException
try {
doSuspendWork()
} catch (e: CancellationException) {
throw e // Must rethrow!
} catch (e: Exception) {
handleError(e)
}
// INCORRECT: Swallows cancellation
try {
doSuspendWork()
} catch (e: Exception) {
handleError(e) // CancellationException swallowed!
}Cooperative Cancellation
// CORRECT: Check for cancellation in tight loops
suspend fun processLargeList(items: List<Item>) {
items.forEach { item ->
ensureActive() // Check cancellation
processItem(item)
}
}
// INCORRECT: Non-cooperative (ignores cancellation)
suspend fun processLargeList(items: List<Item>) {
items.forEach { item ->
processItem(item) // Never checks cancellation
}
}Callback Conversion
// CORRECT: callbackFlow with awaitClose
fun locationUpdates(): Flow<Location> = callbackFlow {
val listener = LocationListener { location ->
trySend(location)
}
locationManager.requestLocationUpdates(listener)
awaitClose { locationManager.removeUpdates(listener) }
}Scope Guidelines
| Scope | Use When | Lifecycle |
|---|---|---|
viewModelScope | ViewModel operations | Cleared with ViewModel |
lifecycleScope | UI operations in Activity/Fragment | Destroyed with lifecycle owner |
repeatOnLifecycle | Flow collection in UI | Started/Stopped with lifecycle state |
applicationScope (injected) | App-wide background work | Application lifetime |
GlobalScope | NEVER USE | Breaks structured concurrency |
Testing Pattern
@Test
fun `loading data updates state`() = runTest {
val testDispatcher = StandardTestDispatcher(testScheduler)
val repository = FakeRepository()
val viewModel = MyViewModel(repository, testDispatcher)
viewModel.loadData()
advanceUntilIdle()
assertEquals(UiState.Success(data), viewModel.uiState.value)
}Reference Material
Related skills
How it compares
Choose kotlin-concurrency-expert over generic Kotlin skills when symptoms are Android-specific lifecycle, ANR, or coroutine-scope failures.
FAQ
What issues does kotlin-concurrency-expert handle?
kotlin-concurrency-expert triages coroutine-related crashes, ANRs, memory leaks, race conditions, and incorrect state in Android Kotlin code. It reviews flows, channels, scoping, and kotlinx-coroutines-android lifecycle integration.
Does kotlin-concurrency-expert change app behavior?
kotlin-concurrency-expert applies structured concurrency, lifecycle-safe scoping, and modern coroutine best practices while aiming for minimal behavior changes. Fixes target concurrency defects without broad refactors.