القائمة
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番号）が追跡可能 |