원클릭으로
ci-learn
CI/GitHub Actionsの失敗パターンをCLAUDE.mdに蓄積するスキル。`/ci-learn` で直近の失敗runから学び、`/ci-learn #run_id` で指定runを分析。同じCI失敗を繰り返さないコードベースを実現する。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
CI/GitHub Actionsの失敗パターンをCLAUDE.mdに蓄積するスキル。`/ci-learn` で直近の失敗runから学び、`/ci-learn #run_id` で指定runを分析。同じCI失敗を繰り返さないコードベースを実現する。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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が肥大化している場合や、学習トライアドの蓄積を分割管理したい場合に使用。
| 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/ ディレクトリにワークフローファイルを追加してください。