# Review Reviewer

> Review code, pull requests, or design changes for concrete, actionable problems introduced or exposed by the change.

- Skill: `horizon67/review-reviewer` (Agent Skill)
- Install (CLI): `npx skillmds@latest add horizon67/review-reviewer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/horizon67/review-reviewer/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: horizon67 (https://skillmd.com/u/horizon67)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/horizon67/review-reviewer

---


# Reviewing Changes

The purpose of a review is to find problems introduced by a change before merge and explain them in a form the author can act on. Do not optimize for the number of findings. Unless the user requests a broader audit, exclude matters of taste, unsupported concerns, and pre-existing problems unrelated to the change.

## Understand the review scope

Establish the review target, comparison base, and expected behavior from the request and available repository context. If the base is unspecified, use a reasonable scope from the current branch or working tree and state it; ask only when materially different interpretations remain.

Inspect surrounding code, callers, requirements, and tests where needed to understand an affected path. For a design review, focus on assumptions, responsibility boundaries, failure behavior, and compatibility relevant to the proposal.

## Verify problems

Prioritize concrete correctness, security, data integrity, compatibility, concurrency, or performance failures on affected paths. Missing tests alone are not a defect; explain the behavior at risk or the explicit testing requirement that is unmet.

Support each candidate with an execution path, established requirement, or focused test. Run checks when they resolve a concrete uncertainty, rather than requiring a test for every finding. Separate unresolved questions from confirmed defects, and do not invent findings to fill a checklist.

## Write findings

Write one finding for each independent problem. Order findings by severity and use these priorities:

- `P0`: Stop immediately. The change can cause a widespread outage, major information disclosure, or data loss that is difficult to recover from.
- `P1`: Fix before merge. A common path can cause a severe failure or security issue.
- `P2`: Normal priority. Specific conditions cause incorrect behavior or a material maintenance problem.
- `P3`: Low impact but worth fixing to prevent a concrete defect or future problem.

Explain each finding's trigger, incorrect behavior, impact, and evidence, with a concise title and a remediation direction when known. For code reviews, cite the smallest useful line range and attach it to a changed line when possible. Use the format requested by the user or review tool; a separate template is unnecessary.

Lead the final review with findings or an explicit statement that none were found. Mention material coverage limits or unresolved questions. A change summary alone is not a completed review.

## Changes and external operations

A review request alone does not authorize code changes. Modify and validate code only when the user explicitly requests fixes.

Submit a GitHub review, comment, approve, request changes, or resolve a conversation only when the user explicitly asks. When posting is requested, keep the GitHub review consistent with the findings reported in the conversation.