本文へ移動
cccskills
無料GitHub で公開

pr-green

Pull Request をグリーンにするスキル。CI チェックの失敗解消と、PR に紐づく Issue の 修正・クローズを一括で実行する。

GitHub Actions の CI ログ分析、ローカル CI (`./scripts/ci-check.sh`)の実行、エラーの根本原因特定と修正、PR コメントや リンクされた Issue の解消を含む。解消した Issue は確認後にクローズする。

ループモード(`/loop 5 /pr-green`)にも対応し、自律的に CI 監視・修正・プッシュを繰り返す。

トリガー:「PR をグリーンにして」「CI を通して」「CI エラーを直して」 「PR の issue を解消して」「PR を修正して」「CI が落ちている」「テストが失敗している」 「PR のレビュー指摘を直して」「PR を mergeable にして」 といった PR 修正・CI 解消関連リクエストで起動。

PR 番号が指定されなくても、 現在のブランチから自動検出して対応する。

インストール方法を見る

含まれるファイル(1)

  • SKILL.md6.4 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

PR Green スキル

PR の CI チェック失敗と紐づく Issue を解消し、PR をマージ可能な状態にする。

動作モード

モード起動方法振る舞い
対話モード/pr-green or 「CI を直して」状況報告→ユーザー確認→修正→確認→プッシュ
ループモード/loop 5 /pr-green自律的に監視・修正・コミット・プッシュ。問題なければ即終了

/loop 経由で呼ばれた場合はループモードとして動作する。判断がつかない場合は対話モードとする。

モード別の振る舞いの違い

判断ポイント対話モードループモード
状況サマリー詳細に表示し確認を取る問題がある場合のみ簡潔に表示
修正前の確認ユーザーに方針確認確認なしで修正を開始
コミット・プッシュユーザー確認後自動
Issue クローズ一覧提示→承認後クローズ自動クローズ(コメント付き)
問題なしの場合「すべてグリーンです」と報告何も出力せず即終了
結果報告詳細な修正レポート修正した場合のみ簡潔に報告
判断困難な問題ユーザーに相談スキップして報告

ワークフロー

ステップ 0: PR の特定

引数で PR 番号が指定されていればそれを使う。指定がなければ現在のブランチから自動検出する。

gh pr view --json number,title,state,statusCheckRollup,url,headRefName

PR が見つからない場合は報告して終了する。

ステップ 1: 状況の把握

1a. CI チェックの状態確認

gh pr checks <number>

# 失敗した CI の詳細ログ(run-id は checks 結果から特定)
gh run view <run-id> --log-failed

1b. PR に紐づく Issue の確認

PR レビューコメント(CodeRabbit 等のボットレビュー含む):

gh api repos/{owner}/{repo}/pulls/<number>/reviews --jq '.[] | select(.state != "APPROVED") | {user: .user.login, state: .state, body: .body}'
gh api repos/{owner}/{repo}/pulls/<number>/comments --jq '.[] | {user: .user.login, body: .body, path: .path, line: .line, created_at: .created_at}'

PR にリンクされた Issue:

gh pr view <number> --json closingIssuesReferences --jq '.closingIssuesReferences[] | {number, title}'

1c. 早期終了判定(ループモード)

以下の条件をすべて満たす場合は何もせず即終了する:

  • CI チェックがすべて成功(PASS)または実行中(PENDING)
  • 未対応のレビューコメントがない
  • リンクされた Issue がすべてクローズ済み

CI が実行中(PENDING)の場合も即終了 — 次のループ周回で結果を確認する。

1d. 状況サマリー(対話モードのみ)

対話モードでは状況サマリーを表示し、対応方針の確認を取る。

ステップ 2: CI エラーの解消

CI エラーを分類し、優先度順に対応する。

優先度エラー種別再現コマンド
1コンパイルエラーエラーメッセージから直接特定
2lint / fmt./scripts/ci-check.sh ai lint, ./scripts/ci-check.sh ai dylint
3テスト失敗./scripts/ci-check.sh ai unit-test, ./scripts/ci-check.sh ai integration-test
4clippy./scripts/ci-check.sh ai clippy
5doc テスト./scripts/ci-check.sh ai doc

各エラーに対して:再現→分析→修正→同じコマンドで検証。

ステップ 3: PR の Issue 解消

3a. レビューコメントへの対応

指摘箇所のコードを読み、指摘に沿って修正する。

3b. リンクされた Issue への対応

Issue 本文から対象コード・問題・期待動作を抽出し、修正・検証する。

3c. 解消済み Issue のクローズ

gh issue close <number> --comment "$(cat <<'EOF'
## 解決確認

- PR: #<pr-number>
- 修正内容: <具体的な修正の説明>
- 確認方法: <テスト結果やコード確認の根拠>

本 PR の修正により解消されたためクローズします。
EOF
)"

対話モードではクローズ前にユーザー承認を取る。ループモードでは自動クローズする。

ステップ 4: コミット・ローカル検証・プッシュ

修正した箇所に関連するチェックのみローカルで再実行する。 フルチェックはローカルでは実行しない — CI に任せる。

対話モードではコミット・プッシュ前にユーザー確認を取る。ループモードでは自動で行う。

プッシュ後の CI 結果は、次のループ周回(ループモード)または gh pr checks --watch(対話モード)で確認する。

ステップ 5: 結果報告

対話モード: 修正内容・Issue 対応・残存事項の詳細レポート。

ループモード: 修正があった場合のみ簡潔に1行報告。修正なし(早期終了)の場合は出力なし。

完了条件

  • CIエラーがないこと
  • PRについたコメント/issueが解決できていること
  • ボーイスカウトルールを適用すること

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

aggregate-design

無料日本語概要

