AgentSkillsCN

java-code-review

具备对Java代码的质量、安全性、可维护性及性能进行评审的能力。在Java文件及Java相关PR的评审中使用，亦可在用户请求对Java代码进行评审时派上用场。

SKILL.md
--- frontmatter
name: java-code-review
description: Javaコードの品質・安全性・保守性・パフォーマンスをレビューするスキル。JavaファイルやJava関連のPRレビュー、ユーザーがJavaコードレビューを求めたときに使用する。

Java Code Review

ゴール

Javaコードを以下の観点からレビューする。

  • •正しさ: 仕様どおりに動作し、例外やバグを生まないか
  • •安全性: セキュリティ上の問題がないか
  • •保守性: 読みやすく変更しやすい構造になっているか
  • •パフォーマンス: 明らかなボトルネックや無駄な処理がないか
  • •一貫性: プロジェクトのコーディング規約や設計方針に沿っているか

このスキルは、Javaファイル単体のレビューと、PR全体のレビューの両方で使う。

レビュー手順（全体の流れ）

  1. •変更の概要を把握する
    • •何のための変更か（バグ修正／機能追加／リファクタリングなど）
    • •公開APIに影響があるか（インターフェース・DTO・REST API など）
  2. •影響範囲を把握する
    • •呼び出し元／呼び出し先クラス
    • •データベースや外部サービスとの連携箇所
  3. •主要な観点でコードを確認する（以下のチェックリストに沿う）
  4. •気づいた点を優先度付きでコメントする
    • •[Critical]: バグ・セキュリティ・設計上の重大な問題
    • •[Major]: 保守性・性能などの重要な改善点
    • •[Minor]: 命名・スタイル・微細なリファクタリング提案
  5. •最後にまとめコメントを書く
    • •変更の良い点
    • •必ず修正してほしい点
    • •任意で検討してほしい改善案

共通チェックリスト

正しさ・堅牢性

  • • 入力値検証（null／空文字／範囲外など）が適切か
  • • nullチェックが必要な箇所で抜けていないか
  • • Optional の使い方が適切か（無理に get() していないか）
  • • コレクションの空チェックができているか（isEmpty() など）
  • • 境界条件・例外ケースを考慮したロジックになっているか
  • • 例外処理で握りつぶし（空catchやログのみ）が行われていないか
  • • ログ出力のレベル（INFO/WARN/ERROR）が適切か

設計・保守性

  • • クラス／メソッドの責務が単一か（God Class / Long Method になっていないか）
  • • メソッドの長さが適切か（複雑な処理は分割されているか）
  • • 条件分岐がネストしすぎていないか（早期returnなどで整理できないか）
  • • 命名が「役割」や「ドメイン」を反映しているか
  • • インターフェース／抽象クラスの境界が妥当か
  • • DI（依存性注入）が適切に使われているか（newで直接生成しすぎていないか）
  • • 定数・マジックナンバーが適切に切り出されているか

パフォーマンス・リソース管理

  • • 不必要なオブジェクト生成やnewがループ内で多発していないか
  • • ストリームAPIの利用が過剰／過度にネストしていないか
  • • コレクション操作で大きなデータに対して非効率なアルゴリズムを使っていないか
  • • I/O・DBアクセス・外部APIコールが最小限に抑えられているか
  • • try-with-resources でリソースクローズが自動化されているか

セキュリティ

  • • SQLクエリでプレースホルダを使っているか（SQLインジェクション対策）
  • • 外部入力値をログに出す際に機密情報（パスワード、トークン等）が含まれていないか
  • • シリアライズ／デシリアライズにおける型安全性が保たれているか
  • • コマンド実行やファイルパス操作で危険な入力を許していないか

テスト

  • • 変更に対するテスト（ユニットテスト／統合テスト）が存在するか
  • • 正常系・異常系・境界値をカバーするテストがあるか
  • • モックの使い方が妥当か（過度なモック／実データ依存がないか）
  • • 新しいパブリックメソッド・ビジネスロジックにテストが追加されているか

Spring / Webアプリでの追加観点（該当する場合）

  • • RESTコントローラでHTTPステータスコードが適切に返却されているか
  • • バリデーションアノテーション（@NotNull, @Size など）が適切か
  • • トランザクション境界（@Transactional）が妥当な単位で設定されているか
  • • エラー応答の形式がAPI仕様（エラーレスポンスフォーマット）と一致しているか
  • • N+1クエリなどORM特有の問題が発生していないか

コメントの書き方ガイド

レビューコメントは、具体的で提案を含む形で記述する。

  • •Bad: 「この命名は微妙です」
  • •Good: 「このメソッドはバリデーションのみを行っているので、validateUserInput のような名前にすると役割が明確になりそうです」

推奨フォーマット:

  • •[Critical] 内容: バグ・セキュリティ・仕様不整合など
  • •[Major] 内容: 構造・パフォーマンス・分かりにくさなど
  • •[Minor] 内容: 命名・コメント・スタイルなど

出力フォーマット（テンプレート）

Javaコードをレビューするときは、次の形式で出力する。

markdown
### 概要
- 変更の目的と全体的な印象を1〜3行でまとめる。

### 良い点
- 良い点1
- 良い点2

### 指摘事項
- [Critical] 箇所と理由、修正案
- [Major] 箇所と理由、修正案
- [Minor] 箇所と理由、修正案

### 補足・提案（任意）
- 将来的なリファクタリング案や設計上の提案があれば記載

このテンプレートに沿って、過不足なく・優先度付きでコメントをまとめること。