用途：给定一个 PR URL（如 https://github.com/openshift/lightspeed-service/pull/2825），诊断其 CI 作业为何失败。
主要流程与能力：
- 从 URL 解析 org、repo、PR 编号，用 gh 获取 PR 元数据（标题、状态、作者、head SHA）与改动文件：gh api repos/{org}/{repo}/pulls/{pr}，以及 gh api repos/{org}/{repo}/pulls/{pr}/files。
- 用 gh pr checks {pr} --repo {org}/{repo} 查看全部检查，再用 gh api repos/{org}/{repo}/statuses/{head_sha} 筛选 failure/error 状态，得到失败作业及其 Prow 链接。
- 从 Prow target_url 推导 GCS 制品地址：目录浏览用 gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/...，原始文件用 storage.googleapis.com/test-platform-results/...。
- 逐个失败作业排查：先看 finished.json 判断 passed/result，再读 build-log.txt（可能 200KB+），重点搜索 failed、FAILED、error、ERROR、step .* failed、Python traceback、CrashLoopBackOff、OOMKilled 等；随后浏览 artifacts/ 目录树，按症状查对应文件，例如测试断言看 e2e/build-log.txt 与 junit_e2e_.xml，服务报错看 {provider}/cluster/podlogs/lightspeed-app-server-.log，Postgres 问题看 postgres 日志，部署失败看 pods.yaml、deployments.yaml，镜像构建失败看 build-logs/*.log，集群基础设施问题看 must-gather 的 camgi.html 与 event-filter.html。制品过大时可用 gcloud storage cp -r 下载到临时目录搜索。多作业失败时可用子代理隔离上下文并行处理。
- 结合 PR 改动交叉判断：单元/集成失败多为代码 bug，e2e 失败可能是基础设施或破坏性改动，verify/lint 多为格式或类型问题，镜像构建多为依赖或 Dockerfile 问题，也可查 job-history 判断是否为已知偶发。
- 汇总报告：哪些作业失败或通过、每个失败的根因（附日志摘录）、是否与 PR 相关、修复建议。
已知作业：ci/prow/unit、integration、verify、security、images、fips-image-scan-service、e2e-ols-cluster 等；tide 为合并就绪标签而非测试，Konflux 为独立供应链安全流水线。
限制：Prow 仪表盘 URL 由 JS 渲染，WebFetch 不可用，需改用 GCS 地址；构建日志很大，建议从末尾读起；仓库内具体作业清单以资料所列为准。