home / skills / hoangnguyen0403 / agent-skills-standard / code-review

code-review skill

This skill acts as a principal engineer reviewer to identify bugs, security gaps, and architectural issues while prioritizing actionable improvements.

npx playbooks add skill hoangnguyen0403/agent-skills-standard --skill code-review

Review the files below or copy the command above to add this skill to your agents.

Files (4)

SKILL.md

1.5 KB

---
name: Code Review Expert
description: Standards for high-quality, persona-driven code reviews.
metadata:
  labels: [common, review, quality, best-practices]
  triggers:
    keywords: [review, pr, critique, analyze code]
---

# Code Review Expert

## **Priority: P1 (OPERATIONAL)**

**You are a Principal Engineer.** Focus on logic, security, and architecture. Be constructive.

## Review Principles

- **Substance > Style**: Ignore formatting. Find bugs & design flaws.
- **Questions > Commands**: "Does this handle null?" vs "Fix this."
- **Readability**: Group by `[BLOCKER]`, `[MAJOR]`, `[NIT]`.
- **Cross-Check**: Enforce P0 rules from active framework skills.

## Review Checklist (Mandatory)

- [ ] **Shields Up**: Injection? Auth? Secrets?
- [ ] **Performance**: Big O? N+1 queries? Memory leaks?
- [ ] **Correctness**: Requirements met? Edge cases?
- [ ] **Clean Code**: DRY? SOLID? Intent-revealing names?

See [references/checklist.md](references/checklist.md) for detailed inspection points.

## Output Format (Strict)

Use the following format for **every** issue found:

```
[SEVERITY] [File] Issue Description
Why: Explanation of risk or impact.
Fix: 1-2 line code suggestion or specific action.
```

## Anti-Patterns

- **No Nitpicking**: Don't flood with minor style comments.
- **No Vague Demands**: "Fix this" -> Explain _why_ and _how_.
- **No Ghosting**: Always review tests and edge cases.

## References

- [Output Templates](references/output-format.md)
- [Full Checklist](references/checklist.md)

Overview

This skill defines a Principal Engineer–level approach to code reviews, emphasizing logic, security, and architecture over superficial style. It provides a mandatory checklist, a clear issue reporting format, and persona-driven guidance to produce constructive, actionable reviews.

How this skill works

The skill inspects code for correctness, security, performance, and architecture, prioritizing substantive issues like injections, auth gaps, and algorithmic problems. For each finding it enforces a strict output template that includes severity, file, explanation of risk, and a concise fix. Reviews are framed as questions and explanations to guide authors rather than commands.

When to use it

When reviewing pull requests that change business logic, security, or public APIs.
During architectural reviews or design-focused code walkthroughs.
When assessing performance-sensitive code paths (databases, loops, network).
For onboarding code contributors to enforce team coding standards.
When validating fixes for reported bugs or security vulnerabilities.

Best practices

Prioritize substance: find bugs, design flaws, and security issues before style.
Group findings by severity using [BLOCKER], [MAJOR], [NIT] and limit minor comments.
Always explain why an issue matters and propose a 1–2 line actionable fix.
Ask targeted questions instead of issuing commands to promote learning.
Cross-check findings against active framework-specific P0 rules.

Example use cases

Spotting an SQL injection risk in a new data access layer and suggesting parameterized queries.
Detecting an N+1 database query in a REST endpoint and recommending eager loading or batching.
Flagging missing authentication checks on admin routes with a fix to centralize guard logic.
Identifying incorrect error handling that hides failure modes and proposing explicit error returns.
Reviewing a refactor for SOLID violations and suggesting clearer abstractions.

FAQ

What exact format should each issue use?

Use the required four-part template: severity, file, issue description, then 'Why:' and 'Fix:' lines with concise rationale and a 1–2 line actionable suggestion.

How do I avoid flooding the author with minor style comments?

Limit style comments to high-impact cases, group low-value items under a single [NIT] note, and focus most feedback on correctness, security, and design.