Communitygithub.com

コードレビューループ

PRからデプロイまでのライフサイクルを管理するエージェントスキル

コードレビューループ とは?

このスキルは、PR作成からレビュー対応、マージ、デプロイ監視、障害復旧までの完全なライフサイクルを自動化します。ユーザーの明示的な承認を得た後、ブランチを公開し、PRをオープンまたは更新し、レビューフィードバックを処理し、ゲート通過後にマージし、結果のデプロイメントを監視・復旧します。Greptileスコア、必須チェック、ブロックスレッドなどの証拠を用いて各ゲートを通過し、最終的にDEPLOYED、BLOCKED_PREFLIGHT、BLOCKED_REVIEW、BLOCKED_MERGE、BLOCKED_DEPLOYMENTのいずれかの結果を報告します。このスキルは、コードレビューとデプロイのプロセスにおいて、確実な証拠に基づいた厳格な進行を求める開発者やAIエージェントに最適です。

対応~Claude Code~Codex CLI~Cursor
npx skills add 0xrohan10/skills

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

コードレビューループ は何をしますか?

明示的にリクエストされたPRからデプロイまでのライフサイクルだけを担当します。finalizeまたは同等の証拠によって生成されたマージ準備完了状態のツリーから開始します。一般的な強化はfinalizeに、動作を維持するクリーンアップはsimplifyに属します。

認可と結果

現在の会話で完全なライフサイクル(ブランチの公開、PRのオープンまたは更新、レビューフィードバックの処理、ゲート通過後のマージ、結果のデプロイメントの監視と復旧)が明示的に認可された場合に開始します。認可がない場合、最初の未認可の遷移の前にBLOCKED_AUTHORIZATIONが生成されます。

最終結果は以下のとおりです。

  • DEPLOYED: すべてのマージおよびデプロイゲートを通過しました。
  • BLOCKED_PREFLIGHT: ツリー、リポジトリ状態、ベースブランチ、または必要なアクセスが準備できていません。
  • BLOCKED_REVIEW: 最新のヘッドSHAが予算内でレビューゲートに到達できません。
  • BLOCKED_MERGE: レビューゲートは通過しましたが、ポリシー、権限、またはプラットフォームの状態により検証済みマージができません。
  • BLOCKED_DEPLOYMENT: デプロイメントが復旧予算内で通過できないか、安全でない/認可されていない決定が必要です。

通常の追加コミットとプッシュを使用します。フォースプッシュ、直接ベースブランチへのコミット、本番データの変更、シークレット/権限の変更、課金の変更、またはインフラストラクチャポリシーの変更には、個別の明示的な認可とリポジトリのサポートが必要です。

不変条件の解決

リポジトリの状態を変更する前に、以下の手順を実行します。

  1. 該当するリポジトリの指示を読み、コミット、PR、マージ、必須チェック、デプロイメントポリシーを発見します。
  2. ユーザーから明示的なターゲットが提供された場合は、そこから<base-branch>を解決します。既存のPRのベースはそれと一致している必要があります。明示的なターゲットがない場合は、既存のPRのベース、次にプロバイダメタデータまたはorigin/HEADからのリモートデフォルトを使用します。ブランチがリモートに存在することを確認し、一度記録し、<base-branch>を全体で使用します。
  3. トピックブランチ、リモート、PRプラットフォーム、必須レビューア/チェック、マージ方法、デプロイプロバイダ、および必須デプロイターゲットを解決します。
  4. 有限の予算を記録します。リポジトリ/ユーザーの値が提供されている場合はそれを使用します。それ以外の場合は、PRごとに5つのレビュー済みヘッドSHA、ヘッドSHAあたり少なくとも60秒間隔で20分のレビューポーリング、2回のデプロイ復旧試行、および必要なデプロイメントごとに30分を使用します。

不変条件の解決は、上記のすべてのプレースホルダーに1つの証拠となる値があり、すべての予算が有限である場合に完了します。矛盾または欠落している重要な値がある場合は、BLOCKED_PREFLIGHTが生成されます。

事前チェックと公開

現在のツリーに対してTREE_MERGE_READYの結果、または範囲、調査結果、簡略化、検証をカバーする同等の証拠が必要です。それ以外の場合はBLOCKED_PREFLIGHTを返し、準備をfinalizeにルーティングします。

現在のステータス、ブランチ、完全な意図された差分、追跡されていないファイル、およびgit diff --checkを検査します。無関係な作業がステージングから除外されていること、および意図された生成アーティファクト、シークレットポリシー、リポジトリチェックがまだ準備の証拠と一致していることを確認します。

現在のブランチが<base-branch>である場合は、ステージングの前に認可されたトピックブランチを作成します。意図されたファイルのみをステージングし、ステージングされた差分とチェックを検査し、リポジトリポリシーに従ってコミットし、通常どおりプッシュします。トピックブランチの既存のPRを再利用するか、変更、根拠、検証、および重要な注意事項を含めて新しいPRをオープンします。

事前チェックは、リモートトピックのヘッドがローカルのHEADと等しく、PRが<base-branch>をターゲットにしており、PRの差分に意図された変更のみが含まれている場合に完了します。

