check-ci

CI ステータスの確認と失敗の調査

目標

コミットをプッシュした後、CI/CD パイプラインのステータスを監視します。失敗が発生した場合は、体系的な調査と証拠に基づく根本原因分析のために、debugger スキルに委任します。

入力

任意のコミット参照：$ARGUMENTS（例：HEAD、abc1234、feature-branch）

• 指定がない場合、現在のブランチの最新コミットが既定値です
• --pr=<reference> — 対象、head、ポリシー、マージ可能性を確認するため、指定された正確な PR/MR を調査します。ライフサイクルを呼び出す側はこれを指定する必要があります
• --once — 1 回だけ読み取り、待機せずにすぐ戻ります

--pr から PR_REFERENCE を解決します。省略された場合は、現在のブランチに対するオープンな変更を使用します。URL はプロバイダー経由で、プロバイダー CLI を呼び出す前に数値の番号/IID に正規化します。コミット参照と PR/MR の両方がある場合、それぞれの完全な head SHA が一致している必要があります。一致しない場合は、両方の確認値とともに CI: BLOCKED を返します。

オープンな PR/MR がない場合は、単独実行の動作を維持します。正確なコミット SHA、設定済みリモートに関連付けられた正規のプロバイダーリポジトリ、そのリポジトリのデフォルトブランチを TARGET として解決します。デフォルトターゲットの必須/厳格ポリシーと、正確な SHA のチェックを同じ肯定判定条件で読み取ります。MERGEABLE: not-applicable と REVIEW_REQUIREMENTS: not-required を設定し、これらのフィールドが変更リクエストの存在を示すものではないことを明確にします。リポジトリ/デフォルトターゲットが特定できない場合、ポリシーを読み取れない場合、または必須チェックが PR/MR の場合にのみ実行されることが設定から確認できる場合は、推測したり無期限にポーリングしたりせず、CI: BLOCKED を返します。

--once：1 回読み取りモード

CI ステータスを 1 回読み取り、報告して終了します。監視、スリープ、ポーリングは行いません。認証済みの CI/フォージプロバイダーを通じて、完全な head SHA、PR/MR のターゲット、ターゲットブランチの必須チェックポリシーを解決します。必須チェックの一式と、正確な head に対して報告されたチェックを照合します。失敗のないロールアップだけでは、必須チェックが報告された証拠にはなりません。

ステータス行を正確に 1 行出力します。

CI: PENDING  — <n> running, <n> queued, <n> completed
CI: PASSED   — <n>/<n> required checks successful; <n> optional checks terminal/non-failing
CI: FAILED   — <failing check names>
CI: NONE     — no CI configuration detected for this commit
CI: BLOCKED  — required-check policy or exact-head status cannot be observed

次の順に選択します。正確な head/ポリシーの証拠を確認できない場合は BLOCKED、CI 設定がない場合は NONE、必須または任意のチェックに終端状態の失敗がある場合は FAILED、チェックが欠落/実行中/キュー待ちの場合、または厳格ポリシーのターゲットが古い場合は PENDING とします。以下の完全な判定条件を満たす場合に限り PASSED とします。

次に、すべての結果について以下の証明ブロックを出力します。

HEAD_SHA: <full SHA>
TARGET: <target branch or none>
TARGET_SHA: <full target-tip SHA or none>
REQUIRED_CHECKS: complete | pending (<identities>) | failed (<identities>) | none-configured | unknown (<reason>)
STRICT_POLICY: required | not-required | unknown (<reason>)
UP_TO_DATE: yes | no | not-required | unknown (<reason>)
CHECKS_JSON: [{"name":"<exact name>","source":"<app or pipeline>","identity":"<provider-stable context/app identity>","required":true,"status":"<conclusion or pending>"}]
MERGEABLE: yes | no (<reason>) | unknown (<reason>) | not-applicable
REVIEW_REQUIREMENTS: satisfied | pending (<requirements>) | not-required | unknown (<reason>)

PASSED には、以下すべての条件が必要です。

