Menu
CI/GitHub Actionsの失敗パターンをCLAUDE.mdに蓄積するスキル。`/ci-learn` で直近の失敗runから学び、`/ci-learn #run_id` で指定runを分析。同じCI失敗を繰り返さないコードベースを実現する。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | ci-learn |
| description | CI/GitHub Actionsの失敗パターンをCLAUDE.mdに蓄積するスキル。`/ci-learn` で直近の失敗runから学び、`/ci-learn #run_id` で指定runを分析。同じCI失敗を繰り返さないコードベースを実現する。 |
CI/GitHub Actionsの失敗パターンをCLAUDE.mdに蓄積するスキル。同じCI失敗を繰り返さないコードベースを実現する。
学習トライアドの第3の柱として、CI/CDパイプラインの失敗から体系的に学ぶ:
| スキル | 学びの源泉 | タイミング |
|---|---|---|
/lessons | 自分で気づいた失敗・修正 | セッション終了時 |
/review-learn | 他者からの指摘 | PRマージ後 |
/ci-learn | CI/CDの失敗パターン | CI失敗発生後 |
3つを組み合わせることで、個人の気づき＋チームの知見＋システムのフィードバックが蓄積される。
/ci-learn — 直近の失敗 CI run から学ぶ/ci-learn #run_id — 指定 run ID から学ぶ/ci-learn --recent — 直近5件の失敗 run を分析# 指定 run の詳細を取得
gh run view {run_id} --json databaseId,displayTitle,conclusion,headBranch,createdAt,event,url
# 直近の失敗 run を取得
gh run list --status failure --limit 5 --json databaseId,displayTitle,conclusion,headBranch,createdAt,event,workflowName
ユーザーに対象 run を確認する:
直近の失敗 CI Run:
1. #12345 - Build and Test (main) — 2時間前
2. #12340 - Deploy Staging (feature/auth) — 1日前
3. #12335 - Lint Check (fix/typo) — 2日前
どの run から学びますか？（番号 or 全て）
--recent フラグの場合直近5件の失敗 run を全て分析対象にする。
# 失敗ステップのログのみ取得
gh run view {run_id} --log-failed
# run の詳細（jobs, steps）を取得
gh run view {run_id} --json jobs
取得データの用途:
--log-failed: エラーメッセージ・スタックトレースの抽出jobs[].steps[]: どのステップで失敗したかの特定（name, conclusion）headBranch: 失敗したブランチ（PR関連か判別）event: トリガー種別（push, pull_request, workflow_dispatch）失敗ログを以下のカテゴリに分類:
| カテゴリ | 判定基準 | 例 |
|---|---|---|
| ビルド | コンパイルエラー、依存関係解決失敗 | 「Gradle 8.x では kotlin.jvm.target を明示」 |
| テスト | テスト失敗、タイムアウト | 「@Test アノテーション忘れ」 |
| リント・フォーマット | lint/ktlint/detekt エラー | 「import の順序ルール」 |
| 環境・設定 | Node/Java バージョン不一致、secrets 不足 | 「JAVA_HOME の設定」 |
| デプロイ | リリース、アーティファクト関連 | 「artifact actions v4 への移行」 |
| 権限・認証 | token 期限切れ、権限不足 | 「GITHUB_TOKEN のスコープ」 |
| タイムアウト | ジョブ/ステップのタイムアウト | 「E2Eテストの timeout 設定」 |
以下の基準で「ルール化すべきパターン」を抽出:
抽出対象:
除外対象:
## Lessons Learned と ## CI Learnings セクションを確認以下のフォーマットでルール案を生成:
### {カテゴリ名}
- {具体的なルール}。{理由や背景}
- 🔧 CI Run #{run_id} ({workflow名}) — {日付}
記述の品質基準（lessons-md-manager と同一）:
良い例:
### ビルド
- Gradle 8.x では `kotlin.jvm.target` を明示的に設定する。未設定だとCIのJDKバージョンとローカルで異なりビルドが失敗する
- 🔧 CI Run #12345 (Build and Test) — 2026-02-15
### テスト
- CI環境ではテストのタイムアウトをローカルの2倍に設定する。GitHub Actions のランナーはローカルマシンより低速なため
- 🔧 CI Run #12340 (Unit Tests) — 2026-02-14
失敗パターンをカテゴリ別にグループ化して提示:
## CI 失敗パターン分析結果
### 分析対象
- Run #12345: Build and Test (main) — failure
### 蓄積候補
#### ビルド
1. Gradle 8.x で kotlin.jvm.target 未設定 → 明示的に設定する
- 🔧 CI Run #12345 — 2026-02-15
→ ルール案: 「Gradle 8.x では `kotlin.jvm.target` を明示的に設定する」
#### テスト
1. CI環境でのタイムアウト → タイムアウト値を2倍に設定
- 🔧 CI Run #12340 — 2026-02-14
→ ルール案: 「CI環境ではテストのタイムアウトをローカルの2倍に設定する」
---
除外したパターン: 一時障害 1件 / flaky 2件
ユーザーの承認を得てからステップ8に進む。
追記先: ## CI Learnings セクション
## CI Learnings
このセクションはCI/GitHub Actionsの失敗パターンから自動生成されました。
`/ci-learn` コマンドで更新できます。
### ビルド
- Gradle 8.x では `kotlin.jvm.target` を明示的に設定する。未設定だとCIのJDKバージョンとローカルで異なりビルドが失敗する
- 🔧 CI Run #12345 (Build and Test) — 2026-02-15
### テスト
- CI環境ではテストのタイムアウトをローカルの2倍に設定する。GitHub Actions のランナーはローカルマシンより低速なため
- 🔧 CI Run #12340 (Unit Tests) — 2026-02-14
セクションの配置:
## CI Learnings セクションがあればそこに追記## Lessons Learned の後に作成エラー1: GitHubリポジトリではない
エラー2: gh CLIが未認証
GitHub CLIが認証されていません。
以下のコマンドで認証してください:
$ gh auth login
エラー3: 失敗した CI run がない
直近に失敗した CI run がありません。
すべてのワークフローが正常に完了しています。
エラー4: ログが取得できない（90日超過）
CI Run #{run_id} のログは保存期間（90日）を超えているため取得できません。
より新しい run を指定してください。
エラー5: GitHub Actions を使用していない
このリポジトリには GitHub Actions ワークフローがありません。
.github/workflows/ ディレクトリにワークフローファイルを追加してください。
Figma のワイヤーフレーム URL から仕様書一式を docs/ 配下に Markdown で抽出するスキル。ページ構成・ユースケース・アクター・データモデル・コンポーネントを 15 ステップで段階的に生成し、整合性／データモデル／コンポーネントの 3 レビューを作成する。**既存リポジトリの機能拡張モード** では既存モデル・ルーティング・ビューを再利用優先。**レビュー反復反映ステップ** では質問ループで方針を確定しドキュメントに反映する。Figma URL が提供されたとき、Figma デザインから実装用仕様書を作りたいとき、または既存仕様書の精度向上を求められたときに使用する。
Claude Codeセッションの効率を分析・スコアリングするWebツール。セッションログ（JSONL）を解析し、7観点100点満点で「無駄の有無」を評価。npx session-evaluatorで起動し、ブラウザUIでセッション選択→分析→改善提案まで実行可能。
PRの変更内容をトリアージし、変更カテゴリ分類・表層チェック・必要リファレンス判定を行います。結果を`.pr-triage.json`に出力し、後続のコードレビューフェーズで活用します。CI環境でのコスト最適化に使用してください。
PRやコード変更の汎用コードレビューを実施します。コードの品質、セキュリティ、設計を共通基準で評価し、approve/rejectを判断します。「このPRをレビュー」「コードレビューして」「マージ前チェック」などの依頼や、gh pr viewコマンドの実行時に使用してください。
テスト仕様書（Excel/Notion）からFlutter integration_testコードを自動生成するスキル。 Page Objectパターン + Key規約に基づき、仕様ステップとコードの対応を示すマッピングレポートも生成する。 「E2Eテストを生成」「テスト仕様からテストコードを作って」「integration_testを生成」などの発言で発動。
CLAUDE.mdを分割ルールファイル(.claude/rules/)で管理するスキル。学習トライアドの書き込み先を分割ファイルにリダイレクトし、自動マージでCLAUDE.mdを生成。/rules-init, /rules-merge, /rules-add, /rules-status コマンドを提供。CLAUDE.mdが肥大化している場合や、学習トライアドの蓄積を分割管理したい場合に使用。