| name | issue-review |
| description | GitHub Issueの品質をレビューする。目的・調査・修正方針・根拠が揃っているかチェックし、方針の妥当性をWebで再調査して検証する。IDがなければissue-listで選択させる。 |
Issue Review
GitHub Issueの品質をレビューし、修正方針の妥当性を独立に検証する。
手順
1. Issue特定
- 引数にissue番号またはURLがあればそれを使う
- なければ
gh issue list --repo Cohey0727/ShogiGPTApp --state open で一覧を表示し、ユーザーに選択させる
2. Issue内容の取得
gh issue view <番号> --repo Cohey0727/ShogiGPTApp
gh issue view <番号> --repo Cohey0727/ShogiGPTApp --comments
3. 構造チェック
以下の4要素が揃っているかを判定し、不足があれば指摘する:
| 要素 | 説明 | 判定基準 |
|---|
| 目的 | なぜこのissueが必要か | 「概要」「背景」「目的」に相当するセクションがある。解決すべき問題が明文化されている |
| 調査 | 現状の分析・データ | 現在の実装の状態、計測値、再現手順、比較対象など具体的な事実が記載されている |
| 修正方針 | 何をどう変えるか | タスクリスト、設計案、アルゴリズム選定など具体的な実装計画がある |
| 根拠 | なぜその方針を選んだか | 参考実装、論文、ベンチマーク、他エンジンの事例など、方針の裏付けがある |
各要素を ✅ / ⚠️ / ❌ で評価する。
4. コード事実の検証
Issueが前提としているコードの状態が、実際の最新コードと一致しているかを確認する:
- ファイルパス・行番号の確認: issueが参照しているファイルや行番号が実在するか、Read/Grepで確認
- 関数・変数の存在確認: issueに書かれた関数名・変数名・構造体が実際に存在し、記述通りの振る舞いをしているか
- コードパスの確認: 「この関数はここからしか呼ばれない」「この条件でのみ実行される」等の記述が正しいか、呼び出し元をGrepで確認
- 変更済み箇所の検出: issueが書かれた後にコードが変更され、前提が崩れていないか(git logで確認)
事実と異なる記述があれば、具体的にどこが違うかを指摘する。
5. 修正方針の妥当性を再調査
Issueに書かれた修正方針が正しいかを 独立に 検証する:
- Web検索で裏取り: 方針の核となる技術(アルゴリズム、ライブラリ、設計パターン等)を検索し、issueの記述と矛盾がないか確認
- 参考実装の確認: issueが参照している外部プロジェクト(やねうら王、dlshogi、KataGo等)のソースを確認し、記述が正確か検証
- 代替案の検討: issueが検討していない有力な代替案がないか調査
- リスクの洗い出し: 方針に隠れたリスク(性能劣化、互換性破壊、保守性低下等)がないか検討
5. レビュー結果の記録
レビュー結果をissueコメントに書き込む:
gh issue comment <番号> --repo Cohey0727/ShogiGPTApp --body "$(cat <<'EOF'
## Issue Review (YYYY-MM-DD)
### 構造チェック
| 要素 | 評価 | コメント |
|------|------|----------|
| 目的 | ✅/⚠️/❌ | ... |
| 調査 | ✅/⚠️/❌ | ... |
| 修正方針 | ✅/⚠️/❌ | ... |
| 根拠 | ✅/⚠️/❌ | ... |
### コード事実の検証
| 記述 | 実際 | 一致 |
|------|------|------|
| (issueが前提としているコードの事実) | (実際のコードの状態) | ✅/❌ |
### 方針の検証結果
#### 裏取り
- 検索・確認した内容と結果
#### 代替案
- 検討すべき代替アプローチ(あれば)
#### リスク
- 見落とされているリスク(あれば)
### 総合判定
- **GO** / **要修正** / **要再設計**
- 理由:
EOF
)"
ルール
- issueの記述を鵜呑みにしない。必ずWeb検索や参考実装の確認で独立に検証する
- issueが前提としているコードの事実は、必ず実際のコードをRead/Grepして裏取りする。ファイルパス、行番号、関数名、呼び出し関係が現在のコードと一致するか確認する。issueが書かれた後にコードが変更されている可能性を常に疑う
- 方針が正しい場合も「正しいことを確認した」と根拠を添えて記録する
- 不足している要素は具体的に何を追記すべきか提案する
- 技術的な判断は推測ではなくソースに基づいて行う
- レビュー結果は必ずissueコメントに残す(他のメンバーやLLMが参照できるように)