requesting-code-review
Request and process code reviews with proper context. Use after completing significant implementation work.
Installation
Follow the repository instructions for this skill and your agent. Review the files and dependencies before adding it to your workflow.
View source ↗GuidesSkill instructions
Requesting Code Reviews
Review early, review often - catch issues before they compound.
When Reviews Are Required
| Scenario | Timing |
|---|---|
| Each task in subagent-driven work | After each task |
| Major feature completion | Before integration |
| Before merging to main | Pre-merge |
| When stuck on a problem | As needed |
| Before refactoring | Pre-refactor |
| After complex bug fix | Post-fix |
How to Request Review
1. Gather Context
# Get commit range for review
git log --oneline -5
git diff main..HEAD --stat
2. Dispatch Reviewer
Task(code-reviewer, prompt="
Review the changes in commits [base]..[head]
**What was implemented:**
[Description of changes]
**Requirements reference:**
[Link or description of requirements]
**Areas of concern:**
[Any specific areas you want extra attention]
**Files changed:**
[List key files]
")
3. Process Feedback
| Severity | Action Required |
|---|---|
| Critical | Fix immediately - blocks all other work |
| High | Resolve before proceeding to next task |
| Medium | Address in current session if time permits |
| Low/Minor | Document for future improvement |
Review Request Template
## Code Review Request
**Commits:** [base-sha]..[head-sha]
**Branch:** [branch-name]
### Summary
[1-2 sentences on what changed]
### Changes by File
| File | Change Type | Description |
| ------------ | -------------- | -------------- |
| path/to/file | Added/Modified | [What changed] |
### Requirements
[Link to issue/spec or brief description]
### Testing Done
- [ ] Unit tests pass
- [ ] Integration tests pass
- [ ] Manual testing completed
### Areas Needing Attention
- [Specific concern 1]
- [Specific concern 2]
### Questions for Reviewer
- [Any specific questions]
Handling Feedback
Agree with Feedback
- Acknowledge the issue
- Fix immediately (Critical/High) or document (Medium/Low)
- Respond with what was changed
Disagree with Feedback
- Never dismiss without explanation
- Provide technical justification with evidence
- Reference code patterns or documentation
- Explain trade-offs considered
- Be open to being wrong
Example Response
## Review Response
### Critical Issues
- **[File:Line]**: Fixed - [what was changed]
### High Priority
- **[File:Line]**: Fixed - [what was changed]
### Disagreement: [Issue]
I believe [current approach] is correct because:
1. [Technical reason]
2. [Evidence from codebase]
However, open to discussion if I'm missing something.
### Deferred
- **[Minor issue]**: Added to tech debt tracker for future
Integration Points
- After executing-plans batches
- After systematic-debugging fixes
- Before finishing branches (merge/PR)
Examples
Read the usage examples in the source repository.
View source ↗Source history
- Indexed on
- 2026-01-20
- Index updated
- 2026-01-28
- Branch
- main
Index and sync dates describe this directory. View the source repository for code history.
GitHub ↗chat Comments (0)
Sign in to join the discussion and leave a comment.
No comments yet. Be the first to share your thoughts!