Skip to content
cccskills
FreePublished on 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 番号が指定されなくても、 現在のブランチから自動検出して対応する。

The English summary is being prepared. Showing the original description.

Works withGitHub
See how to install

Files included (1)

  • SKILL.md6.4 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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が解決できていること
  • ボーイスカウトルールを適用すること

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

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、集約の分割、真の不変条件

The English summary is being prepared. Showing the original description.

j5ik2o/okite-ai80Updated Apr 25, 2026

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

The English summary is being prepared. Showing the original description.

j5ik2o/okite-ai80Updated Apr 25, 2026

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

The English summary is being prepared. Showing the original description.

j5ik2o/okite-ai80Updated Apr 25, 2026

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

The English summary is being prepared. Showing the original description.

j5ik2o/okite-ai80Updated Apr 25, 2026

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

The English summary is being prepared. Showing the original description.

j5ik2o/okite-ai80Updated Apr 25, 2026

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

The English summary is being prepared. Showing the original description.

j5ik2o/okite-ai80Updated Apr 25, 2026

See all skills by j5ik2o

Report a problem with this skill