Code Review

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 (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

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

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

Step 1: Understand the Change Overview

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?

Step 2: Common Quality Checks

Perform language-agnostic general checks.

2-1. Security

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. Logic & Accuracy

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. Design & Maintainability

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. Performance

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. Testing

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

Step 3: Language/Framework-Specific Checks

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

Step 4: Approve/Reject Decision

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

Issue Severity and Point Deductions

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

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

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

Step 5: Output Review Results

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

## Code Review: [Decision Result]

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

### Score: X/10

### Detected Issues

| # | 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
- **Result**: [Approve / Conditional Approve / Reject]
- **Reason**: [Summary of the decision reason]

### Next Steps
- [Specific actions if fixes are needed]

Important Notes

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

code-review

NPX Install

Tags

SKILL.md Content (Chinese)