code-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

コードレビュー

Code Review

PRやコード変更を体系的にレビューするための汎用スキルです。言語非依存の共通レビュー基準と、言語/フレームワーク固有のベストプラクティスを組み合わせて使用します。

This is a general-purpose skill for systematically reviewing PRs and code changes. It combines language-agnostic common review criteria with language/framework-specific best practices.

ディレクトリ構成

Directory Structure

code-review/
├── SKILL.md (このファイル)
└── references/
    ├── typescript-best-practices.md       # TypeScript固有のチェック
    ├── authorization-review-general.md    # 認可レビュー観点（一般編）
    ├── authorization-review-postgres-rls.md  # 認可レビュー観点（PostgreSQL RLS編）
    └── github-pr-review-actions.md        # GitHub PRレビューアクション

code-review/
├── SKILL.md (this file)
└── references/
    ├── typescript-best-practices.md       # TypeScript-specific checks
    ├── authorization-review-general.md    # Authorization review perspectives (general)
    ├── authorization-review-postgres-rls.md  # Authorization review perspectives (PostgreSQL RLS)
    └── github-pr-review-actions.md        # GitHub PR review actions

外部スキル連携

External Skill Integration

React / Next.js のベストプラクティスは、Vercel提供の react-best-practices スキルを使用する。

リポジトリ: https://github.com/vercel-labs/agent-skills/tree/main/skills/react-best-practices
インストール:
```
npx add-skill vercel-labs/agent-skills
```
カバー範囲: 非同期ウォーターフォール排除、バンドルサイズ最適化、サーバー側パフォーマンス、クライアント側データ取得、再レンダリング最適化、レンダリングパフォーマンス、高度なパターン、JavaScriptパフォーマンス（8カテゴリ、40以上のルール）

For React / Next.js best practices, use the react-best-practices skill provided by Vercel.

Repository: https://github.com/vercel-labs/agent-skills/tree/main/skills/react-best-practices
Installation:
```
npx add-skill vercel-labs/agent-skills
```
Coverage: Eliminate async waterfalls, bundle size optimization, server-side performance, client-side data fetching, re-rendering optimization, rendering performance, advanced patterns, JavaScript performance (8 categories, over 40 rules)

レビューワークフロー

Review Workflow

以下のチェックリストをコピーして進行状況を追跡します：

レビュー進捗：
- [ ] ステップ1: 変更概要の把握
- [ ] ステップ2: 共通品質チェック
- [ ] ステップ3: 言語/フレームワーク固有チェック
- [ ] ステップ4: approve/reject判定
- [ ] ステップ5: レビュー結果の出力

Copy the following checklist to track progress:

Review Progress:
- [ ] Step 1: Understand the Change Overview
- [ ] Step 2: Common Quality Checks
- [ ] Step 3: Language/Framework-Specific Checks
- [ ] Step 4: Approve/Reject Decision
- [ ] Step 5: Output Review Results

ステップ1: 変更概要の把握

Step 1: Understand the Change Overview

変更内容を理解する。

変更ファイル一覧を確認 - 変更の範囲とスコープを把握
コード差分を確認 - 追加・変更・削除された内容を把握
変更の意図を理解 - PR説明やコミットメッセージから目的を確認

確認すべきポイント：

変更は単一の目的にフォーカスしているか
スコープが適切か（1つのPRで多すぎる変更をしていないか）
関連する変更が漏れなく含まれているか

Understand the content of the change.

Check the list of changed files - Grasp the scope of the change
Check code diffs - Understand what was added, modified, or deleted
Understand the intent of the change - Confirm the purpose from the PR description or commit messages

Key points to verify:

Is the change focused on a single purpose?
Is the scope appropriate? (Not too many changes in one PR)
Are all related changes included without omission?

ステップ2: 共通品質チェック

Step 2: Common Quality Checks

言語に依存しない汎用的なチェックを実施する。

Perform language-agnostic general checks.

2-1. セキュリティ

2-1. Security

