ביקורת קוד שמחפשת באגים

ביקורת קוד ברירת מחדל מחזירה הערות סגנון: שמות משתנים, אורך פונקציה, והצעה לפרק. זה רעש שמסתיר את מה שבאמת שובר. הדרישה שכל ממצא יגיע עם קלט קונקרטי שמפיל את הקוד מסננת את מרבית הרעש, ומכריחה את הבודק לאמת לפני שהוא מדווח. זהו Skill ל-Claude: תיקייה עם קובץ SKILL.md, שנטענת אוטומטית כשהמשימה מתאימה לתיאור שבראש הקובץ. בניגוד לפרומפט שמדביקים בכל פעם מחדש, Skill מותקן פעם אחת וממשיך לעבוד לבד.

קוד ואיכות · code review · באגים · איכות · קוד

מתי הוא נכנס לפעולה

---
name: defect-focused-review
description: "How to review code for real defects rather than style: require a concrete failure scenario for every finding, prioritize silent wrong results, and report nothing when nothing meets the bar. Use when reviewing code, auditing a change, or checking a pull request."
---

# ביקורת קוד

## הרף

כל ממצא חייב לכלול:

1. קובץ ושורה מדויקים.
2. **תרחיש כישלון קונקרטי**: קלט או מצב ספציפיים שמייצרים תוצאה שגויה,
   קריסה או אובדן נתונים.
3. למה הקוד הנוכחי מייצר את התוצאה הזו.
4. התיקון המינימלי.

**אם אי אפשר לבנות תרחיש כזה, לא מדווחים את הממצא.** הדרישה הזו מוחקת
את רוב ההערות חסרות הערך.

## סדר עדיפות

1. **תוצאה שגויה בשקט.** קוד שמחזיר ערך סביר אך שגוי גרוע מקוד שקורס.
   קריסה נתפסת בבדיקה, מספר שגוי מגיע ללקוח.
2. מסלולי שגיאה שבולעים כישלון וממשיכים.
3. מקרי קצה: אחד יותר או פחות, אוסף ריק, null.
4. תנאי מרוץ ומצב שנשמר במטמון והתיישן.
5. אבטחה: הזרקה, בדיקת הרשאה חסרה, סוד בקוד צד לקוח, קלט משתמש שמקבל
   אמון.
6. דליפת משאבים.

## לא לדווח

שמות, פורמט, אורך קובץ, ו"אפשר להוציא את זה לפונקציה", אלא אם הם גורמים
ישירות לאחד מהסעיפים למעלה.

## כשלא נמצא כלום

אמור זאת במפורש. אל תמלא את הרשימה כדי שתיראה מלאה. רשימה ארוכה של
הערות חלשות מסתירה את הממצא האחד שחשוב.

איך מתקינים

  1. צרו תיקייה בשם defect-focused-review בתוך ‎.claude/skills/‎ בפרויקט, או בתיקיית הבית לשימוש בכל הפרויקטים.
  2. שמרו בתוכה את הקובץ בשם SKILL.md.
  3. זהו. אין צורך להפעיל כלום, והוא ייטען לבד כשהמשימה תתאים לתיאור.