Agent Skills: fix-github-actions-ci

GitHub Actions CI の失敗を調査して修正するためのスキルです。CI ログを分析して失敗箇所・原因を特定し、そのまま修正作業まで行います。

UncategorizedID: sushichan044/dotfiles/fix-github-actions-ci

Install this agent skill to your local

pnpm dlx add-skill https://github.com/sushichan044/dotfiles/tree/HEAD/.agents/skills/fix-github-actions-ci

Skill Files

Browse the full folder contents for fix-github-actions-ci.

Download Skill

Loading file tree…

.agents/skills/fix-github-actions-ci/SKILL.md

Skill Metadata

Name
fix-github-actions-ci
Description
GitHub Actions CI の失敗を調査して修正するためのスキルです。CI ログを分析して失敗箇所・原因を特定し、そのまま修正作業まで行います。

fix-github-actions-ci

Tips

  • gh pr checks --watchgh run watch <run-id> を使うと、CI の再実行後の状況をリアルタイムで確認できますが、 結構時間がかかるので background に移譲して非同期実行してください。
  • すべての gh コマンドについて、--repo でリポジトリを明確にすることをおすすめします
    • 現在いるリポジトリの owner/repo 形式: !gh repo view --json owner,name --jq '.owner.login+"/"+.name'
  • 調査完了後は、そのまま修正作業まで続けて、完了条件を満たしたら push して PR に反映させるところまで行うことを目指してください。

Steps

Step 1: PR コンテキストの確認

現在のブランチに関連する PR を確認する:

!gh pr view --json url,number 2>/dev/null || echo "No PR found for current branch"

PR が見つからない場合はユーザーにどの PR を修正するか確認し、以降の操作でその PR を指定する。 PR コンテキストとして受け付けられる形式: PR 番号、URL、ブランチ名

Step 2: Check ステータスの確認

失敗している check と workflow name を特定し、失敗した run の ID をメモする:

gh pr checks <PR> --json name,state,bucket,workflow --jq '[.[] | select(.bucket == "fail")]'

複数の workflow が失敗している場合は、静的解析系(lint, type-check など)の workflow を優先して調査する。静的解析系 workflow の Step 3〜5 を完了後、その他の failing workflow(E2E など)についても同様に Step 3〜5 を実施する。

Step 3: 失敗ログの取得

gh pr checks の出力には run ID が含まれないため、まず run ID を取得する:

gh run list --branch <branch> --workflow "<workflow-name>"

取得した run ID でログを確認する:

gh run view <run-id> --log-failed

ログからファイル名・行番号・エラーメッセージを特定する。

Step 4: workflow からローカル確認コマンドを特定する

Step 2 で取得した workflow name から workflow の YAML ファイルを取得する。 なお、workflow name は space を含む可能性があるので quote すること。

gh workflow view "<workflow-name>" --yaml

ログと照合しながら、needs: による job 間依存により実行されなかった可能性のある job を特定する。 自動テスト系の時間がかかるチェック以外の静的解析 step をすべてリストアップし、そのコマンドを Step 5 の "How to verify locally" に記載する。

テストと判断する基準: step 名やコマンドに test, spec, e2e, coverage, vrt などのキーワードが含まれるもの。 テスト系はローカル確認コマンドとして列挙しないが、Step 3 のログで確認したテスト系のエラーは Step 5 の Error location に記録する。

Step 5: 修正方針をまとめる

次の形式で簡潔に整理して返す。 修正方針は「どのようなエラーが出ており、どのコードや設定を修正すべきか」を明記すること。

## CI failure summary

- PR context: <PR number/url/branch>
- Failed check: <check name>
- Workflow: <workflow name>
- Run ID: <run id>

## Error location

<!-- 複数ある場合はこのブロックを繰り返す -->

- File: <path or unknown>
- Line: <line or unknown>
- Message: <error message>
- Why it is failing: <root cause hypothesis based on log>

## How to verify locally

- <command 1>
- <command 2>

## Suggested fix location

- <file or component to modify based on error location and workflow steps>
- <additional risk or fail-fast note if relevant>

## Done condition

- <what output or command result should indicate the error is resolved>

Step 6: 修正を実施する

Step 5 のサマリをもとに、実際にコードを修正する。修正後は Done condition に記載したコマンドでローカル確認を行い、エラーが解消されたことを確認し、修正内容を commit して PR に push する。