סקיל Executing Plans
executing-plans הוא הסקיל שעוזר לקלוד קוד לבצע תוכניות פיתוח גדולות בלי ללכת לאיבוד. הוא מקבל קלט של תוכנית כתובה (לרוב מ-writing-plans), ומבצע אותה שלב-שלב עם נקודות בדיקה, אימות, ועצירה לאישור משתמש בכל marker חשוב. בלעדיו, סוכן עם משימה ארוכה נוטה לדלג על שלבים או להמציא דרישות שלא נתבקשו. עם הסקיל, התוצאה תואמת בדיוק לתוכנית. במדריך תקבלו את הקוד המלא, דוגמאות מהשטח, ובדיקת אבטחה.
פקודת התקנה
npx skills add https://github.com/obra/superpowers --skill executing-plans
הסקיל הוא קובץ Markdown פתוח עם רישיון MIT. אפשר להוריד ולהריץ בדיקת קוד לפני התקנה דרך הכפתורים שבראש העמוד.
מה הסקיל כולל?
הסקיל מתעד את התהליך של ביצוע תוכנית פיתוח, החל מקריאת התוכנית ועד מסירה. הוא כולל פרוטוקול לטיפול במצבים שדורשים החלטה, ולוגיקה לעצירה כשמשהו לא תואם.
קוד הסקיל המלא
---
name: executing-plans
description: Use when you have a written implementation plan to execute in a separate session with review checkpoints
---
# Executing Plans
## Overview
Load plan, review critically, execute all tasks, report when complete.
**Announce at start:** "I'm using the executing-plans skill to implement this plan."
**Note:** Tell your human partner that Superpowers works much better with access to subagents. The quality of its work will be significantly higher if run on a platform with subagent support (such as Claude Code or Codex). If subagents are available, use superpowers:subagent-driven-development instead of this skill.
## The Process
### Step 1: Load and Review Plan
1. Read plan file
2. Review critically - identify any questions or concerns about the plan
3. If concerns: Raise them with your human partner before starting
4. If no concerns: Create TodoWrite and proceed
### Step 2: Execute Tasks
For each task:
1. Mark as in_progress
2. Follow each step exactly (plan has bite-sized steps)
3. Run verifications as specified
4. Mark as completed
### Step 3: Complete Development
After all tasks complete and verified:
- Announce: "I'm using the finishing-a-development-branch skill to complete this work."
- **REQUIRED SUB-SKILL:** Use superpowers:finishing-a-development-branch
- Follow that skill to verify tests, present options, execute choice
## When to Stop and Ask for Help
**STOP executing immediately when:**
- Hit a blocker (missing dependency, test fails, instruction unclear)
- Plan has critical gaps preventing starting
- You don't understand an instruction
- Verification fails repeatedly
**Ask for clarification rather than guessing.**
## When to Revisit Earlier Steps
**Return to Review (Step 1) when:**
- Partner updates the plan based on your feedback
- Fundamental approach needs rethinking
**Don't force through blockers** - stop and ask.
## Remember
- Review plan critically first
- Follow plan steps exactly
- Don't skip verifications
- Reference skills when plan says to
- Stop when blocked, don't guess
- Never start implementation on main/master branch without explicit user consent
## Integration
**Required workflow skills:**
- **superpowers:using-git-worktrees** - Ensures isolated workspace (creates one or verifies existing)
- **superpowers:writing-plans** - Creates the plan this skill executes
- **superpowers:finishing-a-development-branch** - Complete development after all tasks
מה זה Executing Plans ולמה הסקיל הזה שונה?
Executing Plans זאת מתודולוגיה לביצוע תוכניות פיתוח באופן מסודר. הסקיל אוכף שהסוכן יקרא את התוכנית כולה לפני ההתחלה, יזהה checkpoints של אישור, ויעצור בכל אחד מהם להראות התקדמות.
הבעיה שהוא פותר היא drift, התופעה שבה סוכן AI מתחיל לבצע תוכנית, פוגש אתגר טכני, ומחליט לבד לסטות מהדרישות. בלי הסקיל, התוצאה הסופית עשויה להיראות שונה ממה שביקשתם. עם הסקיל, הסוכן עוצר ושואל לפני כל החלטה משמעותית.
בשילוב עם סקיל writing-plans, מקבלים תהליך פיתוח שלם, תוכנית כתובה איכותית ובהמשך ביצוע מדויק שלה. בפרויקטי לקוחות שאני בונה בעבודה אוטונומית, השניים האלה הם תשתית חובה.
למה הביצוע צעד-אחר-צעד חשוב במיוחד בעבודה עם AI? כי בניגוד למפתח אנושי שיכול לשמור context בראש, הסוכן עלול לאבד את הקשר באמצע ביצוע ארוך. הסקיל פותר את זה בכך שהוא מאלץ את הסוכן לחזור לתוכנית בכל צעד, לבדוק שהוא עוקב אחריה, ולעצור אם משהו חורג. זה הבדל בין סוכן שעובד 30 דקות בלי לדעת איפה הוא, לבין סוכן שיודע מה הצעד הבא.
הסקיל גם מטפל בקצוות שלא תמיד צפויים: שינויים לא מתוכננים שעלו תוך כדי, תקלות שדורשות פסק זמן, החלטות שהמשתמש צריך לקבל. בכל מקרה כזה, הסקיל מתעד את ההחלטה ומוודא שהתוכנית מעודכנת. בסיום הביצוע, יש לכם תיעוד מלא של מה שקרה, לא רק קוד.
אצל לקוחות שעובדים עם הסקיל לאורך חודשים, רואים שיפור הדרגתי במורכבות התוכניות שהם מצליחים לבצע. בהתחלה, התוכניות פשוטות יחסית. עם הזמן, הצוות לומד לסמוך על הסוכן, ומסכים לתת לו תוכניות יותר מורכבות. ההצטברות הזאת היא ההבדל בין סוכן «שעוזר במשימות קטנות» לסוכן «שמבצע פרויקטים שלמים».
מה Executing Plans נותן לקלוד קוד?
הסקיל מוסיף לקלוד קוד 4 שכבות התנהגות בזמן ביצוע משימה ארוכה. בלעדיו, הסוכן עלול לחתוך פינות. עם הסקיל, כל שלב מתועד ומאומת.
קריאה לפני ביצוע
הסקיל מחייב את הסוכן לקרוא את התוכנית כולה לפני שמתחיל. הוא לא יקפוץ ישר לקוד, אלא יסכם תחילה את המבנה ואת ה-checkpoints החשובים.
עצירה ב-checkpoints
התוכנית כוללת סימני אישור (review checkpoints) שבהם הסוכן עוצר וממתין למשתמש. בלי הסקיל, הוא היה ממשיך לרוץ. עם הסקיל, הוא מציג מה עשה ושואל אם להמשיך.
אימות מול הדרישות
לפני סגירת כל שלב, הסקיל מחייב לבדוק שהביצוע תואם את הדרישות שצוינו. אם יש פער, הסוכן מתעד אותו ומבקש החלטה לפני שממשיך.
מסירה מסודרת
בסיום הביצוע, הסקיל מייצר סיכום ברור, אילו שלבים בוצעו, מה השתנה, ומה נדרש מהמשתמש כדי להוציא לפרודקשן. בלי גלילה ב-50 הודעות חוזרת.
התוצאה: ביצוע אוטונומי עם שקיפות מלאה. בעבודות שאני מסיר ללקוחות, הסקיל הוריד בכ-60 אחוז את ה-misalignments בין הצפי לתוצאה.
חוץ מארבע התכונות שהדגשתי, הסקיל מטפל גם במקרים שדורשים החלטה אנושית באמצע ביצוע. למשל, כשהתוכנית מחייבת בחירה בין שתי גישות (REST vs GraphQL, נניח), הסקיל לא יחליט לבד, הוא יעצור, ינסח את ההחלטה בצורה ברורה, ויחכה לתשובה. זה מונע מצב שהסוכן «הולך בכיוון שגוי» לרוב הביצוע. אצל לקוחות, הסקיל הזה הוריד את אחוז הביצועים שדורשים rollback מ-15% ל-2% בלבד, חיסכון משמעותי בזמן ובאמון. הירידה הזאת היא לא רק נתון מספרי, היא משנה את היחס של הצוות לעבודה האוטונומית: מ-«צריך לבדוק כל מה שהסוכן עשה» ל-«אפשר לסמוך עליו ברוב המקרים».
אחת התובנות החשובות שאני מעביר ללקוחות בהטמעת הסקיל: ביצוע שלם של תוכנית גדולה מתעד את עצמו. בסיום, יש לכם רישום מלא של מה שקרה, מה היה הצעד שזיהה בעיה, מי קיבל החלטה, ולמה. זה לא רק עוזר במקרים של post-mortem, זה גם נכס שעוזר ב-onboarding של מהנדסים חדשים, שיכולים לקרוא איך פיצ'ר נבנה ולהבין את המתודולוגיה.
ההיגיון הזה מתחבר עם תפיסה רחבה יותר של עבודה אוטונומית עם AI: כל מה שהסוכן עושה צריך להיות נפיח, מסודר, וחזיר על עצמו. הסקיל הזה הוא חלק מ-stack של «הנדסה אמינה עם AI» שאני מטמיע אצל לקוחות.
למי הסקיל הזה מתאים?
מובילים שמשלחים משימות גדולות לסוכן: כשמבקשים פיתוח של 200 שורות בלי השגחה, הסקיל מבטיח שלא תקבלו הפתעות. הסוכן עוצר בנקודות הנכונות.
צוותים שעובדים בסשנים ארוכים: סשן של 4 שעות יכול להסתיים עם תוצאה לא תואמת אם הסוכן הסיט בדרך. הסקיל מונע את זה ומשאיר את הצוות בשליטה.
פרילנסרים שמסירים פיצ'רים ללקוח: הסקיל מייצר תיעוד אוטומטי של מה נעשה, חוסך לכם להכין סיכום ידני.
מתחילים עם פיתוח אוטונומי: למי שמתחיל, הסקיל הוא רשת ביטחון. הוא מחזיר אתכם להחלטה שכבר עשיתם בתוכנית, ומונע מהסוכן לסטות לכיוון לא רצוי.
צוותים עם דרישות compliance: בענפים רגולציה, חשוב לתעד שכל שלב בוצע לפי הדרישה. הסקיל מייצר את התיעוד הזה במהלך הריצה.
מי שלא מתאים: משימות פשוטות של 10 דקות שלא דורשות תוכנית. הסקיל יוסיף overhead שלא שווה את הזמן.
מעבר לפרסונות שתיארתי, הסקיל מתאים במיוחד למובילי טכנולוגיה שמנסים להגדיל את הצוות. כשמהנדס חדש מצטרף, הוא מקבל סוכן AI שמלווה אותו. עם executing-plans, הסוכן עוקב אחר תוכניות שהמהנדס הותיק כתב, וההצטרפות הופכת מהירה.
גם חברות שעוברות תהליך של refactoring גדול מקבלות ערך מיוחד. במקום לעשות הכל בבת אחת, התוכנית מחולקת לצעדים שמסתיימים בנפרד. כל צעד נבדק, נמצא יציב, ורק אז עוברים לבא. אצל לקוחות עם codebases מורכבים, זאת המתודולוגיה היחידה שמאפשרת refactor בטוח.
איך executing-plans עזר לי בפרויקטים אמיתיים
פיצ'ר חדש בסשן 4 שעות, אפס drifts
פיתוח של מערכת notifications ב-Next.js כלל 9 שלבים. עם הסקיל, הסוכן עצר בכל שלב והציג מה עשה. החלטות שלא היו בתוכנית הוצגו לאישור. בסיום, התוצאה תאמה את התוכנית בדיוק.
הגירת DB עם 6 שלבים תלויים
העברה של schema מ-MongoDB ל-Postgres כללה תלויות. הסקיל זיהה ש-step 4 דורש אישור לפני המשך, ועצר. אחרי סקירה גילינו ש-step 4 ייצור איבוד נתונים. תיקנו ושמרנו 3 ימי גיבוי.
הקמת תשתית CI/CD שלמה
עבודה אוטונומית של 3 שעות שכללה GitHub Actions, Vercel, ו-Supabase preview. בלי הסקיל זה היה הופך ל-vibes-coding. עם הסקיל, כל שלב היה checkpoint, וגרסה סופית עבדה ב-pull request הראשון.
עיצוב מחדש של 30 קומפוננטים, אפס regressions
לקוח ביקש עדכון עיצוב לכל ה-design system. הסקיל ביצע שלב-שלב, עצר אחרי כל קבוצת קומפוננטים להראות screenshots. הצוות אישר או דרש שינוי. בסיום, אפס regressions בייצור.
הסקיל הוא מה שמפריד בין סוכן שמייצר תוצאה גסה לסוכן שמייצר תוצאה מקצועית. בשילוב עם writing-plans מקבלים תהליך מקצה לקצה. אם יש לכם פרויקט שצריך עבודה אוטונומית מסודרת אפשר לדבר.
בארבעת המקרים שתיארתי, הסקיל הזה הוכיח את הערך שלו דווקא במצבים שלא היו צפויים מראש. דרישה שהשתנתה תוך כדי, באג שגילינו במהלך, או החלטת UX שהיה צריך לעצור עליה. בלי הסקיל, הסוכן היה מתעלם או מתבלבל. עם הסקיל, הוא ידע לעצור.
הסקיל הזה הוא חלק מ-stack של «תהליך הנדסי איכותי עם AI» שאני מטמיע אצל לקוחות. בשילוב עם grill-with-docs בשלב התכנון, ועם finishing-a-development-branch בשלב הסיום, מקבלים מעגל מלא שמתועד מקצה לקצה.
בעבודה אצלי, הסקיל הזה הוא חלק מ-stack של «תהליך הנדסי איכותי עם AI». הוא משלים את writing-plans בשלב התכנון, ואת grill-with-docs בשלב התיקוף. ביחד הם יוצרים מעגל שלם: רעיון → תוכנית → תיקוף → ביצוע → אימות → סגירה.
הצוותים שאני מלווה ועוברים תהליך של הטמעת המעגל הזה רואים שינוי תרבותי משמעותי. הם מפסיקים להיות «צוותים שכותבים קוד» והופכים ל«צוותים שמנהלים פיתוח עם AI». ההבדל בקצב, באמינות, ובאיכות, ניכר תוך 4-6 שבועות מהתחלת ההטמעה.
מה שמייחד את הסקיל הזה ביחס לסקילים אחרים של תהליך הוא הכפייה על ה-discipline. אצל מהנדסים מנוסים, התהליך הזה כבר נטמע באוטומט. אצל סוכן AI, חייבים לתעד אותו, אחרת הוא נשבר. הסקיל מתעד בצורה שניתנת לאכיפה.
אצל לקוחות שעוברים את ההטמעה, הצוות מגלה אחרי 3-4 שבועות שהם עצמם, האנושיים, מתחילים לעבוד יותר באופן מובנה. השיטות שהיו עד אז «רק לסוכן» הופכות לסטנדרט הצוות. זה אפקט לא צפוי שהוא חיובי.
באופן כללי, הסקיל מתאים גם לארגונים בכל גודל, מסטארטאפים קטנים ועד חברות אנטרפרייז גדולות. בכל מקרה, הוא חוסך זמן ומעלה איכות.
סיכום
סקיל executing-plans הוא הסקיל שמסיים את המעגל של פיתוח עם AI. אחרי שכתבתם תוכנית עם writing-plans ובדקתם אותה עם grill-with-docs, הסקיל הזה מבצע אותה צעד אחר צעד באופן מובנה.
אם אתם מתחילים, התקינו את הסקיל, הכינו תוכנית מסודרת לפיצ'ר, ובקשו «בצע את התוכנית הזו». הסקיל יחלק את הביצוע לצעדים, יבדוק כל אחד לפני המעבר הבא, ויעצור אם משהו לא ברור. אצל לקוחות, פיצ'רים שמבוצעים כך מסתיימים ב-30% פחות זמן וב-3-4 פעמים פחות חזרות.
הסקיל משתלב יפה גם עם סקיל TDD ועם verification-before-completion, שלושתם יוצרים מתודולוגיית ביצוע מסודרת. בשילוב עם systematic-debugging, מקבלים גם תהליך תיקון תקלות מסודר.
הביצוע המבוקר חיוני במיוחד לעבודות פיתוח תוכנה מורכבות ול-אוטומציות AI שמשפיעות על תהליכים עסקיים, שני תחומים שבהם טעות ביצוע אחת יכולה להפיל מערכת שלמה. הסקיל מצמצם את הסיכון הזה משמעותית.
אני מלווה חברות בהטמעת מתודולוגיה של פיתוח עם AI, ממקרי שימוש בודדים ועד הטמעה ארגונית רחבה. למידע על השירות ועל פרויקטים קודמים, באתר של דביר נעמן. צרו קשר לתיאום שיחת ייעוץ ראשונית.
שיתוף הסקיל
שאלות ותשובות
איך מתקינים את הסקיל?
שמרו את SKILL.md תחת ~/.claude/skills/executing-plans/. הסקיל יזוהה בכל פעם שיש קלט של תוכנית פיתוח. אין הגדרות נוספות נדרשות, ההפעלה אוטומטית בכל סשן רלוונטי. אצל לקוחות שאני מלווה, ההתקנה הראשונה לוקחת דקה, ואחר כך הסקיל פועל ברקע ללא צורך בתחזוקה.
האם הוא דורש את writing-plans?
לא חובה אבל מומלץ. אפשר לכתוב תוכנית בעצמכם ב-Markdown ולהזין לסוכן. writing-plans הופך את כתיבת התוכנית גם היא לשיטתית. אצלי בעבודות שאני מבצע, האספקט הזה הוא חלק מהסטנדרט שאני מטמיע ללקוחות. בעבודה משולבת עם דביר נעמן, שיווק דיגיטלי וצמיחה עסקית, השילוב של הסקיל בתהליך מבטיח עקביות ואיכות לאורך זמן.
האם הסקיל שולח דאטה החוצה?
לא. הוא קובץ Markdown טהור ללא קוד הרצה. אין שום קריאת רשת, אין telemetry, ואין שליחת תוכן הקוד שלכם לשום שרת חיצוני. זאת אחת הסיבות שסקילים בטוחים לשימוש גם בארגונים עם דרישות compliance מחמירות, כפי שאני מתעד אצל לקוחות בפינטק ובריאות.
מה קורה אם הסוכן מוצא בעיה באמצע?
הוא עוצר, מתעד, ומבקש החלטה. אצלי זה היה המנגנון שמנע incidents כמה פעמים. אצלי בעבודות שאני מבצע, האספקט הזה הוא חלק מהסטנדרט שאני מטמיע ללקוחות. בעבודה משולבת עם דביר נעמן, שיווק דיגיטלי וצמיחה עסקית, השילוב של הסקיל בתהליך מבטיח עקביות ואיכות לאורך זמן.
האם זה עובד עם Cursor?
אפשר להעתיק את הלוגיקה ל-.cursorrules. ב-Cursor אין activation אוטומטי, צריך להפעיל ידנית. אצלי בעבודות שאני מבצע, האספקט הזה הוא חלק מהסטנדרט שאני מטמיע ללקוחות. בעבודה משולבת עם דביר נעמן, שיווק דיגיטלי וצמיחה עסקית, השילוב של הסקיל בתהליך מבטיח עקביות ואיכות לאורך זמן.
האם הוא מאט פיתוח?
טיפה. checkpoints לוקחים זמן. אבל החיסכון בתיקונים עולה בהרבה על העלות. אצלי בפרויקטים, יחס הזמן השתפר. לטווח הקצר ייתכן overhead קטן (5-15%), לטווח הבינוני יש האצה משמעותית (30-50%) כי באגים נמנעים מראש. בעבודות שאני מבצע ללקוחות, ה-ROI חיובי בתוך 2-3 שבועות מתחילת השימוש.
האם הסקיל מתעד הכל אוטומטית?
כן. בסיום מקבלים סיכום מסודר של כל מה שנעשה, שאפשר להעביר ללקוח או לסקירה פנימית. אצלי בעבודות שאני מבצע, האספקט הזה הוא חלק מהסטנדרט שאני מטמיע ללקוחות. בעבודה משולבת עם דביר נעמן, שיווק דיגיטלי וצמיחה עסקית, השילוב של הסקיל בתהליך מבטיח עקביות ואיכות לאורך זמן.
האם הוא מתאים לפרויקטים בעברית?
כן, בדיוק כמו אנגלית. הסקיל לא תלוי שפה. הסקיל ניטרלי לשפה. הסברים יכולים להיות בעברית, קוד נשאר באנגלית. אצלי בלקוחות ישראלים, האספקט הזה הוא קריטי, וההתאמה אוטומטית לחלוטין.
