version: "1.0.1" name: code-review description: 'Performs a quick, lightweight review of a small diff or single file, giving concise feedback on correctness, readability, tests, and obvious risks. Use when the user asks for a fast sanity-check review of a small change. For test-automation suites, architectural refactors, security-sensitive paths, or multi-file reviews, use the code-review-advanced skill instead.' argument-hint: 'The diff, file, or snippet to review, plus the goal of the change' user-invocable: true

Quick Code Review

This skill applies a consistent, lightweight assessment to a small code change. It focuses on key principles of code quality:

• Safety (avoid incorrect assumptions; call out uncertain areas)
• Clarity (structuring comments in positive and actionable form)
• Coverage (address correctness, tests, security, performance, readability)

When to Use

1. The user asks for a quick review of a small diff, single file, or snippet.
2. A change needs a fast sanity check before a fuller review.
3. You need a compact checklist for a routine, low-risk change.

For large or multi-file pull requests, legacy audits, test-automation suites, or high-risk paths (auth, payments, data flows), use code-review-advanced instead.

Skill Behavior

• Start with a summary: what is changing, why, and whether the implementation is aligned with goals.
• Categorize findings:
• ✅ Strengths / wins
• ⚠️ Concerns / risks
• 🛠️ Suggestions / improvements
• Provide short-term fix guidance plus long-term design thoughts.
• Flag any missing tests, docs, or standards violations.
• Respect context: mention the module/file/function names (not generic: "the code").

Quick Review Checklist

1. Correctness

• Does the code do what the ticket/PR describes?
• Are edge cases handled (null, errors, concurrency, format)?
• Any regression risk from changed behavior?

1. Maintainability

• Is the implementation easy to read and reason about?
• Are abstractions and naming appropriate?
• Any repeated logic that should be refactored?

1. Testing

• Are unit and integration tests present and relevant?
• Do tests cover both normal and boundary cases?
• Are tests deterministic and fast?

1. Security & Privacy

• Are user inputs validated/escaped and untrusted data treated carefully?
• Any secrets in code, logs, or config?
• Does the change introduce new permissions, cross-origin, or auth gaps?

1. Performance

• Any obvious O(N^2) loops or hot-path allocations?
• Are caching and batching used when appropriate?
• For network I/O, is retry/backoff and timeout handling present?

1. Style/Convention

• Follow team linting rules and style guide (naming, indent, line length).
• Approve clean diff with minimal noise in formatting.

1. Documentation

• Public APIs should be documented.
• Migration notes, config docs, and README changes included if needed.

Output Style

• Keep each comment concise (1-2 sentences plus the issue).
• Use bullet points for multiple issues.
• Use neutral, teammate-first language (Consider, Could, Would instead of You).
• Include a final recommendation state: approve, request changes, or comment.

Related Skills

• code-review-advanced - evidence-driven, severity-ranked review for complex, risky, or multi-file changes
• tech-debt-analysis - when recurring review findings suggest a broader debt assessment

Definition of Done

This skill is complete when:

• the change is summarized with intent and alignment stated
• findings are categorized (strengths, concerns, suggestions) with concrete file/function references
• missing tests or docs are flagged
• a final recommendation (approve, request changes, or comment) is given