requesting-code-review
Use when implementation is done and you need a structured pre-PR review workflow. Triggers: 'ready for review', 'review my changes before PR', 'pre-merge check', 'is this ready', 'submit for review'. NOT for: post-merge review (use code-review) or deciding how to integrate (use finishing-a-development-branch).
Best use case
requesting-code-review is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Use when implementation is done and you need a structured pre-PR review workflow. Triggers: 'ready for review', 'review my changes before PR', 'pre-merge check', 'is this ready', 'submit for review'. NOT for: post-merge review (use code-review) or deciding how to integrate (use finishing-a-development-branch).
Teams using requesting-code-review should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/requesting-code-review/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How requesting-code-review Compares
| Feature / Agent | requesting-code-review | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Use when implementation is done and you need a structured pre-PR review workflow. Triggers: 'ready for review', 'review my changes before PR', 'pre-merge check', 'is this ready', 'submit for review'. NOT for: post-merge review (use code-review) or deciding how to integrate (use finishing-a-development-branch).
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
Related Guides
AI Agents for Coding
Browse AI agent skills for coding, debugging, testing, refactoring, code review, and developer workflows across Claude, Cursor, and Codex.
Cursor vs Codex for AI Workflows
Compare Cursor and Codex for AI coding workflows, repository assistance, debugging, refactoring, and reusable developer skills.
Best AI Skills for Claude
Explore the best AI skills for Claude and Claude Code across coding, research, workflow automation, documentation, and agent operations.
SKILL.md Source
# Requesting Code Review <ROLE> Self-review orchestrator. Coordinates pre-PR code review workflow. Your reputation depends on every Critical finding being fixed before merge — a missed Critical is a production defect you signed off on. </ROLE> <analysis> Before starting review workflow, analyze: 1. What is the scope of changes? (files, lines, complexity) 2. Is there a plan/spec document to review against? 3. What is the current git state? (branch, merge base) 4. What phase should we resume from if this is a re-review? </analysis> ## Invariant Principles 1. **Phase gates are blocking** - Never proceed to next phase without meeting exit criteria 2. **Evidence over opinion** - Every finding must cite specific code location and behavior 3. **Critical findings are non-negotiable** - No Critical finding may be deferred or ignored 4. **SHA persistence** - Always use reviewed_sha from manifest, never current HEAD 5. **Traceable artifacts** - Each phase produces artifacts for resume and audit capability <FORBIDDEN> - Proceeding past Phase 6 gate with unfixed Critical findings - Making findings without specific file:line evidence - Using current HEAD instead of reviewed_sha for inline comments - Skipping re-review when fix adds >100 lines or modifies new files - Deferring Critical findings for any reason </FORBIDDEN> <reflection> After each phase, verify: - Did we meet all exit criteria before proceeding? - Are all findings backed by specific evidence? - Did we persist the correct SHA for future reference? - Is the artifact properly saved for traceability? </reflection> ## Phase-Gated Workflow Reference: `patterns/code-review-formats.md` for output schemas. ### Phases 1-2: Planning + Context Determine git range, list changed files, identify plan/spec, estimate complexity. Assemble reviewer context bundle: plan excerpts, related code, prior findings. **Execute:** `/request-review-plan` **Outputs:** Review scope definition, reviewer context bundle **Self-Check:** Git range defined, file list confirmed, context bundle ready for dispatch. ### Phases 3-6: Dispatch + Triage + Execute + Gate Invoke code-reviewer agent, triage findings by severity, fix in Critical-first order, apply quality gate for proceed/block decision. **Execute:** `/request-review-execute` **Outputs:** Review findings, triage report, fix report, gate decision **Self-Check:** Valid findings received, triaged, blocking findings addressed, clear verdict. ### Artifact Contract Directory structure, phase artifact table, manifest schema, and SHA persistence rule. **Reference:** `/request-review-artifacts` ## Gate Rules Reference: `patterns/code-review-taxonomy.md` for severity definitions. ### Blocking Rules | Condition | Result | |-----------|--------| | Any Critical unfixed | BLOCKED - must fix before proceed | | Any High unfixed without rationale | BLOCKED - fix or document deferral | | >=3 High unfixed | BLOCKED - systemic issues | | Only Medium/Low/Nit unfixed | MAY PROCEED | Deferral rationale must be written justification citing the specific constraint (risk acceptance, blocked dependency, or explicit product decision) — "will fix later" does not qualify. <CRITICAL> Always use `reviewed_sha` from manifest for inline comments. Never query current HEAD - commits may have been pushed since review started. </CRITICAL> <FINAL_EMPHASIS> Every gate in this workflow exists because defects discovered post-merge cost 10x more to fix. Do not skip phases. Do not defer Criticals. Do not let SHA drift corrupt inline comments. A review that lets one Critical through is worse than no review at all. </FINAL_EMPHASIS>
Related Skills
reviewing-prs
System skill loaded before dispatching any PR review subagent. Ensures correct file version selection based on branch and worktree state. Not invoked directly by users. Required by: code-review, advanced-code-review, distilling-prs when reviewing PRs.
reviewing-impl-plans
Use when reviewing implementation plans before execution. Triggers: 'is this plan solid', 'review the plan', 'check before I start building', 'anything missing from this plan', 'will this plan work', 'audit the implementation plan'. NOT for: reviewing design documents (use reviewing-design-docs) or creating plans (use writing-plans).
reviewing-design-docs
Use when reviewing design documents, technical specifications, architecture docs, RFCs, ADRs, or API designs for completeness and implementability. Triggers: 'review this design', 'is this spec complete', 'can someone implement from this', 'what's missing from this design', 'review this RFC', 'is this ready for implementation', 'audit this spec'. Core question: could an implementer code against this without guessing?
code-review
Use when reviewing code. Triggers: 'review my code', 'check my work', 'look over this', 'review PR #X', 'PR comments to address', 'reviewer said', 'address feedback', 'self-review before PR', 'audit this code', 'branch code review', 'review this branch', 'review the changes', 'review what's on this branch', 'do a code review of the branch'. For heavyweight multi-phase analysis, use advanced-code-review instead. When the request could match more than one review skill, MUST use AskUserQuestion to disambiguate before invoking — never bypass the review skills for a raw Explore dispatch, even when the user's concerns seem narrow or specific.
adversarial-review
Use when dispatching a subagent to re-check work against external feedback (PR review comments, audit findings, multi-comment review cycles, 'did I really address X' verifications). Triggers: 'verify all the review comments are addressed', 'check that I really fixed all the audit findings', 'did I miss anything from the reviewer', 'final check before re-review', 'verify cycle N review'. NOT for: writing the initial response to a review (use code-review), or self-reviewing your own design (use devils-advocate).
advanced-code-review
Use when performing thorough code review with historical context tracking. Triggers: 'thorough review', 'deep review', 'review this branch in detail', 'full code review with report', 'branch code review', 'review this branch', 'review the changes', 'review what's on this branch', 'do a code review of the branch'. More heavyweight than code-review; for quick review, use code-review instead. When the request could match more than one review skill, MUST use AskUserQuestion to disambiguate before invoking — never bypass the review skills for a raw Explore dispatch, even when the user's concerns seem narrow or specific.
writing-skills
Use when creating new skills, editing existing skills, or verifying skills work before deployment. Triggers: 'write a skill', 'new skill', 'create a skill', 'skill doesn't work', 'skill isn't firing', 'edit skill', 'skill quality'. NOT for: general prompt improvement (use instruction-engineering) or command creation (use writing-commands).
writing-plans
Use when you have a spec, design doc, or requirements and need a detailed implementation plan before coding. Triggers: 'write a plan', 'create implementation plan', 'plan this out', 'break this down into steps', 'convert design to tasks', 'implementation order'. Also invoked by develop during planning. NOT for: reviewing existing plans (use reviewing-impl-plans).
writing-commands
Use when creating new commands, editing existing commands, or reviewing command quality. Triggers: 'write command', 'new command', 'create a command', 'review command', 'fix command', 'command doesn't work', 'add a slash command'. NOT for: skill creation (use writing-skills).
verifying-hunches
Use when about to claim discovery during debugging. Triggers: "I found", "this is the issue", "I think I see", "looks like the problem", "that's why", "the bug is", "root cause", "culprit", "smoking gun", "aha", "got it", "here's what's happening", "the reason is", "causing the", "explains why", "mystery solved", "figured it out", "the fix is", "should fix", "this will fix". Also invoked by debugging, scientific-debugging, systematic-debugging before any root cause claim.
using-skills
System skill loaded at session start to initialize skill routing. Not invoked directly by users. Also useful when: 'which skill should I use', 'what skill handles this', 'wrong skill fired', 'skill didn't trigger'.
using-lsp-tools
Use when mcp-language-server tools are available and you need semantic code intelligence. Triggers: 'find definition', 'find references', 'who calls this', 'rename symbol', 'type hierarchy', 'go to definition', 'where is this used', 'where is this defined', 'what type is this'. Provides navigation, refactoring, and type analysis via LSP.