mcpField
A
android-modularization

android-modularization

github.com/krutikjain開発1461 回インストール31 週間前に更新
リポジトリ

android-modularization について

Android リポジトリのモジュール分割を支援するスキルです。feature、core、build-logic の依存方向と所有権を整理し、循環依存や過度な分割を避けます。

主な機能

  1. 01既存のモジュール依存図の把握
  2. 02所有権に基づく境界の設定
  3. 03API と実装依存の明確化
  4. 04循環依存と過剰な分割の回避

活用シーン

  1. 01Android の機能モジュール分割の計画
  2. 02モジュール間の循環依存の調査
  3. 03共有コードと API の所有権整理

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/krutikjain/android-agent-skills --skill android-modularization

インストール後、Claude Code で/android-modularizationを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
references/
official-links.md
patterns.md
scenarios.md
scripts/
run_examples.sh

詳細

Android のモジュール化

使用する場面

  • 次の内容に関するリクエストで使用します：Android のモジュール分割、Android での機能モジュール化、循環するモジュール依存関係の解消。
  • 主な成果：循環依存を起こさずに拡張できる、機能・コア・ビルドロジックの各モジュールを備えた Android リポジトリを設計します。
  • タスク単位のビルド速度調整ではなく、依存関係の方向、API の所有権、機能／データ／コアの境界が問題となる場合に、このスキルを使用します。
  • 対象範囲が広がった場合は、次のスキルに引き継ぎます：
  • android-gradle-build-logic
  • android-architecture-clean

ワークフロー

  1. まず現在のモジュールグラフを把握します：app、feature、data、core、build-logic、および dynamic-feature やテスト専用の各モジュール。
  2. どの依存方向が誤っているかを特定します：feature 間の結合、domain／data へのフレームワークの漏れ、広すぎる API サーフェス、または所有権が不明確な共有コードの重複。
  3. 抽象的な理論ではなく、所有権と変更頻度に基づいて分割します。現在の結合の問題を解消できる最小限のモジュール境界を作成します。
  4. 新しい境界が安定するように、api と implementation の使い分け、公開サーフェス、テストフィクスチャの所有権を明確にします。
  5. モジュールグラフ自体が整合してから、ビルド速度やプラグインアーキテクチャの問題を引き継ぎます。

ガードレール

  • 独自のローカル規約と競合する場合は、公式の Android および Kotlin のガイダンスを優先します。
  • 公開 API はシンプルで明示的なものにし、Android のライフサイクルにかかるコストを覆い隠す凝った抽象化は避けます。
  • リクエストで両方が明示的に必要とされていない限り、アーキテクチャの整理とプロダクトの動作変更を混在させません。
  • 古いモジュールや生成コードに影響する互換性の制約を文書化します。
  • 実際に必要なのが所有権境界を 1 つ明確にすることだけであれば、小規模なコードベースを過度にモジュール化しないようにします。

アンチパターン

  • 明確な所有権境界を設けずに、ヘルパーを複数のモジュールに散在させる。
  • 純粋な domain 層や data 層にフレームワーク固有のコードを導入する。
  • 変更が必要な契約が 1 つだけなのに、隣接するファイルをすべてリファクタリングする。
  • 移行に関する注意事項を暗黙のままにし、文書化しない。
  • ビルドの分離と依存関係の明確化ではなく、モジュール数を目標として扱う。

例

基本的なケース
  • シナリオ：フィクスチャアプリを app モジュールとして確認し、次に feature／core 層へ分割する構成を把握します。
  • コマンド：cd examples/orbittasks-compose && ./gradlew :app:projects
エッジケース
  • シナリオ：共有 XML リソースとマニフェストのプレースホルダーが、モジュール間に漏れないようにします。
  • コマンド：cd examples/orbittasks-xml && ./gradlew :app:dependencies
失敗からの復旧
  • シナリオ：モジュール化のリクエストを architecture-clean や build-logic に関するプロンプトと区別します。
  • コマンド：python3 scripts/eval_triggers.py --skill android-modularization

完了チェックリスト

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

公式リファレンス

コメント

Markdown 対応