القائمة
PRレビューで受けた指摘をCLAUDE.mdのルールとして蓄積するスキル。`/review-learn` または `/review-learn #123` で使用。レビュアーの知見をチーム全体の資産に変換し、同じ指摘を繰り返さないコードベースを実現する。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/xtone/ai_development_tools --skill review-learnيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
استنادا إلى تصنيف SOC المهني
عرض SKILL.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番号）が追跡可能 |