制限付きヘッドSHAレビュー

各PRは独立したヘッドSHA予算を取得します。サイクルは1つの不変の<head-sha>にバインドされます。

  1. 各プッシュ後にリモートPRのヘッドSHAをキャプチャし、レビュー済みヘッドカウントをインクリメントします。設定されたカウントを超えるSHAはBLOCKED_REVIEWを生成します。
  2. SHAごとの期限までポーリングし、Greptileの出力と、プラットフォームの証拠がその正確なSHAにリンクする必須チェックを取得します。古いコメントとスコアは履歴であり、現在の証拠ではありません。
  3. Greptileスコア、必須チェック結果、ブロックスレッド、およびすべての現在のコメントの処分(修正、既に対処済み、誤り/古い、範囲外、または動作リスクの決定)を記録します。
  4. クリーンアップのみの修正は、PRの解決済み<base-branch>と現在の<head-sha>を有効な差分としてsimplifyにルーティングします。正確性の修正は、リポジトリの証拠が明確な範囲内の回答を示す場合にのみ適用します。無効にされたすべてのサーフェスを検証します。変更なしの処分には証拠を添えて返信します。
  5. 一貫性のある修正セットをコミットしてプッシュします。新しいリモートSHAが次のサイクルを開始します。以前のサイクルはそのゲートを満たすことができません。

製品または契約の意図が必要な動作リスクの決定、無関係な原因による必須チェックの失敗、期限でのレビュー証拠の欠如、またはヘッド予算の枯渇は、正確な証拠とともにBLOCKED_REVIEWを生成します。

マージゲート

以下のすべてのステートメントが同じ観測された<head-sha>で真である場合にのみマージします。

  • <head-sha>が最新のリモートPRヘッドと等しい。
  • Greptileが<head-sha>に対して5/5を報告している。
  • すべての必須チェックが<head-sha>に対して成功を報告している。
  • すべてのブロックスレッドが解決され、すべてのレビューコメントに記録された処分がある。
  • PRがマージ可能であり、リポジトリの更新および承認ポリシーを満たしている。
  • <base-branch>との新しい比較に、意図された差分のみが含まれている。

リポジトリの確立されたマージ方法を使用します。プラットフォームから<merged-sha>をキャプチャし、リモートの<base-branch>にそれが含まれていること、またはスカッシュ/リベースワークフローの場合はプラットフォームが報告した結果のコミットが含まれていることを確認します。いずれかのステートメントの失敗はBLOCKED_MERGEを生成します。レビューの失敗は、予算が残っている間のみ制限付きレビューループに戻ります。

デプロイメントゲート

結果の<merged-sha>によってトリガーされた各必須デプロイメント、またはそれを含むことが証明された後の<base-branch>コミットによってトリガーされた各必須デプロイメントを見つけます。それぞれが成功するか期限に達するまで監視し、プロバイダのステータス、および関連するビルド、移行、ランタイム、ヘルスの証拠を保持します。

以下のすべてのステートメントが真である場合にのみDEPLOYEDを報告します。

  • PRが解決済みの<base-branch>にマージされ、リモート履歴にプラットフォームが報告した結果が含まれている。
  • すべての必須デプロイメントがその結果、または<base-branch>上の証明された子孫に関連付けられている。
  • すべての必須デプロイメントおよびデプロイ後のヘルス/リリースチェックが、期限内に最終的な成功を報告している。
  • 保留中、失敗、キャンセル、またはタイムアウトになった必須ターゲットがない。

制限付きデプロイメント復旧

必須デプロイメントが失敗した場合、プロバイダの証拠から最小の因果ブロッカーを診断します。無関係な失敗、不明確な因果関係、または個別に認可されたアクションを必要とする修正はBLOCKED_DEPLOYMENTを生成します。

利用可能な各復旧試行について、以下の手順を実行します。

  1. 復旧カウントをインクリメントし、リモートの<base-branch>を更新し、その正確な先端から復旧ブランチを作成します。デフォルトの復旧パスはブランチとPRです。ベースブランチは編集ワークスペースではなく、統合ターゲットのままです。
  2. 因果修正のみを適用し、finalizeを実行して復旧差分に対するTREE_MERGE_READYを確立します。
  3. <base-branch>をターゲットとする復旧PRを公開します。新しい制限付きヘッドSHAレビューループを与え、完全なマージゲートを要求します。
  4. 新しいマージ結果をキャプチャし、無効にされたすべてのターゲットに対して完全なデプロイメントゲートを再実行します。

直接の<base-branch>コミットは、ユーザーが現在の会話で個別に認可し、リポジトリポリシーが許可する場合にのみ使用します。復旧回数または復旧PRのレビュー予算を使い果たすとBLOCKED_DEPLOYMENTが生成されます。

報告

最終結果、<base-branch>、PR URL、最新のレビュー済みヘッドSHAと予算使用量、Greptileスコア、チェック、コメントの処分、マージ方法と結果のSHA、デプロイメントターゲット、URL、証拠、復旧使用量、およびすべてのブロッカーを返します。完全なデプロイメントゲートが通過した後にのみ、DEPLOYEDとして成功を主張します。

関連スキル