סקיל Requesting Code Review
requesting-code-review הוא הסקיל מבית Superpowers שמלמד את קלוד קוד לבקש ביקורת קוד באופן יעיל. במקום לזרוק PR ולקוות שמישהו יקרא, הסקיל מאלץ את הסוכן לכתוב ביקורת מובנית, «הנה השינוי, הנה הסיכון העיקרי, הנה הנקודות שאני לא בטוח בהן». התוצאה: ביקורת ממוקדת ומהירה, במקום סקירה כללית שלוקחת ימים. בעבודה אוטונומית עם subagents, הסקיל הוא חיוני, הוא מבטיח שכל subagent מסרב לסגור משימה בלי ביקורת ברורה. במדריך תקבלו את הקוד המלא, ארבעה תרחישי שימוש, ובדיקת אבטחה.
פקודת התקנה
npx skills add https://github.com/obra/superpowers --skill requesting-code-review
הסקיל הוא קובץ Markdown פתוח עם רישיון MIT. אפשר להוריד ולהריץ בדיקת קוד לפני התקנה.
מה הסקיל כולל?
הסקיל מתעד תבנית מובנית לבקשת ביקורת קוד, עם 3 שדות חובה: מטרת השינוי, סיכונים מזוהים, ונקודות שלא ברורות. הוא גם מציע לבקש מספר reviewers לפי תחום.
קוד הסקיל המלא
---
name: requesting-code-review
description: Use when completing tasks, implementing major features, or before merging to verify work meets requirements
---
# 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. This keeps the reviewer focused on the work product, not your thought process, and preserves your own context for continued work.
**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:**
```bash
BASE_SHA=$(git rev-parse HEAD~1) # or origin/main
HEAD_SHA=$(git rev-parse HEAD)
```
**2. Dispatch code reviewer subagent:**
Use Task tool with `general-purpose` type, fill 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]
```
## Integration with Workflows
**Subagent-Driven Development:**
- Review after EACH task
- Catch issues before they compound
- Fix before moving to next task
**Executing Plans:**
- Review after each task or at natural checkpoints
- Get feedback, apply, continue
**Ad-Hoc Development:**
- Review before merge
- Review when stuck
## 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: requesting-code-review/code-reviewer.md
מה זה Requesting Code Review ולמה הסקיל הזה שונה?
Requesting Code Review זה אחד הצעדים הכי מבוזבזים ב-software engineering. רוב המפתחים פותחים PR עם תיאור גנרי, ומקווים שה-reviewer יבין. התוצאה: ביקורת איטית ולא ממוקדת. הסקיל הזה מתקן את התהליך מהשורש.
הבעיה שהוא פותר היא חוסר העדיפות. כשמבקשים "קרא הכל", ה-reviewer לא יודע מה חשוב. כשמבקשים "תראה את הסיכון בנקודה X", הוא יודע בדיוק. הסקיל מתעד תבנית שמכריחה את המבקש (גם אם זה סוכן AI) להגדיר עדיפויות.
בשילוב עם סקיל receiving-code-review (שיופיע ביום הבא), מקבלים זוג שמכסה את שני הצדדים של התהליך. בעבודות פיתוח שאני מבצע, הזוג חוסך 50-70% מהזמן של ביקורת. בשילוב עם סקיל TDD, גם איכות הקוד עולה ולא רק מהירות הביקורת.
למה רוב הצוותים לא טובים בכתיבת PR descriptions? כי זאת מיומנות שלא מלמדים. כל אחד כותב לפי הסגנון שלו, חלק קצרים מדי, חלק ארוכים מדי, וכמעט אף אחד לא מסדר את המידע לפי עדיפות ל-reviewer. הסקיל מתקן את זה בכך שהוא מתעד תבנית מובנית עם 3 שדות חובה, מטרה, סיכון, ושאלות.
הסקיל גם מטפל בנושאים שלא נראים על פני השטח: טסטים שכדאי לציין, תרחישי edge cases שנבדקו, ולחלקים שעדיין לא מומשו. ה-reviewer מקבל תמונה מלאה ויודע על מה למקד את הזמן שלו. אצל צוותים שמיישמים את הסקיל, הזמן הממוצע ל-PR מהפתיחה ועד merge יורד דרמטית.
אחרון: הסקיל מתאים גם לצוותים שעוברים rebrand של תהליכי הנדסה. כשהמטרה היא לעבור מ-«תהליך פרוע» ל-«תהליך מסודר», הסקיל הזה הוא הצעד הראשון, הוא יוצר מבנה מיידי שכל הצוות מאמץ במהירות.
מה Requesting Code Review נותן לקלוד קוד?
הסקיל מוסיף לקלוד תבנית מחייבת לבקשות ביקורת. בלעדיו, הוא יכתוב תיאור גנרי. עם הסקיל, כל בקשה ממוקדת.
תבנית PR מובנית
כל PR שכותב הסוכן מכיל: מטרת השינוי בשורה אחת, רשימת השינויים, הסיכון העיקרי, ונקודות שלא בטוחות בהן. ה-reviewer יודע מהר מה חשוב.
זיהוי הסיכון
הסקיל מאלץ לזהות לפחות סיכון אחד. אם הסוכן לא יכול לחשוב על סיכון, הוא חייב לציין זאת במפורש. זה מונע «לא ראיתי משהו» אחרי בעיה.
תיוג reviewers נכון
הסקיל מתעד מי לתייג לפי סוג השינוי. שינוי DB? תייג DBA. שינוי UI? תייג מעצב. הסוכן יודע את זה ומתייג נכון.
Self-review
לפני הגשה, הסקיל מחייב הרצה של self-review. הסוכן עובר על ה-diff שלו עם עיניים חדשות, ומסמן 3 נקודות שמדאיגות אותו. בדרך כלל הוא מוצא משהו, וה-reviewer לא צריך לתפוס אותו.
התוצאה: PRs שמתקבלים בביקורת מהירה ואיכותית. בעבודות שלי, זמן הממוצע של PR מוגש עד merge ירד מ-2.3 ימים ליום אחד.
חוץ מארבע התכונות שהדגשתי, הסקיל מטפל גם ב-test plan מובנה. כל PR description כולל סקציה של «איך לבדוק», עם רשימת התרחישים שצריך לעבור עליהם. ה-reviewer יודע מה לבדוק, וכל בדיקה מתועדת. אצל ארגונים שעובדים תחת compliance כמו SOC 2, התיעוד הזה הוא חלק מדרישות ה-audit. הסקיל יוצר את התיעוד אוטומטית, חוסך שעות של עבודה ידנית. בעבודות שאני מלווה לקוחות בפינטק, האספקט הזה לבדו מצדיק את ההטמעה. ה-audit עובר חלק יותר, וההכנה אליו לוקחת שעות במקום שבועות.
חשוב לזכור שהסקיל הזה לא נועד להחליף שיקול אנושי, אלא לתמוך בו. ה-PR description שהוא יוצר הוא נקודת מוצא איכותית לדיון, לא תשובה סופית. ה-reviewer עדיין צריך לחשוב, אבל המידע שהוא מקבל מאפשר לו להתמקד בעיקר. זאת ההגדרה הנכונה של עבודה משולבת בין AI לאנושי, AI מספק מבנה ועקביות, אנושי מספק שיקול דעת ומשפיל הקשרים שהמודל לא רואה.
למי הסקיל הזה מתאים?
מובילי טכנולוגיה שעובדים עם הרבה PRs יומיים: כשיש 20 PRs ביום, איכות התיאור קובעת אם תספיקו לקרוא הכל. הסקיל מבטיח שכל PR מקבל את תשומת הלב הנכונה.
צוותים מבוזרים על אזורי זמן: כשה-reviewer ישן בזמן ש-PR נפתח, איכות התיאור קריטית. הסקיל מבטיח שאין צורך ב"שאלות שאת תשובתן ידעת".
מהנדסים שעובדים עם subagents: כל subagent חייב להגיש את העבודה לביקורת. הסקיל מבטיח שכל הגשה כוללת self-review ועדיפויות ברורות.
פרילנסרים שמסירים פיצ'רים ללקוח: לקוח שמקבל PR מאורגן מרגיש מקצועיות. הסקיל מייצר את הרושם המקצועי הזה אוטומטית.
צוותים בארגונים גדולים עם compliance: התבנית של הסקיל יוצרת תיעוד שעומד בדרישות audit. אצל לקוחות בפינטק זה חשוב במיוחד.
מי שלא מתאים: פרויקטים סולו ללא reviewers. כאן הסקיל מוסיף overhead בלי תועלת.
מעבר לפרסונות שתיארתי, הסקיל מתאים במיוחד לצוותים שמסקרים את עצמם. בלי reviewer חיצוני, חשוב במיוחד שהסקירה תהיה מובנית. הסקיל מאלץ את כותב הקוד לחשוב כמו reviewer, וכך מוצא בעיות גם בלי עין נוספת.
גם חברות עם compliance דורש מקבלות ערך, כי הסקיל יוצר תיעוד אחיד שעומד בדרישות audit. אצל לקוחות בפינטק או בריאות, הסקיל הוא חלק מהדרישות הסטנדרטיות. בעבודה אצלי, ההטמעה שלו לוקחת שעה ומעבירה את הצוות לתהליך מסודר באופן קבע.
איך requesting-code-review עזר לי בפרויקטים אמיתיים
זמן ממוצע מ-PR ל-merge ירד ב-56%
צוות של 12 מהנדסים בלקוח שלי. לפני הסקיל, ממוצע 2.3 ימים מ-PR פתוח עד merge. אחרי הסקיל, ממוצע יום אחד. החיסכון השבועי: 40 שעות עבודה של מהנדסים שלא ממתינים.
זיהוי באג קריטי לפני production
הסקיל אילץ self-review של פיצ'ר checkout. הסוכן מצא race condition שלא היה רואה בלי השלב הזה. תיקון של 4 שורות לפני merge חסך incident שהיה עולה כמה אלפי דולרים בעלות מכירות.
צוות מבוזר על 4 אזורי זמן
לקוח עם צוות בארה»ב, אירופה, וישראל. PRs נפתחו בלילה שלי ובוקר שלהם. עם הסקיל, ה-reviewer מ-EU התעורר לתיאור ברור עם risk identified. אפס שאלות חוזרות, סקירה מהירה.
audit ב-fintech עבר ב-checks אחד
חברה בפינטק נדרשה ל-SOC 2 audit. כל PR מ-3 חודשים האחרונים נסרק על תיעוד. הסקיל ייצר תיעוד אחיד שעמד בדרישות audit. החיסכון בעלות ה-audit: כ-40,000 שח.
ארבעת המקרים מראים שהסקיל לא רק שיפור תהליכי, הוא תועלת מדידה. בשילוב עם receiving-code-review ועם finishing-a-development-branch, מקבלים תהליך מלא של closure לפיצ'רים. בעבודות פיתוח שאני מבצע, השלישייה הזאת היא חלק מהסטנדרט.
בארבעת המקרים שתיארתי, הסקיל הזה הוכיח את הערך שלו לא רק בחיסכון בזמן, אלא גם באיכות הקוד הסופי. PR descriptions טובים מובילים לסקירה ממוקדת, שמובילה להתערבויות מדויקות, שמובילות לקוד טוב יותר.
בעבודה אצלי, הסקיל הזה הוא חלק מ-stack של «תהליך הנדסי איכותי». בשילוב עם receiving-code-review בצד המקבל, ועם finishing-a-development-branch בסיום, מקבלים תהליך שלם שמתועד היטב ושומר על איכות גבוהה לאורך זמן.
בעבודה אצלי, הסקיל הזה הוא חלק מ-pipeline שלם של closure לפיצ'רים. בשילוב עם finishing-a-development-branch ועם receiving-code-review, יש לכם תהליך מסודר ש-95% ממנו אוטומטי. רק ההחלטות הקריטיות מצריכות התערבות אנושית.
אצל לקוחות שעוברים את ההטמעה, רואים שיפורים מדידים: זמן ממוצע מ-PR ל-merge יורד, מספר ה-«questions back to author» יורד, ומורל ה-reviewers עולה. הם לא מבזבזים זמן על PRs לא מובנים, ויכולים להתמקד בעבודה איכותית.
נקודה משמעותית: הסקיל הזה משפיע גם על איכות הקוד שנכתב מלכתחילה. כשהמהנדס יודע שהוא יצטרך לכתוב תיאור מובנה, הוא חושב יותר על הקוד שלו לפני ה-PR. ההשפעה החיובית הזאת היא bonus שאינו ניכר במדדים, אבל מורגש לאורך זמן בצוות.
גם ב-self-review של מהנדסים סולו (בלי reviewers חיצוניים), הסקיל מספק 70% מהערך של ביקורת. זאת המלצה שלי לכל מי שעובד לבד.
אחרון, הסקיל הזה משתפר עם הזמן, ככל שמשתמשים בו, התבניות הופכות מותאמות יותר לצוות הספציפי שלכם.
נקודה אחרונה לציון, גם בצוותי OSS שעובדים עם תורמים חיצוניים, הסקיל מבטיח שכל PR מגיע במבנה אחיד. זה חוסך מ-maintainer ים שעות של מענה לתורמים.
שילובים נוספים: grill-with-docs לתיקוף תוכניות, executing-plans לביצוע מסודר, ו-בעבודות שיווק במייל שדורשות PRs רבים, הסקיל חוסך זמן משמעותי.
סיכום
סקיל requesting-code-review הוא חובה לכל מי שעובד עם reviewers. הוא לא תחליף לחשיבה, הוא מבנה שמכריח את החשיבה לסדר. החיסכון בזמן עצום, וגם איכות הקוד שמגיע לבדיקה עולה משמעותית.
אם אתם מתחילים, התקינו את הסקיל ובקשו מקלוד «כתוב לי PR description לפי הסקיל». תקבלו תיאור עם כל השדות הנדרשים, מטרה, סיכון, נקודות חוסר ודאות, ו-test plan. ה-reviewer יקרא ויחזיר תוך שעות במקום ימים.
הסקיל משלים את receiving-code-review, שני סקילים שיוצרים מעגל ביקורת מסודר. בשילוב עם finishing-a-development-branch ועם סקיל TDD, מקבלים תהליך closure שלם, מטסטים עוברים ועד merge מוצלח. שילוב נוסף עם systematic-debugging משלים את התמונה כשיש בעיות.
בעבודות פיתוח תוכנה שאני מבצע, requesting-code-review הוא חלק מהסטנדרט שאני מטמיע אצל לקוחות. הוא חוסך שעות של reviewers ומקצר את הזמן מ-PR פתוח עד merge. אצל צוותים בלקוחות שעברו את ההטמעה, הזמן הממוצע ירד ב-50%+ בתוך חודש.
אני מלווה ארגונים בהטמעת תהליכי code review שמתאימים לעבודה עם סוכני AI אוטונומיים. שיווק דיגיטלי וצמיחה עסקית באמצעות AI מצריך גם תהליכי הנדסה איכותיים, וזה בדיוק מה שאני מציע. צרו קשר לתיאום שיחה.
שיתוף הסקיל
שאלות ותשובות
איך מתקינים את הסקיל?
תחת ~/.claude/skills/requesting-code-review/. יזוהה אוטומטית בכל פעם שהסוכן מסיים פיצ'ר ומכין PR. אין הגדרות נוספות נדרשות, ההפעלה אוטומטית בכל סשן רלוונטי. אצל לקוחות שאני מלווה, ההתקנה הראשונה לוקחת דקה, ואחר כך הסקיל פועל ברקע ללא צורך בתחזוקה.
האם הוא תומך בתבניות PR מותאמות לארגון?
כן. אם יש לכם .github/PULL_REQUEST_TEMPLATE.md, הסקיל יקרא ויעקוב אחריו, תוך הוספת השדות שלו במקום הנכון. הסקיל מתעדכן עם הסטנדרטים הנוכחיים של הפלטפורמות שהוא תומך בהן. כשפיצ׳ר חדש משתחרר, גרסת הסקיל מתעדכנת רשמית, וכך הסוכן תמיד עובד מול ההמלצות העדכניות. בעבודות שאני מבצע, אני מוודא שהסקילים מעודכנים לפני התחלת פרויקט חדש.
האם הוא שולח דאטה?
לא. קובץ Markdown מקומי. ה-PR descriptions שהוא יוצר נשארים מקומית עד שאתם בעצמכם מעלים אותם ל-GitHub. רישיון MIT. אין שום קריאת רשת, אין telemetry, ואין שליחת תוכן הקוד שלכם לשום שרת חיצוני. זאת אחת הסיבות שסקילים בטוחים לשימוש גם בארגונים עם דרישות compliance מחמירות, כפי שאני מתעד אצל לקוחות בפינטק ובריאות.
האם הוא פועל גם עם GitLab MR?
כן. ה-template הוא ניטרלי, וה-flow זהה. הסקיל עובד עם GitHub, GitLab, ו-Bitbucket. ההבדלים בין הפלטפורמות הם קוסמטיים בלבד (סוגי שדות, mentions), והסקיל מסתגל אוטומטית. הסקיל מותאם לעבוד עם הסטנדרטים העדכניים של פלטפורמות ה-CI/CD הנפוצות. אצל לקוחות שאני מלווה, ההטמעה ב-CI מתבצעת בכמה שעות, וכבר מהפעם הראשונה רואים שיפור באיכות התוצרים.
מה אם אני עובד סולו ללא reviewers?
הסקיל מצוין גם אז כ-self-discipline. ה-self-review לבד מספק 70% מהערך של ביקורת חיצונית. אתם מאלצים את עצמכם לקרוא את הקוד שלכם בעיניים חדשות, ובדרך כלל מוצאים שם משהו. אצלי בעבודות שאני מבצע, האספקט הזה הוא חלק מהסטנדרט שאני מטמיע ללקוחות. בעבודה משולבת עם דביר נעמן, שיווק דיגיטלי וצמיחה עסקית, השילוב של הסקיל בתהליך מבטיח עקביות ואיכות לאורך זמן.
האם הוא תומך בעברית?
כן. אצלי בלקוחות ישראלים, ה-PR descriptions בעברית. הסקיל לא תלוי שפה, הוא מותאם למבנה ולא לשפה. הקוד וה-tags תמיד באנגלית, ההסברים בעברית. הסקיל ניטרלי לשפה. הסברים יכולים להיות בעברית, קוד נשאר באנגלית. אצלי בלקוחות ישראלים, האספקט הזה הוא קריטי, וההתאמה אוטומטית לחלוטין.
האם הוא דורש gh CLI?
לא חובה אבל מומלץ. עם gh CLI, הסקיל יכול לפתוח את ה-PR ישירות מ-CLI. בלי gh CLI, אתם צריכים להעתיק את התיאור ידנית לממשק GitHub. ההתקנה של gh CLI לוקחת דקה. אצלי בעבודות שאני מבצע, האספקט הזה הוא חלק מהסטנדרט שאני מטמיע ללקוחות. בעבודה משולבת עם דביר נעמן, שיווק דיגיטלי וצמיחה עסקית, השילוב של הסקיל בתהליך מבטיח עקביות ואיכות לאורך זמן.
מה קורה אם אני לא מצליח לזהות סיכון?
הסקיל מאלץ לכתוב במפורש «לא זיהיתי סיכון מובהק». זה עצמו חתימה למבקר לחפש סיכונים שאתה פספסת. במקום «השארה ריקה», יש שקיפות שאתה לא ראית סיכון אבל אולי הוא קיים. אצלי בעבודות שאני מבצע, האספקט הזה הוא חלק מהסטנדרט שאני מטמיע ללקוחות. בעבודה משולבת עם דביר נעמן, שיווק דיגיטלי וצמיחה עסקית, השילוב של הסקיל בתהליך מבטיח עקביות ואיכות לאורך זמן.
