דביר נעמן

סקיל Verification Before Completion לקלוד קוד
סקילים לקלוד קוד

סקיל Verification Before Completion

8 דקות קריאה דביר נעמן

verification-before-completion הוא הסקיל שמכריח את קלוד קוד לבדוק את עצמו לפני שמסיים משימה. בלעדיו, הסוכן נוטה לדווח 'בוצע' גם כאשר ה-build נכשל, הטסטים אדומים, או הקוד לא הועלה כראוי. עם הסקיל, כל סגירת משימה דורשת ראיה אובייקטיבית, command output, טסט ירוק, או build שעבר. אצלי הסקיל הזה הציל אותי מ-deploys שבורים פעמיים בחודש האחרון. במדריך תקבלו את הקוד המלא, רשימת הבדיקות הקנונית, ודוגמאות מהשטח.

תמונת כותרת לפוסט: סקיל Verification Before Completion

פקודת התקנה

מפתח: Superpowers
קטגוריה: Quality Assurance
התקנות: כ-72K בשבוע
רישיון: MIT
npx skills add https://github.com/obra/superpowers --skill verification-before-completion

הסקיל הוא קובץ Markdown פתוח עם רישיון MIT. אפשר להוריד ולהריץ בדיקת קוד לפני התקנה.

מה הסקיל כולל?

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

אסור לדווח 'בוצע' בלי הוכחה מבדיקה
Build, test, lint חייבים לעבור
Output נקי ללא warnings
אם UI: מסך אמיתי בדפדפן, לא רק קומפילציה
ראייה הופכת לאישור (terminal output, screenshot)
אם נכשל: דיווח כן ולא הסתרה

קוד הסקיל המלא

Markdown

מה זה Verification Before Completion ולמה הסקיל הזה שונה?

Verification זה השלב שבו אתם מאמתים שהמשימה הסתיימה כראוי לפני שאתם הולכים הלאה. הסקיל הזה מטמיע את העיקרון הזה בקלוד קוד באופן כפוף, "evidence before assertions".

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

בשילוב עם סקיל test-driven-development ועם סקיל executing-plans, מקבלים שלוש שכבות הגנה. הראשונה כותבת טסטים, השנייה מבצעת לפי תוכנית, השלישית מאמתת לפני סיום.

למה זה הבעיה הכי שכיחה בעבודה עם סוכני AI? כי מודלי שפה מתקשים להבחין בין «הפעולה הסתיימה טכנית» לבין «התוצאה אכן עובדת». סוכן ללא הסקיל יסיים פעולה כי הריץ פקודה, גם אם הפקודה החזירה שגיאה. עם הסקיל, הוא חייב לוודא: הקוד מתקמפל? הטסטים עוברים? התוצאה תואמת ל-spec? רק אם כל אלה כן, הוא מצהיר שסיים.

הסקיל מתעד גם רמות שונות של verification: בסיסי (קומפילציה + טסטים), בינוני (linting + type checking), מתקדם (E2E tests + manual smoke). הוא בוחר את הרמה לפי קונטקסט המשימה. פיצ'ר קטן מקבל verification בסיסי, פיצ'ר קריטי מקבל מתקדם. זה לא overhead מיותר, זה התאמה.

מה Verification Before Completion נותן לקלוד קוד?

הסקיל מוסיף לקלוד קוד שלב אימות חובה. בלעדיו, סגירת משימה היא declarative. עם הסקיל, היא חייבת ראיה.

הרצה ולא רק בדיקה

הסוכן חייב להריץ build, tests, ו-lint בפועל. לא להסיק מהקוד שזה אמור לעבוד. הוא מציג את הפלט כראיה.

UI דורש דפדפן

לפיצ'רים של UI, build נקי לא מספיק. הסקיל מחייב צילום מסך מהדפדפן או הרצה ב-headless. אם לא ראית את הפיצ'ר עובד, הוא לא בוצע.

output נקי

הסקיל לא מקבל warnings. הוא מחייב פלט נקי. אם warnings, הסוכן צריך לטפל לפני סגירה. אצלי בפרויקטים זה הוריד את כמות ה-deprecation noise.

כישלון מדווח

הסקיל אוסר על הסוכן להסתיר כישלונות. אם הטסט נכשל, הוא מדווח כן ומסביר. בלי לקפוץ ישר ל-fix שלא בקשתם.

התוצאה: דיווחי 'בוצע' שאפשר לסמוך עליהם. בעבודות שלי, מאז הוספת הסקיל אפס deploys שבורים בייצור.

למי הסקיל הזה מתאים?

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

צוותי DevOps שעובדים על pipelines: deploys שבורים יקרים. הסקיל מונע אותם בכך שהוא מאלץ אימות לפני release.

מנהלי מוצר שמקבלים pull requests מ-AI: PR עם תיוג 'ready for review' שלא נבדק הוא מטרד. הסקיל מבטיח שכל PR שמסומן עבר את כל הבדיקות.

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

צוותים עם compliance או audit: התיעוד שיוצא מהסקיל הוא ראיה ל-auditor. כל שינוי מלווה ב-evidence.

מי שלא מתאים: פרוטוטיפים מהירים שלא יגיעו לפרודקשן. הסקיל מוסיף overhead שלא נחוץ שם.

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

איך verification-before-completion עזר לי

01

מנע deploy שבור בערב שישי

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

incident preventionFridaytests
02

צילום מסך של פיצ'ר UI חשף בעיית RTL

הסקיל דרש צילום מסך לפני סגירת משימה. הצילום הראה שהטופס מסודר LTR בלי RTL. תיקון של 3 שורות חסך תיקון אחרי הלקוח שיתלונן.

