compose-preview-lab

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 にある差分を適切な粒度でコミット

バイナリ互換性チェック（./gradlew apiCheck）が失敗した時の診断と修正を行う。public API の差分を確認し、必要に応じて apiDump で API ダンプを更新する。Use when "apiCheck が失敗", "binary compatibility エラー", "API ダンプを更新", "公開 API の互換性チェック".

Gradle ビルド（assembleDebug, compileKotlin など）が失敗した時の診断と修正を行う。コンパイルエラー、依存関係の問題、Convention Plugin の設定不備などを切り分けて修正する。Use when "ビルドが失敗", "Gradle build error", "コンパイルエラー", "compileKotlin が失敗".

Kotlin リントチェック（./gradlew ktlintCheck）が失敗した時の診断と修正を行う。ktlintFormat による自動修正と、手動修正が必要なケースの切り分けを案内する。Use when "ktlintCheck が失敗", "lint エラー", "コードスタイル違反", "ktlintFormat".

PR に付いたレビューコメントへ対応するワークフロー。gh CLI でコメントを取得し、TodoWrite で追跡しながら修正・返信・resolve まで進める。Use when "PR コメントに対応", "レビュー指摘を修正", "PR レビュー対応", "review comments を resolved にする".

GitHub Actions の CI/CD 環境構築・セットアップ周りの問題（JDK バージョン、キャッシュ設定、シークレット、ワークフロー定義）を診断・修正する。Use when "CI のセットアップ問題", "GitHub Actions の設定", "JDK バージョン問題", "ワークフロー定義の修正".

CI（継続的インテグレーション）の問題を診断し、修正するためのエージェントです。GitHub Actionsのワークフローが失敗した際に、問題を特定し、修正方法を提案・実行します。 例: - <example> Context: ユーザーがCIの失敗を報告している。 user: "CIが失敗しています。修正してください。" assistant: "CI設定を確認し、失敗しているジョブを特定して修正します。" <commentary>CIの問題を修正する必要があるため、ci-fixerエージェントを使用して問題を診断・修正します。</commentary> </example> - <example> Context: プルリクエストのCIチェックが失敗している。 user: "PRのCIが失敗している。何が問題か確認して。" assistant: "CI設定とエラーログを確認し、問題を特定して修正します。" <commentary>CIの失敗を診断する必要があるため、ci-fixerエージェントを使用します。</commentary> </example>

CI で実行される各種テスト（jvmTest, jsBrowserTest, wasmJsBrowserTest, testDebugUnitTest, iosSimulatorArm64Test, integrationTest）の失敗を診断・修正する。Property-Based Test (PBT タグ) の扱いも含む。Use when "テストが失敗", "jvmTest が失敗", "Kotest 失敗", "PBT が落ちる", "integrationTest 失敗".

機能やバグ修正を最初から最後まで実装するためのエージェントです。実装内容を理解し、期待されるアウトプットと検証方法を定義してから実装を進めます。 例: - <example> Context: ユーザーが新機能の実装を依頼している。 user: "新しいアノテーション機能を実装してください。" assistant: "実装内容を理解し、期待されるアウトプットと検証方法を定義してから実装を進めます。" <commentary>実装タスクのため、implエージェントを使用して実装プロセスを進めます。</commentary> </example>