チェック項目	重要度
ハードコードされた秘密情報（APIキー、パスワード、トークン）がないか	Critical
ユーザー入力の適切なバリデーション・サニタイズがあるか	Critical
SQLインジェクション、XSS、コマンドインジェクションの脆弱性がないか	Critical
認証・認可のチェックが適切に実装されているか	Critical
機密データが不用意にログ出力されていないか	Major
CORS設定が適切か	Major

認可（Authorization）の詳細レビュー：認可に関わる変更がある場合は、references/authorization-review-general.md を参照して詳細なチェックを行う。PostgreSQL RLSを使用している場合は、追加で references/authorization-review-postgres-rls.md も参照する。

Check Item	Severity
Are there any hardcoded secrets (API keys, passwords, tokens)?	Critical
Is user input properly validated and sanitized?	Critical
Are there any vulnerabilities like SQL injection, XSS, or command injection?	Critical
Are authentication and authorization checks properly implemented?	Critical
Is sensitive data not inadvertently logged?	Major
Is the CORS configuration appropriate?	Major

Detailed Authorization Review: If there are changes related to authorization, refer to references/authorization-review-general.md for detailed checks. If using PostgreSQL RLS, additionally refer to references/authorization-review-postgres-rls.md.

2-2. ロジック・正確性

2-2. Logic & Accuracy

チェック項目	重要度
エッジケースが適切に処理されているか（null、空配列、境界値）	Major
エラーハンドリングが適切か（例外の握りつぶし、不適切なcatch）	Major
条件分岐のロジックが正しいか（off-by-one、論理演算子の誤り）	Major
非同期処理の競合状態（race condition）がないか	Major
リソースの確実な解放（ファイル、接続、ロック）	Major

Check Item	Severity
Are edge cases properly handled (null, empty arrays, boundary values)?	Major
Is error handling appropriate (no swallowed exceptions, improper catches)?	Major
Is conditional branching logic correct (off-by-one errors, logical operator mistakes)?	Major
Are there any race conditions in asynchronous processing?	Major
Are resources reliably released (files, connections, locks)?	Major

2-3. 設計・保守性

2-3. Design & Maintainability

チェック項目	重要度
関数/メソッドの責務が単一か	Minor
DRY原則: 不要な重複コードがないか	Minor
命名が意図を正確に表しているか	Minor
マジックナンバーや意味不明な文字列リテラルがないか	Minor
適切な抽象度で設計されているか（過剰な抽象化・不足）	Minor
循環参照・不適切な依存関係がないか	Major

Check Item	Severity
Does each function/method have a single responsibility?	Minor
DRY Principle: Is there any unnecessary duplicate code?	Minor
Does the naming accurately reflect the intent?	Minor
Are there any magic numbers or unclear string literals?	Minor
Is the design at an appropriate level of abstraction (no over-abstraction or under-abstraction)?	Minor
Are there any circular references or inappropriate dependencies?	Major

2-4. パフォーマンス

2-4. Performance

チェック項目	重要度
N+1クエリなど非効率なデータアクセスパターンがないか	Major
不要なループやネスト、計算量の大きい処理がないか	Minor
メモリリークの可能性がないか	Major
大量データの適切なページネーション・ストリーミング処理	Minor

Check Item	Severity
Are there any inefficient data access patterns like N+1 queries?	Major
Are there any unnecessary loops, nesting, or computationally expensive processes?	Minor
Is there any possibility of memory leaks?	Major
Is large data properly paginated or streamed?	Minor

2-5. テスト

2-5. Testing

チェック項目	重要度
変更に対応するテストが追加/更新されているか	Major
エッジケースのテストが含まれているか	Minor
テストが実装詳細でなく振る舞いをテストしているか	Minor
テスト名がテスト対象の振る舞いを明確に表しているか	Suggestion

Check Item	Severity
Have tests been added/updated for the change?	Major
Are edge cases covered in tests?	Minor
Do tests behavior rather than implementation details?	Minor
Do test names clearly reflect the behavior being tested?	Suggestion

ステップ3: 言語/フレームワーク固有チェック

Step 3: Language/Framework-Specific Checks

変更ファイルの言語/フレームワークに応じて、対応するリファレンスファイルを参照する。

