jetpack-compose-audit

Jetpack Compose 監査

このスキルは、Android Jetpack Compose リポジトリを監査し、厳格かつ根拠に基づくレポートを作成します。

スキルのバージョン： 4.3.2 — リリース日：2026-07-07。 Compose の対象バージョン： Kotlin 2.0.20+ / Compose Compiler 1.5.4+（Strong Skipping Mode がデフォルト）。変更点については README の変更履歴を参照してください。

対象を次の4つのカテゴリに意図的に絞っています。

• パフォーマンス
• 状態管理
• 副作用
• Composable API の品質

このスキルでは、v1 でデザインや Material 3 への準拠は採点しません。監査でデザインシステムに関する問題が見つかった場合は、material-3 スキル（参照実装：https://github.com/hamen/material-3-skill）を使った追加監査を推奨してください。

テスト、フォーカス／キーボード操作、Compose Multiplatform は、採点カテゴリではなくカバレッジに関する注記です。該当する場合はこれらの領域を確認し、明らかなリスクを指摘したうえで、追加作業として compose-agent の参考資料（testing、focus、kmp）を推奨してください。同じ根本原因が、採点対象の4カテゴリのいずれかにも明らかに影響している場合を除き、0～100のスコアには反映しないでください。

Android の起動時 UX に関するリソースも、採点カテゴリではなく隣接するカバレッジ対象です。必ずスプラッシュ画面のテーマリソースを確認してください。Android 12 以降で静的なスプラッシュアイコンがぼやけて表示される可能性がある場合は、Android Launch UX の指摘事項として含め、根拠が具体的であれば Critical Findings／Prioritized Fixes に含めてください。

v1 の対象外

意図的に定めた対象範囲であり、意図的な判断です。カバレッジが薄いまま黙ってレポートを作成するのではなく、制限事項としてレポートに明記してください。

• Material 3 への準拠、テーマ設定、色／タイポグラフィのトークン — material-3 スキルに委ねてください。
• アクセシビリティの採点（semantics、コンテンツの説明、タッチターゲットのサイズ）— 明らかな不足を注記として指摘し、採点はしないでください。
• UI テストのカバレッジと Compose テストルールのパターン — 有無を記載し、採点はしないでください。詳しく確認する場合は compose-agent focus on testing を推奨してください。
• Compose Multiplatform 固有のルール（expect／actual、ターゲット固有のコードパス）— 対象範囲と明らかなプラットフォーム境界のリスクを記載してください。詳しく確認する場合は compose-agent focus on kmp を推奨してください。
• Wear OS／TV／Auto／Glance の画面 — フォーカス／キーボード／D-pad に関する明らかなリスクを記載してください。詳しく確認する場合は compose-agent focus on focus を推奨してください。
• ビルドパフォーマンス（インクリメンタルコンパイル、KSP／KAPT の選択）。

ユーザーがこれらのいずれかを明示的に依頼した場合は、対象範囲を絞り、その旨をレポートに記載してください。

使用する場面

次のような依頼があった場合に、このスキルを使用してください。

• Jetpack Compose リポジトリを監査する
• Compose のアーキテクチャや品質をレビューする
• スコアを付けてコードベースを評価する
• 再コンポーズ、状態、副作用に関する問題を調べる
• 既存のリポジトリで Compose のベストプラクティス違反を特定する

典型的な依頼の表現：

• 「この Compose リポジトリを監査して」
• 「この Jetpack Compose コードベースにスコアを付けて」
• 「状態のホイスティングと副作用をレビューして」
• 「Compose のパフォーマンスを確認して」
• 「このリポジトリを評価して」

出力要件

次の両方を作成してください。

• COMPOSE-AUDIT-REPORT.md という名前のリポジトリレポートファイル
• 総合スコア、カテゴリ別スコア、最も深刻な問題、優先度の高い修正をまとめた短いチャット要約

監査の原則

