using-chrisbanes-skills

v2026.09.24

Use when routing Kotlin or Jetpack Compose work, or physical Android benchmark evidence that needs a configuration decision, especially when several Kotlin or Compose concerns overlap.

GitHub
Install command
npx skhub add chrisbanes/using-chrisbanes-skills
Markdown
SKILL.md

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. For Kotlin or Compose work, inspect the source that makes the concern concrete. For an Android benchmark comparison, inspect the supplied reports, configurations, and traces instead.
  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. For example, a flow delivery defect plus a separate catch-all over a sealed route needs both kotlin-concurrency-and-flow and kotlin-control-flow. Load the latter because the branch mapping needs an explicit decision, including whether a data-bearing subtype's payload is used through a smart cast or deliberately discarded, not merely because a when appears in the file.
  6. Finish routing when every material concern has one focused owner and those skills are loaded before advice or edits.

Common routes

Task signalStart with
Evidenced Compose state, effects, screen ownership, or UI event collectioncompose-state-and-effects
Recomposition, stability, frame-rate reads, back-writing, or @ReadOnlyComposablecompose-performance
Component modifiers, caller placement, slots, or public content shapecompose-component-design
Visibility, value, transition, content-swap, or other motion API choicecompose-animations
Keyboard, TV, D-pad, focus targets, custom traversal, or key eventscompose-focus-navigation
Compose UI, screenshot, semantics, focus/key, or interaction-state testscompose-ui-testing-patterns
Coroutine ownership, raw Thread or Executor work, cancellation, Flow state/events, sharing, or replaykotlin-concurrency-and-flow
Kotlin classification, when, guards, exhaustiveness, smart casts, or null brancheskotlin-control-flow
Kotlin function ownership, domain types, expect/actual, or platform seamskotlin-api-design
Planned Gradle execution or a Gradle-centered warning/failure workflowgradle-run
Comparing physical Android benchmark configurations, reversed rankings, or an Android defaultandroid-benchmark-comparison
Kotlin library release preparation, publication, or readinessrelease-kotlin-library
One ready GitHub issue or in-chat task needs repository-aware planningto-plan
Polling PRs/MRs, review comments, CI failures, or routine follow-upshepherd

Combination boundaries

  • Add kotlin-concurrency-and-flow to Compose state work only when delivery, replay, sharing, or cancellation is a separate concern. Add state ownership or performance only when animation work changes that concern too.
  • Pair focus navigation with UI testing when the task also needs a test shape. For a focus-aware AnimatedContent swap, load Compose animations as well: rendering each outgoing and incoming branch from its content-lambda target is a separate identity decision from focus timing and the interaction test.
  • Add kotlin-control-flow when a Kotlin concern also has an independent branch decision, such as a catch-all over a sealed result that hides cases or branch payload. Plain route delivery with no separate branching issue does not need it. Do not add Compose without the evidence required in step 3.
  • Encapsulating a Compose snapshot property behind a read-only public accessor remains one state-ownership decision. Do not add kotlin-api-design merely because the accessor is public; add it when the same change also needs a separate function-ownership, domain-type, compatibility, or platform-boundary decision.
  • Load gradle-run only for planned Gradle execution or an existing Gradle workflow, not incidental Kotlin or Compose advice.
Discovery
Tags

No tags published for this skill.

Version
Latest version metadata

Version

v2026.09.24

Published

Sep 24, 2026

Category

Uncategorized

License

Apache-2.0

Source path

skills/using-chrisbanes-skills

Default branch

main

Latest commit

ba03969

Tree SHA

c7e2420