mcpField
P
parallel-ci-triage

parallel-ci-triage

github.com/spencerpaulyテスト・品質868408 回インストール13 週間前に更新
リポジトリ

parallel-ci-triage について

独立した GitHub Actions の失敗を、ジョブまたは障害グループ単位で並行サブエージェントに割り当てるスキルです。各エージェントがログ調査から修正、ローカル検証まで担当します。

主な機能

  1. 01ジョブ単位での失敗分割
  2. 02サブエージェントによる並行調査
  3. 03原因分析と修正
  4. 04ローカル検証の手順
  5. 05競合とマージの手引き

活用シーン

  1. 01複数の失敗した CI ジョブへの対応
  2. 021つのジョブ内の無関係なエラーの分割
  3. 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 つ発生している場合は、メインエージェントで修正します。
  • 純粋に不安定なインフラストラクチャが原因の失敗の場合は、まず再試行するか、ワークフローの設定を修正します。

メモ

  • ログをチャットに貼り付ける場合は、シークレットを伏せてください。
  • 共有ファイルでエージェント同士が競合した場合は、並列処理の後に順番にマージします。

コメント