name: ci description: “诊断和修复CI/CD流水线故障。当用户提到’CI’、‘GitHub Actions’、‘GitLab CI’、‘ビルドエラー’、‘テスト失敗’、‘パイプライン’、‘CIが落ちた’，或要求分析构建/测试失败时使用。不要用于：本地构建、常规实现工作、代码审查、环境设置。” allowed-tools: [“Read”, “Grep”, “Bash”, “Task”] context: fork metadata: skillport: category: ci tags: [ci-cd, github-actions, pipeline, debugging] alwaysApply: false
CI/CD 技能
用于解决CI/CD流水线相关问题的技能集合。
触发条件
- 「CI失败了」「GitHub Actions运行失败」
- 「构建错误」「测试不通过」
- 「请修复流水线」
包含的子技能
| 技能 | 用途 | 触发词 |
|---|---|---|
| ci-analyze-failures | 分析失败原因 | 「查看日志」「调查原因」 |
| ci-fix-failing-tests | 提出测试修复建议 | 「修复测试」「提出修正方案」 |
路由逻辑
根据用户意图选择合适的子技能：
需要分析调查的情况
→ 参考 ci-analyze-failures/doc.md
示例：
- 「请告诉我CI失败的原因」
- 「查看GitHub Actions的日志」
- 「为什么构建失败了？」
需要修复处理的情况
→ 参考 ci-fix-failing-tests/doc.md
示例：
- 「请修复测试」
- 「请修正错误」
- 「让流水线通过」
执行步骤
- 测试 vs 实现判定（第0步）
- 对用户意图进行分类（分析 或 修复）
- 判定复杂度（参考下文）
- 阅读相应子技能的 doc.md，或启动 ci-cd-fixer 子代理
- 确认结果，必要时重新执行
第0步：测试 vs 实现判定（质量判定门）
CI失败时，首先进行原因分类：
CI 失败报告
↓
┌─────────────────────────────────────────┐
│ 测试 vs 实现判定 │
├─────────────────────────────────────────┤
│ 分析错误原因： │
│ ├── 实现错误 → 修正实现 │
│ ├── 测试过时 → 向用户确认 │
│ └── 环境问题 → 修正环境 │
└─────────────────────────────────────────┘
禁止事项（防止篡改）
⚠️ CI 失败时的禁止事项
以下“解决方案”被禁止：
| 禁止行为 | 示例 | 正确做法 |
|------|-----|-----------|
| 跳过测试 | `it.skip(...)` | 修正实现 |
| 删除断言 | 删除 `expect()` | 确认期望值 |
| 绕过CI检查 | `continue-on-error` | 修复根本原因 |
| 放宽lint规则 | `eslint-disable` | 修正代码 |
判断流程
🔴 CI 运行失败
**需要判断**：
1. **实现错误** → 修正实现 ✅
2. **测试期望值过时** → 请求用户确认
3. **环境问题** → 修正环境设置
⚠️ 禁止篡改测试（跳过、删除断言）
属于哪种情况？
需要批准的情况
当测试/设置的更改不可避免时：
## 🚨 请求批准测试/设置更改
### 原因
[为什么需要此更改]
### 更改内容
[差异]
### 替代方案考虑
- [ ] 确认是否无法通过修正实现来解决
等待用户的明确批准
子代理协作
满足以下条件时，使用Task工具启动 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. **「请修复」**
- 尝试自动修复
💡 重要：禁止“糊弄”测试的修复
- ❌ 删除测试、跳过测试
- ⭕ 正确修正代码
如果觉得“测试可能错了”，
请先确认再决定如何应对