Menu
Review someone else's code changes. Produces a report only, never edits files. Scope to a PR, branch, specific commits, or a local diff.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when the user wants to design, redesign, shape, critique, audit, polish, clarify, distill, harden, optimize, adapt, animate, colorize, extract, or otherwise improve a frontend interface. Covers websites, landing pages, dashboards, product UI, app shells, components, forms, settings, onboarding, and empty states. Handles UX review, visual hierarchy, information architecture, cognitive load, accessibility, performance, responsive behavior, theming, anti-patterns, typography, fonts, spacing, layout, alignment, color, motion, micro-interactions, UX copy, error states, edge cases, i18n, and reusable design systems or tokens. Also use for bland designs that need to become bolder or more delightful, loud designs that should become quieter, live browser iteration on UI elements, or ambitious visual effects that should feel technically extraordinary. Not for backend-only or non-UI tasks.
Audit AI agent configurations for security risks — excessive permissions, prompt injection surfaces, data exfiltration paths, and missing guardrails. Use when reviewing CLAUDE.md files, MCP configs, agent orchestration code, or any AI agent setup.
Assess agentic AI applications against the OWASP Top 10 for Agentic Applications 2026. Use when reviewing autonomous AI agents, multi-agent systems, or agentic workflows for security risks including goal hijacking, tool misuse, privilege abuse, and rogue agent behavior.
Comprehensive API security review against OWASP API Security Top 10 (2023). Use when reviewing OpenAPI/Swagger specs, auditing REST/GraphQL/gRPC implementations, testing authentication mechanisms, or checking API gateway configurations. Covers BOLA/IDOR, broken auth, mass assignment, rate limiting, SSRF, and more with real-world attack scenarios.
Security-focused code review mapped to OWASP Top 10 and ASVS. Use when reviewing pull requests, auditing files or modules for vulnerabilities, or performing pre-merge security gate checks. Covers injection, auth, authorization, cryptography, data exposure, misconfiguration, and deserialization.
Security review of Infrastructure-as-Code (Terraform, Kubernetes, CloudFormation). Use when reviewing IaC files for misconfigurations, overpermissioning, exposed resources, missing encryption, secrets in code, and supply chain risks. Covers CIS benchmarks and cloud security best practices.
| name | peer-review |
| description | Review someone else's code changes. Produces a report only, never edits files. Scope to a PR, branch, specific commits, or a local diff. |
Review code you did not write. Report only. Never edit files.
Parse the user's request for what to review. Ask if unclear.
| Scope | How to get the diff |
|---|---|
| PR | gh pr diff <number> and gh pr view <number> --json title,body for context |
| branch | git diff main...<branch> (or whatever base the user specifies) |
| commits | git diff <base>..<head> or git show <sha> |
| unstaged | git diff |
| unpushed | git diff @{u}..HEAD (fall back to origin/main..HEAD) |
Always read the full diff first. For PRs, also read the title, description, and any existing review comments. Then ask the user what the purpose of the changes is. Use their answer as the primary lens for the review.
After determining scope, present the list of checks and let the user pick which ones to run. If the user already specified checks in their request, use those without asking.
Logic errors, off-by-one mistakes, race conditions, null/undefined hazards, unhandled error paths, broken edge cases. Trace the code paths mentally; do not assume it works because it looks plausible.
Does the code do what the PR/commit description claims? Are there requirements from the description that are missing from the diff? Is there scope creep (changes unrelated to the stated purpose)?
New code that duplicates existing logic elsewhere in the codebase. Same pattern introduced in multiple places within the diff itself.
New any usage, unsafe assertions, missing annotations on public API surfaces, types that do not match the data they describe. Check that new types are consistent with existing ones and that validation schemas stay in sync.
Functions or components that are too large or do too many things. Missing extractions. Deeply nested logic. High parameter counts. Changes that make an existing god component worse.
For each risky area in the change, assess two things: likelihood of breakage (how likely is it that this causes a problem?) and blast radius (if it does break, how bad is it? One user, one feature, whole app down?). Flag backwards compatibility concerns, migration safety, performance implications, and security surface changes.
# Peer Review: [PR title / branch / commit description]
**Scope**: [what was reviewed]
**Files changed**: [count]
**Findings**: [count by severity]
## Summary
[2-3 sentences: what this change does, overall impression, biggest concerns]
## Findings
### Critical
[file:line, description, why it matters]
### High
[file:line, description, why it matters]
### Medium
[file:line, description, suggested improvement]
### Low
[file:line, description]
## What Looks Good
[Briefly note things done well. Keeps the review balanced.]
## Stats
| Check | Findings |
|-------|----------|
| ... | ... |