分析 GitHub Action 日志
获取并分析指定工作流的最近 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 测试导致超时
- 指令违规 — 代理执行了指令明确禁止的操作
- 冗余工作 — 重复读取文件、重复运行搜索、重复安装依赖项
优先级建议
按照所有运行中估计的时间节省量对你的改进建议进行排序。对于每个建议：
- 要更改什么 — 要编辑哪些文件以及要添加/修改什么
- 原因 — 解决了什么模式，附上来自运行的证据
- 预期影响 — 每次运行可以节省多少时间
输出
呈现完整的整合报告。不要编辑任何工作流或技能文件——仅报告发现和建议。用户将决定应用哪些更改。