name: ci description: “CI变红时呼叫。管道消防队，出动。当用户提到CI失败、构建错误、测试失败或管道问题时使用。不要用于：本地构建、标准实现工作、审查或设置。” description-en: “CI变红？呼叫我们。管道消防队部署。当用户提到CI失败、构建错误、测试失败或管道问题时使用。不要用于：本地构建、标准实现工作、审查或设置。” description-ja: “CI变红时呼叫。管道消防队，出动。当用户提到CI失败、构建错误、测试失败或管道问题时使用。不要用于：本地构建、标准实现工作、审查或设置。” 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: 更新 API | Alice | 2026-02-04 |
| e4f5g6h | test: 添加测试 | Bob | 2026-02-03 |

变更文件（--raw）：
├── src/api/endpoint.ts（修改）← 类型错误发生
├── tests/api.test.ts（修改）
└── package.json（修改）

→ a1b2c3d 的提交可能是原因
  类型错误：src/api/endpoint.ts:42

子代理联动

满足以下条件时，使用 Task tool 启动 ci-cd-fixer：

修正 → 重新执行 → 失败的循环发生 2次以上
或者，错误涉及多个文件的复杂情况

启动模式：

Task tool：
  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. **“修复它”**
   - 尝试自动修正

💡 重要：禁止“糊弄”测试的修正
   - ❌ 删除测试、跳过测试
   - ⭕ 正确修正代码

如果觉得“测试可能错了”，
首先确认，然后决定对应方式