using-chrisbanes-skills

name	using-chrisbanes-skills
description	Use when debugging, benchmarking, or profiling leads into Kotlin or Jetpack Compose source before the cause is known, or when one task spans multiple Kotlin or Compose concerns, especially plain Kotlin Flow or navigation delivery plus sealed branching.

Using chrisbanes skills

Core principle

Route by the decision the code needs, not by the number of APIs mentioned. Load one cluster when its shared procedure owns the concern; add a specialist only when its independent behavior changes the same work.

Routing procedure

1. Read the task and the Kotlin source that makes the concern concrete.
2. If one focused skill clearly matches, load it directly and stop routing.
3. Before loading a Compose skill, point to a concrete Compose API or composable in the inspected source, or to an explicit request to create or design Compose code. A hypothetical UI consumer is not evidence. If neither form of evidence exists, stay in the Kotlin cluster even when the task mentions UI, routes, or navigation.
4. Match each observed code signal to the table below.
5. Add a second skill only when it owns an independent decision in the same change; do not load adjacent skills speculatively.
6. Finish routing when every material concern has one focused owner and those skills are loaded before advice or edits.

Common routes

Task signal	Start with
Evidenced Compose state, effects, screen ownership, or UI event collection	compose-state-and-effects
Recomposition, stability, frame-rate reads, back-writing, or @ReadOnlyComposable