1. 正確な head に対して、少なくとも 1 つの CI チェックまたはパイプラインが設定されています。
2. ターゲットポリシーで必須とされるすべてのチェックが、終端状態の結果とともに報告されています。
3. 必須チェックの結果がすべて成功しています。
4. 報告された必須ではないチェックがすべて終端状態で、失敗していません。この場合に限り、skipped と neutral は許容されます。
5. ターゲットポリシーで厳格/最新状態のブランチが必要とされる場合、承認済みの head に現在のターゲットの tip が含まれています。

必須チェックが報告されていない場合は、成功ではなく PENDING です。ブランチポリシーを読み取れない場合、必須チェックを列挙できないプロバイダーの場合、または head が一致しない場合は BLOCKED です。呼び出し側は PENDING を待機してもかまいませんが、NONE や BLOCKED を成功として扱ってはいけません。

ドラフトに対して一度も報告されていない必須チェックを待つ前に、CI のトリガー対象となる条件を調べます。プロバイダー設定またはワークフロールールから、そのチェックがレビュー準備完了後にのみ開始されること、またはドラフトが明示的に除外されていることが確認できる場合は、直ちに CI: BLOCKED — draft suppresses required CI を返します。スイートのドラフト優先の契約が有効な間、変化し得ない状態をポーリングしてはいけません。Player-coach はドラフトを維持し、この証拠をもって終端状態にします。CI を起動するためだけにレビュー準備完了にはしません。

厳格/最新状態のポリシーが適用され、head に現在のターゲットの tip が含まれていない場合は、UP_TO_DATE: no とともに CI: PENDING — target update required を出力します。これは実行中のチェックとは別の状態であり、オーケストレーションが古いターゲットを修正可能なフィードバックとして返せるようにするものです。 このスイートでは、必須チェックが skipped または neutral で終了することを許容するプロバイダーよりも厳格な終了ルールを意図的に適用します。必須チェックを満たすのは成功のみです。他の CI が設定されている場合、REQUIRED_CHECKS: complete には必須チェックがゼロの場合も含まれます。none-configured は CI: NONE の場合にのみ使用します。

ヘッドがオープンな PR/MR に属する場合は、同じプロバイダー読み取りでマージ可能かどうかを確認し、MERGEABLE に設定してください。このフィールドは CI ステータス自体には影響しません。マージ可能な PR を保証する呼び出し元は、CI: PASSED に加えて MERGEABLE: yes も必要とします。

MERGEABLE は、コードの競合やヘッドの古さによる違反なしに、正確なソースをターゲットへ統合できるかどうかを示します。ドラフト状態や保留中の人間による承認は、CI またはコードレベルのマージ可能性を非グリーンにしません。それらは REVIEW_REQUIREMENTS で別途報告してください。準備状況を確認する呼び出し元は、レビューが保留中でも処理を進められます。マージを行う呼び出し元は、マージ直前にレビュー要件が satisfied または not-required であることを必要とします。

PENDING は通常想定される結果です。これを返して停止してください。パイプラインが保留中の場合、debugger を起動しないでください。調査するのは、終了状態が FAILED の場合のみです。BLOCKED はコードの失敗ではなく、プロバイダーの可観測性に関する失敗です。そのため、debugger を起動せず、証拠を報告してください。

このモードは、複数の作業を同時に管理する呼び出し元向けに用意されています。パイプラインを監視すると、CI にかかる時間だけセッションを占有することになります。徹底的に計測されたプロジェクトでは、それが1時間に及ぶ場合もあります。その間、呼び出し元は別の作業を進められません。独自のスケジューリングを行う呼び出し元が必要としているのは、ブロッキング待機ではなく、いつでも取得できる軽量な読み取り結果です。このセクション以降はすべて、デフォルトの監視モードについて説明します。

デフォルトの監視機能では、同じ正確なヘッドに対する必須ポリシーの紐付けと、同じ PASSED 判定を使用します。チェックが実行中またはキューに入っている間はポーリングします。PENDING — target update required は時間経過で解消する状態ではなく、対応が必要な状態です。そのため、ポーリングせずに直ちに返してください。呼び出し元はターゲットを取り込んで、新しいヘッドを作成する必要があります。FAILED は調査し、NONE または BLOCKED はどちらもグリーンとせずに報告してください。終了状態または対応が必要な状態を読み取った後、上記で定義した同じステータス行と完全な証明ブロックを出力してください。監視によって変わるのはタイミングであり、真偽ではありません。

