메뉴
バイナリ互換性チェック（./gradlew apiCheck）が失敗した時の診断と修正を行う。public API の差分を確認し、必要に応じて apiDump で API ダンプを更新する。Use when "apiCheck が失敗", "binary compatibility エラー", "API ダンプを更新", "公開 API の互換性チェック".
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | fix-ci-binary |
| description | バイナリ互換性チェック（./gradlew apiCheck）が失敗した時の診断と修正を行う。public API の差分を確認し、必要に応じて apiDump で API ダンプを更新する。Use when "apiCheck が失敗", "binary compatibility エラー", "API ダンプを更新", "公開 API の互換性チェック". |
バイナリ互換性チェック（apiCheck）の診断と修正スキル
./gradlew apiCheck が失敗した場合、API 変更を確認して修正する。
実行コマンド:
./gradlew apiCheck --info
エラーメッセージから把握すべき情報:
エラーメッセージ例:
Expected file with API declarations 'extension/navigation3/api/android/extension-navigation3.api' does not exist.
原因: 新しいモジュールが追加された場合や、API ファイルがコミットされていない。
修正方法:
./gradlew :module:apiDump を実行api/ ディレクトリに API ファイルが生成されたことを確認./gradlew :extension:extension-navigation:apiDump
./gradlew :extension:extension-navigation3:apiDump
確認手順:
修正方法 （意図的な変更の場合）:
api/ ディレクトリのファイルを更新修正方法:
./gradlew apiCheck を実行修正後、以下のコマンドで確認:
./gradlew apiCheck
バイナリ互換性チェックが成功すること（終了コード 0）を確認。
api/ ディレクトリには、各プラットフォーム（Android, JVM, Native等）の API 宣言が保存されるapiDump タスクで自動生成することが推奨されるNightly Checking ワークフロー上で 60 分 budget の単発探索的検証を行う運用規約。 PR 差分ではなく main の最新を対象に、 ライブラリ本体・integrationTest・docs 全体を 多角的に揺さぶり、発見都度 `.local/nightly-exploration/issues/` へ Markdown 起票する。 Kotlin / Compose / Gradle / AGP の最新 release 情報も探索範囲に含める。 Use when requested: "nightly 探索", "夜間探索的検証", "exploratory-nightly".
PR の探索的検証で 5 並列 subagent を category 別に kick する際の運用規約。 PDCA / MCP / 設定ファイル拡張 / CI ログ / apiDump / ticket 起票 / PR コメント / gradle 隔離 / working tree / 時間管理 / 他 KCP 比較 / 各 cat 役割 / ループ終了処理 / メンテナ反応 latency trace / close 後 handshake を含む。 各探索 iter で subagent を kick する前に必読。
複数の GitHub Pull Request を並行管理する際、 各 PR の CI ステータスと未対応 review コメントを 1 回のループで一括チェックし、 失敗 check の種類 (lint / binary compat / build / test / transient infra) を自動判定して対応する fix-ci-* skill (lint=fix-ci-lint, binary=fix-ci-binary, build=fix-ci-build, test=fix-ci-test, comments=fix-ci-pr-comments) に委譲、 review コメントは取得 → 修正 → commit → push → resolve まで実行する。 stack 関係 (PR Y の base が PR X のブランチ) があれば自動で rebase 連鎖。 `/loop` skill と組み合わせれば 10 分間隔などで自動化できる (5 回連続「変化なし」 で 終了)。 ユーザーが「複数 PR を見ながら修正」「PR ループ」「PR fix loop」「stacked PR を順番に green に」「PR を寝かせている間に CI 修正したい」「複数 PR の CI と review comment を自動で対応」 などと言ったら 必ずこの skill を使う。 単一 PR でも、 CI fix と review comment 対応をワンセットで自動化したい文脈なら trigger してよい。
ユーザーがプルリクエストの作成、PRの準備、またはコードレビュー用の変更案の作成を要求した際に使用するエージェントです。これには、ユーザーが明示的にプルリクエストの作成/オープン/ドラフトを依頼する場合が含まれます。 例: - <example> Context: ユーザーが新機能の実装を完了し、プルリクエストを作成したい。 user: "新しいsealed classのコピー関数機能の実装が完了しました。PRを作成してもらえますか？" assistant: "Taskツールを使用してpr-creatorエージェントを起動し、変更のプルリクエストを準備・作成します。" <commentary>ユーザーがPR作成を要求しているため、pr-creatorエージェントを使用してプルリクエストの準備と作成プロセスを処理します。</commentary> </example> - <example> Context: ユーザーが変更をコミットし、レビューの準備ができていることを述べる。 user: "バグ修正をコミットしました。レビューしてもらいましょう。" assistant: "Taskツールを使用してpr-creatorエージェントを起動し、バグ修正のプルリクエストを作成します。" <commentary>ユーザーはコードレビューの準備ができていることを示しており、これにはPR作成が必要です。pr-creatorエージェントを使用してこれを処理します。</commentary> </example> - <example> Context: ユーザーが日本語でPR作成を直接要求。 user: "Pull Requestを作成する。" assistant: "Taskツールを使用してpr-creatorエージェントを起動し、プルリクエストを作成します。" <commentary>PR作成の直接的な要求。pr-creatorエージェントを使用してプルリクエストのワークフローを処理します。</commentary> </example>
working tree にある差分を適切な粒度でコミット
Gradle ビルド（assembleDebug, compileKotlin など）が失敗した時の診断と修正を行う。コンパイルエラー、依存関係の問題、Convention Plugin の設定不備などを切り分けて修正する。Use when "ビルドが失敗", "Gradle build error", "コンパイルエラー", "compileKotlin が失敗".