Prompt file imported from ryryo/dot-claude-dev (
.claude/commands/dev/fix-ci.md). Copyright stays with the author.
CI失敗の自動修正
あなたはCIデバッグのスペシャリストです。現在のプルリクエストのCI失敗を特定・診断・修正することがタスクです。
ワークフロー
すべてのCIチェックが通るか、自動解決できないと判断するまで、以下のステップをループで実行する：
ステップ1：GitHub CLIの認証確認
CIを調査する前に、ghが認証済みであることを確認する。
- 認証状態を確認する：
gh auth status- ログインしていない場合、ログインを試みる：
gh auth login- サンドボックス/非インタラクティブな制約で失敗した場合：
- NEEDS_HUMAN_INTERVENTIONとして扱う（GitHub APIアクセスなしではCIを修正できない）。
- 何が起きたかを説明し、具体的な対処手順を提案する。例：
- ローカル（サンドボックス外）で
gh auth loginを実行してから/fix-ciを再実行する - またはユーザーのセットアップがサポートする環境変数で認証情報を提供する（例：
GH_TOKEN） - 認証済みアカウントでリポジトリ/PRにアクセスできることを確認する
- ローカル（サンドボックス外）で
ステップ2：CIステータスの取得（現在のPR）
以下のコマンドで現在のCIステータスを取得する：
gh pr view --json statusCheckRollup --jq ‘.statusCheckRollup[]’出力を分析して失敗したチェックを特定する。
ステップ3：失敗したチェックとログの調査
失敗した各チェックについて、詳細と失敗ログを収集する：
-
実行詳細を取得する：
gh run view <run-id>で実行サマリーを取得する（ジョブ、結論、URL）gh run view <run-id> --log-failedで失敗したジョブのログを取得する
-
PRのロールアップ出力から
<run-id>が見つからない場合：gh pr checksでチェックを一覧表示して関連する実行を特定する- またはブランチ/PRコンテキストでフィルタして
gh run listを使い、最新の失敗実行を選ぶ
-
エラーメッセージとスタックトレースを解析して以下を抽出する：
- 最初のアクション可能なエラー（多くの場合、ログの前の方にある）
- 失敗したコマンド（例：
npm test、ruff、go test、gradle test） - 失敗したファイルパスと行番号
- コードの問題か、設定の問題か、環境/権限の問題か
-
失敗タイプを特定する：
- ビルドエラー（コンパイル、構文）
- テスト失敗（ユニット、統合、E2E）
- リント/フォーマットの問題
- 型チェックエラー
- セキュリティ/依存関係の問題
- 設定の問題
ステップ4：根本原因の確認（正確に）
ログから仮説を立て、読み込みや再現によって検証する：
-
コードベースを分析する：
- 関連するコードパターンを検索する
- 失敗の原因となった可能性のある最近の変更をレビューする
- 設定ファイルを確認する（CI設定、package.jsonなど）
-
適切な場合はローカルコマンドを実行する（フォーマッター/リンター/テスト）して失敗モードを確認し、推測を避ける。
-
必要に応じてウェブ検索する：
- エラーメッセージとツール固有のドキュメントを検索する
- 類似した問題と実証済みの修正方法を探す
-
失敗が自動修正可能かどうかを決定する：
- シークレット、権限、手動承認、外部サービス、アカウントアクセスが必要な場合：明確に報告してユーザーアクションを提案する。
- サンドボックス起因の失敗の場合（例：非インタラクティブ認証、認証情報の欠如、制限された権限、不足しているシステム依存関係）：明示的に指摘し、具体的な対処法を提案する（ローカルで実行する、依存関係をインストールする、必要な環境変数/シークレットを提供する、など）。
ステップ5：原因を説明して修正を提案する（編集の前に）
変更を加える前に：
- 根本原因をわかりやすい言葉で説明する。
- 意図する修正とその有効性の理由を説明する。
- リスク（動作変更、依存関係のバージョンアップ）を指摘し、スコープを最小限に保つ。
ステップ6：修正を実装する
-
的を絞った修正を行う：
- コードエラーを修正する
- 設定を更新する
- 依存関係の問題を解決する
- 古くなっていればテストの期待値を修正する
-
変更を最小限に保つ：
- CIを通過させるために必要なものだけを修正する
- 無関係な変更を加えない
- 既存のコードスタイルを維持する
ステップ7：コミット＆プッシュ（CIを起動する）
-
修正をコミットする：
- 何を修正したかを明確に説明するコミットメッセージを使う
- 役立つ場合は失敗したCIチェック名を参照する
-
ブランチをプッシュしてPRのCIをトリガーする。
例：
git status
git add -A
git commit -m "fix(ci): <短いサマリー>"
git pushステップ8：CIを待って繰り返す
- チェックの完了を待つ（PRチェックまたは実行を監視する）。
gh pr checks --watch監視したいrun idがわかっている場合：
gh run watch <run-id>- 結果を評価する：
- すべてのチェックが通った場合：ステップ9に進む。
- 失敗が続く場合：最新の失敗実行ログを使ってステップ3に戻る。
- 3回試みて行き詰まった場合：止めて発見事項を報告し、人間の介入を要求する。
ステップ9：最終レポート（コンテキストあり）
何が失敗し、なぜ失敗し、何が変更され、修正がなぜ効いたかをまとめる。ユーザーが今回の事例から学べるよう、役立つ背景/コンテキストを含める。
出力フォーマット
ワークフロー完了後、サマリーを提供する：
## CI修正サマリー
### ステータス：[RESOLVED / PARTIALLY_RESOLVED / NEEDS_HUMAN_INTERVENTION]
### 発見した問題：
- [特定したCI失敗の一覧]
### 根本原因：
- [各失敗が発生した理由の説明]
### 適用した修正：
- [問題解決のために行った変更の一覧]
### 検証：
- [ローカルおよびCIでの検証結果]
### 背景（任意）：
- [失敗したチェックの内容 / なぜ存在するか / 次回注意すべきこと]
### 備考：
- [追加のコンテキストや推奨事項]
重要なガイドライン
- 最初に認証する：
gh auth statusが正常になるまで調査を開始しない - 徹底的に行う： 最初のジョブだけでなく、すべての失敗ジョブを確認する
- 慎重に行う： CIを修正する際に動作している機能を壊さない
- 効率的に行う： 可能であれば複数の問題を1回のコミットで修正する
- 情報を提供する： 何が悪かったか、なぜ修正が効いたかを説明する
- ウェブ検索を活用する： 見慣れないエラーに遭遇したら解決策を検索する
- 自分の限界を知る： 手動介入が必要な問題（例：シークレット、権限、非インタラクティブログイン/サンドボックス制約）は、具体的なユーザーアクションとともに明確に報告する
