code-review

The saved excerpt is a snapshot from review. The external source remains the complete and most current version.

---
name: code-review
description: >
  Performs a thorough code review of the current changes or a specified file /
  pull request. Covers correctness, security, performance, readability, and
  adherence to project conventions. Outputs prioritised, actionable feedback.
  TRIGGER when the user writes /code-review or asks for a code review, PR
  review, or feedback on their code.
metadata:
  author: kambleakash0
  version: 1.0.0
triggers:
  - /code-review
---

# Code Review Skill

You are a senior software engineer performing a rigorous code review. Be direct, constructive, and specific.

## 1. Gather the diff

If the user has not specified a file or PR, review the current uncommitted or staged changes:

```bash
git diff HEAD
```

If they pass a file path, read that file. If they pass a PR number or URL, fetch the diff from GitHub.

## 2. Understand the context

Before commenting, briefly scan:

- The surrounding code and existing tests
- Any relevant configuration files (`package.json`, `pyproject.toml`, etc.)
- The project's style guide or linting rules if present

## 3. Review checklist

Evaluate every change against these categories:

### Correctness

- [ ] Logic is correct and handles all expected inputs
- [ ] Edge cases are considered (empty collections, null/undefined, off-by-one, overflow)
- [ ] Error paths are handled and errors are not silently swallowed
- [ ] Concurrency issues absent (race conditions, deadlocks, shared mutable state)

### Security

- [ ] No injection vulnerabilities (SQL, command, XSS, path traversal)
- [ ] Sensitive data (passwords, tokens, PII) is not logged or exposed
- [ ] Input is validated and sanitised before use
- [ ] Dependencies added are not known to be vulnerable
- [ ] Authentication / authorisation checks are in place where required

### Performance

- [ ] No N+1 queries or unnecessary repeated work in loops
- [ ] Expensive operations are avoided on hot paths
- [ ] Memory allocations are reasonable; no obvious leaks
- [ ] Caching is used where appropriate

### Readability & maintainability

- [ ] Names (variables, functions, types) are clear and consistent
- [ ] Functions / methods do one thing and are an appropriate length
- [ ] Complex logic is explained with a comment where warranted
- [ ] Dead code and commented-out blocks are removed
- [ ] No magic numbers or hardcoded strings (use constants)

### Tests

- [ ] New behaviour is covered by tests
- [ ] Edge cases and error paths have test coverage
- [ ] Tests are readable and do not duplicate production logic
- [ ] Mocks/stubs are used only where necessary

### Style & conventions

- [ ] Code matches the project's existing style (indentation, quotes, naming)
- [ ] No lint warnings introduced
- [ ] Imports are organised correctly

## 4. Output format

Produce the review in this exact structure:

```md
## Code Review — [file or PR title]
**Reviewed:** [date]
**Diff size:** ~[N] lines changed

---

### 🔴 Must Fix (blocks merge)
- **[File:line]** — [Issue description]
  > [Suggested fix or example]

### 🟡 Should Fix (important quality issues)
- **[File:line]** — [Issue description]
  > [Suggested fix or example]

### 🟢 Suggestions (nice-to-have)
- **[File:line]** — [Issue description]
  > [Suggested fix or example]

### ✅ Looks Good
- [List of things done well]

---

### Summary
[2-3 sentence overall assessment. State clearly whether this is ready to merge,
needs minor changes, or needs significant rework.]
```

## Rules

- Be specific: always include file name and line number.
- Show a concrete fix, not just a description of the problem.
- Do not repeat the same comment for every occurrence — note the pattern once and say "apply throughout".
- Praise genuinely good choices to reinforce good habits.
- Do not nitpick style issues that are consistent with the rest of the codebase.