android-kotlin-core

Android Kotlin Core

使用する場面

• 次のような依頼でこのスキルを使用します：Android アプリの Kotlin コードの整理、冗長な Android Java 風 Kotlin の変換、UI 状態の sealed class 化。
• 主な成果：null 許容型、データクラス、sealed 型、拡張関数、コレクションのパイプラインなど、Kotlin の慣用的な機能を Android アプリで安全に使用します。
• 対応範囲が広がる場合は、次のスキルに引き継ぎます：
• android-state-management
• android-testing-unit

ワークフロー

1. 依頼の内容を、現在の Android スタック、モジュールの境界、最小サポート API レベルに照らし合わせます。
2. 既存の実装を調査し、暗黙の前提、重複するヘルパー、古くなったパターンを確認します。
3. 正確性、可読性、長期的な保守性を高める最小限の変更を適用します。
4. 関連するショーケースアプリのパスとリポジトリのベンチマークに照らして、結果を検証します。
5. 基盤が安定してから、関連する作業を次の専門スキルに引き継ぎます。

ガードレール

• Android と Kotlin の公式ガイダンスと独自のローカル規約が矛盾する場合は、公式ガイダンスを優先します。
• 公開 API はシンプルで明示的に保ち、Android のライフサイクルにかかるコストを見えにくくする巧妙な抽象化は避けます。
• 依頼で両方が明示的に必要とされていない限り、アーキテクチャの整理とプロダクトの動作変更を混在させません。
• 古いモジュールや生成コードに影響する互換性の制約は、文書に記載します。

アンチパターン

• 明確な所有範囲を定めずに、複数のモジュールへヘルパーを散在させる。
• ドメイン層やデータ層の純粋なコードに、フレームワーク固有のコードを持ち込む。
• 変更が必要なのは 1 つの契約だけなのに、隣接するファイルをすべてリファクタリングする。
• 移行に関する注意事項を暗黙のままにし、明記しない。

例

想定どおりのケース

• シナリオ：sealed interface と不変データを使って、ドメインと UI の状態モデルを強化します。
• コマンド：cd examples/orbittasks-compose && ./gradlew :app:testDebugUnitTest

エッジケース

• シナリオ：XML の Activity 境界を越える nullable なプラットフォーム値を保護します。
• コマンド：cd examples/orbittasks-xml && ./gradlew :app:testDebugUnitTest

失敗からの復旧

• シナリオ：呼び出し元を壊さずに、広範なヘルパーオブジェクトを用途ごとの拡張関数にリファクタリングします。
• コマンド：python3 scripts/eval_triggers.py --skill android-kotlin-core

完了チェックリスト

• 実装のパスが明確かつ最小限で、適切な Android の領域に紐付いている。
• 関連する例のコマンドとベンチマーク用プロンプトを実行するか、更新している。
• 依頼が隣接するスキルの範囲にまたがる場合、引き継ぎ内容を記録している。
• 選択したパターンと、主な移行またはトラブルシューティングの手順を公式リファレンスで確認できる。

公式リファレンス

• https://developer.android.com/kotlin
• https://developer.android.com/build/kotlin-support
• https://kotlinlang.org/docs/coding-conventions.html
• https://kotlinlang.org/docs/null-safety.html