/ci-audit — GitHub Actionsの無駄な時間を見つけて修正する
まず測定し、次に本当に重要な数項目を修正します。実際の監査では、最大の成果はテストスイートの低速化ではないことがほとんどでした。毎日何ヶ月も失敗し続けているスケジュールパイプライン、月間730分として課金される30秒ごとのcron、またはデッドリクエストを3回静かにリトライしているSDKなどが真犯人です。
このスキルのフォルダにあるstdlibスクリプト scripts/ci_audit.py が測定を行います。あなたはその出力を読み、修正する価値があるものを判断し、実際に修正を適用します。
python3 <skill-dir>/scripts/ci_audit.py inventory <owner> # どのリポジトリがActionsを実行しているか、プライベートvsパブリック
python3 <skill-dir>/scripts/ci_audit.py month <owner/repo> # ワークフローごとの課金時間（30日間）
python3 <skill-dir>/scripts/ci_audit.py jobs <owner/repo> --runs 150 # ジョブごとのキュー/セットアップ/実行時間
python3 <skill-dir>/scripts/ci_audit.py steps <owner/repo> <run-id> # 1回の実行のステップごとの秒数
python3 <skill-dir>/scripts/ci_audit.py schedules <owner/repo> # すべてのcronの月間実行回数
GitHub CLI（gh）がログイン状態である必要があります。month と jobs は実行ごとに1回のAPI呼び出しを行うため、忙しいリポジトリでは1〜2分かかります。バックグラウンドで実行してください。
ステップ0 — スコープとルール
測定する前に、ユーザーと以下の点を合意します。
- どのオーナーとリポジトリか。 1つのリポジトリか、過去60日間にプッシュがあったすべてのリポジトリか。
- 触ってはいけないリポジトリ。 他のチームメンバーや別のエージェントがそこで機能開発中の場合。それらのリポジトリには数値を添えたIssueを作成し、ブランチへのプッシュは決して行いません。
- マージ先ブランチ。 デフォルトでは統合ブランチ（例：
development）。デフォルトブランチへのリリースは別途確認が必要ですが、cronやスケジュールされた修正は、そのリリースが行われて初めて有効になります（ステップ6）。 - スコープ外： テストカバレッジ削減、有料ランナー、CIベンダーの切り替え。これらは数値を添えて推奨するにとどめ、実行しません。
ここで references/gotchas.md を読んでください。
ステップ1 — インベントリとコスト
- 各オーナーに対して
ci_audit.py inventory <owner>を実行します。プライベートリポジトリとパブリックリポジトリを区別します。費用がかかるのはプライベートリポジトリのみですが、エージェントがCIでブロックされる場合、すべてのリポジトリの待機時間が重要になります。 - 組織の場合、実際の課金情報を取得します：
gh api "/organizations/<org>/settings/billing/usage?year=YYYY&month=M"。個人アカウントの場合は、各プライベートリポジトリでci_audit.py monthを実行し、合計とプランの含まれる分数を比較します。 - 課金時間の多いトップ5リポジトリを書き出します。そこに時間が費やされています。
ステップ2 — 遅いよりも壊れている
スケジュールされたワークフローがあるすべてのリポジトリについて：
- ワークフローごとに最後の10回のスケジュール実行を確認します。毎回失敗しているワークフローがあれば、それが最初の発見です。コストは問いません。そのログを読みます（
gh api repos/O/R/actions/runs/<id>/logs > logs.zip）。 .github/workflows/でactionlintを実行します。GitHubがパースできないファイルは、スケジュールを決して実行しません。
階層的なエラーが発生することがあります。references/fixes.md の§1を参照してください。
ステップ3 — スケジュール
cronがある各リポジトリで ci_audit.py schedules <repo> を実行します。月間実行回数にジョブあたりの課金時間（jobs から取得）を掛けます。以下の項目にフラグを立てます。
- タイトなスケジュールでの短いジョブ（30秒のチェックを毎時実行すると、月間730分の課金）。
- 同じ分に複数のcronが設定され、同じレート制限のあるAPIにヒットしている場合。
- 月1回のcronが1回の巨大な実行を行っている場合。作業を複数の夜に分割します。
ステップ4 — ジョブごとの内訳
トップリポジトリに対して：ci_audit.py jobs <repo> --runs 150 を実行し、次に各コストの高いジョブの最近のグリーンな実行1つに対して steps を実行します。各ジョブの時間を分類します。
| バケット | 示唆するもの |
|---|---|
| キュー が高い | ランナー競合または並行性グループ。通常、安価に修正できるものではありません。記録します。 |
| セットアップ が高い | 依存関係のインストールとキャッシュ（references/fixes.md §3–4）。 |
| 実行 が高い、アプリテスト | 実際のテスト時間。ステップが明らかに冗長でない限り、そのままにします。 |
| 実行 が高い、データパイプライン | フェーズを計測し、CIではなくコードを修正します（references/fixes.md §6）。 |
| 失敗 > 5% | フレーキーテストまたは壊れたパイプライン（references/fixes.md §1, §7）。 |
ステップ5 — 報告と選択
以下の列を持つ1つのテーブルを作成し、推定月間節約分数でソートします。
| リポジトリ | 発見事項 | エビデンス | 修正方法 | 推定節約/月 | リスク |
|---|
修正しないもの（触ってはいけないリポジトリ、cron頻度や並列化などのオーナーの決定）も、オーナーが判断するために必要な数値を添えて含めます。それをユーザーに提示し、どの行を実行に移すか合意を得ます。結果を ${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/ci-audit/archive/<YYYY-MM-DD>-<scope>.md にアーカイブします。
ステップ6 — 修正パス
1つのリポジトリ、1人のワーカー。サブエージェントをサポートするホストでは、同じ要領でリポジトリを並列に実行します：新規クローン、最初にIssue、Issueにちなんだブランチ名、小さなコミット、PR本文に前後の数値。
各修正について：
- 測定結果を添えてIssueを開きます。
- ブランチで変更を行います。Lintとテストをローカルで実行し、終了コードで確認します。
- 証明します：プッシュし、PRのCIを再実行してキャッシュをウォーム状態にし、過去の複数の実行のベースラインと比較します。パイプライン修正の場合は、ブランチから少量の制限付きでワークフローをディスパッチします。
- 変更が効果がなかった場合（例えば、Playwrightのキャッシュ問題）、数値を添えてPRをクローズします。それは失敗ではなく、結果です。
- レビューとグリーンチェックの後、統合ブランチにマージします。
- スケジュールされたジョブについては、ユーザーが同意したらデフォルトブランチへのリリースPRを開きます。それまでは本番環境に変更は加えません。
ステップ7 — 検証と記録
- 次のスケジュール実行後に、そのタイミングとログを確認します。修正がブランチだけでなく本番環境でも有効であることを確認します。
- アーカイブファイルに結果を追記します：リポジトリごとの前後比較、マージせずにクローズしたもの、新しい注意点。
- 監査を月1回、またはCIが遅く感じられたときに再実行することを提案します。定期的なリマインダー（
loopify）が効果的です。
連携スキル
loopify— 月次の再監査や、最初のスケジュール実行の翌朝の確認をスケジュールします。castmate— リスクの高いワークフロー変更について、別のモデルのレビューを受けます。unstuck— うまくいくはずの修正が遅くなってしまった場合、諦める前に活用します。project-manager— 監査で明らかになったが実施しなかったオーナーの決定（cron頻度、有料ランナーなど）を追跡します。
品質に関する注意事項
- 遅いよりも壊れている。 時間を計測する前に、常に失敗しているスケジュールワークフローを確認してください。6ヶ月間毎日失敗しているパイプラインは、どのキャッシュよりも大きな損失です。
- ウォーム状態の数値がないなら、主張しない。 1回のコールド実行の高速化を報告してはいけません。再実行し、過去の複数の実行をベースラインとして、両方の数値をPRに明記してください。
- 秒ではなく課金時間。 ジョブごとの切り上げにより、プライベートリポジトリでは、細かいジョブをまとめた方が多数の小さなジョブよりも有利です。並列化はコストを伴う速度の判断であり、無料の勝利ではありません。
- 毎回同じカバレッジ。 テスト数はPR本文に前後で記載します。実行するテストが減っただけの高速化は修正ではありません。
- スケジュールはデフォルトブランチ。 cronまたはパイプラインの修正は、デフォルトブランチにマージされ、1回のスケジュール実行が成功するまで完了とみなさないでください。
- 失敗した実験はデータとともにクローズ。 遅くなったPRは数値を添えてクローズし、次の四半期に誰も同じアイデアを再試行しないようにします。
- 他の人のブランチを尊重する。 触ってはいけないリポジトリにはIssueを作成し、決してプッシュしません。