rad-code-review

Reviews git diffs against task, phase, or final contracts and produces verdict-driven review reports.

Updated May 24, 2026
One-click install
npx skills add https://github.com/MetalHexx/rad-orc-marketplace --skill rad-code-review-metalhexx
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: rad-code-review
Source: https://github.com/MetalHexx/rad-orc-marketplace/tree/main/claude-plugin/skills/rad-code-review
Command: npx skills add https://github.com/MetalHexx/rad-orc-marketplace --skill rad-code-review-metalhexx

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It gives a reviewer agent a consistent, evidence-based procedure for judging code changes against the contract they were meant to satisfy, replacing ad-hoc review with a structured verdict and findings workflow. ## Core Features & Use Cases - Three review scopes: Route to task, phase, or final review based on spawn context, each with its own contract (task handoff, phase plan, or requirements doc) and diff range. - Two-lens judgment: Evaluate every diff for conformance against its contract and for engineering quality, merging both into one numbered findings list with severity levels. - Running review reports: Maintain a single report per scope across corrective cycles, adjudicating coder fixes and disputes in place rather than re-reviewing from scratch. - Use Case: A reviewer agent receives a task commit SHA and handoff document, runs the diff and tests itself, and writes a review report with an approved, changes_requested, or rejected verdict backed by file:line evidence. ## Quick Start Review the diff for the task identified in my spawn context against its handoff and write the review report with a verdict.

Frequently Asked Questions about rad-code-review

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

FAQPage Schema
How do I review a code diff against a task handoff?▼

Read the task handoff as the contract, run git diff for the task's head SHA plus the change-relevant tests yourself, then judge conformance and quality through two lenses. Write numbered findings with file:line evidence and set the verdict from the highest-severity finding.

What is the difference between task, phase, and final code review scope?▼

Task review checks one commit against its handoff, phase review checks the cumulative phase diff against the phase plan with focus on cross-task integration, and final review strictly checks the whole project diff against the requirements doc with no partial credit.

When should a code review verdict be rejected instead of changes_requested?▼

Use rejected sparingly, only when the run caused damage, failed outright, or has a defect beyond what a bounded corrective can fix, including a broken git state. changes_requested is the default corrective verdict for fixable medium-or-high findings.

How does re-review work on a corrective cycle?▼

When review_report_path is present in context, re-open that existing report instead of writing a new one. Verify each fix in the new diff, weigh each dispute against the code, close or keep findings, and update the verdict in place.

Can the reviewer modify git state during a review?▼

No. The worktree safety charter forbids checkout, switch, reset, commit, or anything moving HEAD or the index. Only read-only inspection like git diff and git show is allowed; a broken git state is reported as a rejected verdict.