android-architecture-clean

Android のクリーンアーキテクチャ

使用する場合

• リクエストが次の内容に関する場合にこのスキルを使用します：Android のクリーンアーキテクチャ、ユースケースとリポジトリの分割、プレゼンテーション層とデータ層の整理。
• 主な成果：Android プロジェクトにクリーンアーキテクチャの境界、ユースケース、リポジトリ、ライフサイクルを考慮したプレゼンテーションモデルを適用します。
• 対象範囲が広がる場合の引き継ぎ先スキル：
• android-modularization
• android-state-management

ワークフロー

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

ガードレール

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

アンチパターン

• 明確な所有境界を設けずに、モジュール間にヘルパーを散在させる。
• 純粋なドメイン層やデータ層に、フレームワーク固有のコードを導入する。
• 変更が必要な契約が 1 つだけなのに、隣接するすべてのファイルをリファクタリングする。
• 移行に関する注意事項を暗黙のままにし、文書化しない。

例

想定されるケース

• シナリオ：OrbitTasks の機能状態、ユースケース、リポジトリの契約を分離します。
• コマンド：cd examples/orbittasks-compose && ./gradlew :app:testDebugUnitTest

エッジケース

• シナリオ：保存状態の動作を維持しながら、XML アクティビティのアクションを薄く保ちます。
• コマンド：cd examples/orbittasks-xml && ./gradlew :app:testDebugUnitTest

失敗からの復旧

• シナリオ：モジュール化や状態管理のリクエストと、トリガーの混同を検出します。
• コマンド：python3 scripts/eval_triggers.py --skill android-architecture-clean

完了チェックリスト

• 実装の経路が明確かつ最小限で、適切な Android の適用先に結び付いています。
• 関連するサンプルコマンドとベンチマーク用プロンプトを実行または更新しています。
• リクエストが境界をまたぐ場合は、関連スキルへの引き継ぎを文書化しています。
• 選択したパターンと、主な移行またはトラブルシューティングの経路を公式リファレンスで確認できます。

公式リファレンス

• https://developer.android.com/topic/architecture
• https://developer.android.com/topic/architecture/recommendations
• https://developer.android.com/jetpack/guide
• https://developer.android.com/topic/libraries/architecture/viewmodel