プロセス

1. 最近のコミットを特定する： CI ステータスを確認する最新のコミットを取得します
2. CI プラットフォームを検出する： 使用中の CI/CD システムを特定します
3. CI ステータスを監視する： リアルタイムで更新しながら CI パイプラインの完了をポーリングします
4. 結果に対応する：
   • 成功の場合 → 成功の概要を提示します
   • 失敗の場合 → 調査のために debugger を起動します
5. レポートを提示する： スキルによる調査結果または成功ステータスを表示します

CI プラットフォームの検出

このコマンドは、設定ファイルを調べて CI/CD プラットフォームを自動検出します。

検出の優先順位

1. GitHub Actions

   • .github/workflows/*.yml または .github/workflows/*.yaml を確認します
   • API アクセスには gh CLI を使用します
   • ワークフローの実行とジョブログを解析します

2. GitLab CI

   • .gitlab-ci.yml を確認します
   • API アクセスには glab CLI を使用します
   • パイプラインとジョブログを解析します

3. CircleCI

   • .circleci/config.yml を確認します
   • 検出されたトークンを使用して CircleCI API を利用します

4. Jenkins

   • Jenkinsfile または .jenkins を確認します
   • URL が設定されている場合は Jenkins API を使用します

5. Travis CI

   • .travis.yml を確認します
   • 認証を使用して Travis API を利用します

6. Azure DevOps

   • azure-pipelines.yml を確認します
   • 利用可能な場合は Azure CLI を使用します

必須チェックポリシーの紐付け

設定ファイルから CI システムを特定し、認証済みのプロバイダーからターゲットブランチのマージに必要な条件を特定します。PASSED を出力する前に、両方を解決してください。 PR/MR がない場合は、正確なコミットに設定されたリモートからプロバイダーのリポジトリを特定し、そのデフォルトブランチを照会します。GitHub では同じブランチルールを適用し、HEAD_SHA のチェック実行とステータスをページネーションで取得しますが、PR のレビューとマージ可能性に関する読み取りだけは省略します。GitLab では、SHA が HEAD_SHA と一致するすべてのパイプライン、そのジョブ、およびプロジェクト／デフォルトブランチのポリシーを列挙し、MR のみに関するステータス／承認の読み取りは省略します。正確な SHA に一致する複数のパイプラインがある場合、すべてのチェックを評価に含めます。異なる ref の最新パイプラインを代わりに使うことはありません。

GitHub: チェックアウトの origin ではなく、明示的に選択した PR から正規のベースリポジトリを特定し、その headRefOid、baseRefName、statusCheckRollup を確認します。クラシックなブランチ保護の必須ステータスチェックと、対象ブランチに適用されるルールの両方を照会します。ポリシーにコンテキストとアプリ／インテグレーションの識別情報がある場合は、それを保持します。あるプロバイダーの必須チェックを、同名の別プロバイダーの結果で満たしてはなりません。strict／最新状態のポリシーと現在の対象ブランチ先端の SHA を、同じ検証の一部として特定します。strict ポリシーが適用される場合、プロバイダーのマージ状態が BEHIND ではないことに加え、対象ブランチ先端の SHA が正確な head の祖先である（または同一である）ことを compare 結果で確認します。チェックロールアップがグリーンであるだけでは不十分です。ポリシーが存在しないことを示す 404 と、認証／API の失敗は区別します。API パスにブランチ名を挿入する前に URL エンコードします。

述語を適用する前に、GitHub の再試行を正規化します。チェック実行は、安定したチェック識別情報（名前とアプリ ID）でグループ化し、同じ論理チェックの再試行間で安定しているとプロバイダーが文書化しているフィールドだけを拡張情報として使います。external_id、suite ID、workflow run ID など、実行ごとに変わる値を拡張情報に使ってはなりません。GitHub Actions にリンクされた run_attempt がある場合は、その最大値を優先します。それ以外の場合は、completed_at／started_at が最も新しいものを選び、次にプロバイダー ID が最大のものを選びます。同じアプリの独立した同名チェックを安定したキーで区別できない場合は、推測せず CI: BLOCKED を返します。コミットステータスはコンテキストと作成者／アプリの識別情報でグループ化し、created_at、次に ID の順で最新のプロバイダーレコードを選択します。エンドポイントの並び順だけに依存してはなりません。選択されたこれらのレコードだけを CHECKS_JSON または必須チェックの評価に含めます。上書きされたレコードは監査メモとして保持しますが、再実行が成功した場合、上書きされた失敗によって正確な head を失敗扱いにしてはなりません。同じ最新状態のレコードが競合する状態のまま 2 件残る場合は、CI: BLOCKED を返します。ブランチポリシーは、表示名だけではなく、同じ安定したコンテキスト／アプリ識別情報に照合します。

TARGET_BRANCH_ENCODED=$(jq -rn --arg value "$TARGET_BRANCH" '$value|@uri')
# BASE_REPOSITORY is the provider-scoped canonical base selected from PR_REFERENCE;
# BASE_REPOSITORY_PATH is its OWNER/REPO portion for REST paths.
gh -R "$BASE_REPOSITORY" pr view "$PR_REFERENCE" \
  --json headRefOid,baseRefName,isDraft,statusCheckRollup,mergeable,mergeStateStatus,reviewDecision
gh api --hostname "$BASE_HOST" \
  "repos/$BASE_REPOSITORY_PATH/branches/$TARGET_BRANCH_ENCODED/protection/required_status_checks"
gh api --hostname "$BASE_HOST" --paginate \
  "repos/$BASE_REPOSITORY_PATH/rules/branches/$TARGET_BRANCH_ENCODED"
TARGET_REF_JSON=$(gh api --hostname "$BASE_HOST" \
  "repos/$BASE_REPOSITORY_PATH/git/ref/heads/$TARGET_BRANCH_ENCODED")
TARGET_SHA=$(echo "$TARGET_REF_JSON" | jq -er .object.sha)
COMPARE_STATUS=$(gh api --hostname "$BASE_HOST" \
  "repos/$BASE_REPOSITORY_PATH/compare/$TARGET_SHA...$HEAD_SHA" --jq .status)
case "$COMPARE_STATUS" in ahead|identical) UP_TO_DATE=yes ;; behind|diverged) UP_TO_DATE=no ;; *) exit 1 ;; esac
gh api --hostname "$BASE_HOST" --paginate -H 'Accept: application/vnd.github+json' \
  "repos/$BASE_REPOSITORY_PATH/commits/$HEAD_SHA/check-runs?per_page=100"
gh api --hostname "$BASE_HOST" --paginate \
  "repos/$BASE_REPOSITORY_PATH/commits/$HEAD_SHA/statuses?per_page=100"

GitLab: チェックアウトの origin ではなく、明示的に選択した MR から正規のターゲットプロジェクトを特定し、その正確な head のパイプライン、プロジェクトのマージ／パイプラインポリシー、ターゲットの保護ブランチ設定、外部ステータスチェック、詳細なマージ状態、承認状態を確認します。MR の diff_refs.head_sha、選択されたパイプラインの SHA、要求された HEAD_SHA が一致することを必須とします。パイプラインは MR の head_pipeline.id で選択し、単に最新のパイプラインを選んではなりません。各ジョブのプロバイダー固有で安定したパイプライン／ジョブ識別情報を保持します。オプションではないすべてのジョブが終了状態になった場合に限り、パイプラインは完了とします。checking、CI pending、ターゲットの取り込みが必要な状態、またはソースの競合はグリーンではない状態として扱います。ドラフトと保留中の承認は REVIEW_REQUIREMENTS でのみ報告します。プロジェクトポリシーまたは外部ステータス要件を列挙できない場合、存在しないと仮定せず BLOCKED を返します。API パスにブランチ名を挿入する前に URL エンコードします。

TARGET_BRANCH_ENCODED=$(jq -rn --arg value "$TARGET_BRANCH" '$value|@uri')
# Resolve BASE_SELECTOR from the explicit MR URL's project, or from the configured provider
# repository/remote for number, branch, and standalone calls.
BASE_PROJECT_JSON=$(glab -R "$BASE_SELECTOR" repo view --output json)
BASE_REPOSITORY_URL=$(echo "$BASE_PROJECT_JSON" | jq -er .web_url)
BASE_HOST=$(echo "$BASE_REPOSITORY_URL" \
  | sed -E 's#^[a-zA-Z][a-zA-Z0-9+.-]*://([^/]+)/.*#\1#')
BASE_REPOSITORY_PATH=$(echo "$BASE_PROJECT_JSON" \
  | jq -er '.path_with_namespace // .full_path')
BASE_PROJECT_PATH_ENCODED=$(jq -rn --arg value "$BASE_REPOSITORY_PATH" '$value|@uri')
BASE_REPOSITORY="$BASE_HOST/$BASE_REPOSITORY_PATH"
BASE_REPOSITORY_SELECTOR=$BASE_REPOSITORY_URL
BASE_PROJECT_ID=$(glab api --hostname "$BASE_HOST" \
  "projects/$BASE_PROJECT_PATH_ENCODED" | jq -er .id)
MR_LOOKUP=$PR_REFERENCE
case "$PR_REFERENCE" in
  http://*|https://*)
    clean_reference=${PR_REFERENCE%%\?*}
    clean_reference=${clean_reference%/}
    MR_LOOKUP=${clean_reference##*/}
    case "$MR_LOOKUP" in ''|*[!0-9]*) exit 1 ;; esac
    ;;
