using-chrisbanes-skills について
using-chrisbanes-skillsは、Kotlin、Compose、Gradle、Androidベンチマークの作業に適したスキルへ振り分けます。コードやタスクに現れた具体的な手掛かりから専門スキルを選び、隣接スキルの推測的な読み込みを抑えます。
主な機能
- 01具体的なコードの手掛かりで振り分け
- 02KotlinとComposeのルートを区別
- 03一般的なタスク別ルートを提示
- 04スキルの組み合わせ境界を定義
活用シーン
- 01Kotlin並行処理に適したスキルの選択
- 02Composeコードに基づくUIスキルの選択
- 03GradleやAndroidベンチマーク作業の振り分け
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ chrisbanes/ skills --skill using-chrisbanes-skillsインストール後、Claude Code で/using-chrisbanes-skillsを入力して読み込まれたか確認します。
詳細
chrisbanes のスキルの使用
基本原則
言及されている API の数ではなく、コードが必要とする判断に基づいて振り分けます。 共通の手順がその懸念を担う場合は、該当するクラスターを 1 つ読み込みます。同じ作業に独立した振る舞いが影響する場合に限り、専門スキルを追加します。
振り分け手順
- タスクを読みます。Kotlin または Compose の作業では、懸念を具体的に示しているソースを調べます。Android ベンチマークの比較では、代わりに提供されたレポート、設定、トレースを調べます。
- 明確に該当するスキルが 1 つある場合は、それを直接読み込み、振り分けを終了します。
- Compose スキルを読み込む前に、調べたソース内の具体的な Compose API またはコンポーザブルを示すか、Compose コードの作成または設計を求める明示的な依頼を確認します。仮定上の UI 利用者は根拠になりません。どちらの根拠もない場合、タスクで UI、ルート、ナビゲーションに言及されていても、Kotlin クラスターの範囲内にとどめます。
- 観察された各コードのシグナルを、以下の表に照らし合わせます。
- 同じ変更内の独立した判断を担う場合に限り、2 つ目のスキルを追加します。隣接するスキルを推測で読み込まないでください。たとえば、Flow の配信不具合と、sealed route に対する別個の catch-all がある場合は、
kotlin-concurrency-and-flowとkotlin-control-flowの両方が必要です。後者を読み込むのは、ファイルにwhenがあるからではなく、分岐の対応付けで明示的な判断が必要だからです。その判断には、データを持つサブタイプのペイロードをスマートキャストで使用するのか、意図的に破棄するのかも含まれます。 - すべての重要な懸念にそれぞれ適切な担当スキルが割り当てられ、助言や編集の前にそれらのスキルが読み込まれたら、振り分けを終了します。
よくある振り分け先
| タスクのシグナル | まず読み込むスキル |
|---|---|
| 根拠のある Compose の状態、エフェクト、画面の所有権、または UI イベントの収集 | compose-state-and-effects |
再コンポジション、安定性、フレームレート読み取り、バックライト、または @ReadOnlyComposable | compose-performance |
| コンポーネント修飾子、呼び出し側での配置、スロット、または公開コンテンツの形状 | compose-component-design |
| 可視性、値、トランジション、コンテンツ切り替え、その他のモーション API の選択 | compose-animations |
| キーボード、TV、D-pad、フォーカスターゲット、カスタムトラバーサル、またはキーイベント | compose-focus-navigation |
| Compose UI、スクリーンショット、セマンティクス、フォーカス/キー、またはインタラクション状態のテスト | compose-ui-testing-patterns |
コルーチンの所有権、生の Thread または Executor による処理、キャンセル、Flow の状態/イベント、共有、またはリプレイ | kotlin-concurrency-and-flow |
Kotlin の分類、when、ガード、網羅性、スマートキャスト、または null 分岐 | kotlin-control-flow |
| Kotlin の関数の所有権、ドメイン型、expect/actual、またはプラットフォーム境界 | kotlin-api-design |
| Gradle の実行計画、または Gradle を中心とする警告/失敗のワークフロー | gradle-run |
| 物理 Android デバイスのベンチマーク設定、順位の逆転、または Android のデフォルトの比較 | android-benchmark-comparison |
| Kotlin ライブラリのリリース準備、公開、またはリリース可否 | release-kotlin-library |
| リポジトリを考慮した計画が必要な、準備済みの GitHub issue 1 件またはチャット内のタスク | to-plan |
| PR/MR、レビューコメント、CI の失敗、または定例のフォローアップの確認 | shepherd |
組み合わせの境界
- Compose の状態に関する作業に
kotlin-concurrency-and-flowを追加するのは、配信、再生、共有、キャンセルが独立した懸念事項である場合に限ります。アニメーション作業でも状態の所有権やパフォーマンスに関する懸念が変わる場合に限り、それらを追加します。 - タスクでテストの形も必要な場合は、フォーカスナビゲーションと UI テストを組み合わせます。フォーカス対応の
AnimatedContentの切り替えでは、Compose アニメーションも読み込みます。コンテンツラムダのターゲットから切り替え前後の各ブランチを描画することは、フォーカスのタイミングやインタラクションテストとは別の識別性に関する判断です。 - Kotlin の懸念に、独立した分岐判断も伴う場合は、
kotlin-control-flowを追加します。たとえば、シールドされた結果に対する包括的な catch-all によって、ケースやブランチのペイロードが隠される場合です。独立した分岐の問題がない単純なルート配信には必要ありません。手順 3 で必要とされる根拠なしに Compose を追加しないでください。 - Compose のスナップショットプロパティを読み取り専用の公開アクセサーでカプセル化する場合も、状態の所有権に関する判断は 1 つです。アクセサーが公開されているという理由だけで
kotlin-api-designを追加しないでください。同じ変更で関数の所有権、ドメイン型、互換性、またはプラットフォーム境界に関する独立した判断も必要な場合に追加します。 gradle-runを読み込むのは、Gradle の実行を予定している場合、または既存の Gradle ワークフローがある場合に限ります。付随的な Kotlin や Compose のアドバイスのためには読み込まないでください。
コメント
Markdown 対応