メニュー
PRレビューで受けた指摘をCLAUDE.mdのルールとして蓄積するスキル。`/review-learn` または `/review-learn #123` で使用。レビュアーの知見をチーム全体の資産に変換し、同じ指摘を繰り返さないコードベースを実現する。
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 | review-learn |
| description | PRレビューで受けた指摘をCLAUDE.mdのルールとして蓄積するスキル。`/review-learn` または `/review-learn #123` で使用。レビュアーの知見をチーム全体の資産に変換し、同じ指摘を繰り返さないコードベースを実現する。 |
PRレビューで受けた指摘をCLAUDE.mdのルールとして蓄積するスキル。レビュアーの知見をチーム全体の資産に変換する。
Boris Cherny氏のTip #3「CLAUDE.mdへの投資」の拡張版:
| スキル | 学びの源泉 | タイミング |
|---|---|---|
/lessons | 自分で気づいた失敗・修正 | セッション終了時 |
/review-learn | 他者からの指摘 | PRマージ後 |
両方使うと、個人の気づき＋チームの知見が蓄積される。
/review-learn - 直近のマージ済みPRから学ぶ/review-learn #123 - 指定PRのレビューコメントから学ぶ/review-learn --my-prs - 自分が作成したPRのレビューから学ぶ（直近5件）# PR番号からレビューコメントを取得
gh pr view {PR番号} --json number,title,author,reviewDecision,reviews,comments
# 直近にマージされた自分のPRを取得
gh pr list --author @me --state merged --limit 5 --json number,title,mergedAt
ユーザーに対象PRを確認する:
直近のマージ済みPR:
1. #123 - Fix animation flickering (2日前)
2. #120 - Add user authentication (5日前)
3. #118 - Refactor API client (1週間前)
どのPRのレビューから学びますか？（番号 or 全て）
変更理由: isResolved / isOutdated は REST API では取得できず、GraphQL でのみ取得可能。
対応済み判定に必須のため、GraphQL をメインのデータ取得手段として使用する。
# GraphQL でレビュースレッド・コミット・レビューを一括取得
gh api graphql -f query='
query($owner: String!, $repo: String!, $pr: Int!) {
repository(owner: $owner, name: $repo) {
pullRequest(number: $pr) {
author { login }
commits(last: 100) {
nodes {
commit {
committedDate
message
additions
deletions
}
}
}
reviewThreads(first: 100) {
nodes {
isResolved
isOutdated
path
comments(first: 10) {
nodes {
author { login }
body
createdAt
}
}
}
}
reviews(first: 50) {
nodes {
author { login }
state
body
}
}
}
}
}
' -f owner='{owner}' -f repo='{repo}' -F pr={pr_number}
取得データの用途:
reviewThreads: 各スレッドの isResolved / isOutdated で対応済み判定commits: コメント後の同一ファイルへのコミット有無を確認reviews: APPROVED レビューの body から具体的指摘を抽出author: PR作者の特定（返信の判別に使用）目的: 「対応した指摘のみをナレッジ化する」ためのフィルタ。 Bot の的外れな指摘や、未対応のコメントをノイズとして除外する。
| 著者種別 | 判定方法 | デフォルト扱い |
|---|---|---|
| Bot | login が [bot] で終わる or GitHub API の is_bot | 蓄積対象外 |
| 人間 | 上記以外 | 蓄積候補 |
以下の順で判定し、最初にマッチした条件を採用する:
対応済み判定(thread):
1. thread.isResolved == true → 対応済み（確定）
2. thread.isOutdated == true かつ
thread.comments[0].createdAt 以降に同一ファイル（thread.path）へのコミットあり
→ 対応済み（高確度）
3. PR作者からの返信に対応キーワードあり
（"対応しました", "修正しました", "fixed", "done", "updated"）
→ 対応済み（中確度）
4. いずれにも該当しない → 未対応
| 対応済み | 未対応 | |
|---|---|---|
| Bot | 蓄積候補に昇格 | 除外（デフォルト） |
| 人間 | 蓄積候補（高優先） | 除外 |
レビュー state: APPROVED の body に具体的な指摘（番号付きリスト等）が含まれる場合:
例: APPROVED レビューの body が以下の場合
LGTMです。以下の修正ありがとうございました:
1. LifecycleResumeEffectの追加
2. トリガーイベントの送信タイミング修正
→ 2つの個別の蓄積候補として抽出
レビューコメントを以下のカテゴリに分類:
| カテゴリ | 判定基準 | 例 |
|---|---|---|
| 命名規則 | 変数名、関数名、クラス名への指摘 | 「fetchではなくgetを使う」 |
| アーキテクチャ | レイヤー構造、依存方向への指摘 | 「ViewModelからRepositoryを直接呼ばない」 |
| エラーハンドリング | 例外処理、Resultパターンへの指摘 | 「Resultでラップして呼び出し元で処理」 |
| テスト | テストコード、カバレッジへの指摘 | 「エッジケースのテストを追加」 |
| パフォーマンス | 効率、最適化への指摘 | 「N+1クエリに注意」 |
| セキュリティ | 脆弱性、認証への指摘 | 「入力値のサニタイズ」 |
| コードスタイル | フォーマット、可読性への指摘 | 「早期リターンを使う」 |
| ドキュメント | コメント、READMEへの指摘 | 「公開APIにはdocstringを」 |
以下の基準で「ルール化すべき指摘」を抽出:
抽出対象:
除外対象:
以下のフォーマットでルール案を生成:
### {カテゴリ名}
- {具体的なルール}。{理由や背景}
- 📝 PR #{PR番号} で @{レビュアー} さんが指摘
記述の品質基準:
良い例:
### 命名規則
- Repository層のメソッドは `fetchXxx` ではなく `getXxx` を使う。fetchは非同期を暗示するが、Repositoryは同期/非同期を抽象化するため
- 📝 PR #123 で @tanaka さんが指摘
### エラーハンドリング
- API呼び出しでは `Result<T, E>` でラップし、呼び出し元で処理する。例外を投げると呼び出し側でtry-catchが必要になり、漏れやすい
- 📝 PR #120 で @suzuki さんが指摘
蓄積候補を対応確度別にグループ化して表示する:
## 蓄積候補（対応済み指摘から抽出）
### 確実に対応した指摘（resolved / APPROVED body）
1. {指摘の要約} → {対応内容}
- 📝 PR #{PR番号} で @{レビュアー} さんが指摘
→ ルール案: 「{具体的なルール文}」
### おそらく対応した指摘（outdated + コミットあり）
2. ...（該当があれば表示）
---
除外した指摘: Bot未対応 {N}件 / 人間未対応 {N}件
（詳細を見たい場合は「除外した指摘を見せて」と伝えてください）
追記先セクション:
## Review Learnings セクションがあればそこに追記## Lessons Learned の後に作成## Review Learnings
このセクションはPRレビューで受けた指摘から自動生成されました。
`/review-learn` コマンドで更新できます。
### 命名規則
- Repository層のメソッドは `fetchXxx` ではなく `getXxx` を使う
- 📝 PR #123 で @tanaka さんが指摘
### エラーハンドリング
- API呼び出しでは `Result<T, E>` でラップする
- 📝 PR #120 で @suzuki さんが指摘
エラー1: GitHubリポジトリではない
エラー2: gh CLIが未認証
GitHub CLIが認証されていません。
以下のコマンドで認証してください:
$ gh auth login
エラー3: PRにレビューコメントがない
エラー4: 自分のPRがない
| シナリオ | 効果 |
|---|---|
| 新メンバー参加 | 過去のレビュー指摘が蓄積済み。同じミスをしない |
| レビュアー | 同じ指摘を繰り返す手間が減る |
| チーム全体 | 暗黙知が形式知化され、コード品質が均一に |
| オンボーディング | 「なぜこのルール？」の背景（PR番号）が追跡可能 |