4 שלבים לסוכן שמבקר את הקוד שלך לפני מיזוג

הרעיון

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

• הסוכן שכותב את הקוד לא בודק את עצמו. הביקורת מגיעה מקונטקסט נקי.
• הביקורת רצה על הדיף בלבד, לא על כל הפרויקט.
• ממצא חמור עוצר את המיזוג במקום להיכנס בשקט.
• זה אותו כלל של Snyk: לא אומרים "סיימתי" כשיש חור פתוח.

שלב 1: הגדר סקיל ביקורת

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

• תן לו תפקיד אחד: מבקר אבטחה וקוד, לא כותב קוד.
• הוא לא מתקן. הוא רק מסמן ומדרג חומרה.
• הפלט קצר: בעיה, מיקום, חומרה, למה זה מסוכן.
• שמור את זה כסקיל כדי שכל הרצה תיראה אותו דבר.

# Skill: code-audit

אתה סוכן ביקורת אבטחה וקוד.

תפקיד:
- קרא רק את השינוי (הדיף), לא את כל הפרויקט.
- אל תכתוב ותקן קוד.
- מצא חולשות אבטחה, באגים ושבירת התנהגות.
- דרג כל ממצא: low / medium / high / critical.

תחזיר טבלה בלבד:
1. הבעיה.
2. הקובץ והשורה.
3. החומרה.
4. למה זה מסוכן במשפט אחד.

אם אין בעיות: כתוב "לא נמצאו ממצאים".

שלב 2: תן לו לקרוא את הדיף

אל תשפוך עליו את כל בסיס הקוד. תן לו בדיוק את מה שהשתנה. זה מוזיל, ממקד, ומונע ממנו להמציא בעיות בקוד שאף אחד לא נגע בו.

• הזן את הדיף של השינוי שעומד להיכנס, לא את הריפו.
• staged בלבד: מה שבאמת עומד למיזוג עכשיו.
• קבצים גדולים? חתוך לפי אזור שינוי.
• צרף את הקונטקסט המינימלי שצריך כדי להבין את השינוי.

# מה שהסוכן מקבל, לא יותר
git diff --staged > change.diff

# מריצים את הביקורת רק על הדיף
agent: audit change.diff

שלב 3: סמן חולשות

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

• סודות וטוקנים שנכנסו לקוד בטעות.
• קלט משתמש שלא עבר ולידציה: SQL injection, XSS, path traversal.
• הרשאות ובקרת גישה: מי מורשה לגעת במה.
• תלויות חדשות עם חולשה ידועה.
• שבירת התנהגות קיימת או מחיקת דאטה בלי כוונה.

# דוגמה לפלט ביקורת

| # | בעיה | קובץ | חומרה |
|---|------|------|--------|
| 1 | טוקן API בקוד | config.ts:14 | critical |
| 2 | קלט לא מסונן לשאילתה | db.ts:52 | high |
| 3 | קונסול לוג עם דאטה של משתמש | api.ts:88 | low |

שלב 4: עצור לפני מיזוג

ממצא בלי שער הוא רק הערה שאף אחד לא קורא. הכלל הפשוט: high או critical עוצרים את המיזוג. הכל חוזר אליך להחלטה, ואתה זה שמשחרר, לא הסוכן.

• high או critical = עצירה. אין מיזוג עד שמתקנים או מאשרים ידנית.
• low ו-medium נרשמים אבל לא חוסמים.
• הסוכן לא מאשר את עצמו, אתה משחרר את השער.
• חבר את זה ל-pre-merge או pre-commit כדי שזה ירוץ לבד בכל פעם.

# כלל השער

אם יש ממצא high או critical:
  -> עצור. אל תמזג.
  -> החזר את הרשימה למפתח.
אחרת:
  -> רשום ממצאים.
  -> אפשר להמשיך למיזוג.

התבנית המלאה בהרצה אחת

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

לפני מיזוג של כל שינוי:

1. סקיל ביקורת פעיל (code-audit).
2. git diff --staged  ->  זה הקלט היחיד.
3. הסוכן סורק: סודות, קלט לא מסונן, הרשאות, תלויות, שבירת התנהגות.
4. ממצא high/critical  ->  עצירה לפני מיזוג. הכל חוזר אליי.

כלל אחד: לא מזייגים כשיש חור פתוח.

רשימת בדיקה לפני שאתה מסתמך על זה

• הסקיל קורא רק את הדיף, לא ממציא בעיות בקוד שלא נגעת בו.
• יש דירוג חומרה על כל ממצא, לא רק רשימה שטוחה.
• high ו-critical באמת עוצרים, לא רק מדפיסים אזהרה.
• אתה משחרר את השער ידנית, הסוכן לא מאשר את עצמו.
• אם יש לך כלי סריקה כמו Snyk, הוא רץ על השינוי ומוזן פנימה.