TBSten

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".

このリポジトリ (debuggable-compiler-plugin) の debuggable ライブラリバージョンを 上げる。canonical source は root の `gradle.properties` の `debuggable.version=X.Y.Z`。 これと同期が必要な約 10 ファイル (各 integration-test の gradle.properties + libs.versions.toml + 3 つの README + root README の install snippet) を一括で書き換え、 最後に `chore(release): bump to X.Y.Z` で auto-commit する。単純な「next patch version」でもよいし、明示的に「0.2.0 にして」「1.0.0-rc.1 にしたい」も受け付ける。 このリポジトリで「バージョン上げて」「バージョンアップ」「N.N.N にして」「bump to X.Y.Z」「次の patch」「minor bump」「リリース準備」等を言われたら必ずこの skill を 発動。手で sed すると README 内 stale バージョンを取り残すので使わないこと。

このプロジェクト (debuggable-compiler-plugin) のサポート Kotlin バージョンを 追加・変更・削除する。Kotlin の新 patch/minor/RC/Beta を対象に、どの compat module に載せるか判定 → 必要なら新 compat module を足場作成 → VERSIONS テーブル (smoke-test-all / test-all / ci.yml / README / current.md) を同期 → kctfork と Compose の version マップを更新 → 両スクリプトで検証 → current.md に結果反映、 までを一括でやる。Kotlin バージョンまわりの変更は触る場所が多く散らばっているため この skill が必ず起動するべき。 Use when requested: "Kotlin 2.X.Y をサポートしたい", "Kotlin の新バージョン対応", "サポート Kotlin バージョン追加", "Kotlin 2.X.Y のサポートを外す", "kctfork を X にあげて", "新しい Kotlin RC / Beta を入れて", "integration-test を Kotlin 2.X.Y で動かしたい", "compat module 追加", "VERSIONS を更新", "current.md の Kotlin バージョンを直して".

Kotlin Compiler Plugin の開発・レビューを支援するスキル。 30+ の既存プラグインの調査データ (Extension Point、設計パターン、ソースコード URL) を参照し、 やりたいことに最適な Extension Point の選択、設計パターンの提案、前例のソースコード参照を行う。 deepwiki MCP を使って最新のソースコードを深掘りする機能も持つ。 Use when requested: "compiler plugin をレビュー", "compiler plugin の実装を評価", "review compiler plugin", "FIR/IR の設計をチェック", "Extension Point の選択は正しいか", "compiler plugin の前例を探して", "compiler plugin を開発したい", "この機能は FIR と IR どっちでやるべき？", "既存プラグインでこういうことやってるのある？", "compiler plugin の設計を相談したい".

Sets up a Kotlin Compiler Plugin project with multi-module Gradle structure. Creates buildSrc convention plugins (kotlin-jvm), compiler-plugin module with AutoService + KSP for plugin registration, Gradle plugin wrapper (KotlinCompilerPluginSupportPlugin), runtime API module (Kotlin Multiplatform), unit tests with kctfork (KotlinCompilation testing) + Kotest, and integration test module using kotlinCompilerPluginClasspath. Targets Kotlin 2.x K2 compiler with FIR + IR extension architecture. Use when requested: "Kotlin compiler plugin を作りたい", "compiler plugin のプロジェクトをセットアップ", "setup kotlin compiler plugin", "KotlinCompilation でテストしたい", "compiler plugin の unit test を書きたい", "FIR/IR extension のプロジェクト構成", "Gradle plugin で compiler plugin をラップ", "compiler plugin の integration test をセットアップ".

Markdown ベースのローカルチケット管理システムをプロジェクトにセットアップする。 .local/ticket/ ディレクトリにタスク・バグ・チャプターチケットを作成し、 チェックリスト形式で進捗を追跡する。Git 管理対象外のため気軽に使える。 言語・フレームワーク不問。 Use when requested: "チケットシステムを導入", "タスク管理を Markdown で", "ローカルチケット管理をセットアップ", "チケットを作成", "バグチケットを作成", "チャプターを作成", "epic を作成", "local ticket system", "setup ticket management".

Operational rules for exploratory PR verification driven by multiple parallel subagents in a Kotlin project (Android / JVM / KMP / Compose / server-side Kotlin). Covers PDCA / MCP-driven dynamic checks / ticket bookkeeping / PR comment etiquette / build isolation / time budgeting / loop termination / maintainer-response latency tracking. Designed for OSS contributors who want to deeply audit a PR alongside its maintainer without going noisy on the PR thread. Use when requested: "PR exploratory verification", "PR 探索検証", "並列 subagent kick", "PR loop", "ticket 駆動で PR review", "stacked PR を多角的に audit", "complex PR を 5 並列で深掘り".

