AgentSkillsCN

issue-review

对 Issue 的工作树编辑内容进行严格审查。 指定 Issue 编号后，从 Issue 要求的契合度、代码质量、测试、安全性等多个维度进行检查。 可通过“Review Issue 4”、“#7 Review”等指令触发。

SKILL.md
--- frontmatter
name: issue-review
description: |
  Issueのworktree編集内容を厳しくレビューする。
  Issue番号を指定すると、Issue要件との整合性、コード品質、テスト、セキュリティ等の観点でチェック。
  「Issue 4をレビューして」「#7のレビュー」などで発動。
compatibility: Requires git 2.17+, gh CLI

Issue Review

Issue番号を指定して、worktreeの編集内容を厳しくレビューする。

Workflow

Step 1: Issue情報の取得

bash
gh issue view {NUMBER} --json number,title,body

Step 2: ブランチ名の特定

bash
# worktreeからブランチ名を取得
REPO_NAME=$(basename $(git rev-parse --show-toplevel))
WORKTREE_PATH="../${REPO_NAME}-{NUMBER}"

# worktreeが存在するか確認
git worktree list | grep "${WORKTREE_PATH}"

Step 3: 差分の取得

bash
# worktreeディレクトリで差分を取得
cd "$WORKTREE_PATH"
git diff main..HEAD
git diff main..HEAD --stat

Step 4: レビュー実施

以下の観点で厳しくレビューする。問題がなくても「問題なし」で済ませず、改善の余地があれば指摘する。

Review Checklist

1. Issue要件との整合性 (MUST)

  • • Issueで要求された機能がすべて実装されているか
  • • Issueで要求されていないことを勝手に実装していないか（スコープクリープ）
  • • 実装がIssueの意図を正しく理解しているか
  • • タスクリスト（- [ ]）があれば全て完了しているか

2. コード品質

  • • 命名は意図を正確に表しているか（略語の乱用、曖昧な名前）
  • • 関数/メソッドの責務は単一か（SRP違反）
  • • ネストが深すぎないか（early returnで改善可能か）
  • • マジックナンバー/マジックストリングがないか
  • • コピペコードがないか（DRY違反）
  • • 不要なコメントアウトされたコードが残っていないか

3. エラーハンドリング

  • • エラーを握りつぶしていないか（_ = err）
  • • エラーメッセージは原因特定に十分な情報を含むか
  • • リカバリ可能なエラーと致命的なエラーを区別しているか
  • • panicの使用は適切か（ライブラリでpanicは基本NG）

4. テスト

  • • 新機能/変更に対するテストが追加されているか
  • • エッジケースがテストされているか（空、nil、境界値）
  • • テストは実装の詳細ではなく振る舞いをテストしているか
  • • テスト名は何をテストしているか明確か

5. セキュリティ

  • • ユーザー入力のバリデーションは十分か
  • • SQLインジェクション、コマンドインジェクションの可能性
  • • 機密情報（APIキー、パスワード）がログに出力されていないか
  • • 適切な権限チェックがあるか

6. パフォーマンス

  • • N+1クエリの可能性
  • • 不要なループ内でのメモリアロケーション
  • • 適切なデータ構造の選択（mapが必要な場面でslice使用など）
  • • 重い処理のキャッシュ検討

7. 並行性 (該当する場合)

  • • 競合状態（race condition）の可能性
  • • デッドロックの可能性
  • • goroutineリーク（終了条件が不明確）
  • • 共有状態へのアクセスは適切に保護されているか

8. 設計・アーキテクチャ

  • • プロジェクトの既存パターンに従っているか
  • • 依存関係の方向は適切か（循環依存、レイヤー違反）
  • • インターフェースは適切に使われているか（過剰/不足）
  • • 将来の変更に対して開いているか（OCP）

9. YAGNI / KISS

  • • 今必要ないものを実装していないか
  • • 過度な抽象化をしていないか
  • • 「念のため」のコードがないか
  • • シンプルな解決策で十分ではないか

10. 破壊的変更

  • • 公開APIのシグネチャ変更
  • • 設定ファイルのフォーマット変更
  • • データベーススキーマの変更（マイグレーション必要）
  • • 既存の動作を変える変更

11. ログ・可観測性

  • • 適切なログレベル（debug/info/warn/error）
  • • 構造化ログになっているか
  • • トレーサビリティ（リクエストID等）

12. ドキュメント

  • • 公開API/関数にはdocstringがあるか
  • • 複雑なロジックにはコメントがあるか
  • • READMEの更新が必要か

Output Format

markdown
# Review: Issue #{NUMBER} - {TITLE}

## Summary
[1-2文で全体の評価]

## Must Fix (マージブロッカー)
- [ ] [深刻な問題1]
- [ ] [深刻な問題2]

## Should Fix (強く推奨)
- [ ] [中程度の問題1]
- [ ] [中程度の問題2]

## Consider (検討事項)
- [ ] [軽微な改善案1]
- [ ] [軽微な改善案2]

## Good Points
- [良かった点1]
- [良かった点2]

## Verdict
[ ] **Approved** - マージ可能
[ ] **Request Changes** - 修正が必要

Notes

  • •厳しくレビューする。褒めるだけのレビューは無意味。
  • •問題がなければ「問題なし」ではなく「この実装で問題ない理由」を述べる
  • •コードを読まずに推測でレビューしない。必ずdiffを確認する
  • •「動けばいい」は許容しない。保守性・可読性も重視
  • •指摘には具体的な改善案を添える