סקיל Verification Before Completion
verification-before-completion הוא הסקיל שמכריח את קלוד קוד לבדוק את עצמו לפני שמסיים משימה. בלעדיו, הסוכן נוטה לדווח 'בוצע' גם כאשר ה-build נכשל, הטסטים אדומים, או הקוד לא הועלה כראוי. עם הסקיל, כל סגירת משימה דורשת ראיה אובייקטיבית, command output, טסט ירוק, או build שעבר. אצלי הסקיל הזה הציל אותי מ-deploys שבורים פעמיים בחודש האחרון. במדריך תקבלו את הקוד המלא, רשימת הבדיקות הקנונית, ודוגמאות מהשטח.
פקודת התקנה
npx skills add https://github.com/obra/superpowers --skill verification-before-completion
הסקיל הוא קובץ Markdown פתוח עם רישיון MIT. אפשר להוריד ולהריץ בדיקת קוד לפני התקנה.
מה הסקיל כולל?
הסקיל מתעד את כללי האימות שסוכן חייב לעבור לפני שמדווח על סיום משימה. הוא כולל רשימת בדיקות לפי סוג משימה, וטעם של איך לזהות ראיה תקפה.
קוד הסקיל המלא
---
name: verification-before-completion
description: Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
---
# Verification Before Completion
## Overview
Claiming work is complete without verification is dishonesty, not efficiency.
**Core principle:** Evidence before claims, always.
**Violating the letter of this rule is violating the spirit of this rule.**
## The Iron Law
```
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
```
If you haven't run the verification command in this message, you cannot claim it passes.
## The Gate Function
```
BEFORE claiming any status or expressing satisfaction:
1. IDENTIFY: What command proves this claim?
2. RUN: Execute the FULL command (fresh, complete)
3. READ: Full output, check exit code, count failures
4. VERIFY: Does output confirm the claim?
- If NO: State actual status with evidence
- If YES: State claim WITH evidence
5. ONLY THEN: Make the claim
Skip any step = lying, not verifying
```
## Common Failures
| Claim | Requires | Not Sufficient |
|-------|----------|----------------|
| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
| Linter clean | Linter output: 0 errors | Partial check, extrapolation |
| Build succeeds | Build command: exit 0 | Linter passing, logs look good |
| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
| Regression test works | Red-green cycle verified | Test passes once |
| Agent completed | VCS diff shows changes | Agent reports "success" |
| Requirements met | Line-by-line checklist | Tests passing |
## Red Flags - STOP
- Using "should", "probably", "seems to"
- Expressing satisfaction before verification ("Great!", "Perfect!", "Done!", etc.)
- About to commit/push/PR without verification
- Trusting agent success reports
- Relying on partial verification
- Thinking "just this once"
- Tired and wanting work over
- **ANY wording implying success without having run verification**
## Rationalization Prevention
| Excuse | Reality |
|--------|---------|
| "Should work now" | RUN the verification |
| "I'm confident" | Confidence ≠ evidence |
| "Just this once" | No exceptions |
| "Linter passed" | Linter ≠ compiler |
| "Agent said success" | Verify independently |
| "I'm tired" | Exhaustion ≠ excuse |
| "Partial check is enough" | Partial proves nothing |
| "Different words so rule doesn't apply" | Spirit over letter |
## Key Patterns
**Tests:**
```
✅ [Run test command] [See: 34/34 pass] "All tests pass"
❌ "Should pass now" / "Looks correct"
```
**Regression tests (TDD Red-Green):**
```
✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
❌ "I've written a regression test" (without red-green verification)
```
**Build:**
```
✅ [Run build] [See: exit 0] "Build passes"
❌ "Linter passed" (linter doesn't check compilation)
```
**Requirements:**
```
✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
❌ "Tests pass, phase complete"
```
**Agent delegation:**
```
✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
❌ Trust agent report
```
## Why This Matters
From 24 failure memories:
- your human partner said "I don't believe you" - trust broken
- Undefined functions shipped - would crash
- Missing requirements shipped - incomplete features
- Time wasted on false completion → redirect → rework
- Violates: "Honesty is a core value. If you lie, you'll be replaced."
## When To Apply
**ALWAYS before:**
- ANY variation of success/completion claims
- ANY expression of satisfaction
- ANY positive statement about work state
- Committing, PR creation, task completion
- Moving to next task
- Delegating to agents
**Rule applies to:**
- Exact phrases
- Paraphrases and synonyms
- Implications of success
- ANY communication suggesting completion/correctness
## The Bottom Line
**No shortcuts for verification.**
Run the command. Read the output. THEN claim the result.
This is non-negotiable.
מה זה 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 עזר לי
מנע deploy שבור בערב שישי
לקוח ביקש פיצ'ר דחוף לפני סוף השבוע. הסוכן השלים את הפיצ'ר אבל הסקיל זיהה שטסט אחד נכשל בשקט. הוא לא דיווח 'בוצע'. תיקנו ב-15 דקות. בלי הסקיל, היינו מעלים שבור.
צילום מסך של פיצ'ר UI חשף בעיית RTL
הסקיל דרש צילום מסך לפני סגירת משימה. הצילום הראה שהטופס מסודר LTR בלי RTL. תיקון של 3 שורות חסך תיקון אחרי הלקוח שיתלונן.
warnings של דרגה גבוהה תוקנו לפני release
פרויקט Next.js עם 12 deprecation warnings. הסקיל סירב לסגור את המשימה לפני שטופלו. תיקון של 30 דקות חסך עבודה כשהגרסה הבאה של Next.js תחייב.
כישלון מדווח כראוי, לא הוסתר
הסוכן ניסה לפתור באג ב-3 ניסיונות שונים. בלי הסקיל היה אומר 'בוצע' בניסיון רביעי. עם הסקיל הוא דיווח 'התקשיתי, הנה מה שניסיתי, אצטרך עזרה'. החיסכון בזמן: שעה של דיבוג של תוצאה שגויה.
ארבעת המקרים מראים שהסקיל לא בולם, הוא מאיץ. הוא מונע מתיקונים אחרי המסירה. בשילוב עם 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 דורש שאילתה לאימות. אצלי בעבודות שאני מבצע, האספקט הזה הוא חלק מהסטנדרט שאני מטמיע ללקוחות. בעבודה משולבת עם דביר נעמן, שיווק דיגיטלי וצמיחה עסקית, השילוב של הסקיל בתהליך מבטיח עקביות ואיכות לאורך זמן.