分析 GitHub Actions 日誌
擷取並分析指定工作流程最近的 GitHub Actions 執行記錄。審查代理/步驟的效能，找出浪費的精力與錯誤，並產出含有可行改進方案的報告。
輸入
你需要：
workflow（必要）— 工作流程檔案名稱或 ID（例如issue-triage.yml、deploy.yml）。repo（可選）— GitHub 倉庫，格式為OWNER/REPO。預設為withastro/astro。count（可選）— 要分析的最近完成執行次數。預設為5。
步驟 1：列出最近的執行
擷取工作流程最近的已完成執行。使用 --status=completed 過濾：
gh run list --workflow=<workflow> -R <repo> --status=completed -L <count>
列出結果以便定位：執行 ID、標題、狀態（成功/失敗）與持續時間。挑選要分析的執行 — 如果可能，偏好混合成功與失敗的案例，並優先選擇執行較多步驟的執行（較長的執行通常會經過更多階段，而較短的執行可能提前結束）。
步驟 2：擷取日誌
對於每個要分析的執行，將完整日誌儲存到暫存檔案：
gh run view <run_id> -R <repo> --log > /tmp/actions-run-<run_id>.log
步驟 3：識別步驟/技能邊界
搜尋每個日誌檔案，找出標記每個步驟或技能開始與結束的標記。標記取決於工作流程 — 請尋找以下模式：
- Flue 技能標記：
[flue] skill("..."): starting/completed - GitHub Actions 步驟標記：日誌輸出中的步驟名稱標題
- 自訂標記：工作流程使用的任何
START/END或類似分隔符號
grep -n "skill(\|step\|START\|END\|starting\|completed" /tmp/actions-run-<run_id>.log | head -50
根據此資訊，判斷每個步驟/技能對應的行範圍。同時找出任何結果標記：
grep -n "RESULT_START\|RESULT_END\|extractResult" /tmp/actions-run-<run_id>.log
注意：某些日誌檔案可能包含二進位/空位元組。必要時請使用 grep -a。
步驟 4：分析每個步驟（使用子代理）
對於每個執行的步驟/技能，啟動一個子代理來分析該區段的日誌。這對於避免你的上下文被數千行日誌汙染至關重要。
對於每個子代理，提供：
- 日誌檔案路徑與該步驟的行範圍
- 如果工作流程存在技能說明檔案，請告知子代理先讀取它們以取得上下文
- 執行標題/上下文，讓子代理了解正在進行的工作
- 以下的分析標準
分析標準
指示每個子代理評估：
- 正確性 — 該步驟的最終結果/裁決是否正確？
- 效率 — 花費了多少時間？合理的基準是什麼？時間浪費在哪裡？
- 錯誤 — 錯誤的工具呼叫、未經修改而重試失敗的命令、不必要的重建等。
- 指令遵循度 — 如果存在技能說明，代理是否遵循了它們？在哪裡偏離了？
- 範疇蔓延 — 代理是否做了屬於其他步驟的工作？
- 建議 — 具體、可操作的更改，能夠防止發現的問題。
指示每個子代理回傳結構化的回應，包含：摘要、時間分析、發現的問題（附每個問題估計浪費的時間），以及改善建議。
步驟 5：彙整報告
在所有子代理回傳後，將它們的發現綜合為一份報告。報告結構如下：
各執行摘要表
對於每個分析的執行，包含一個表格：
| 步驟/技能 | 時間 | 結果 | 浪費的時間 | 主要問題 |
|---|
跨執行共通模式
識別在多個執行或多個步驟中出現的問題。這些是價值最高的改進方向。需尋找的常見模式包括：
- TodoWrite 濫用 — 代理在自動化執行期間浪費時間管理任務清單
- 伺服器管理失敗 — 連接埠衝突、程序終止失敗、過時的日誌檔案
- 工具誤用 — 使用
curl而非gh、找不到jq等 - 範疇蔓延 — 一個步驟做了屬於另一個步驟的工作
- 不必要重建 — 多次建置套件但沒有變更
- 測試逾時 — 執行耗時的 E2E/Playwright 測試導致超時
- 違反指令 — 代理做了指令明確禁止的事情
- 重複工作 — 重新讀取檔案、重新執行搜尋、重新安裝相依套件
優先改善建議
根據所有執行預估節省的時間，對你的改善建議進行排序。對於每個建議：
- 要更改什麼 — 要編輯哪個（些）檔案，以及要新增/修改什麼
- 原因 — 它解決了什麼模式，並附上來自執行的證據
- 預估影響 — 每次執行可節省多少時間
輸出
展示完整的彙整報告。不要編輯任何工作流程或技能檔案 — 僅報告發現與建議。使用者將決定要套用哪些變更。