mcpField
K
kotlin-concurrency-and-flow

kotlin-concurrency-and-flow

github.com/chrisbanesDevelopment1.1k1.1k installsUpdated 1d ago
Repository

About kotlin-concurrency-and-flow

A coding skill for reviewing and designing Kotlin coroutine and Flow behavior. It guides decisions about ownership, cancellation, state, events, sharing, and buffering.

Key features

  1. 01Trace coroutine ownership and cancellation
  2. 02Preserve suspend API contracts
  3. 03Choose Flow state and event semantics
  4. 04Route topics to focused references

Use cases

  1. 01Reviewing coroutine lifecycle and failure handling
  2. 02Choosing delivery semantics for one-shot events
  3. 03Selecting Flow sharing and buffering behavior

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/chrisbanes/skills --skill kotlin-concurrency-and-flow

After installing, type/kotlin-concurrency-and-flowin Claude Code to confirm it loaded.

Bundled filesreferences/flow-state-events.mdreferences/structured-concurrency.md

Details

From the project README

Kotlin concurrency and Flow

Core principle

Give asynchronous work an explicit owner and lifetime, then model durable state and transient events with primitives whose delivery and replay semantics match the product contract.

Procedure

  1. Identify each coroutine owner, cancellation boundary, producer, consumer, durable state, and transient event.
  2. Before changing an API, compare its existing caller-visible contract with the required owner and lifetime. If a suspend API already gives its caller cancellation, result, and failure ownership, finish with no change; do not add a scope, launch, callback, or deferred wrapper merely for convenience.
  3. Select a scope whose lifecycle owns the work; do not retain arbitrary scopes or hide unstructured launches behind non-suspending APIs.
  4. Model renderable, current data as state and imperative one-shot work as an event only when its loss and replay behavior are explicitly acceptable. Ask whether one consumer handles each event or every active consumer must receive it. A Channel hands each event to one consumer; a configured SharedFlow broadcasts to active consumers. If that consumer contract is unknown, state both options and the decision needed before choosing one. For a one-consumer navigation handoff that must survive a collector gap, choose a bounded Channel(Channel.BUFFERED) (not UNLIMITED) exposed as receiveAsFlow(); do not preserve a replay-zero SharedFlow after identifying event loss as the defect.
  5. Choose Flow sharing and buffering semantics from the producer and consumer lifetimes rather than from a default.
  6. Read the focused reference for the material concern below.
  7. Finish when cancellation, restart, replay, and failure behavior are all observable from the public API and no caller must guess who owns the work.

Topic router

SignalRead
Stored CoroutineScope, raw Thread or Executor work, init { launch }, fire-and-forget API, runBlocking, broad catch, or cancellation boundaryStructured concurrency
StateFlow, SharedFlow, Channel, stateIn, SharingStarted, .value, state updates, sentinel values, or one-shot eventsFlow state and events
Running Gradle to validate a changeGradle run; never raw ./gradlew
Compose collection or UI effect handlingCompose state and effects

Comments

Markdown supported