esac
MR_IID=$(glab -R "$BASE_REPOSITORY_SELECTOR" mr view "$MR_LOOKUP" --output json | jq -er .iid)
MR_JSON=$(glab api --hostname "$BASE_HOST" \
  "projects/$BASE_PROJECT_ID/merge_requests/$MR_IID")
test "$(echo "$MR_JSON" | jq -er .target_project_id)" = "$BASE_PROJECT_ID"
MR_HEAD_SHA=$(echo "$MR_JSON" | jq -er '.diff_refs.head_sha // .sha')
HEAD_PIPELINE_ID=$(echo "$MR_JSON" | jq -r '.head_pipeline.id // empty')
HEAD_PIPELINE_PROJECT_ID=$(echo "$MR_JSON" | jq -r '.head_pipeline.project_id // empty')
test "$MR_HEAD_SHA" = "$HEAD_SHA"
glab api --hostname "$BASE_HOST" "projects/$BASE_PROJECT_ID" \
  | jq '{only_allow_merge_if_pipeline_succeeds, only_allow_merge_if_all_discussions_are_resolved, merge_method, squash_option}'
if [ -n "$HEAD_PIPELINE_ID" ]; then
  test -n "$HEAD_PIPELINE_PROJECT_ID" # otherwise exact project scope is unprovable: BLOCKED
  PIPELINE_PROJECT_JSON=$(glab api --hostname "$BASE_HOST" \
    "projects/$HEAD_PIPELINE_PROJECT_ID")
  PIPELINE_REPOSITORY_SELECTOR=$(echo "$PIPELINE_PROJECT_JSON" | jq -er .web_url)
  PIPELINE_JSON=$(glab api --hostname "$BASE_HOST" \
    "projects/$HEAD_PIPELINE_PROJECT_ID/pipelines/$HEAD_PIPELINE_ID")
  test "$(echo "$PIPELINE_JSON" | jq -er .sha)" = "$HEAD_SHA"
  glab api --hostname "$BASE_HOST" --paginate \
    "projects/$HEAD_PIPELINE_PROJECT_ID/pipelines/$HEAD_PIPELINE_ID/jobs"
