## פוסט: איך הופכים הערות Code Review לכללים ש-Cursor יכול להשתמש בהם?
**תשובה קצרה:** אוספים הערות שחזרו בכמה Pull Requests, בודקים שהצוות באמת מסכים עליהן, ואז כותבים כללים קצרים וממוקדים בתוך הריפו.

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

**1. אוספים ראיות, לא רק ניסוחים.** בוחרים הערות של בני אדם מ-PRs שמוזגו. בודקים מה השתנה בעקבות ההערה. חזרה בכמה PRs היא ראיה חזקה יותר משתי תגובות באותו דיון.

**2. מפרידים מוסכמה מהעדפה רגעית.** המלצה שנכונה לקובץ אחד עשויה להיות שגויה בשאר המערכת. ליד כל כלל שומרים קישור לדוגמאות ולדיון המקורי, ומישהו מהצוות בודק אותו לפני שימוש.

**3. כותבים כלל שאפשר לפעול לפיו.** במקום "כתוב קוד איכותי", כותבים מה לבדוק, מתי, ובאיזה קובץ יש דוגמה נכונה. זו דוגמת ניסוח, לא כלל של לקוח: "בנתיבי API חדשים, בדוק קלט לפני פנייה למסד הנתונים, לפי התבנית בקובץ הדוגמה של הפרויקט".

**4. שומרים את הכלל במקום הנכון.** לפי התיעוד של Cursor, כללי פרויקט נשמרים כקובצי `.mdc` בתוך `.cursor/rules` ומנוהלים ב-Git. אפשר להחיל כלל לפי סוג קובץ, לפי רלוונטיות או ידנית. כך כל הצוות עובד מול אותו מקור, ולא מול פרומפט פרטי של מפתח אחד.

**5. מתחילים מעט ובודקים בקוד אמיתי.** Cursor ממליצה לשמור כללים ממוקדים, מתחת ל-500 שורות, ולפצל נושאים. זה גבול מנחה לכלל, לא יעד למלא. כלל קצר שמונע טעות חוזרת עדיף על ספר נהלים שהסוכן מתקשה ליישם.

בניסוי המתועד של pr-rulebook נסרקו 15 PRs ו-45 הערות review אנושיות בפרויקט Ruff. נמצאו שני כללים מועמדים, ורק אחד עמד בבדיקה. זו תזכורת טובה: חזרה בטקסט היא תחילת בדיקה, לא אישור אוטומטי לאכוף כלל.

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

אני מלווה צוותים בבניית כללי עבודה, ביקורת קוד והטמעת כלי AI. פרטים: https://israeli-ai-agency.pages.dev/services/ai-native/ .


## מהניסיון שלי

ביקשתי מהסוכן שלי לבנות את pr-rulebook מתוך רעיון שעלה בשיחה. בפוסט שפרסמתי סיפרתי גם על התוצאה וגם על הכלל שנפסל בניסוי. דווקא הכישלון עוזר להבין איך להפוך הערות review לידע שימושי, בלי להפוך כל הערה לחוק.

## בקצרה

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



## שאלות נפוצות

### איפה שומרים כללי פרויקט ב-Cursor?

בתיקיית .cursor/rules בריפו, בקובצי .mdc שמנוהלים ב-Git.

### האם כל הערת review צריכה להפוך לכלל?

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

### האם כללים מחליפים ביקורת קוד?

לא. כללים מספקים הקשר לסוכן; בדיקות וביקורת אנושית עדיין נדרשות.

## על הכותב

עופר שפירא - The Israeli AI Agency - התאמה והתקנת סוכני AI לעסקים קטנים בישראל, בעברית, עם ליווי לאורך זמן.