ci

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

CI/CD Skills

CI/CD Skills

CI/CD パイプラインに関する問題を解決するスキル群です。

This is a set of skills for solving CI/CD pipeline issues.

発動条件

Activation Conditions

  • 「CIが落ちた」「GitHub Actionsが失敗」
  • 「ビルドエラー」「テストが通らない」
  • 「パイプラインを直して」

  • "CI failed", "GitHub Actions failed"
  • "Build error", "Tests not passing"
  • "Fix the pipeline"

機能詳細

Feature Details

機能詳細トリガー
失敗分析See references/analyzing-failures.md「ログを見て」「原因を調べて」
テスト修正See references/fixing-tests.md「テストを直して」「修正案を出して」

FeatureDetailsTrigger
Failure AnalysisSee references/analyzing-failures.md"Check the logs", "Investigate the cause"
Test CorrectionSee references/fixing-tests.md"Fix the tests", "Propose a fix"

実行手順

Execution Steps

  1. テスト vs 実装判定(Step 0)
  2. ユーザーの意図を分類(分析 or 修正)
  3. 複雑度を判定(下記参照)
  4. 上記の「機能詳細」から適切な参照ファイルを読む、または ci-cd-fixer サブエージェント起動
  5. 結果を確認し、必要に応じて再実行
  1. Test vs Implementation Judgment (Step 0)
  2. Classify user's intent (Analysis or Correction)
  3. Determine complexity (see below)
  4. Read the appropriate reference file from the above "Feature Details", or launch the ci-cd-fixer subagent
  5. Confirm results, re-run if necessary

Step 0: テスト vs 実装判定(品質判定ゲート)

Step 0: Test vs Implementation Judgment (Quality Check Gate)

CI 失敗時、まず原因の切り分けを行う:
CI 失敗報告
┌─────────────────────────────────────────┐
│           テスト vs 実装判定             │
├─────────────────────────────────────────┤
│  エラーの原因を分析:                    │
│  ├── 実装が間違い → 実装を修正          │
│  ├── テストが古い → ユーザーに確認      │
│  └── 環境問題 → 環境修正                │
└─────────────────────────────────────────┘
When CI fails, first identify the cause:
CI Failure Report
┌─────────────────────────────────────────┐
│           Test vs Implementation Judgment             │
├─────────────────────────────────────────┤
│  Analyze the cause of the error:                    │
│  ├── Implementation is incorrect → Fix the implementation          │
│  ├── Test is outdated → Confirm with user      │
│  └── Environment issue → Fix the environment                │
└─────────────────────────────────────────┘

禁止事項(改ざん防止)

Prohibited Items (Tampering Prevention)

markdown
⚠️ CI 失敗時の禁止事項

以下の「解決策」は禁止です:

| 禁止 || 正しい対応 |
|------|-----|-----------|
| テスト skip 化 | `it.skip(...)` | 実装を修正 |
| アサーション削除 | `expect()` を消す | 期待値を確認 |
| CI チェック迂回 | `continue-on-error` | 根本原因修正 |
| lint ルール緩和 | `eslint-disable` | コードを修正 |
markdown
⚠️ Prohibited Items When CI Fails

The following "solutions" are prohibited:

| Prohibited | Example | Correct Response |
|------|-----|-----------|
| Test skipping | `it.skip(...)` | Fix the implementation |
| Assertion removal | Remove `expect()` | Check the expected value |
| Bypass CI checks | `continue-on-error` | Fix the root cause |
| Relax lint rules | `eslint-disable` | Fix the code |

判断フロー

Decision Flow

markdown
🔴 CI が失敗しています

**判断が必要です**:

1. **実装が間違い** → 実装を修正 ✅
2. **テストの期待値が古い** → ユーザーに確認を求める
3. **環境の問題** → 環境設定を修正

⚠️ テストの改ざん(skip化、アサーション削除)は禁止です

どれに該当しますか?
markdown
🔴 CI has failed

**Need to make a judgment**:

1. **Implementation is incorrect** → Fix the implementation ✅
2. **Test expected value is outdated** → Ask user for confirmation
3. **Environment issue** → Fix environment settings

⚠️ Tampering with tests (skipping, removing assertions) is prohibited