参照可能なリファレンス：

言語/FW	参照先	種別
TypeScript	references/typescript-best-practices.md	内部リファレンス
React / Next.js	`react-best-practices` スキル（Vercel提供）	外部スキル

観点	参照先	種別
認可（一般）	references/authorization-review-general.md	内部リファレンス
認可（PostgreSQL RLS）	references/authorization-review-postgres-rls.md	内部リファレンス
GitHub PRレビュー	references/github-pr-review-actions.md	内部リファレンス

参照ルール：

TypeScriptの変更 → 内部リファレンスを読み込む
React / Next.js の変更 →
```
react-best-practices
```
スキルを併用する（インストール済みの場合）
認可に関わる変更（認証/権限チェック、データアクセス制御等） → 認可リファレンス（一般編）を参照
PostgreSQL RLSを使用している場合 → 認可リファレンス（RLS編）も追加で参照
GitHub Actions等のCI環境でPRレビューを実行する場合 → GitHub PRレビューアクションを参照（コメント投稿・評価方法）
複数の言語/FWにまたがる変更の場合は、すべての該当リファレンスを参照する
リファレンスが存在しない言語の場合は、ステップ2の共通チェックのみで判断する

Refer to the corresponding reference file based on the language/framework of the changed files.

Available References:

Language/FW	Reference	Type
TypeScript	references/typescript-best-practices.md	Internal Reference
React / Next.js	`react-best-practices` skill (provided by Vercel)	External Skill

Aspect	Reference	Type
Authorization (General)	references/authorization-review-general.md	Internal Reference
Authorization (PostgreSQL RLS)	references/authorization-review-postgres-rls.md	Internal Reference
GitHub PR Review	references/github-pr-review-actions.md	Internal Reference

Reference Rules:

For TypeScript changes → Load internal references
For React / Next.js changes → Use the
```
react-best-practices
```
skill (if installed)
For changes related to authorization (authentication/permission checks, data access control, etc.) → Refer to the general authorization reference
If using PostgreSQL RLS → Additionally refer to the RLS authorization reference
If performing PR reviews in CI environments like GitHub Actions → Refer to GitHub PR review actions (comment posting/evaluation methods)
For changes spanning multiple languages/FWs → Refer to all applicable references
For languages without references → Make judgments based only on the common checks in Step 2

ステップ4: approve/reject判定

Step 4: Approve/Reject Decision

すべてのチェック結果に基づき、以下の基準でapprove/rejectを判定する。

Based on all check results, make an approve/reject decision using the following criteria.

問題の重要度と減点

Issue Severity and Point Deductions

重要度	説明	減点
Critical	マージ前に必ず修正が必要。セキュリティ脆弱性、データ損失リスク、重大なバグ	-3点/件
Major	優先的に修正すべき。ロジックの問題、パフォーマンス劣化、テスト不足	-2点/件
Minor	改善が望ましい。設計改善、可読性向上、軽微な問題	-1点/件
Suggestion	提案。ベストプラクティスの推奨、より良いアプローチの提示	-0.5点/件

Severity	Description	Deduction
Critical	Must be fixed before merging. Security vulnerabilities, data loss risks, critical bugs	-3 points/item
Major	Should be fixed prioritized. Logic issues, performance degradation, insufficient testing	-2 points/item
Minor	Improvement is desired. Design improvements, readability enhancements, minor issues	-1 point/item
Suggestion	Proposal. Recommendation of best practices, presentation of better approaches	-0.5 points/item

判定基準

Decision Criteria

満点は10点とし、以下の基準で判定する。

判定	条件	アクション
Reject	Critical問題が1件以上ある	REQUEST_CHANGES
Reject	Major問題が3件以上ある	REQUEST_CHANGES
Reject	スコアが5点未満	REQUEST_CHANGES
Conditional Approve	Critical問題なし、Major 1-2件、スコア5点以上	APPROVE（改善点をコメント）
Approve	Critical/Major問題なし、スコア8点以上	APPROVE

The full score is 10 points, and judgments are made based on the following criteria.