• 厳格に、ただし根拠に基づいて評価してください。
• 検索結果だけを根拠に採点しないでください。カテゴリを評価する前に、代表的なファイルを読んでください。
• 重要な減点はすべて、具体的なファイルパスをレポートに記載してください。
• 減点の根拠ごとに、公式ドキュメントの URL を記載してください。 「根拠は不要」といった判断は禁止です。ルーブリックでは、すべてのルールを references/canonical-sources.md の正規の情報源に対応づけています。レポートのテンプレートでは、指摘事項ごとに References: 行が必須です。
• 通説よりも、Android の公式ガイダンスを優先してください。
• パフォーマンスを重視しつつも、評価の唯一の観点にはしないでください。
• 公開ライブラリの純粋性に関する検証を満たしていないことを理由に、アプリのコードを減点しないでください。API 品質の確認は主に、再利用可能な内部コンポーネント、デザインシステムの構成要素、共有 UI ビルディングブロックに適用してください。
• 0-3 のスコアは、孤立したミスではなく、繰り返し発生する問題やシステム全体に及ぶ問題にのみ使用してください。
• カテゴリ全体で一貫して優れていない限り、9-10 のスコアを付けないでください。

プロセス

1. 対象範囲の確認

対象のパスを特定します。

• ユーザーが明示的なパス（[repo path or module path]）を指定した場合は、そのパスを使用します。
• パスが指定されていない場合は、現在の作業ディレクトリを使用します。
• パスが存在しない場合は、ユーザーに確認を求めます。

モジュールをマッピングする前に、Compose が実際に存在することを確認します（早期に処理を中止します）。

