用途：排查 Materialize 仓库 PR 上的 CI 失败，回答“CI 为什么红了”“构建坏了”“检查失败”等问题。
前置条件：需安装并认证 gh（GitHub CLI）与 bk（Buildkite CLI）。先验证：which gh && gh auth status；which bk && bk auth status。任一缺失或未认证就停止并提示用户修复（Buildkite 用 bk configure 或 bk auth login），不要改用 REST API 等替代方案。gh 与 bk 的网络请求会被默认沙箱拦截，所有 Bash 命令需使用 dangerouslyDisableSandbox: true。
使用方式：先从参数提取 PR 号（支持纯数字或完整 URL）。用 gh pr view <PR_NUMBER> --json headRefName --jq .headRefName 获取分支，或用 gh pr checks <PR_NUMBER> 列出失败检查，从失败行 URL 中解析 pipeline、build 号与 job ID。优先查看构建注解：bk api /pipelines/<PIPELINE>/builds/<BUILD_NUMBER>/annotations --no-pager，注解含错误摘要、堆栈及已知 flaky 测试的 issue 链接。注解不足时再取日志，按 clippy、lint-and-rustfmt、cargo-test、fast-sql-logic-tests、testdrive 等顺序排查，命令如 bk job log <JOB_ID> -p <PIPELINE> -b <BUILD_NUMBER> --no-timestamps --no-pager，可先 grep 定位错误。
主要能力：识别 Materialize 特有失败模式，如 clippy 的 as_conversions、needless_borrow、clone_on_ref_ptr；check-test-flags 未在 action.py 与 mzcompose/init.py 注册新配置标志；cargo 测试的 unwrap_err 或断言差异；testdrive 崩溃后的级联失败（只关注首个错误）；SLT 输出错误与连接错误的区分。最后按根因而非 job 名归类，区分 PR 引入的回归与既有 flaky 测试。
限制：仅适用于 Materialize 仓库且必须使用 gh 与 bk；资料未提供其他平台或替代工具支持。