github-fix-action-error

github-fix-action-error

目的

CI の失敗から成功までの流れを完結させます。このスキルは、現在のブランチで直近に失敗した GitHub Actions の実行を特定してログを取得し、コード内の根本原因を見つけてローカルで修正します。その後、ユーザーの承認を得てから修正をコミットしてプッシュし、CI を再実行できるようにします。

使用するタイミング

• ユーザーが「CI を直して」「失敗しているワークフローを直して」「ビルドを成功させて」、またはハンガリー語の同等表現（「javítsd a CI-t」「piros a build, nézd meg」）と言った場合
• ユーザーが失敗した Actions の実行 URL を貼り付け、修正を求めた場合
• ユーザーが失敗したチェックに言及し、修正を求めた場合

前提条件

作業を始める前に、環境を確認してください。

1. Git リポジトリ内にいること

git rev-parse --show-toplevel

リポジトリ内でない場合は、明確なメッセージを表示して中止します。

2. 作業ツリーに問題がないこと

git status --porcelain

コミットされていない変更がある場合は、ユーザーに内容を示し、続行するかどうか確認してください。ユーザーが作業中の変更と自動修正を混在させると、生成されるコミットのレビューが難しくなります。ユーザーが先にスタッシュまたはコミットできるよう、いったん作業を止めることを推奨します。

ワークフロー

ステップ 1：安全確認 — ブランチ

現在のブランチを取得します。

git rev-parse --abbrev-ref HEAD

ブランチが main、master、または develop の場合は、次のようなメッセージを表示して拒否し、停止します。

Refusing to run on protected branch '<name>'.
This skill commits and pushes a fix directly; that's unsafe on shared branches.
Switch to a feature branch (or open one from the failing commit) and try again.

続行してはいけません。「強制」用の回避策も提示しないでください。このガードの目的は、これらのブランチで必ず PR レビューを受けることです。

ステップ 2：直近の失敗した実行を見つける

gh run list --branch "$BRANCH" --status failure --limit 1 \
  --json databaseId,displayTitle,workflowName,headSha,conclusion,createdAt

コマンドが空のリストを返した場合は、このブランチに失敗した実行がないことをユーザーに伝えて停止します。ほかの失敗状態も確認する価値があります。実行の状態が failure ではなく cancelled や timed_out の場合もあります。有用な結果が何も見つからない場合は停止します。

databaseId を RUN_ID として取得します。どの実行を調べているかユーザーが把握できるよう、1 行で概要を表示します。

Inspecting run <RUN_ID>: <workflowName> — "<displayTitle>" (sha <short-sha>)

ステップ 3：ログをダウンロードして確認する

gh run view "$RUN_ID" --log

ログは大きくなる場合があります。修正に取りかかる前に、失敗した箇所に絞り込んでください。