fi
glab api --hostname "$BASE_HOST" \
  "projects/$BASE_PROJECT_ID/merge_requests/$MR_IID/status_checks"
glab api --hostname "$BASE_HOST" \
  "projects/$BASE_PROJECT_ID/merge_requests/$MR_IID/approvals"
glab api --hostname "$BASE_HOST" \
  "projects/$BASE_PROJECT_ID/merge_requests/$MR_IID/approval_state"
glab api --hostname "$BASE_HOST" \
  "projects/$BASE_PROJECT_ID/protected_branches/$TARGET_BRANCH_ENCODED"
glab api --hostname "$BASE_HOST" \
  "projects/$BASE_PROJECT_ID/repository/branches/$TARGET_BRANCH_ENCODED"

外部ステータスチェックを利用できないことを示す、文書化された 404 は空の集合として扱います。認証失敗または列挙に対応していない場合は BLOCKED とします。HEAD_PIPELINE_ID が存在しない場合は、プロジェクトのパイプラインポリシーとリポジトリの CI 設定を組み合わせて NONE、PENDING、またはドラフトによって抑制された BLOCKED のいずれかを判断します。パイプラインがない状態を、成功したパイプラインとして暗黙に扱ってはなりません。 別のプロバイダーの場合は、ハーネスが公開する認証済み機能から、同等のポリシー操作と厳密な HEAD ステータス操作を解決してください。同等の操作が見つからない場合は、CI: BLOCKED を返します。

