parallel-ci-triage について
独立した GitHub Actions の失敗を、ジョブまたは障害グループ単位で並行サブエージェントに割り当てるスキルです。各エージェントがログ調査から修正、ローカル検証まで担当します。
主な機能
- 01ジョブ単位での失敗分割
- 02サブエージェントによる並行調査
- 03原因分析と修正
- 04ローカル検証の手順
- 05競合とマージの手引き
活用シーン
- 01複数の失敗した CI ジョブへの対応
- 021つのジョブ内の無関係なエラーの分割
- 03複数の障害グループの修正調整
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ spencerpauly/ awesome-cursor-skills --skill parallel-ci-triageインストール後、Claude Code で/parallel-ci-triageを入力して読み込まれたか確認します。
詳細
並列 CI トリアージ
失敗したジョブ(または独立した失敗クラスター)を並列サブエージェントに分担させ、CI の修正を迅速化します。各サブエージェントは、ログ、根本原因、コード修正、担当範囲のローカル検証まで、ひとつの縦割り範囲を受け持ちます。
前提条件
- GitHub CLI(
gh)がインストールされ、認証済みであること(gh auth login)。または、GitHub のウェブ UI/API を使ってログを手動でコピーします。 - 修正をプッシュして CI を再実行できるよう、リポジトリへのプッシュ権限があること。
ワークフロー
1. 失敗した実行を特定する
リポジトリのルートで実行します。
gh run list --limit 5
gh run view <RUN_ID> --log-failed
または、Actions タブを開き、失敗したワークフローの実行を開いて、失敗したジョブを確認します(失敗したステップだけではなく、ジョブ名ごとに分類します)。
gh を利用できない場合は、GitHub の UI からログをダウンロードして、会話に貼り付けます。
2. ジョブ(または失敗クラスター)ごとに分担する
- ジョブごとに異なる内容をテストしている場合(例:
lint、test-node-18、e2e)、失敗したジョブごとにサブエージェントを 1 つ割り当てます。 - 1 つのジョブのログに無関係なエラーが複数含まれる場合は、独立した失敗クラスターごとにサブエージェントを 1 つ割り当てます。ただし、同じファイルへの編集の競合を避けるため、エージェント 1 つにつきジョブ 1 つを優先します。
2 つの失敗が同じファイルの同じ根本原因に由来する場合は、両方の修正をサブエージェント 1 つに割り当てます。
3. 並列サブエージェントを起動する
失敗したジョブごとに、generalPurpose サブエージェントを単一のメッセージで起動し、並行して実行します。
Task: Fix CI failure for job "<JOB_NAME>"
Context:
- Workflow run: <RUN_URL or RUN_ID>
- Branch: <branch>
- Relevant log excerpt (failed steps only):
<paste gh run view --job <JOB_ID> --log or the failed section>
Instructions:
1. Infer the root cause from the log (command, stack trace, file:line).
2. Open and edit only what this job requires.
3. Run the same commands locally that failed in CI (or the narrowest equivalent, e.g. `npm run lint`, `pytest tests/foo`, `pnpm test --filter pkg`).
4. Report: what failed, what you changed, and confirmation that the local command passes.
サブエージェントが推測しなくて済むよう、失敗したコマンドとエラー行を正確に含めてください。
4. マージして検証する
-
各サブエージェントが変更したファイルを集めます。複数のエージェントが同じファイルに変更を加えた場合は、手動で競合を解決します。
-
可能であれば、CI と同等の処理をローカルで実行します。
# Example: match your repo npm run lint && npm test -
慣例に沿ったメッセージでコミットしてプッシュし、ワークフローを再確認します。
gh run watch
使用する場合
- 複数の GitHub Actions ジョブが失敗し、それぞれの失敗が独立しているように見える場合。
- 長いワークフローのログを順番に修正するより、ジョブごとに分けたほうが作業しやすい場合。
使用しない場合
- ジョブ 1 つで明確なエラーが 1 つ発生している場合は、メインエージェントで修正します。
- 純粋に不安定なインフラストラクチャが原因の失敗の場合は、まず再試行するか、ワークフローの設定を修正します。
メモ
- ログをチャットに貼り付ける場合は、シークレットを伏せてください。
- 共有ファイルでエージェント同士が競合した場合は、並列処理の後に順番にマージします。
コメント
Markdown 対応