• 任意の build.gradle* または libs.versions.toml 内で androidx.compose を検索します。
• src/ 以下で setContent { または @Composable を検索します。

どちらも見つからない場合は、処理を中止し、対象範囲外であることを報告します。先にモジュール全体のマッピングを実行しないでください。

Compose が samples/、demos/、またはテストソースにのみ存在し、本番コードでは使用されていない場合は、対象をそれらのディレクトリに絞り、信頼度を Low に設定します。また、監査対象は本番パスではなくサンプルコードであることをレポートに明記します。デモコードに対して本番品質のカテゴリを採点しないでください。

2. リポジトリのマッピング

採点する前に、以下を特定します。

• Gradle モジュール
• Android アプリモジュールと機能モジュール
• Compose ソースルートと思われる場所
• 共有 UI／コンポーネントのパッケージ
• テーマまたはデザインシステムのパッケージ
• 状態ホルダーまたは ViewModel の領域
• テストとプレビューの場所
• UI テスト、スクリーンショットテスト、フォーカス／キーボードテスト、セマンティクステストの場所
• ベースラインプロファイル関連のモジュールまたは設定（存在する場合）
• KMP／Compose Multiplatform のソースセット（commonMain、androidMain、iosMain、desktopMain、wasmJsMain）（存在する場合）
• Android のスプラッシュスクリーンテーマとドローアブルリソース（res/values*/themes.xml、styles.xml、drawable-v31）（存在する場合）

3. Compose のサーフェスマップの作成

以下を探します。

• @Composable 関数
• 再利用可能な UI コンポーネント
• 画面とルート
• ViewModel の使用箇所
• remember、rememberSaveable、mutableStateOf
• collectAsStateWithLifecycle、collectAsState
• LaunchedEffect、DisposableEffect、SideEffect、rememberUpdatedState、produceState
• LazyColumn、LazyRow、items、itemsIndexed
• アニメーション API：animate*AsState、Animatable、updateTransition、rememberInfiniteTransition、AnimatedVisibility、AnimatedContent、Crossfade
• フォーカス API：FocusRequester、focusRequester、focusProperties、focusable、onFocusChanged、onPreviewKeyEvent、onKeyEvent
• UI テスト API：createComposeRule、createAndroidComposeRule、onNodeWithText、assertIsDisplayed、assertIsFocused、スクリーンショットテストルール
• KMP／CMP の指標：commonMain、expect、actual、AndroidView、UIKitView、共通 UI に渡されるプラットフォームサービス
• Android の起動リソース：windowSplashScreenAnimatedIcon、android:windowSplashScreenAnimatedIcon、drawable-v31、animated-vector

リポジトリが大規模な場合は、カテゴリまたはモジュールごとに監査します。サブエージェントを利用できる場合は、書き込みツールを使用しない Explore タイプのサブエージェントを起動し、カテゴリ別のスキャンを並列で実行して、結果を統合します。

3a. Android 起動 UX リソースの監査

これはスコア対象外の関連項目ですが、ユーザーに見える不具合であり、Kotlin のみを対象としたスキャンでは見落としやすいため、通常の監査ごとに実行してください。

次の項目を確認します。

• res/values*/themes.xml と res/values*/styles.xml にある windowSplashScreenAnimatedIcon と android:windowSplashScreenAnimatedIcon
• @drawable/ic_splash など、参照されているドローアブル
• res/drawable-v31/ にある API レベル別のオーバーライド
• ドローアブル XML のルート要素：<animated-vector>、<vector>、<adaptive-icon>、<bitmap>、<layer-list>

AnimatedVectorDrawable は Animatable であるため、プラットフォームはこれを SurfaceView にフルサイズで描画します。一方、静的アイコンは内部の ImmobileIconDrawable の経路（108 dp で事前にレンダリングされ、160/192 dp のアイコンへ拡大）になるため、XHDPI 以上のデバイスでぼやけて見えます。次のすべてに該当する場合は、指摘事項として報告してください。

1. テーマで Android アプリの windowSplashScreenAnimatedIcon が設定されている。
2. API 31 以降で解決されるリソースが静的アイコン（<vector>、<adaptive-icon>、ビットマップ、またはこれらを含むレイヤーリスト）であるか、参照先のスプラッシュアイコンに対する drawable-v31 のオーバーライドがない。
3. API 31 以降で、リソースがすでに <animated-vector> になっているわけではない。

スコアの減点ではなく、Android 起動 UX：Android 12 以降の静的なスプラッシュアイコンがぼやけて描画される可能性がありますとして報告してください。根拠には、テーマ項目、解決されたドローアブルファイル、および res/drawable-v31 の animated-vector オーバーライドがないかどうかを含めてください。修正方針は、テーマの @drawable/<name> を変更せず、API 31 以降では実際のベクターをラップする <animated-vector> に解決されるようにすることです。アニメーターは不要です。AVD であることによって描画経路が変わるため、空の <animated-vector> で十分です。 正確性に関する注意点として、ラッパーが参照するベクターには別の名前を付ける必要があります。テーマで使う名前と同じベクターをラッパーが参照すると、API 31 以降で再解決されて循環します。Android のスプラッシュ画面のドキュメント、AndroidX SplashScreen のリファレンス、およびプラットフォームの問題 https://issuetracker.google.com/issues/520672537（AOSP のソースを引用）を参照してください。このバグは Android 12（API 31）の XHDPI 以上のデバイスで発生し、このスキルの公開時点では未解決でした。未解決のままだと断定せず、問題の最新状況を確認してください。

4. Compose Compiler レポートの生成（自動）

build.gradle を編集したり、ユーザー自身でコマンドを実行したりするよう依頼しないでください。このスキルは、バンドルされた Gradle init スクリプトを使ってビルドを実行し、対象リポジトリ内のファイルを変更せずに、すべての Compose モジュールへ reportsDestination / metricsDestination を注入します。スコアリングの前に、次の手順を試してください。

1. スキルに同梱されている init スクリプトを探します。 scripts/compose-reports.init.gradle を使用します。絶対パスがスキルのインストール先です。ほとんどの場合、~/.claude/skills/jetpack-compose-audit/scripts/compose-reports.init.gradle にあります。パスを解決できない場合は、<target>/.compose-audit-reports.init.gradle にスクリプトを書き込み、実行後に削除してください。

2. 対象に Gradle ラッパーがあるか確認します。 test -x <target>/gradlew を実行します。見つからない場合は、手順 6 のフォールバックに進んでください。

3. コンパイル対象を選びます。 Compose モジュールの Kotlin コンパイルを実行できる、最も低コストのタスクを優先します。

   • rg -l 'com\.android\.application' -g '*.gradle*' を使って、最初のアプリケーションモジュールを探します。
   • 次の順に試します。:<app-module>:compileReleaseKotlinAndroid、:<app-module>:compileReleaseKotlin、assembleRelease、assembleDebug
   • プロジェクトがライブラリのみで Compose を使用している（com.android.library）場合は、そのモジュールを使用します。

4. ビルドを実行します。 ビルドを開始することをユーザーに伝えてください（数分かかる場合があります）。

   cd <target> && ./gradlew <task> \
       --init-script <path-to>/compose-reports.init.gradle \
       --no-daemon --quiet
   

   タイムアウトは 600 秒に設定します。タスクが失敗した場合は、手順 3 の次のフォールバックタスクを一度だけ試してください。無期限に繰り返さないでください。

5. レポートを収集します。

   find <target> -path '*/build/compose_audit/*' \
       \( -name '*-classes.txt' -o -name '*-composables.txt' -o -name '*-composables.csv' -o -name '*-module.json' \)
   

   これらのファイルから、次の情報を抽出します。

   • 不安定なクラス（*-classes.txt 内で unstable class から始まる行）のうち、コンポーザブルのパラメーターとして使用されているもの
   • スキップ不可だが再起動可能な名前付きコンポーザブル（引数のないラムダは無視し、*-composables.txt または *-composables.csv 内で isLambda == "0" の実際の名前付き関数に注目します）
   • *-module.json に記録されたモジュール全体のスキップ可能性の件数と、*-composables.csv から算出した名前付きコンポーザブルのみのスキップ可能性（isLambda == "1" の行を除外し、sum(skippable) / sum(restartable) を計算します）。パフォーマンスセクションでは両方を引用し、引数のないラムダがモジュール全体の指標を人為的に押し上げる場合があることを明記してください。

6. ビルドに失敗した場合、または Gradle を利用できない場合のフォールバック。 ソースコードから推定した安定性に関する所見をもとに進めます。ただし、次の点に従ってください。

   • レポートの「Notes And Limits」に Compiler diagnostics used: no と記載し、失敗理由（ラッパーの不在、コンパイルエラー、タイムアウト）を簡潔に説明します。
   • 総合信頼度を 1 段階下げます。
   • 安定性に関する推論はすべて、「ソースから推定 — コンパイラレポートでは未検証」と明記します。

手順 5 で得られた安定性の推論は測定済みの根拠として通常どおり重み付けします。手順 6 のフォールバックによる推論は、レポート内で推定であると明記する必要があります。

5. 4 つのカテゴリを監査する

references/scoring.md のスコアリング基準と、references/search-playbook.md のヒューリスティックを使用します。

ナビゲーション 3： リポジトリで rememberNavBackStack、NavDisplay、または NavKey を使用している場合は、スコアリングの前に プレイブックのセクション 2b（Nav3 の検出と監査）を実行してください。Nav3 の所見は状態管理と副作用に対応します。スコアリングに関する注記はセクション 2b を参照してください。

パフォーマンス

次の点に注目します。

• コンポジション中の高コストな処理
• 回避可能な再コンポジション
• 遅延リストのキー
• collectAsLazyPagingItems が存在する場合の、ページングリストのキーと LazyPagingItems の誤用
• 不適切な状態読み取りのタイミング
• 不安定な状態読み取り、または範囲が広すぎる状態読み取り
• 逆方向の書き込み。これには、コンポジションで読み取られる状態をレイアウトコールバックが書き込むフェーズ間の逆方向書き込みや、コンポーザブルの本体でのスナップショットコレクションによる自己無効化が含まれます。
• アニメーションのフェーズが適切かどうか（ラムダ修飾子を介してフレームごとの値の読み取りをレイアウト／描画フェーズに遅らせているか、Animatable を remember 内に保持しているか、rememberInfiniteTransition のスコープが画面外で停止するよう設定されているか）
• 明らかに確認できるリリース時のパフォーマンス対策

状態管理

以下に重点を置きます。

• 状態のホイストが正しいこと
• 単一の信頼できる情報源
• 再利用可能なステートレスな境界
• remember と rememberSaveable の適切な使い分け
• ライフサイクルを考慮した監視可能なコレクション
• LazyPagingItems が存在する場合のページング LoadState の処理（読み込み中／空／エラー／追加読み込み）
• 監視可能な可変状態と監視不可能な可変状態

副作用

以下に重点を置きます。

• コンポジション内で誤って実行されている副作用
• 適切なエフェクト API の選択
• エフェクトのキー
• 古いラムダのキャプチャ
• クリーンアップの正しさ
• ライフサイクルを考慮したエフェクトの動作
• ターゲット駆動型の状態変化に対して、LaunchedEffect(target) でアニメーションを駆動すること（コンポジション本体からではありません。rememberCoroutineScope().launch { animateTo(...) } は通常、イベント駆動またはジェスチャー駆動のアニメーションに使用します）
• ページングの LazyPagingItems.refresh() / retry() を、コンポジション内または「画面に入ったときに読み込む」ための LaunchedEffect(Unit) 内で呼び出していること。初回読み込みは PagingData の役割であり、これらはユーザー操作によってのみ実行します

Composable API の品質

すべての末端画面ではなく、再利用可能な内部コンポーネントに重点を置きます。

以下を確認します。

• modifier の有無と配置
• パラメーターの順序
• 暗黙的な設定より明示的な設定を優先していること
• 意味のあるデフォルト値
• より適切な形式がある場合に、再利用可能な API のパラメーターとして MutableState<T> や State<T> を避けていること
• 呼び出し元が時間を制御する必要が想定される再利用可能なアニメーション付きコンポーネントでは animationSpec: AnimationSpec<T> を公開していること。また、共有アニメーションやツールから確認できるアニメーションでは、意味のある label 値を使用していること
• コンポーネントの目的とレイヤー構成

6. 指摘事項を検証する

減点する前に、以下を確認します。

• 問題のパターンが見られるファイルを読む
• そのパターンが誤検出ではなく、実際に存在することを確かめる
• リポジトリ内の別の箇所に、それを補うパターンがすでにないか確認する
• 単発のミスと全体的な傾向を区別する
• 安定性に関する指摘（スキップ可能性／再起動可能性／不安定なパラメーター）には、Step 4 で生成したコンパイラーレポートを使用する。根拠として具体的なレポートの行を示す（例：app/build/compose_audit/app_release-classes.txt:42）。Step 4 が失敗した場合に限り、ソースから推測した安定性に関する主張を代わりに用い、その旨を明記する

7. スコアを付ける

各カテゴリに 0-10 のスコアとステータスを割り当てます。

• 0-3：不合格
• 4-6：要改善
• 7-8：良好
• 9-10：優秀

全体スコアの算出には references/scoring.md の重みを使用します。

測定値による上限は必須であり、目安ではありません。 Step 4 でコンパイラーレポートが生成された場合、references/scoring.md のパフォーマンス評価基準で上限を定めます。まず Strong Skipping が有効かどうか（Kotlin 2.0.20 以降／Compose Compiler 1.5.4 以降、または明示的なオプトインフラグ）を判断し、該当する表を選びます。SSM オフの表は skippable% と不安定クラス数を基準とし、SSM オンの表は skippable%、インスタンスの再生成による churn、および不安定なパラメーターに対する equals() の品質を基準とします。定性的なパフォーマンススコアを算出した後、必ず上限を適用し、スコアが上限を超える場合は引き下げてください。レポートには計算過程を示し、適用した表の名前を記載します。

Performance ceiling check:
  Strong Skipping: OFF (Kotlin 1.9.x, no opt-in) → applying SSM-off table
  skippable% = 186/273 = 68.1% → falls in 50-70% band → cap at 4
  qualitative score: 7
  applied score: 4 (ceiling lowered from 7)

Strong Skipping が有効な場合、通常 skippable% はほぼ 100% となり、制約要因ではなくなります。上限は通常、観測された churn（コンポーザブルに渡される listOf(...)／mapOf(...)／新しいリテラルなど）や、不安定なパラメーターに対するコストの高い、または壊れた equals() によって決まります。読者が選択の根拠を検証できるよう、上限確認のセクションでは、これらの指摘事項を明示してください。

skippable% を切り上げて、より高い評価帯に入れないでください。68.1% は ≥70% ではありません。定性的スコアが上限以下なら、調整は不要です。ただし、読者が検証できるよう、確認内容は必ずレポートに記載してください。

カテゴリの監査可能な範囲が本当に少なすぎる場合は N/A とし、その理由を説明したうえで、残りの重みに基づいて再計算してください。

8. レポートを作成する

references/report-template.md を使用してください。

レポートには、次の項目を含める必要があります。

• 全体スコア
• カテゴリ別スコア表
• 重大な指摘事項の上位項目
• カテゴリごとの根拠
• 根拠となるファイルパス
• 優先度順の修正リスト
• デザイン上の問題が疑われる場合は、material-3 の実行を促す任意のフォローアップメモ
• テスト、フォーカス／キーボード、KMP/CMP の対象範囲に関する任意のメモ。これらのメモは、スコア対象のカテゴリと重複しない限り、スコアには影響しません

レポートは次の場所に作成してください。

• 監査対象（ユーザーが指定したパス）内の COMPOSE-AUDIT-REPORT.md。現在の作業ディレクトリには作成しないでください。

そのパスに COMPOSE-AUDIT-REPORT.md がすでに存在する場合、黙って上書きしないでください。ユーザーに上書きを確認するか、同じ場所に COMPOSE-AUDIT-REPORT-<YYYY-MM-DD>.md を作成してください。

9. 短い要約を返す

チャットでは、一般的な概要ではなく、レポートの Prioritized Fixes セクションを反映した要約を作成してください。開発者がレポートを開かなくても、要約だけで対応できる内容にしてください。

次の項目を含めてください。

• 全体スコア（同じパスに以前の COMPOSE-AUDIT-REPORT*.md がある場合は、そのスコアとの差分も含める）
• 各カテゴリの1行の評価。適用された上限があれば、それも記載する（例：「パフォーマンス 8/10 — SSM-on の上限表により制限：FeedItemUiModel のパラメーターが再生成されています」）
• アニメーションの不具合がパフォーマンスに影響した場合は、パフォーマンスの行で具体的に示す（例：「パフォーマンス 6/10 — アニメーション付きの offset の読み取りにより、フレームごとに DrawerContent が再コンポーズされます」）
• アニメーションの不具合が副作用に影響した場合は、副作用の行で具体的に示す（例：「副作用 5/10 — SettingsScreen のコンポジション内に scope.launch { animateTo(...) } があります」）
• ページングの不具合が副作用に影響した場合は、副作用の行で具体的に示す（例：「副作用 6/10 — FeedScreen の LaunchedEffect(Unit) { feed.refresh() } により、コンポジションから読み込みが実行されます」）
• ステップ 4 が成功した場合は、コンパイラーレポートの要点を含める：Strong Skipping の有効／無効（またはモジュール間で混在していること）、適用された上限表、モジュール全体の skippable%、名前付き要素のみの skippable%、上限を実際に決定した指標、不安定な共有型の数、ビルドに失敗したモジュール
• 実行可能な修正案の上位3つ。それぞれに次の内容を含めてください。
  • 具体的な変更（「feed/FeedList.kt:42 の items(...) に key = { it.id } を追加する」）
  • ファイルパスと行番号（レポートの Prioritized Fixes に記載したものと同じ）
  • references/canonical-sources.md にある公式ドキュメントの URL を1つ
  • 適用中の上限表に沿った期待される効果。SSM-off の場合は、名前付き要素のみの skippable%／不安定なパラメーターの削減という観点で説明してください。SSM-on の場合は、インスタンス再生成による無駄の解消、高コストまたは不適切な equals() の修正、あるいは上限の解除という観点で説明してください
• 次に material-3 の監査を実行する価値があるか
• 次に対象を絞ったフォローアップを実行する価値があるか：compose-agent focus on testing、compose-agent focus on focus、compose-agent focus on kmp、compose-agent focus on animation、または compose-agent focus on paging

チャット要約の修正案上位3つは、レポートの Prioritized Fixes リストと同じ項目にしてください（同じファイルパスと同じドキュメントリンクを使用）。レポートにない一般的な助言をチャットに追加しないでください。

根拠のルール

• 目立つ問題を1つだけ示すのではなく、複数の例を優先してください。
• 問題点だけでなく、適切な実装の根拠も示してください。
• コードから裏付けられない実行時の問題を推測しないでください。
• 公式ガイダンスに基づくルールであっても、アプリレベルのトレードオフによって逸脱が妥当な場合は、常に誤りであるかのように扱わず、トレードオフとして明示してください。

大規模リポジトリへの対応

中規模または大規模なリポジトリでは、次の手順に従ってください。

1. まずモジュールを把握します。
2. モジュールごとに代表的なファイルを選びます。
3. 可能であれば、カテゴリ別のスキャンを並行して実行します。
4. 同じ問題を何度も列挙するのではなく、繰り返し見られる指摘を体系的な問題としてまとめます。

避けるべきこと

• リポジトリの根拠を示さず、一般的なチェックリストを作成しないでください。
• リポジトリがアプリの場合、レポートをパブリックライブラリの API 解説にしないでください。
• アプリが Compose を使用しているという理由だけで、パフォーマンスのスコアを水増ししないでください。
• 孤立した実験用コードやサンプルファイルが、本番環境へのパスに含まれていない限り、過度に減点しないでください。
• v1 では設計を採点しないでください。
• LaunchedEffect(Unit) や LaunchedEffect(true) だけを理由に指摘しないでください。「一度だけ実行する」パターンは慣用的な書き方です。rememberUpdatedState を使わずに、本文が変更される可能性のある値をキャプチャしている場合に限り、指摘してください。Paging の例外： LaunchedEffect(Unit) { lazyPagingItems.refresh() }（または retry()）は副作用の不具合です。初回のページ読み込みは PagingData の役割であり、refresh()／retry() はユーザーが開始する操作です。指摘してください。
• Compose Multiplatform のコードパスでは、Android 専用 API（collectAsStateWithLifecycle、lifecycle-runtime-compose）を理由に減点しないでください。代わりに、トレードオフとしてプラットフォーム上の制約を記載してください。
• 同じ根本原因を複数のカテゴリで重複して数えないでください。安定性の問題は通常、パフォーマンスと状態の両方に現れます。主要なカテゴリを選び、相互参照してください。

参考資料

• references/scoring.md — インライン引用付きのルール別評価基準
• references/search-playbook.md — 検索パターンと危険信号のヒューリスティック
• references/report-template.md — COMPOSE-AUDIT-REPORT.md に必要な構成
• references/canonical-sources.md — 減点のたびに引用が必要な公式 URL
• references/diagnostics.md — Compose Compiler レポート、安定性設定、ベースラインプロファイル、R8 チェック用のコピー＆ペースト可能な Gradle／コードスニペット
• scripts/compose-reports.init.gradle — Step 4 でスキルが --init-script 経由で注入し、コンパイラレポートを自動生成する Gradle 初期化スクリプト

受け入れ評価

evals/evals.json には、既存コードの監査を評価する受け入れケースが含まれています。それぞれの {prompt, expected_output, expectations} は、監査で出すべき指摘を含むスニペットです。ケース 12～14（フェーズをまたぐ書き戻し、Strong Skipping の誤検知、スナップショットの自己無効化）は、compose-agent の書き込みモード評価で反対方向から再現されているため、評価のパスと作成のパスが常に同期します。各プロンプトに対してモデルを実行し、すべての期待事項を確認してください。