監視ワークフロー

1. 初期ステータス確認

# Get latest commit
git rev-parse HEAD

# Get commit details
git log -1 --format="%H %s"

# Check push status
git log "$CI_REMOTE/$BRANCH"..HEAD

2. CI ステータスのポーリング

GitHub Actions の場合：

# List workflow runs for the exact commit; required-check truth still comes from the policy
# and exact-SHA check/status API reads above
gh -R "$BASE_REPOSITORY" run list --commit "$HEAD_SHA"

# Get run details
gh -R "$BASE_REPOSITORY" run view "$RUN_ID"

# Watch run status
gh -R "$BASE_REPOSITORY" run watch "$RUN_ID"

GitLab CI の場合：

# Read only the MR's exact head_pipeline selected above
glab api --hostname "$BASE_HOST" \
  "projects/$HEAD_PIPELINE_PROJECT_ID/pipelines/$HEAD_PIPELINE_ID"

# Get the exact pipeline's jobs
glab api --hostname "$BASE_HOST" --paginate \
  "projects/$HEAD_PIPELINE_PROJECT_ID/pipelines/$HEAD_PIPELINE_ID/jobs"

# Get job logs
glab -R "$PIPELINE_REPOSITORY_SELECTOR" ci trace "$JOB_ID"

3. リアルタイム更新

ステータスの更新を 5～10 秒ごとに表示します：

⏳ CI Status: In Progress
  ✓ Build: Success
  ⏳ Tests: Running... (2m 15s)
  ⏳ Lint: Queued
  - Deploy: Pending

失敗の調査

CI が失敗した場合は、debugger スキルに調査を委任します：

スキルの呼び出し

Skill ツールを使用して、以下の情報とともに debugger を呼び出します：

• CI のジョブ／パイプライン ID
• 失敗したジョブ名
• 関連するログの抜粋
• コミット情報

プロンプトの例：

Investigate CI failure for commit [SHA]:
- Failed jobs: [job names]
- CI platform: [GitHub Actions/GitLab CI/etc]
- Job logs available via: [command to fetch logs]

Please gather evidence about:
1. What specifically failed (tests, build, lint, etc.)
2. Exact error messages and stack traces
3. Which files/changes are involved
4. Root cause based on evidence

Provide a complete investigation report.

スキルの動作

debugger スキルは次の処理を行います：

1. 失敗したジョブの CI ログ全体を取得します
2. 正確なエラーメッセージと発生箇所を特定します
3. 実行フローをたどって失敗の原因を調査します
4. 環境とコンテキストに関する証拠を収集します
5. 修正案を提示せずに調査結果を報告します

出力形式

デフォルトのウォッチャーでは、以下の人間向け要約を表示してもかまいません。ただし、必ず最後に、single-reading モードで定義された正確な CI: ステータス行と完全な証拠ブロックを出力してください。ライフサイクルを管理する呼び出し元が解析するのは、絵文字の要約ではなく、この最後の契約です。

成功時

✅ CI Status: All checks passed!

📊 Summary:
  ✓ Build: Success (1m 23s)
  ✓ Tests: 156 passed (2m 45s)
  ✓ Lint: No issues (0m 15s)
  ✓ Security: No vulnerabilities (0m 38s)

🎉 CI and code-level mergeability are green; review requirements are reported below.

失敗時

❌ CI Status: Failed

📊 Summary:
  ✓ Build: Success (1m 23s)
  ❌ Tests: 2 failed, 154 passed (2m 45s)
  ⚠️ Lint: 3 warnings (0m 15s)
  ✓ Security: No vulnerabilities (0m 38s)

🔍 Launching `debugger` to investigate...