Kotlin Compiler Plugin の開発・レビュー、および複数 Kotlin バージョン対応 (compat module layer / source set separation) の追加・削除を支援するスキル。 30+ の既存プラグインの調査データ (Extension Point、設計パターン、ソースコード URL) を参照し、 やりたいことに最適な Extension Point の選択、設計パターンの提案、前例のソースコード参照を行う。 サポート Kotlin バージョンの追加・削除では compat module の delegation pattern / capability flag / reflection shim / SSOT 駆動 CI matrix / kctfork version mapping / Java 21 toolchain pin など実運用パターンをカバーする。 deepwiki MCP を使って最新のソースコードを深掘りする機能も持つ。 Use when requested: "compiler plugin をレビュー", "compiler plugin の実装を評価", "review compiler plugin", "FIR/IR の設計をチェック", "Extension Point の選択は正しいか", "compiler plugin の前例を探して", "compiler plugin を開発したい", "この機能は FIR と IR どっちでやるべき？", "既存プラグインでこういうことやってるのある？", "compiler plugin の設計を相談したい", "複数 Kotlin バージョン対応のアーキテクチャをレビュー", "compat module layer の設計は正しいか", "source set separation を評価して", "multi-version support の設計を評価", "タンデム vs 独立リリースどちらがよいか", "Kotlin X.Y.Z をサポートしたい", "新しい Kotlin バージョン対応", "サポート Kotlin バージョンを追加したい", "Kotlin X.Y.Z のサポートを外したい", "compat module を追加したい", "CI matri

Sets up a Kotlin Compiler Plugin project with multi-module Gradle structure. Creates buildSrc convention plugins (kotlin-jvm), compiler-plugin module with AutoService + KSP for plugin registration, Gradle plugin wrapper (KotlinCompilerPluginSupportPlugin), runtime API module (Kotlin Multiplatform), unit tests with kctfork (KotlinCompilation testing) + Kotest, and integration test module using kotlinCompilerPluginClasspath. Targets Kotlin 2.x K2 compiler with FIR + IR extension architecture. Use when requested: "Kotlin compiler plugin を作りたい", "compiler plugin のプロジェクトをセットアップ", "setup kotlin compiler plugin", "KotlinCompilation でテストしたい", "compiler plugin の unit test を書きたい", "FIR/IR extension のプロジェクト構成", "Gradle plugin で compiler plugin をラップ", "compiler plugin の integration test をセットアップ".

Markdown ベースのローカルチケット管理システムをプロジェクトにセットアップする。 .local/ticket/ ディレクトリにタスク・バグ・チャプターチケットを作成し、 チェックリスト形式で進捗を追跡する。Git 管理対象外のため気軽に使える。 言語・フレームワーク不問。 Use when requested: "チケットシステムを導入", "タスク管理を Markdown で", "ローカルチケット管理をセットアップ", "チケットを作成", "バグチケットを作成", "チャプターを作成", "epic を作成", "local ticket system", "setup ticket management".

cream のリリースノート・リリース準備資料を作成する。前バージョンからの変更を git log / merged PR から収集し、.local/v<version>-release-note/ に 3 ファイル構成（all.md=全変更リスト / highlight.md=ヘッドライン級のみ / release-note.md=GitHub Release に貼る英日併記本文）でまとめ、バージョン bump〜publish 確認までのリリース手順を案内する。Use when: "release note を書きたい", "リリースノート", "リリース準備", "次バージョンの変更をまとめて", "release notes for the next version".

Build a golden snapshot test for a cream.kt KSP feature/annotation by horizontally extending the established @CopyTo / @CopyFrom pattern. Use whenever the user wants to add, build, or "横展開" (roll out) a `<Feat>SnapshotTest` for a cream annotation — @CopyToChildren, @SealedCopy, @CombineTo, @CombineFrom, @CopyMapping, @CombineMapping (or any cream annotation) — including replacing a `<Feat>SnapshotTest` xtest stub, building scenario families, or getting golden coverage for cream's generated copy/combine functions. Trigger even if the user just names a feature and says "add the snapshot test" without mentioning copyTo or copyFrom. This is for the cream.kt repo (me.tbsten.cream KSP plugin) specifically.