Requesting Code Review
requesting-code-review
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
كيف تركّبه؟
- ١حمّل ملف ZIP من الزر فوق.
- ٢فكّ الضغط وحطّ المجلد داخل
.claude/skills/في مشروعك (أو~/.claude/skills/لو تبيه في كل مشاريعك). - ٣شغّل Claude Code من جديد — بيلقط السكِل تلقائياً ويستدعيه وقت ما تحتاجه المهمة.
Requesting Code Review
Dispatch a code reviewer subagent to catch issues before they cascade. The reviewer gets precisely crafted context for evaluation — never your session's history.
Core principle: Review early, review often.
When to Request Review
Mandatory:
- After each task in subagent-driven development
- After completing major feature
- Before merge to main
Optional but valuable:
- When stuck (fresh perspective)
- Before refactoring (baseline check)
- After fixing complex bug
How to Request
1. Get git SHAs:
BASE_SHA=$(git rev-parse HEAD~1) # or origin/main
HEAD_SHA=$(git rev-parse HEAD)2. Dispatch code reviewer subagent:
Dispatch a general-purpose subagent, filling the template at code-reviewer.md
Placeholders:
{DESCRIPTION}- Brief summary of what you built{PLAN_OR_REQUIREMENTS}- What it should do{BASE_SHA}- Starting commit{HEAD_SHA}- Ending commit
3. Act on feedback:
- Fix Critical issues immediately
- Fix Important issues before proceeding
- Note Minor issues for later
- Push back if reviewer is wrong (with reasoning)
Example
[Just completed Task 2: Add verification function]
You: Let me request code review before proceeding.
BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
HEAD_SHA=$(git rev-parse HEAD)
[Dispatch code reviewer subagent]
DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
PLAN_OR_REQUIREMENTS: Task 2 from docs/superpowers/plans/deployment-plan.md
BASE_SHA: a7981ec
HEAD_SHA: 3df7661
[Subagent returns]:
Strengths: Clean architecture, real tests
Issues:
Important: Missing progress indicators
Minor: Magic number (100) for reporting interval
Assessment: Ready to proceed
You: [Fix progress indicators]
[Continue to Task 3]Common Rationalizations
| Excuse | Reality |
|---|---|
| "I'll just review the diff myself instead of dispatching a reviewer" | You're the coordinator — reviewing the diff inline burns the context window you need to keep driving the work. Dispatch a reviewer subagent: the diff and the evaluation live in its context, and only the findings come back to you. |
| "The reviewer needs my whole session history to understand the change" | Hand it precisely crafted context, never your session's history. That keeps the reviewer on the work product, not your thought process. |
Red Flags
Never:
- Skip review because "it's simple"
- Ignore Critical issues
- Proceed with unfixed Important issues
- Argue with valid technical feedback
If reviewer wrong:
- Push back with technical reasoning
- Show code/tests that prove it works
- Request clarification
See template at: code-reviewer.md
سكِلات في نفس المجال
Abc Xyz Segmentation
Segment a SKU portfolio on value (ABC) and demand variability (XYZ), produce the 9-box with a planning policy per cell, …
Academic Cv Builder
Format CVs for academic positions, including publications, grants, teaching, and research experience. Use when the user …
Address Github Comments
Use when you need to address review or issue comments on an open GitHub Pull Request using the gh CLI.…
Avoid Ai Writing
Audit and rewrite content to remove AI writing patterns ("AI-isms"). Use this skill when asked to "remove AI-isms," "cle…
Brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying …
Browser Automation
Browser automation powers web testing, scraping, and AI agent interactions. The difference between a flaky script and a …
تبي سكِل مفصّل على شغلك أنت؟
نبني لك سكِلات ووكلاء ذكاء اصطناعي يفهمون نظامك ويشتغلون عليه.