用途：为 workerd 的 Pull Request 生成一份 CI 状态报告，覆盖 GitHub Actions 检查；对 Cloudflare 员工，还可纳入内部 GitLab CI 流水线。输入为 PR 编号或 URL；若省略则自动检测当前分支的开放 PR。
主要能力：先用 ci-report 自定义工具一次拉取 GitHub 侧数据，包含各项检查状态、失败任务日志中的错误片段、从 internal-build 任务日志解析出的内部构建元数据（projectPath、pipelineId、headRef、userLogin、branchRef、status）、受影响文件 changedFiles 以及 main 分支近期 CI 运行情况。随后用一次 portal_codemode_execute 调用汇总 GitLab 侧数据，可获取流水线中失败与成功任务的列表，并并行抓取失败任务日志、提取错误片段。最后对每个失败进行归类：由本 PR 改动引起的实质性失败、基础设施或与改动无关的疑似偶发/既有失败，以及无法判断的情形。
使用方式：PR 为空时自动检测；GitHub 数据经 ci-report 工具获取；GitLab 查询通过 codemode 调用 gitlab_mcp_server_list_pipelines、list_pipeline_jobs、get_job_log 等完成；必要时用 gh run list 对比 main 分支。最终输出合并报告，含 GitHub Actions 与内部 GitLab CI 两部分、失败分类表以及总体结论，并在有失败时按分类建议是否重试。重试 GitHub 用 gh run rerun <run-id> --failed --repo cloudflare/workerd，重试 GitLab 用 gitlab_mcp_server_retry_job 或 gitlab_mcp_server_retry_pipeline，且执行前须与用户确认。
适用场景：workerd 仓库 PR 的 CI 结果汇总、失败归因与是否重试的决策辅助。
限制：GitLab 部分需要相应 MCP 服务与项目访问权限，无权限时只能给出 GitHub 报告；若无法确定项目路径则跳过 GitLab 步骤；无法判断的失败关系不做猜测，会说明还需检查什么。