unblock-pr

PR のブロック解除

1 行での要約：失敗している PR の CI パイプラインを調査します。各失敗を不安定、インフラ、回帰のいずれかに分類し、的を絞った対処を提案します。

必要なもの：dd-pup スキル（pup CLI のインストールと認証が必要）、triage-flaky-test スキル（不安定な失敗を詳細に調査するため）。

---

バックエンド

検出 — 呼び出しのたびに、何らかの操作を行う前に、使用するバックエンドを判定します。

1. ユーザーがどこかで --backend pup を指定した場合 → 直ちに pup モードを使用します。手順 2〜4 はスキップします。
2. 利用可能なツールに search_datadog_ci_pipeline_events が含まれているか確認します。
3. 含まれている場合 → 最初から最後まで MCP モードを使用します。このスキルのワークフローの各セクションで指定されたとおりにツールを呼び出します。
4. 含まれていない場合 → pup が実行可能か確認します。Bash 経由で pup --version を実行します。コマンドが正常終了（終了コード 0）した場合、pup を利用できます。
5. pup が応答した場合 → 最初から最後まで pup モードを使用します。このファイル末尾のツールリファレンス付録を使って、すべてのツール呼び出しを置き換えます。
6. どちらも利用できない場合 → 中止し、ユーザーに次のように伝えます。

   「Datadog MCP サーバーも pup CLI も利用できません。MCP サーバーに接続するか、pup をインストールしてください（brew install datadog-labs/pack/pup）。」

pup の呼び出しルール：

• Bash 経由で呼び出します。pup は常に JSON を出力するため、そのまま解析します。
• pup に渡すリポジトリ ID はすべて小文字にする必要があります（API は大文字と小文字が混在した値を拒否します）。github.com/DataDog/my-repo ではなく、github.com/datadog/my-repo を指定します。
• pup が 401/403 を返した場合は、ユーザーに pup auth refresh または pup auth login を実行するよう伝えます。

---

入力

パラメーター	説明
PR ブランチ	調査対象のブランチ（例：my-feature-branch）
リポジトリ	小文字のスキーマなし URL（例：github.com/org/repo）。指定されていない場合は、git remote get-url origin から取得します。

---

ワークフロー

STEP 0 — 入力の解析

指定されていない場合は、git からリポジトリ ID とデフォルトブランチを取得します。

# Repository ID: fully lowercase, no-schema URL (the API rejects mixed-case)
git remote get-url origin
# Strip protocol and trailing .git, then lowercase the result
# e.g. https://github.com/DataDog/my-repo.git → github.com/datadog/my-repo

# Default branch
git symbolic-ref refs/remotes/origin/HEAD
# Strip refs/remotes/origin/ prefix — fall back to main if unset

STEP 1 — PR の CI 概要を取得（並列実行）

パイプラインの失敗：

Tool: search_datadog_ci_pipeline_events
query: @ci.status:error @git.branch:<branch> @git.repository.id_v2:"<repo>"
ci_level: job
from: now-24h

テストの失敗（パイプラインの結果にテストランナーのジョブが含まれる場合のみ）：

Tool: search_datadog_test_events
query: @test.status:fail @git.branch:<branch> @git.repository.id_v2:"<repo>"
from: now-24h
test_level: test

両方を並列実行します。テストイベントの結果から、重複しないすべての @test.service 値を収集します。重複しないサービスが複数見つかった場合は、トリアージの概要にそれぞれ個別に記載します。単一のサービスフィルターにまとめないでください。パイプラインの結果にビルド、lint、デプロイなどのインフラジョブタイプのみが含まれ、テストランナーの出力がない場合は、テスト結果を破棄して STEP 3 に進みます。

STEP 1.5 — PR の健全性を取得（STEP 1 と並列実行）

この手順は常に実行します。CI が失敗していても成功していても、PR の健全性に関する情報は有用です。

コードカバレッジ（両モード）：

