名称: ci 描述: “CI 红了吗？叫我们。管道消防队出动。当用户提到 CI 失败、构建错误、测试失败或管道问题时使用。不要用于：本地构建、标准实现工作、评审或设置。” 英文描述: “CI red? Call us. Pipeline fire brigade deploys. Use when user mentions CI failures, build errors, test failures, or pipeline issues. Do NOT load for: local builds, standard implementation work, reviews, or setup.” 日文描述: “CIが赤くなったら呼んで。パイプライン消防隊、出動します。Use when user mentions CI failures, build errors, test failures, or pipeline issues. Do NOT load for: local builds, standard implementation work, reviews, or setup.” 允许工具: [“读取”, “搜索”, “Bash”, “任务”] 用户可调用: false 上下文: 分叉 参数提示: “[分析|修复|运行]”
CI/CD 技能
这是一个解决 CI/CD 管道问题的技能群。
触发条件
- “CI 失败” “GitHub Actions 失败”
- “构建错误” “测试不通过”
- “修复管道”
功能详情
| 功能 | 详情 | 触发器 |
|---|---|---|
| 失败分析 | 见 references/analyzing-failures.md | “查看日志” “调查原因” |
| 测试修正 | 见 references/fixing-tests.md | “修复测试” “提出修正方案” |
执行步骤
- 测试 vs 实现判定（第 0 步）
- 分类用户意图（分析或修正）
- 判定复杂度（见下）
- 从上述“功能详情”中读取适当参考文件，或启动 ci-cd-fixer 子代理
- 确认结果，根据需要重新执行
第 0 步: 测试 vs 实现判定（质量判定门）
CI 失败时，首先进行原因分析：
CI 失败报告
↓
┌─────────────────────────────────────────┐
│ 测试 vs 实现判定 │
├─────────────────────────────────────────┤
│ 分析错误原因： │
│ ├── 实现错误 → 修正实现 │
│ ├── 测试过时 → 向用户确认 │
│ └── 环境问题 → 修正环境 │
└─────────────────────────────────────────┘
禁止事项（防止篡改）
⚠️ CI 失败时的禁止事项
以下“解决方案”被禁止：
| 禁止 | 例子 | 正确应对 |
|------|-----|-----------|
| 测试跳过化 | `it.skip(...)` | 修正实现 |
| 断言删除 | 删除 `expect()` | 确认预期值 |
| CI 检查绕过 | `continue-on-error` | 修正根本原因 |
| lint 规则放松 | `eslint-disable` | 修正代码 |
判断流程
🔴 CI 失败中
**需要判断**：
1. **实现错误** → 修正实现 ✅
2. **测试预期值过时** → 向用户请求确认
3. **环境问题** → 修正环境设置
⚠️ 禁止篡改测试（跳过化、断言删除）
属于哪种情况？
需要批准的情况
测试/设置更改不可避免时：
## 🚨 测试/设置更改的批准请求
### 理由
[为何需要此更改]
### 更改内容
[差异]
### 替代方案考虑
- [ ] 已确认是否可通过实现修正解决
等待用户的明确批准
Git log 扩展标志的活用（CC 2.1.49+）
利用结构化日志在 CI 失败时识别原因提交。
原因提交识别
# 结构化格式提交分析
git log --format="%h|%s|%an|%ad" --date=short -10
# 拓扑顺序时间序列分析
git log --topo-order --oneline -20
# 更改文件与原因关联
git log --raw --oneline -5
主要应用场景
| 用途 | 标志 | 效果 |
|---|---|---|
| 失败原因识别 | `–format="%h | %s"` |
| 时间序列追踪 | --topo-order |
考虑合并顺序的追踪 |
| 更改影响把握 | --raw |
文件更改详细显示 |
| 合并排除分析 | --cherry-pick --no-merges |
提取实际提交 |
输出示例
🔍 CI 失败原因分析
最近的提交（结构化）：
| 哈希 | 主题 | 作者 | 日期 |
|------|---------|--------|------|
| a1b2c3d | 功能：更新 API | Alice | 2026-02-04 |
| e4f5g6h | 测试：添加测试 | Bob | 2026-02-03 |
更改文件（--raw）：
├── src/api/endpoint.ts（已修改）← 类型错误发生
├── tests/api.test.ts（已修改）
└── package.json（已修改）
→ a1b2c3d 提交可能是原因
类型错误：src/api/endpoint.ts:42
子代理协作
满足以下条件时，使用任务工具启动 ci-cd-fixer：
- 修正 → 重新执行 → 失败循环发生 2 次以上
- 或错误跨多个文件的复杂案例
启动模式：
任务工具：
subagent_type="ci-cd-fixer"
prompt="请诊断和修复 CI 失败。错误日志：{error_log}"
ci-cd-fixer 以安全优先模式运行（默认干运行模式）。
详情见 agents/ci-cd-fixer.md。
面向 VibeCoder
🔧 CI 损坏时的说法
1. **"CI 失败" "变红"**
- 自动测试失败的状态
2. **"为什么失败？"**
- 希望调查原因
3. **"修复"**
- 尝试自动修正
💡 重要：禁止“糊弄”测试的修正
- ❌ 删除测试、跳过测试
- ⭕ 正确修正代码
如果认为“测试可能错误”，
首先确认后再决定应对措施