name: ci description: “CI变红？叫我们。管道消防队出动。使用当用户提到CI失败、构建错误、测试失败或管道问题时。不要加载：本地构建、标准实施工作、审查或设置。” description-en: “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.” description-ja: “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.” allowed-tools: [“Read”, “Grep”, “Bash”, “Task”] user-invocable: false context: fork argument-hint: “[analyze|fix|run]”
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 失败原因分析
最近提交（结构化）：
| Hash | Subject | Author | Date |
|------|---------|--------|------|
| a1b2c3d | feat: update API | Alice | 2026-02-04 |
| e4f5g6h | test: add tests | Bob | 2026-02-03 |
变更文件（--raw）：
├── src/api/endpoint.ts (Modified) ← 类型错误发生
├── tests/api.test.ts (Modified)
└── package.json (Modified)
→ a1b2c3d 提交可能为主要原因
类型错误: src/api/endpoint.ts:42
子代理联动
满足以下条件时，使用Task工具启动ci-cd-fixer：
- 修正 → 重新执行 → 失败的循环发生 2次以上
- 或，错误跨多个文件的复杂案例
启动模式：
Task工具：
subagent_type="ci-cd-fixer"
prompt="请诊断和修复CI失败。错误日志: {error_log}"
ci-cd-fixer 以安全第一行动（默认dry-run模式）。
详情参照agents/ci-cd-fixer.md。
向VibeCoder
🔧 CI 损坏时的说法
1. **「CI失败了」「变红了」**
- 自动测试失败状态
2. **「为什么失败？」**
- 希望调查原因
3. **「修复」**
- 尝试自动修正
💡 重要：禁止「糊弄」测试的修正
- ❌ 删除测试、跳过测试
- ⭕ 正确修正代码
认为「测试可能错误」时，
首先确认后再决定对应