Tool: get_datadog_code_coverage_branch_summary
repository_id: <repo>
branch: <branch>

PR 番号の解決（MCP モードのみ — PR 番号が入力としてすでに指定されている場合はスキップ）：

Tool: get_prs_by_head_branch
repo_url: https://<repo>
head_branch: <branch>

返された最初のオープン PR を使用します。オープン PR が見つからない場合は、品質／セキュリティの取得をスキップし、品質とセキュリティについて「データなし」と報告します。

コード品質とセキュリティ（MCP モードのみ — PR 番号を取得できている場合のみ）：

Tool: search_pr_insights
repo_url: https://<repo>
pr_number: <pr_number>

products_status から code_quality と code_security のみを抽出します。failed_tests、flaky_tests、failed_jobs は無視します。CI データは STEP 1〜3 から取得します。

pup モードに関する注意： PR 番号の解決と search_pr_insights は pup では利用できません。pup モードでは、品質とセキュリティは常に「データなし」と表示されます。

STEP 2 — 失敗した各ジョブの Blame Guard

まず、STEP 1 のジョブイベントに @error_classification.domain／@error_classification.type が存在するか確認します。値が設定されている場合は、主要な分類シグナルとして使用します。

分類が引き続き必要な、失敗した各ジョブについて、次の 2 つの確認を並列で実行します。

デフォルトブランチの確認 — このジョブは、この PR より前からすでに失敗していましたか？

Tool: aggregate_datadog_ci_pipeline_events
query: @ci.status:error @ci.job.name:"<job>" @git.branch:<default-branch> @git.repository.id_v2:"<repo>"
ci_level: job
aggregation: count
from: now-24h

影響範囲の確認 — このジョブは、ほかのブランチでも失敗していますか？

Tool: aggregate_datadog_ci_pipeline_events
query: @ci.status:error @ci.job.name:"<job>" @git.repository.id_v2:"<repo>"
ci_level: job
aggregation: count
group_by: ["@git.branch"]
from: now-24h

パフォーマンス上のフォールバック：影響範囲のクエリに時間がかかる、またはタイムアウトする場合はスキップし、デフォルトブランチの確認のみを使用します。

STEP 3 — 各失敗を分類する

優先順位：

1. @error_classification.domain / @error_classification.type がある場合 → 主な判定材料として使用します
2. テストが失敗しており、get_datadog_flaky_tests で flaky_test_state:active となっている場合 → flaky
3. blame ガードの結果を使用します：

デフォルトブランチで失敗しているか？	ほかの3つ以上のブランチでも失敗しているか？	分類
はい	はい	infra（既存の広範な問題）
はい	いいえ	infra（デフォルトブランチで発生している既存の問題）
いいえ	いいえ	regression（この PR で導入された問題）
いいえ	はい	flaky（ブランチ間で断続的に発生）
データ不足	—	unknown

STEP 4 — トリアージ概要を作成する

失敗したジョブごとに1件作成します。

PR CI Triage Brief
==================
Branch:   <branch>
Repo:     <repo>

Job: <job-name>
  Classification:  <flaky | infra | regression | unknown>
  Evidence:        <1 key data point — error message, pipeline count, or test result>
  Confidence:      <high | medium | low>
  Recommended:     <action>

[repeat for each failing job]

Overall: <N> failures — <e.g. "1 regression, 1 flaky, 1 infra">

PR Health
=========
Coverage:   <X>% on <branch> | No data available
Quality:    <N violations (X high, Y medium)> | No violations | No data available
Security:   <N violations> | No violations | No data available

必ず3行すべてを記載します。ツールからデータが返されなかった場合、またはツールが利用できない場合（Quality/Security の pup モード）は、「データを利用できません」と記載します。

STEP 5 — 対応を提案する

regression → ユーザーにコードの変更を調査するよう促します。書き込み操作は利用できません。