Decision	Condition	Action
Reject	1 or more Critical issues	REQUEST_CHANGES
Reject	3 or more Major issues	REQUEST_CHANGES
Reject	Score below 5 points	REQUEST_CHANGES
Conditional Approve	No Critical issues, 1-2 Major issues, score 5 points or higher	APPROVE (comment on improvement points)
Approve	No Critical/Major issues, score 8 points or higher	APPROVE

判定フローチャート

Decision Flowchart

Critical問題あり？ → Yes → Reject（REQUEST_CHANGES）
       ↓ No
Major問題が3件以上？ → Yes → Reject（REQUEST_CHANGES）
       ↓ No
スコア5点未満？ → Yes → Reject（REQUEST_CHANGES）
       ↓ No
Major問題が1-2件？ → Yes → Conditional Approve
       ↓ No
スコア8点以上？ → Yes → Approve
       ↓ No
Conditional Approve

Any Critical issues? → Yes → Reject (REQUEST_CHANGES)
       ↓ No
3 or more Major issues? → Yes → Reject (REQUEST_CHANGES)
       ↓ No
Score below 5? → Yes → Reject (REQUEST_CHANGES)
       ↓ No
1-2 Major issues? → Yes → Conditional Approve
       ↓ No
Score 8 or higher? → Yes → Approve
       ↓ No
Conditional Approve

ステップ5: レビュー結果の出力

Step 5: Output Review Results

以下のフォーマットでレビュー結果を出力する。

GitHub上でのレビュー投稿：GitHub Actions等のCI環境でPRレビューを実行している場合のみ、references/github-pr-review-actions.md を参照して、
gh
コマンドやインラインコメントを使用してレビュー結果をGitHub上に投稿する。ローカル環境での実行時は、結果を標準出力に表示するのみとする。

markdown

undefined

Output the review results in the following format.

Posting Reviews on GitHub: Only when performing PR reviews in CI environments like GitHub Actions, refer to references/github-pr-review-actions.md to post review results on GitHub using
gh
commands or inline comments. When running locally, only display the results on standard output.

markdown

undefined

Code Review: [判定結果]

Code Review: [Decision Result]

変更概要

Change Overview

スコープ: [変更の概要を1-2文で]
変更ファイル数: [N]ファイル
主な言語/FW: [検出された言語/FW]

Scope: [1-2 sentences summarizing the change]
Number of Changed Files: [N] files
Main Language/FW: [Detected language/FW]

スコア: X/10

Score: X/10

検出された問題

Detected Issues

#	重要度	ファイル	問題	推奨される対応
1	[Critical/Major/Minor/Suggestion]	[ファイルパス:行番号]	[問題の説明]	[対応方法]

#	Severity	File	Issue	Recommended Action
1	[Critical/Major/Minor/Suggestion]	[File path:line number]	[Issue description]	[Recommended action]

良い点

Positive Points

[コードの良い点を具体的に記載]

[Specifically describe the good points of the code]

判定

Decision

結果: [Approve / Conditional Approve / Reject]
理由: [判定理由の要約]

Result: [Approve / Conditional Approve / Reject]
Reason: [Summary of the decision reason]

次のステップ

Next Steps

[修正が必要な場合の具体的なアクション]

undefined

[Specific actions if fixes are needed]

undefined

重要な注意事項

Important Notes

レビューはコードの品質向上が目的であり、批判ではない。建設的なフィードバックを心がける
問題の指摘には必ず具体的な改善案を添える
変更の意図を尊重し、スタイルの好みではなく客観的な基準で判断する
自動検出が困難なドメイン知識やビジネスロジックの判断は、人間のレビュアーに委ねる
Suggestionは強制ではなく、採用するかどうかは著者の判断に任せる

The purpose of reviews is to improve code quality, not to criticize. Focus on constructive feedback
Always attach specific improvement proposals when pointing out issues
Respect the intent of the change and judge based on objective standards, not personal style preferences
Delegate judgments on domain knowledge or business logic that are difficult to detect automatically to human reviewers
Suggestions are not mandatory; authors can decide whether to adopt them