// 分析 CI 失败原因并给出修复建议。在用户提到 CI 失败、pipeline 失败、构建失败、测试失败时使用。典型场景：PR 合前 CI 红、需要根因与修复建议时。
| name | ci-analyze |
| description | 分析 CI 失败原因并给出修复建议。在用户提到 CI 失败、pipeline 失败、构建失败、测试失败时使用。典型场景：PR 合前 CI 红、需要根因与修复建议时。 |
| argument-hint | <PR 编号或 CI URL> |
| allowed-tools | ["Read","Grep","Glob","Bash(gh run list:*)","Bash(gh run view:*)","Bash(gh pr view:*)","Bash(gh pr checks:*)","Bash(gh api *)","Bash(git *)","Bash(curl *)","Bash(jq *)","Bash(cat *)","Bash(wc *)","Bash(head *)","Bash(tail *)","Bash(grep *)"] |
开始时声明："我正在使用 ci-analyze skill 分析 CI 失败原因。"
本项目使用 GitHub Actions（.github/workflows/ci-test.yml），CI 流程：
gofmt -s -l . 检查未格式化文件make staticcheckgo build ./examples/...make unittest# 按 PR 编号分析
ci-analyze 123
# 按 run URL 分析
ci-analyze https://github.com/qiniu/go-sdk/actions/runs/999999
# 获取 PR 的 CI checks
gh pr checks <PR编号> --repo qiniu/go-sdk
# 或获取最近一次 workflow run 的失败
gh run list --repo qiniu/go-sdk --branch <branch> --limit 5
gh run view <run-id> --repo qiniu/go-sdk --log-failed
获取 CI 状态概览：
gh pr view <PR编号> --repo qiniu/go-sdk \
--json statusCheckRollup \
--jq '.statusCheckRollup[]? | {name: .context, state: .state, url: .targetUrl}'
# GitHub Actions 失败日志
gh run view <run-id> --repo qiniu/go-sdk --log-failed
对每个失败的 check/job：
## CI 失败分析报告
### 失败汇总
| 序号 | 测试/Job | 错误类型 | 根因 | 置信度 |
|------|----------|----------|------|--------|
| 1 | ... | ... | ... | 高/中/低 |
### 详细分析
#### 失败 1: <测试名>
错误信息：
<具体错误日志>
日志来源：
<GitHub Actions URL 或 API 端点>
根因分析：
<分析过程>
修复建议：
<具体修复方案>
相关代码：
<文件路径:行号>
gofmt -s -w . 或修复 staticcheck 报告的问题| 失败类型 | 典型表现 | 修复方式 |
|---|---|---|
| gofmt | "Files not formatted" | gofmt -s -w . |
| staticcheck | SA/S/ST 开头的错误码 | 按 staticcheck 建议修复 |
| examples 编译 | go build ./examples/... 失败 | 检查 examples 依赖的包是否有 breaking change |
| 单元测试 | FAIL + 具体测试函数名 | 定位测试代码和被测代码 |
| Windows/macOS | 平台相关路径、换行符问题 | 使用 filepath.Join 等跨平台写法 |
只有满足以下条件才能判定为 flaky：
# 检查历史运行
gh run list --repo qiniu/go-sdk --branch <branch> --workflow "Run Test Cases" --limit 10
执行本 skill 时同时遵守 AGENTS.md 中的系统规范；与本 skill 冲突时以本 skill 为准。
运行提交前检查：代码格式化验证、静态检查和单元测试。在准备提交代码、检查代码质量或验证修改是否通过时使用。
运行代码生成并检查变更。在修改 API 规范（api-specs/ YAML）或 sandbox OpenAPI/protobuf 后使用。
分析 GitHub issues、PRs 与 discussions，提供见解或实施指导。在用户提供 GitHub URL、issue/PR 编号或询问仓库内容时使用。典型场景：看 issue/PR 状态、拉 diff 与 checks、要结论与建议下一步时。
遵循 Angular 规范生成 git commit 消息。在用户请求创建 commit、写 commit message 或暂存并提交时使用。典型场景：改完代码要提交前、或要求按 Angular 规范写 message 时。
检查发布版本号是否在三处保持一致（conf/conf.go、CHANGELOG.md、README.md）。在准备发布新版本时使用。