using-chrisbanes-skills
GitHub指导如何根据代码信号路由选择 Kotlin 或 Jetpack Compose 相关技能,强调基于决策而非 API 数量加载技能集群,适用于多技能重叠场景。
Trigger Scenarios
Install
npx skills add chrisbanes/skills --skill using-chrisbanes-skills -g -y
SKILL.md
Frontmatter
{
"name": "using-chrisbanes-skills",
"description": "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."
}
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. For example, a flow
delivery defect plus a separate catch-all over a sealed route needs both
kotlin-concurrency-and-flowandkotlin-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 awhenappears in the file. - 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.
For a focus-aware
AnimatedContentswap, 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-flowwhen 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-designmerely 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-runonly for planned Gradle execution or an existing Gradle workflow, not incidental Kotlin or Compose advice.
Version History
-
2026.9.25
Current 2026-09-27 20:24
优化了路由逻辑描述,明确添加第二个技能的条件,并更新了常见路由表的示例内容。
-
2026.9.21
2026-09-22 08:34
新增 android-benchmark-comparison 技能,支持物理 Android 基准测试配置的对比与决策。
-
2026.9.2
2026-09-09 03:00
新增kotlin-library-release技能以支持Kotlin库发布流程;移除不支持的frontmatter路径字段。
-
2026.9.2
2026-09-03 04:30
新增对原始 Thread 和 Executor 使用的并发技能路由支持,并添加结构化迁移指导。
-
2026.8.24
2026-08-27 17:16
精简指令冗余度;重新认证 Kotlin 和 Gradle 技能评估标准。
-
2026.8.16
2026-08-19 19:31
新增 Gradle 运行工作流支持,增加直接聊天内规划功能。
-
2026.8.5
2026-08-16 02:45
重构技能分类,将15个细粒度入口合并为5个自包含集群;更新路由表以匹配新的技能簇;移除旧的技能名称引用,优化了路由决策逻辑。
- 2026.7.21 2026-07-24 12:25


