Agent Skills › chrisbanes/skills › kotlin-concurrency-and-flow

kotlin-concurrency-and-flow

GitHub

指导 Kotlin 协程作用域所有权、生命周期管理及 Flow 状态/事件建模的最佳实践，确保异步工作具备明确的所有者和可观测的取消行为。

skills/kotlin-concurrency-and-flow/SKILL.md chrisbanes/skills

Trigger Scenarios

审查 Kotlin 协程作用域所有权处理 StateFlow/SharedFlow 状态更新解决 runBlocking 或 init launch 问题设计非恢复性事件与可恢复状态的边界

Install

npx skills add chrisbanes/skills --skill kotlin-concurrency-and-flow -g -y

More Options

Use without installing

npx skills use chrisbanes/skills@kotlin-concurrency-and-flow

指定 Agent (Claude Code)

npx skills add chrisbanes/skills --skill kotlin-concurrency-and-flow -a claude-code -g -y

安装 repo 全部 skill

npx skills add chrisbanes/skills --all -g -y

预览 repo 内 skill

npx skills add chrisbanes/skills --list

SKILL.md

Frontmatter

{
    "name": "kotlin-concurrency-and-flow",
    "description": "Use when writing or reviewing Kotlin coroutine scope ownership, init launches, non-suspending launch APIs, runBlocking, cancellation, StateFlow, SharedFlow, Channel, stateIn, SharingStarted, state updates, or one-shot events."
}

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

Identify each coroutine owner, cancellation boundary, producer, consumer, durable state, and transient event.
Select a scope whose lifecycle owns the work; do not retain arbitrary scopes or hide unstructured launches behind non-suspending APIs.
Model renderable, current data as state and imperative one-shot work as an event only when its loss and replay behavior are explicitly acceptable.
Choose Flow sharing and buffering semantics from the producer and consumer lifetimes rather than from a default.
Read the focused reference for the material concern below.
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

Signal	Read
Stored `CoroutineScope`, `init { launch }`, fire-and-forget API, `runBlocking`, broad catch, or cancellation boundary	Structured concurrency
`StateFlow`, `SharedFlow`, `Channel`, `stateIn`, `SharingStarted`, `.value`, state updates, sentinel values, or one-shot events	Flow state and events
Compose collection or UI effect handling	Compose state and effects

RED/GREEN agent scenarios

RED stores a long-lived CoroutineScope in a service and launches from arbitrary callers. GREEN makes ownership and cancellation follow a defined lifecycle boundary.
Novel case: a screen needs replayable loading state and non-replayable navigation. GREEN uses distinct state and event contracts with documented delivery semantics.
Counterexample: a suspend function already has a caller-owned scope. GREEN does not add an internal scope merely to make the API look asynchronous.