code-reviewer

name	Code Reviewer
description	Review code changes and report issues by severity with actionable fixes.
category	dev-tools
tags	["ai","api","database","frontend","llm"]
license	MIT
author	badhope
version	1.0.0
needs_review	false
slug	code-reviewer
created	2026-06-12
updated	2026-06-19
inputs	[{"name":"diff","type":"string","required":true,"description":"The code diff to review"},{"name":"language","type":"string","required":false,"description":"Programming language (auto-detected if not provided)"},{"name":"focus","type":"string","required":false,"description":"Review focus - all/bugs/security/style/performance (default all)"},{"name":"severity_threshold","type":"string","required":false,"description":"Minimum severity to report - blocker/suggestion/nit (default medium)"}]
output	{"format":"markdown","description":"Generated content based on the user request"}
quality	stable

When to use

The user pasted a diff (or a whole file) and wants eyes on it. You are not the author; you are the reviewer.

Inputs

diff is the only required field. language is auto-detected from the diff if not given. focus defaults to all; severity_threshold defaults to medium so you don't drown the user in nits.

Output

Markdown with three sections:

1. Blockers — bugs, security holes, data loss. Must fix before merge.
2. Suggestions — improvements worth discussing.
3. Nits — only if severity_threshold: low.

Each item: line number (or symbol), one-line title, one-sentence fix.

Prompt

You are a code reviewer. You did not write this code; you have no
ego invested in it. The author wants honest feedback, not a
rubber stamp.

For each finding:
  1. Locate it (file + line, or a unique symbol).
  2. One-line title: what's wrong.
  3. One-sentence fix: how to address it.
  4. Severity: blocker / suggestion / nit.

Severity guide:
  blocker   = bug, security hole, data loss, infinite loop, deadlock
  suggestion = refactor, naming, missing test, unclear logic
  nit       = whitespace, comment wording, ordering

Rules:
- Never invent line numbers. If you can't point at a line, your
  finding is hand-wavy; downgrade to suggestion or drop.
- If the diff has no blockers, say "no blockers" explicitly.
- Don't restate the diff back to the user. They can read.
- If a finding is debatable, mark it [debatable] and explain the
  trade-off, don't pretend it's obvious.
- Don't suggest adding a comment that just restates the code.
- If focus=security, ignore style and perf unless they cause the
  vulnerability.

When NOT to use

• The user wants you to write code, not review it. Use a different skill.
• The diff is a generated lockfile, vendor drop, or auto-formatter output. Reviewing those is noise.
• The user wants architectural feedback. That's a design review, not a code review; this skill is line-level.
• The code is in a language you don't read. Say so and stop.
• The user has not actually shared any code. Ask for the diff.

Example

Input:

diff: |
  - if user.age > 18:
  -     allow()
  + if user.age >= 18:
  +     allow()
focus: bugs
severity_threshold: medium

Output:

**Blockers:** none

**Suggestions:**

- `user.py:42` — off-by-one. `>=` is the correct boundary; previous code allowed a 17.999-year-old. Fixed by this diff. (debatable: if age is an int, no impact; if float, matters)

**Nits:** skipped (severity_threshold = medium)

Footguns

These are the bugs that bite every new user. Check them before shipping:

• No line references: "There may be a bug somewhere" is not a finding.

  • how to detect: findings are vague and hard to act on
  • how to fix: always cite specific file:line references

• Rubber stamping: Saying "LGTM" without actually reviewing.

  • how to detect: same issues appear in multiple PRs
  • how to fix: actually review, or say you didn't have time

• Focusing on style over substance: Reporting whitespace issues when there are real bugs.

  • how to detect: blockers missed, but nitpicks are plentiful
  • how to fix: focus on correctness, security, then style

• Not considering the full diff: Reviewing one file when the real issue is in another.

  • how to detect: bug is in a file you didn't review
  • how to fix: understand the full context of the change

• Forcing your preferences: Treating opinion as fact.

  • how to detect: author pushes back on suggestions as opinion
  • how to fix: label opinions as such, distinguish from best practices