flaky → 詳細な調査のため、triage-flaky-test スキルを読み込みます。flaky と分類された失敗テスト名ごとに1回、そのテスト名（STEP 1 の結果にある @test.name）と、導出したリポジトリを入力として渡して実行します。このスキルでは、次の処理を行います。

• flaky_category とスタックトレースを使って、エージェントによる修正を試みます
• すぐに修正できない場合は、update_datadog_flaky_test_states による隔離を提案します

infra → 再試行を提案する前に、失敗が一時的なものかどうかを評価します。

• @error_classification.type とエラーメッセージを確認し、timeout、runner unavailable、network error、quota exceeded などの兆候を探します。これらは再試行が有効と考えられる一時的な失敗です
• エラーが決定的なもの（ビルド設定の誤り、シークレットの欠落、明示的なテストアサーションの失敗）の場合、再試行しても効果は期待できません。根本原因を調査するよう提案します
• デフォルトブランチですでに発生している問題の場合は、ユーザーにその旨を伝えます。再試行しても再び失敗する可能性が高いため、上流で修正されるまで待つよう案内します

一時的な失敗の場合：

MCP モード — GitHub Actions： retry_datadog_ci_job を使用します。失敗したジョブイベントから、以下を取得します。

• @ci.provider.name → ci_provider（"github"）
• @git.repository.id_v2 → repository_id
• @ci.job.id → job_id
• イベントの id フィールド → event_uuid（任意）

pipeline_id には、@ci.pipeline.id が ^\d+-[1-9]\d*$（例：26027867390-1）に一致する場合、その値を直接使用します。単独の数値の実行 ID の場合は、同じイベントの @github.run_attempt と組み合わせて、"{@ci.pipeline.id}-{@github.run_attempt}" とします。フォールバックとして、@ci.pipeline.url から {run_id} と {attempt} を抽出します（runs/{run_id}/attempts/{attempt}）。

再試行の実行後、search_datadog_ci_pipeline_events（query: @ci.job.name:"<job>" @git.branch:<branch>、from: now-5m）で新しい実行が表示されることを確認します。

フォールバック／pup モード — GitHub Actions： @ci.pipeline.url から実行 ID を抽出します。

gh run rerun <run_id> --failed

GitLab／その他のプロバイダー（両方のモード）：@ci.pipeline.url を共有し、プロバイダーの UI を案内します。

unknown → CI プロバイダーの UI、またはパイプラインイベントの @ci.pipeline.url から、ジョブの生ログを確認するよう提案します。

---

ツールリファレンス

この付録は pup モード の場合にのみ適用されます。MCP モードでは、ワークフローのセクションに記載されているツール名を直接使用してください。

MCP ツール	pup コマンド
search_datadog_ci_pipeline_events (ci_level: job)	pup cicd events search --query "..." --level job --from 24h --limit 50
aggregate_datadog_ci_pipeline_events (count, group_by branch)	pup cicd events aggregate --query "..." --compute count --group-by "@git.branch" --from 24h
aggregate_datadog_ci_pipeline_events (count, no group_by)	pup cicd events aggregate --query "..." --compute count --from 24h
search_datadog_test_events	pup cicd tests search --query "..." --from 24h --limit 50
get_datadog_flaky_tests	pup cicd flaky-tests search --query "flaky_test_state:active ..."
update_datadog_flaky_test_states	本文を /tmp/flaky-update.json に書き込んでから、pup test-optimization flaky-tests update --file /tmp/flaky-update.json を実行します
get_datadog_code_coverage_branch_summary	repo_lower=$(echo "<repo>" | tr '[:upper:]' '[:lower:]') && pup code-coverage branch-summary --repo "$repo_lower" --branch "<branch>"
get_prs_by_head_branch	pup では利用できません。スキップし、Quality/Security について「データを利用できません」と報告してください
search_pr_insights	pup では利用できません。スキップし、Quality/Security について「データを利用できません」と報告してください
retry_datadog_ci_job	利用できません。代わりに gh run rerun <run_id> --failed を使用してください