• gh run view "$RUN_ID" --log-failed は失敗したステップのログのみを返します。利用できる場合はこちらを優先してください。
• よくある失敗を示す文字列を検索します：FAIL、error:、Error:、✗、failed、AssertionError、Traceback、error TS、error[E、FAILED、npm ERR!

次の点を特定します。

• 失敗したジョブ／ステップ（ワークフロー名、ジョブ名、ステップ名）
• 失敗のカテゴリ — テスト失敗、コンパイル／型エラー、Lint／フォーマット違反、依存関係のインストール失敗、スクリプトエラー、不安定なインフラストラクチャ（ネットワーク、ランナー）、シークレットの不足
• 具体的な手がかり — テスト名、ファイルパス、行番号、スタックフレーム、ルール名

失敗の原因がコードの不具合ではなく、インフラストラクチャの一時的な問題（ランナーの喪失、ネットワークタイムアウト、レート制限、シークレットの不足）のように見える場合は、その旨をユーザーに伝え、コードを修正するのではなくワークフローの再実行（gh run rerun <RUN_ID>）を提案します。修正内容をでっち上げてはいけません。

ステップ 4：コード内の問題箇所を特定する

ログの手がかりをリポジトリ内の箇所と対応付けます。

• テスト失敗 → テストファイルを開いてアサーションを理解し、テスト対象の本番コードをたどります。
• コンパイル／型エラー → 報告されたファイルを、報告された行で開きます。
• Lint／フォーマット → ファイルを開きます。ツールで自動修正できる場合（eslint --fix、ruff --fix、cargo fmt、gofmt -w、./gradlew spotlessApply）は、手作業で編集するよりも実行を優先します。
• インポートの不足／未定義のシンボル／ビルドスクリプトの失敗 → 周辺のコードと直近のコミット（git log -n 5 --oneline）を読み、何が変わったのかを把握します。

ログで示されたファイルがローカルに存在しない場合、またはローカルのコミットが CI の実行したコミットと異なる場合（ステップ 2 の headSha と git rev-parse HEAD を比較）、そのことをユーザーに伝えます。CI が実行したものとは異なるツリーに対する修正は信頼性に欠けます。

ステップ 5：的を絞った修正を適用する

根本原因に対処する最小限の変更を行います。

• 無関係なコードの再フォーマット、名前変更、リファクタリングは行わないでください
• 実際の失敗を隠さないでください（例：アサーションの削除、包括的な try/except の追加、ファイル全体でのリンタールールの無効化、テストへの skip の指定）。ユーザーから明示的に依頼された場合を除きます。テストが本当に間違っている場合はテストを修正し、本番コードが間違っている場合はコードを修正してください。どちらを修正したのか、その理由も説明してください。
• 修正方法が自明でない場合や、複数の解釈が妥当な場合は、編集する前にいったん停止し、ユーザーと相談してください

ステップ 6：可能であればローカルで検証する

ユーザーにプッシュの承認を求める前に、手軽に実行でき、利用可能であれば、同じチェックをローカルで再実行してください。

• テスト失敗 → 該当するテストファイルまたはテスト名を指定して実行
• 型エラー → npx tsc --noEmit、cargo check、mypy、go build ./... など
• リント → CI で実行されるものと同じリンター

ローカルでの検証に合格した場合は、その旨を伝えてください。ローカルで再現できない場合（シークレット、特定の OS、大規模なサービスが必要な場合など）もその旨を伝え、CI が最終的な判断基準であることを明記してください。

ステップ 7：概要を示し、承認を求める

簡潔な概要を提示します。

Failing run: <RUN_ID> — <workflowName> / <jobName> / <stepName>
Root cause: <one-sentence diagnosis>

Files changed:
- <path>  (<what changed, in a few words>)
- <path>  (<what changed, in a few words>)

Local verification: <passed | not runnable — reason>

Commit and push? [Y/n]

ユーザーの返答を待ってください。明示的な肯定がない限り、プッシュしてはいけません。y／Y／yes（またはハンガリー語の i／igen）以外の返答は、すべて停止を意味します。ユーザーが作業を続けるか、引き継げるようにしてください。

ステップ 8：コミットしてプッシュする

承認を得たら：

git add -- <files you actually edited>
git commit -m "<generated message>"
git push

具体的なファイルを指定して git add -- <path> を使うことを推奨します。無関係な変更をまとめて追加してしまうのを避けるため、git add -A／git add . は使用しないでください。コミットの修正（amend）は行わないでください。強制プッシュはしないでください。--no-verify も使用しないでください。pre-commit フックが実行された場合は、他の失敗と同様に扱い、根本原因を修正して新しいコミットを作成してください。

コミットメッセージ：修正対象が分かる Conventional Commits 形式の件名を使用し、CI の症状ではなく修正内容を記述してください。git log --oneline -n 20 でリポジトリに既存のスタイルが確認できる場合は、それに合わせてください。

良い例：

• fix(parser): handle trailing comma in object literal
• fix(ci): pin node to 20 to match lockfile
• test(user-service): correct expected timestamp format

避けるべき例：

• fix CI — 何を変更したのか分かりません
• fix failing test — 同様です
• attempt 3 — 不要な情報です

プッシュ後、次の内容を報告してください。

Pushed <short-sha> to origin/<branch>.
Watch the re-run with: gh run watch

ユーザーから依頼がない限り、自分で CI の状況を確認し続けないでください。プッシュ後は引き継ぎとなります。

エラー処理

シナリオ	検出方法	対応
gh がインストールされていない	command -v gh が失敗	https://cli.github.com を案内
Git リポジトリ内ではない	git rev-parse が失敗	明確なメッセージを表示して中止
保護対象ブランチ	ブランチが main/master/develop	拒否して停止（ステップ 1）
作業ツリーに未コミットの変更がある	git status --porcelain が空でない	変更内容を表示し、続行するか確認
失敗した実行がない	gh run list が空	「修正対象なし」と報告して停止
ローカルの HEAD ≠ CI の sha	headSha と git rev-parse HEAD を比較	ユーザーに警告する。異なるツリーに対する修正の信頼性は低い
インフラストラクチャの一時的な障害	ログにコードではなく、ランナー／ネットワーク／シークレットの問題が示されている	gh run rerun を提案し、コードは修正しない
根本原因が曖昧	複数の修正方法が妥当	いったん停止し、どの解釈が正しいかユーザーに確認
ローカルで再現できない	シークレット／サービス／OS が必要	概要で明記する。CI が最終的な判断基準
pre-commit フックが失敗	git commit がゼロ以外で終了	フックが指摘した問題を修正し、新しいコミットを作成（--no-verify は絶対に使用しない）
プッシュが拒否された（fast-forward でない）	git push がゼロ以外で終了	停止してユーザーに伝える。強制プッシュはしない

重要な制約

このスキルは共有履歴に書き込むため、以下の境界を守ってください。

• main、master、またはdevelopでは絶対に実行しないでください。例外はありません。
• ステップ7でユーザーから明示的な承認を得るまで、絶対にプッシュしないでください。
• 絶対に強制プッシュ、公開済みコミットの修正、フックのスキップをしないでください。
• 近道として失敗を隠すこと（アサーションの削除、無条件の例外捕捉、テストのスキップ、lint ルールの無効化）は絶対にしないでください。根本原因を修正するか、ユーザーに引き継いでください。
• CI の修正に関係のない変更を同じコミットに絶対に含めないでください。他の問題に気づいた場合は、別途伝えて、対応をユーザーに委ねてください。
• インフラの不安定な動作に対する修正を絶対にでっち上げないでください。代わりに再実行を勧めてください。
• 原因の特定が曖昧な場合は、必ず停止して質問してください。誤った推測は、確認の質問をするよりも大きな損失につながります。