続けて、次の項目を含むスキルの完全な調査レポートを提示します：

• 問題調査レポート
• 収集した証拠（ログ、エラー、スタックトレース）
• 根本原因の分析（事実に基づくもの）
• 影響を受けるコンポーネント
• 解決に向けた推奨事項

このスキルのレポートでは、修正を実装せず、証拠に基づいた調査結果を提示します。

エラー処理

• CI 設定がない場合： 完全な証拠ブロックとともに CI: NONE を出力します
• 認証が必要な場合： 失敗した証拠の読み取り結果とともに CI: BLOCKED を出力します
• API レート制限： ウォッチャーモードでは待機して再試行し、--once では CI: BLOCKED を出力します
• ネットワークの問題： ウォッチャーモードでは指数バックオフで再試行し、--once では CI: BLOCKED を出力します
• CI の実行に時間がかかる場合： 待機を続けます。大規模な CI は機能であり、障害ではありません。詳しくは以下の「待機について」を参照してください
• ログが一部しかない場合： 入手できる情報を使って調査を試みます

待機について

1 時間実行されているパイプラインは、停止しているとは限りません。マージを制御できるほど CI が信頼されているプロジェクトでは、意図的にテストスイートの規模を大きくしています。また、複数のブランチが同時にマージされると、共有ランナーのキューにジョブがたまり、実行が始まるまで Queued の状態が長く続くことがあります。どちらも正常です。

したがって、経過時間だけを根拠に、CI が停止している、壊れている、または諦めるべきだと判断してはいけません。CI を省略すること、「停止解除」のための再実行、または CI を通さないマージを提案しないでください。待機を終了するのは、最終結果、明示的な CI_CHECK_TIMEOUT、またはユーザーからの停止指示のみです。明示的なタイムアウトに達した場合は、最後にもう一度、正確な HEAD のステータスを読み取り、完全な証拠ブロックとともに CI: PENDING — timeout reached; <n> running, <n> queued, <n> completed を返します。タイムアウトによって、保留中のチェックが失敗または成功に変わることはありません。タイムアウトが指定されておらず、時間がかかっている場合は、何を待っているかを伝えて待機を続けてください。

プラットフォーム固有の機能

GitHub Actions

• マトリックスビルド（複数のジョブ構成）に対応
• 詳細なログを確認するためのアーティファクトのダウンロード
• 失敗したジョブの再実行コマンド
• ワークフローのディスパッチトリガー

GitLab CI

• パイプラインのステージ分析
• 手動ジョブのトリガー
• マージリクエストパイプラインのサポート
• 子パイプラインの検出

設定オプション

ユーザーは環境変数を使って動作をカスタマイズできます：

• CI_CHECK_TIMEOUT：CI の完了を待つ時間（正の整数秒、デフォルト：未設定 — 無期限に待機）
• CI_POLL_INTERVAL：ステータスを確認する間隔（デフォルト：10s）

最終指示

コアワークフロー

1. 特に指示がない限り、まず最新のコミットを確認します
2. CI プラットフォームを自動的に検出します。GitHub Actions と決めつけないでください
3. ユーザーの入力を求めず、CI のステータスを継続的に監視します
4. CI が完了したら：
   • 成功 → 所要時間の詳細を含む成功サマリーを提示します
   • 失敗 → 直ちに debugger を起動します

スキルの委任

5. debugger を起動する際：
   • コミット SHA とジョブの詳細を提供します
   • 関連するログを取得するコマンドを含めます
   • 失敗したジョブを指定します
   • スキルに体系的な調査を任せます

報告

6. スキルによる調査レポートをすべて提示します
7. スキルのレポートは解決策ではなく、証拠に基づくものです
8. コードの変更や修正の自動実装は決して行いません
9. 調査結果を提示した後は、次の手順について人間が判断するのを待ちます

エラー処理

10. リポジトリで複数の CI プラットフォームを使用している場合は、それらすべてに対応します
11. CI がまだ実行中の場合は、待機を続けて進捗を報告します。パイプラインが長いからといって、停止しているとは限りません

使用例

# Check CI for latest commit
/check-ci

# Check CI for specific commit
/check-ci abc1234

# Check CI for a branch
/check-ci feature/new-api