mcpField
P
parallel-ci-triage

parallel-ci-triage

github.com/revitalb-portテスト・品質055 回インストール10 週間前に更新
リポジトリ

parallel-ci-triage について

独立した CI 失敗ジョブやエラー群を並列サブエージェントに割り当てるワークフロースキルです。ログ収集、根本原因の分析、修正、ローカル検証、GitHub Actions の再実行を扱います。

主な機能

  1. 01ジョブまたはエラー群ごとに失敗を分類
  2. 02独立した作業をサブエージェントに割り当て
  3. 03GitHub Actions のログで原因を調査
  4. 04修正を調整しファイル競合を解決
  5. 05変更をローカルで検証して CI を再実行

活用シーン

  1. 01複数の独立した CI 失敗ジョブを調査
  2. 02長いジョブログの無関係なエラーを切り分け
  3. 03並列修正を調整して GitHub Actions を再実行

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/revitalb-port/skills-registry-demo --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 対応