tuyv 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
- 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.
- If one focused skill clearly matches, load it directly and stop routing.
- 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.
- Match each observed code signal to the table below.
- Add a second skill only when it owns an independent decision in the same change; do not load adjacent skills speculatively.
- 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 |
compose-performance |
| Component modifiers, caller placement, slots, or public content shape | compose-component-design |
| Visibility, value, transition, content-swap, or other motion API choice | compose-animations |
| Keyboard, TV, D-pad, focus targets, custom traversal, or key events | compose-focus-navigation |
| Compose UI, screenshot, semantics, focus/key, or interaction-state tests | compose-ui-testing-patterns |
Coroutine ownership, raw Thread or Executor work, cancellation, Flow state/events, sharing, or replay |
kotlin-concurrency-and-flow |
Kotlin classification, when, guards, exhaustiveness, smart casts, or null branches |
kotlin-control-flow |
| Kotlin function ownership, domain types, expect/actual, or platform seams | kotlin-api-design |
| Planned Gradle execution or a Gradle-centered warning/failure workflow | gradle-run |
| Comparing physical Android benchmark configurations, reversed rankings, or an Android default | android-benchmark-comparison |
| Kotlin library release preparation, publication, or readiness | release-kotlin-library |
| One ready GitHub issue or in-chat task needs repository-aware planning | to-plan |
| Polling PRs/MRs, review comments, CI failures, or routine follow-up | shepherd |
Combination boundaries
- Add
kotlin-concurrency-and-flowto 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.
- Add
kotlin-control-flowwhen a Kotlin concern also changes branching. Plain Kotlin route delivery plus a sealed mapping stays in the Kotlin cluster; do not add Compose without the evidence required in step 3. - Load
gradle-runonly for planned Gradle execution or an existing Gradle workflow, not incidental Kotlin or Compose advice.