/requesting-code-review
Use when completing tasks, implementing major features, or before merging to verify work meets requirements - dispatches code-reviewer subagent, handles retries and timeouts, manages review-fix loop until zero issues
$ npx -y skills add ed3dai/ed3d-plugins --skill requesting-code-review --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/requesting-code-review
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when completing tasks, implementing major features, or before merging to verify work meets requirements - dispatches code-reviewer subagent, handles retries and timeouts, manages review-fix loop until zero issues
SKILL.md
requesting-code-review.SKILL.mdname: requesting-code-review
description: Use when completing tasks, implementing major features, or before merging to verify work meets requirements - dispatches code-reviewer subagent, handles retries and timeouts, manages review-fix loop until zero issues
user-invocable: false
Requesting Code Review
Dispatch ed3d-plan-and-execute:code-reviewer subagent to catch issues before they cascade.
**Core principle:** Review early, review often. Fix ALL issues before proceeding.
**Do not use nested subagents.** This skill may dispatch code-reviewer and task-bug-fixer as first-level subagents. Those subagents must do their assigned work directly and must not dispatch additional subagents.
Session Isolation
**If the calling context provides a SCRATCHPAD_DIR, pass it to code-reviewer.**
This prevents collisions when multiple planning/execution sessions run in parallel. The SCRATCHPAD_DIR is a namespaced temp directory (e.g., `/tmp/plan-2025-01-24-feature-a7f3b2/`) that the code-reviewer uses for any scratch files.
When to Request Review
**Mandatory:**
- After each task in plan execution
- After completing major feature
- Before merge to main
**Optional but valuable:**
- When stuck (fresh perspective)
- Before refactoring (baseline check)
- After fixing complex bug
The Review Loop
The review process is a loop: review → fix → re-review → until zero issues.
┌──────────────────────────────────────────────────┐
│ │
│ Dispatch code-reviewer │
│ │ │
│ ▼ │
│ Issues found? ──No──► Done (proceed) │
│ │ │
│ Yes │
│ │ │
│ ▼ │
│ Dispatch bug-fixer │
│ │ │
│ ▼ │
│ Re-review with prior issues ◄──────────────────┘
│
└──────────────────────────────────────────────────┘
**Exit condition:** Zero issues, or issues accepted per your workflow's policy.
Step 1: Initial Review
**Get git SHAs:**
BASE_SHA=$(git rev-parse HEAD~1) # or commit before task
HEAD_SHA=$(git rev-parse HEAD)
**Dispatch code-reviewer subagent:**
<invoke name="Task">
<parameter name="subagent_type">ed3d-plan-and-execute:code-reviewer</parameter>
<parameter name="description">Reviewing [what was implemented]</parameter>
<parameter name="prompt">
Use template at requesting-code-review/code-reviewer.md
WHAT_WAS_IMPLEMENTED: [summary of implementation]
PLAN_OR_REQUIREMENTS: [task/requirements reference]
BASE_SHA: [commit before work]
HEAD_SHA: [current commit]
DESCRIPTION: [brief summary]
SCRATCHPAD_DIR: [session-isolated temp dir, or omit if not applicable]
Do not dispatch or invoke any subagents.
</parameter>
</invoke>
**Code reviewer returns:** Strengths, Issues (Critical/Important/Minor), Assessment
Step 2: Handle Reviewer Response
If Zero Issues
All categories empty → proceed to next task.
If Any Issues Found
Regardless of category (Critical, Important, or Minor), dispatch bug-fixer:
<invoke name="Task">
<parameter name="subagent_type">ed3d-plan-and-execute:task-bug-fixer</parameter>
<parameter name="description">Fixing review issues</parameter>
<parameter name="prompt">
Fix issues from code review.
Code reviewer found these issues:
[list all issues - Critical, Important, and Minor]
Your job is to:
1. Understand root cause of each issue
2. Apply fixes systematically (Critical → Important → Minor)
3. Verify with tests/build/lint
4. Commit your fixes
5. Report back with evidence
6. Do not dispatch or invoke any subagents.
Work from: [directory]
Fix ALL issues — including every Minor issue. The goal is ZERO issues on re-review.
Minor issues are not optional. Do not skip them.
</parameter>
</invoke>
After fixes, proceed to Step 3.
Step 3: Re-Review After Fixes
**CRITICAL:** Track prior issues across review cycles.
<invoke name="Task">
<parameter name="subagent_type">ed3d-plan-and-execute:code-reviewer</parameter>
<parameter name="description">Re-reviewing after fixes (cycle N)</parameter>
<parameter name="prompt">
Use template at requesting-code-review/code-reviewer.md
WHAT_WAS_IMPLEMENTED: [from bug-fixer's report]
PLAN_OR_REQUIREMENTS: [original task/requirements]
BASE_SHA: [commit before this fix cycle]
HEAD_SHA: [current commit after fixes]
DESCRIPTION: Re-review after bug fixes (review cycle N)
SCRATCHPAD_DIR: [session-isolated temp dir, or omit if not applicable]
PRIOR_ISSUES_TO_VERIFY_FIXED:
[list all outstanding issues from previous reviews]
Verify:
1. Each prior issue listed above is actually resolved
2. No regressions introduced by the fixes
3. Any new issues in the changed code
Do not dispatch or invoke any subagents.
Report which prior issues are now fixed and which (if any) remain.
</parameter>
</invoke>
**Tracking prior issues:**
- When re-reviewer explicitly confirms fixed → remove from list
- When re-reviewer doesn't mention an issue → keep on list (silence ≠ fixed)
- When re-reviewer finds new issues → add to list
Loop back to Step 2 if any issues remain.
Handling Failures
Operational Errors
If reviewer reports operational errors (can't run tests, missing scripts): 1. **STOP** - do not continue 2. Report to human 3. When told to continue, re-execute same review
Timeouts / Empty Response
Usually means context limits. Retry with focused scope:
**First retry:** Narrow to changed files only:
FOCUSED REVIEW - Context was too large.
Review ONLY the diff between BASE_SHA and HEAD_SHA.
Focus on: [list only files actually modified]
Skip: broad architect
Read more
name: requesting-code-review description: Use when completing tasks, implementing major features, or before merging to verify work meets requirements - dispatches code-reviewer subagent, handles retries and timeouts, manages review-fix loop until zero issues user-invocable: false
Requesting Code Review
Dispatch ed3d-plan-and-execute:code-reviewer subagent to catch issues before they cascade.
**Core principle:** Review early, review often. Fix ALL issues before proceeding.
**Do not use nested subagents.** This skill may dispatch code-reviewer and task-bug-fixer as first-level subagents. Those subagents must do their assigned work directly and must not dispatch additional subagents.
Session Isolation
**If the calling context provides a SCRATCHPAD_DIR, pass it to code-reviewer.**
This prevents collisions when multiple planning/execution sessions run in parallel. The SCRATCHPAD_DIR is a namespaced temp directory (e.g., `/tmp/plan-2025-01-24-feature-a7f3b2/`) that the code-reviewer uses for any scratch files.
When to Request Review
**Mandatory:**
- After each task in plan execution
- After completing major feature
- Before merge to main
**Optional but valuable:**
- When stuck (fresh perspective)
- Before refactoring (baseline check)
- After fixing complex bug
The Review Loop
The review process is a loop: review → fix → re-review → until zero issues.
┌──────────────────────────────────────────────────┐ │ │ │ Dispatch code-reviewer │ │ │ │ │ ▼ │ │ Issues found? ──No──► Done (proceed) │ │ │ │ │ Yes │ │ │ │ │ ▼ │ │ Dispatch bug-fixer │ │ │ │ │ ▼ │ │ Re-review with prior issues ◄──────────────────┘ │ └──────────────────────────────────────────────────┘
**Exit condition:** Zero issues, or issues accepted per your workflow's policy.
Step 1: Initial Review
**Get git SHAs:**
BASE_SHA=$(git rev-parse HEAD~1) # or commit before task HEAD_SHA=$(git rev-parse HEAD)
**Dispatch code-reviewer subagent:**
<invoke name="Task"> <parameter name="subagent_type">ed3d-plan-and-execute:code-reviewer</parameter> <parameter name="description">Reviewing [what was implemented]</parameter> <parameter name="prompt"> Use template at requesting-code-review/code-reviewer.md WHAT_WAS_IMPLEMENTED: [summary of implementation] PLAN_OR_REQUIREMENTS: [task/requirements reference] BASE_SHA: [commit before work] HEAD_SHA: [current commit] DESCRIPTION: [brief summary] SCRATCHPAD_DIR: [session-isolated temp dir, or omit if not applicable] Do not dispatch or invoke any subagents. </parameter> </invoke>
**Code reviewer returns:** Strengths, Issues (Critical/Important/Minor), Assessment
Step 2: Handle Reviewer Response
If Zero Issues
All categories empty → proceed to next task.
If Any Issues Found
Regardless of category (Critical, Important, or Minor), dispatch bug-fixer:
<invoke name="Task"> <parameter name="subagent_type">ed3d-plan-and-execute:task-bug-fixer</parameter> <parameter name="description">Fixing review issues</parameter> <parameter name="prompt"> Fix issues from code review. Code reviewer found these issues: [list all issues - Critical, Important, and Minor] Your job is to: 1. Understand root cause of each issue 2. Apply fixes systematically (Critical → Important → Minor) 3. Verify with tests/build/lint 4. Commit your fixes 5. Report back with evidence 6. Do not dispatch or invoke any subagents. Work from: [directory] Fix ALL issues — including every Minor issue. The goal is ZERO issues on re-review. Minor issues are not optional. Do not skip them. </parameter> </invoke>
After fixes, proceed to Step 3.
Step 3: Re-Review After Fixes
**CRITICAL:** Track prior issues across review cycles.
<invoke name="Task"> <parameter name="subagent_type">ed3d-plan-and-execute:code-reviewer</parameter> <parameter name="description">Re-reviewing after fixes (cycle N)</parameter> <parameter name="prompt"> Use template at requesting-code-review/code-reviewer.md WHAT_WAS_IMPLEMENTED: [from bug-fixer's report] PLAN_OR_REQUIREMENTS: [original task/requirements] BASE_SHA: [commit before this fix cycle] HEAD_SHA: [current commit after fixes] DESCRIPTION: Re-review after bug fixes (review cycle N) SCRATCHPAD_DIR: [session-isolated temp dir, or omit if not applicable] PRIOR_ISSUES_TO_VERIFY_FIXED: [list all outstanding issues from previous reviews] Verify: 1. Each prior issue listed above is actually resolved 2. No regressions introduced by the fixes 3. Any new issues in the changed code Do not dispatch or invoke any subagents. Report which prior issues are now fixed and which (if any) remain. </parameter> </invoke>
**Tracking prior issues:**
- When re-reviewer explicitly confirms fixed → remove from list
- When re-reviewer doesn't mention an issue → keep on list (silence ≠ fixed)
- When re-reviewer finds new issues → add to list
Loop back to Step 2 if any issues remain.
Handling Failures
Operational Errors
If reviewer reports operational errors (can't run tests, missing scripts): 1. **STOP** - do not continue 2. Report to human 3. When told to continue, re-execute same review
Timeouts / Empty Response
Usually means context limits. Retry with focused scope:
**First retry:** Narrow to changed files only:
FOCUSED REVIEW - Context was too large. Review ONLY the diff between BASE_SHA and HEAD_SHA. Focus on: [list only files actually modified] Skip: broad architect
Showing the first part of this file.
This is my collection of plugins that I use on a day-to-day basis for getting stuff done with Claude Code. Most of these are development-oriented in some way or another, but also often end up being useful for other things.
Repo: ed3dai/ed3d-plugins
Other skills on ed3d-plugins.
- /doing-a-simple-two-stage-fanout
Use when analyzing a large corpus of text, code, or data that exceeds a single agent's effective context - orchestrates parallel Worker subagents, Critic review subagents, and a final Summarizer subagent with task tracking and failure recovery
Open skill - /using-generic-agents
Use to decide what kind of generic agent you should use
Open skill - /creating-a-plugin
Use when creating a new Claude Code plugin or setting up plugin structure - provides complete file organization, manifest format, and component definitions for commands, agents, skills, hooks, and MCP servers
Open skill - /creating-an-agent
Use when creating specialized subagents for Claude Code plugins or the Task tool - covers description writing for auto-delegation, tool selection, prompt structure, and testing agents
Open skill - /maintaining-a-marketplace
Use when creating, releasing, or maintaining a Claude Code Plugin Marketplace - covers marketplace.json schema, version management, release checklists, changelog conventions, and validation to prevent sync drift between plugin.json and marketplace.json
Open skill - /maintaining-project-context
Use when completing development phases or branches to identify and update CLAUDE.md or AGENTS.md files that may have become stale - analyzes what changed, determines affected contracts and documentation, and coordinates updates
Open skill