DDDの集約(Aggregate)設計ルールに基づくコードレビュー・設計支援・リファクタリングを行う。 Evans Rules、Vernon's 4 Rules、Design by Contractに基づき、集約の境界定義、不変条件の検証、 不変(Immutable)設計、ID参照、結果整合性、ドメインイベント連携を包括的にガイドする。 以下のいずれかに該当する場合は必ずこのスキルを使用すること: - 集約(Aggregate)の新規設計・実装・リファクタリング(どの言語でも) - 既存の集約やエンティティクラスのDDD観点でのコードレビュー - 集約の境界決定(「AとBは同じ集約にすべきか?」「この集約は大きすぎるか?」) - 集約内の不変条件・整合性境界の設計 - 集約間の連携方式の判断(ドメインイベント、結果整合性、Sagaパターン) - 可変(Mutable)な集約コードを不変(Immutable)設計にリファクタリングする - publicフィールド、直接参照、push/appendなどカプセル化違反の検出・修正 キーワード例:集約、Aggregate、aggregate boundary、集約ルート、AggregateRoot、 エンティティ設計、DDD実装、Vernon Rules、Evans Rules、集約の分割、真の不変条件

j5ik2o/okite-ai802026年4月25日 更新

aggregate-transaction-boundary

無料日本語概要

集約とトランザクション境界の関係を明確化し、複数集約を単一トランザクションに含めるアンチパターンを 検出・是正する。集約は強い整合性境界であり、ユースケースで複数集約を更新する場合は結果整合性を 使うべきという原則を適用する。コードレビュー、ユースケース設計、リファクタリング時に トランザクション境界の問題を検出する場合に使用。 対象言語: 言語非依存(Java, Kotlin, Scala, TypeScript, Go, Rust, Python等すべて)。 トリガー:「複数集約を同じトランザクションで更新している」「ユースケースに@Transactionalがある」 「集約間の整合性をどう取るか」「Sagaパターンを使うべきか」「トランザクション境界の設計」 「1トランザクション1集約」「結果整合性の実装」「集約をまたぐトランザクション」 といったトランザクション境界関連リクエストで起動。

j5ik2o/okite-ai802026年4月25日 更新

backward-compat-governance

無料日本語概要

後方互換性がゴミコードを量産する構造を検出し、互換性を「契約と撤去計画」として管理する ガバナンスを支援するスキル。公開API境界の明確化、非推奨化サイクル(deprecation cycle)の 制度化、互換層の局所化(Adapter/Strangler Fig)、契約テスト(CDC)による互換性検証、 AI生成コードの互換性ゲート設計を含む。コードレビュー、API設計、リファクタリング、 レガシー移行時に互換性起因の技術的負債を防ぐために使用。 対象言語: 言語非依存(Java, TypeScript, Go, Python, Rust等すべて)。 トリガー:「後方互換性を保ちたい」「非推奨APIをどうする」「互換層が増えてきた」 「レガシー移行の戦略」「API設計レビュー」「互換性のためのコードが多い」 「deprecation policyを作りたい」「破壊的変更の管理」といった互換性管理関連リクエストで起動。

j5ik2o/okite-ai802026年4月25日 更新

breach-encapsulation-naming

無料日本語概要

getterの濫用を防ぐための命名規約スキル。ドメインモデルでgetterが必要な場合(永続化、JSON変換など)に `breachEncapsulationOf` プレフィックスを付与することで、カプセル化を破っていることを明示する。 これにより、Tell Don't Ask原則の違反を未然に防ぎ、getterの意図しない使用を抑制する。 コードレビュー、新規実装、リファクタリング時にgetter設計が必要な場合に使用。 対象言語: Java, Kotlin, Scala, TypeScript, Python, Go, Rust。 トリガー:「getterの命名規約」「カプセル化を破るgetter」「永続化用のgetter」 「breachEncapsulation」「getterを作りたいが濫用を防ぎたい」といったgetter命名関連リクエストで起動。

j5ik2o/okite-ai802026年4月25日 更新

clean-architecture

無料日本語概要

クリーンアーキテクチャを採用しているプロジェクト向けの設計・レビュー支援。4層構造(ドメイン層、 ユースケース層、インターフェースアダプタ層、インフラストラクチャ層)に基づく。特にインフラ層は 横断的関心事(ロギング、設定管理)のみ、永続化やRPCはインターフェースアダプタ層に配置すべき という原則を適用する。トリガー:「クリーンアーキテクチャで」「クリーンアーキテクチャに従って」 「クリーンアーキテクチャのレビュー」など、クリーンアーキテクチャを明示的に指定した場合のみ起動。 一般的な「設計レビュー」「アーキテクチャ相談」では起動しない。

j5ik2o/okite-ai802026年4月25日 更新

cqrs-aggregate-modeling

無料日本語概要

CQRS/ESが集約の境界定義とモデリングに与える影響を解説する。CQRSを導入すると集約は コマンド実行に必要な最小限の状態のみ保持すればよくなり、読み取り責務はリードモデルに 委譲できる。大きすぎる集約の軽量化、集約境界の再定義、イベントによる状態管理を支援する。 集約設計、CQRS導入時のモデリング見直し、パフォーマンス問題の解決時に使用。 対象言語: 言語非依存。 トリガー:「CQRSで集約が変わる」「集約が大きすぎる」「集約にメッセージ1000件」 「集約の更新が重い」「CQRS導入で集約を見直す」「集約を軽量化したい」 「集約にクエリ用データが混ざっている」「集約の境界を再定義」 といったCQRS/モデリング関連リクエストで起動。

j5ik2o/okite-ai802026年4月25日 更新

j5ik2o のスキルをすべて見る

このスキルの問題を報告する