Which one applies?

承認が必要な場合

When Approval is Required

テスト/設定の変更がやむを得ない場合:
markdown
undefined
If changing tests/settings is unavoidable:
markdown
undefined

🚨 テスト/設定変更の承認リクエスト

🚨 Approval Request for Test/Configuration Changes

理由

Reason

[なぜこの変更が必要か]
[Why this change is necessary]

変更内容

Change Details

[差分]
[Diff]

代替案の検討

Alternative Consideration

  • 実装の修正で解決できないか確認した
ユーザーの明示的な承認を待つ
undefined
  • Confirmed if implementation fix can resolve the issue
Wait for explicit user approval
undefined

Git log 拡張フラグの活用(CC 2.1.49+)

Utilizing Git Log Extended Flags (CC 2.1.49+)

CI 失敗時の原因コミット特定に構造化ログを活用します。
Use structured logs to identify the causing commit when CI fails.

原因コミットの特定

Identifying the Causing Commit

bash
undefined
bash
undefined

構造化フォーマットでコミット分析

Analyze commits in structured format

git log --format="%h|%s|%an|%ad" --date=short -10
git log --format="%h|%s|%an|%ad" --date=short -10

トポロジカル順序で時系列分析

Chronological tracking with merge order consideration

git log --topo-order --oneline -20
git log --topo-order --oneline -20

変更ファイルと原因の紐付け

Link file changes to causes

git log --raw --oneline -5
undefined
git log --raw --oneline -5
undefined

主な活用場面

Main Usage Scenarios

用途フラグ効果
失敗原因の特定`--format="%h%s"`
時系列での追跡
--topo-order
マージ順序を考慮した追跡
変更影響の把握
--raw
ファイル変更の詳細表示
マージ除外分析
--cherry-pick --no-merges
実コミットのみを抽出
UsageFlagEffect
Identify failure cause`--format="%h%s"`
Chronological tracking
--topo-order
Track considering merge order
Understand change impact
--raw
Detailed display of file changes
Merge exclusion analysis
--cherry-pick --no-merges
Extract only actual commits

出力例

Output Example

markdown
🔍 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
markdown
🔍 CI Failure Cause Analysis

Recent Commits (Structured):
| Hash | Subject | Author | Date |
|------|---------|--------|------|
| a1b2c3d | feat: update API | Alice | 2026-02-04 |
| e4f5g6h | test: add tests | Bob | 2026-02-03 |

File Changes (--raw):
├── src/api/endpoint.ts (Modified) ← Type error occurred
├── tests/api.test.ts (Modified)
└── package.json (Modified)

→ Commit a1b2c3d is likely the cause
  Type error: src/api/endpoint.ts:42

サブエージェント連携

Subagent Integration

以下の条件を満たす場合、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
を参照。

Launch ci-cd-fixer via Task tool if:
  • Fix → Re-run → Failure loop occurs 2+ times
  • Or complex cases where errors span multiple files
Launch Pattern:
Task tool:
  subagent_type="ci-cd-fixer"
  prompt="Please diagnose and fix the CI failure. Error log: {error_log}"
ci-cd-fixer operates with safety first (default dry-run mode). See
agents/ci-cd-fixer.md
for details.

VibeCoder 向け

For VibeCoder

markdown
🔧 CI が壊れたときの言い方

1. **「CI が落ちた」「赤くなった」**
   - 自動テストが失敗している状態

2. **「なんで失敗してるの?」**
   - 原因を調べてほしい

3. **「直して」**
   - 自動で修正を試みる

💡 重要: テストを「ごまかす」修正は禁止です
   - ❌ テストを消す、スキップする
   - ⭕ コードを正しく直す

「テストが間違ってそう」と思ったら、
まず確認してから対応を決めましょう
markdown
🔧 How to say when CI breaks

1. **"CI failed", "turned red"**
   - State where automated tests are failing

2. **"Why is it failing?"**
   - Want to investigate the cause

3. **"Fix it"**
   - Automatically attempt to fix

💡 Important: Fixes that "cheat" tests are prohibited
   - ❌ Delete or skip tests
   - ⭕ Correctly fix the code

If you think "the test seems wrong",
First confirm, then decide on the response