reviewer

Analyze code diffs and produce evidence-based review findings with a verdict.

Updated Feb 23, 2026
One-click install
npx skills add https://github.com/mcevoyinit/agentic-skills --skill reviewer-mcevoyinit
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: reviewer
Source: https://github.com/mcevoyinit/agentic-skills/tree/main/skills/coding-modes/reviewer
Command: npx skills add https://github.com/mcevoyinit/agentic-skills --skill reviewer-mcevoyinit

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Code review is often noisy and can miss real issues. This Skill enforces a read-only posture and delivers concise, evidence-backed findings to help teams focus on meaningful risks.

Core Features & Use Cases

  • Read-Only Posture: You review changes and never suggest edits; you produce findings with concrete evidence.
  • Classify First: You categorize risk types and severity at the top of the review.
  • Signal Over Noise: You limit comments to up to five, each backed by line-level evidence.
  • System-Aware Context: You consider tests, callers, and related configurations to assess impact.
  • Verdict Required: You end with a single verdict: APPROVE, REQUEST CHANGES, or NEEDS DISCUSSION.
  • Use Case: For PR reviews in software projects to surface critical issues without proposing changes.

Quick Start

Activate reviewer mode in your CI or chat interface and provide the code diff or PR for evaluation.

Frequently Asked Questions about reviewer

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I get evidence-based code review findings for a pull request?

Evidence-based code review findings require analyzing the diff alongside test files and related code to identify production, architecture, and security risks. The reviewer skill enforces a read-only posture to surface concrete line-level issues without suggesting edits.

What is the best way to limit noise during automated code reviews?

Limiting noise during automated code reviews involves capping output to five evidence-backed findings and classifying risk severity upfront. This signal-over-noise approach ensures developers focus only on critical issues rather than minor stylistic suggestions.

How do I structure a final verdict for pull request risk assessment?

A final verdict for pull request risk assessment should conclude with a single structured decision: APPROVE, REQUEST CHANGES, or NEEDS DISCUSSION. This provides clear guidance on whether the code changes are safe for production deployment.

Does the code review process consider test files and system context?

The code review process does consider test files and system context by reading related configurations and callers. This system-aware approach assesses the true impact of code changes rather than reviewing diffs in isolation.

Can I use this to detect security and architecture risks in production code?

You can use this to detect security and architecture risks in production code. It analyzes pull request diffs to identify these specific threats, classifying risk types and severity before delivering focused findings.

When should I avoid using an automated review mode for pull requests?

You should avoid using an automated review mode if you need suggested code edits or fixes. This approach maintains a strictly read-only posture, producing structured findings and verdicts rather than proposing direct modifications to your codebase.