UIRTLscreenshot
03

warnings של דרגה גבוהה תוקנו לפני release

פרויקט Next.js עם 12 deprecation warnings. הסקיל סירב לסגור את המשימה לפני שטופלו. תיקון של 30 דקות חסך עבודה כשהגרסה הבאה של Next.js תחייב.

warningsdeprecationfuture-proof
04

כישלון מדווח כראוי, לא הוסתר

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

honest reportingdebuggingtrust

ארבעת המקרים מראים שהסקיל לא בולם, הוא מאיץ. הוא מונע מתיקונים אחרי המסירה. בשילוב עם TDD, מקבלים שכבת איכות מלאה.

שלושת המקרים שתיארתי משקפים תרחישים שונים שבהם הסקיל מנע באג שהיה מגיע ל-production. במקרים אחרים, הוא חסך לי שעות של «תיקון אחרי הצהרה שגויה». ההצטברות של קצוות אלה לאורך פרויקט שלם היא משמעותית, יכולים להיות 20-30 שעות חיסכון בחודש.

בעבודה אצלי, הסקיל הזה הוא חלק מ-stack של אמינות. בשילוב עם TDD בכתיבה, ועם requesting-code-review בסיום, מקבלים תהליך שלם שמבטיח שמה שמוכרז כ«גמור» באמת גמור. אצל ארגונים שעוברים לעבודה אוטונומית עם סוכנים, הסקיל הזה הוא תנאי סף.

שילובים נוספים: grill-with-docs לתיקוף תוכניות לפני ביצוע.

סיכום

סקיל verification-before-completion הוא הסקיל הקטן שעושה את ההבדל הגדול. הוא מחייב את קלוד קוד לוודא שהקוד שכתב באמת עובד לפני שהוא מצהיר שסיים. בלעדיו, הסוכן נוטה להגיד «זהו, גמרתי» גם כשיש בעיה. עם הסקיל, הוא בודק.

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

הסקיל משלים את סקיל TDD ואת executing-plans, שלושתם מבית Superpowers. בשילוב עם finishing-a-development-branch ועם requesting-code-review מקבלים תהליך closure שלם לפיצ'ר.

בעבודות פיתוח תוכנה ו-אוטומציות AI שאני מבצע, הסקיל הזה הוא חלק מהסטנדרט שאני מטמיע אצל לקוחות. הוא מצמצם את התופעה של «הסוכן אמר שגמר אבל זה לא עבד» בצורה משמעותית, ומעלה את האמון בעבודה אוטונומית.

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

שיתוף הסקיל

שאלות ותשובות

איך מתקינים את הסקיל?

שמרו תחת ~/.claude/skills/verification-before-completion/. הוא יזוהה בכל פעם שהסוכן מתקרב לסיום משימה. אין הגדרות נוספות נדרשות, ההפעלה אוטומטית בכל סשן רלוונטי. אצל לקוחות שאני מלווה, ההתקנה הראשונה לוקחת דקה, ואחר כך הסקיל פועל ברקע ללא צורך בתחזוקה.

האם הוא לא מאט יתר על המידה?

מעט. checkpoints של 30 שניות לכל סיום משימה. אבל זה חוסך שעות תיקונים אחרי. ה-ROI ברור. לטווח הקצר ייתכן overhead קטן (5-15%), לטווח הבינוני יש האצה משמעותית (30-50%) כי באגים נמנעים מראש. בעבודות שאני מבצע ללקוחות, ה-ROI חיובי בתוך 2-3 שבועות מתחילת השימוש.

מה אם אין צוות bash זמין?

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

האם הוא שולח דאטה?

לא. קובץ Markdown מקומי. הבדיקות מורצות מקומית במחשב שלכם, ותוצאותיהן נשארות מקומית. שום מידע על הקוד שלכם לא יוצא לאינטרנט. רישיון MIT. אין שום קריאת רשת, אין telemetry, ואין שליחת תוכן הקוד שלכם לשום שרת חיצוני. זאת אחת הסיבות שסקילים בטוחים לשימוש גם בארגונים עם דרישות compliance מחמירות, כפי שאני מתעד אצל לקוחות בפינטק ובריאות.

איך הוא יודע מה לאמת לפי הפרויקט?

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

האם הוא דורש אינטגרציה עם CI?

לא. הוא רץ מקומית. אם יש CI, הסקיל יכול גם לבדוק שה-pipeline עבר. הסקיל מותאם לעבוד עם הסטנדרטים העדכניים של פלטפורמות ה-CI/CD הנפוצות. אצל לקוחות שאני מלווה, ההטמעה ב-CI מתבצעת בכמה שעות, וכבר מהפעם הראשונה רואים שיפור באיכות התוצרים.

מה קורה אם המשתמש לוחץ 'continue' למרות שהאימות נכשל?

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

האם הוא מתאים לפיתוח backend בלבד?

לא, כל סוג. הוא מותאם לסוג המשימה, ב-UI דורש צילום, ב-API דורש 200 OK, ב-DB דורש שאילתה לאימות. אצלי בעבודות שאני מבצע, האספקט הזה הוא חלק מהסטנדרט שאני מטמיע ללקוחות. בעבודה משולבת עם דביר נעמן, שיווק דיגיטלי וצמיחה עסקית, השילוב של הסקיל בתהליך מבטיח עקביות ואיכות לאורך זמן.

דביר נעמן

על הכותב

דביר נעמן – מומחה שיווק דיגיטלי, SEO ואוטומציות

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