התוסף ל-Claude Code שמתכנתים בחו"ל עובדים איתו כל יום. מה הוא עושה, מתי הוא שווה את זה (ומתי ממש לא), ואיך משתמשים בכל אחד מ-36 הכלים שבתוכו - בשפה פשוטה, בלי להיות מתכנתים.
תחשבו איך אתם עובדים עם קלוד היום. מבקשים משהו, והוא מיד מתחיל לכתוב קוד בלי להבין עד הסוף מה רציתם. יוצאות טעויות, אתם מתקנים. ובפעם הבאה? הוא עושה בדיוק את אותן טעויות, כי הוא לא זוכר מה למד.
קופץ ישר לקוד. כל פרויקט מתחיל מאפס. אותן טעויות חוזרות. ככל שהפרויקט גדל, כל שינוי נהיה קשה יותר.
קודם מבין, אחר כך מתכנן, ורק אז בונה. בסוף כל משימה הוא כותב לעצמו מה למד. כל משימה הופכת את הבאה לקלה יותר.
הרעיון בשורה אחת: 80% מהזמן הולכים על תכנון ובדיקה, ורק 20% על כתיבת הקוד עצמו. נשמע הפוך, אבל ככה עובדים הצוותים הכי מהירים.
התוסף נבנה בחברת Every האמריקאית, והוא חינמי וקוד פתוח. יש בו 36 סקילים (כלים), והוא עובד גם ב-Cursor וב-Codex, לא רק ב-Claude Code.
זה החלק שרוב האנשים מפספסים. התוסף הזה הוא מכונה כבדה. הוא שואל שאלות, מתכנן, בודק ומתעד. על פרויקט גדול זה חוסך לכם שעות. על משימה קטנה זה סתם מאט אתכם.
• אפליקציה שאתם בונים מאפס
• אתר או מערכת שתמשיכו לפתח חודשים
• פיצ'ר גדול עם הרבה חלקים (תשלומים, התחברות, הרשאות)
• באג שחוזר שוב ושוב
• כל דבר שתחזרו אליו גם בעוד חודש
• לשנות צבע של כפתור
• לתקן טקסט או טעות כתיב
• שאלה מהירה
• סקריפט חד-פעמי שתזרקו אחרי שימוש
• כל דבר שלוקח פחות מ-10 דקות
כלל אצבע: תשאלו את עצמכם "אני אחזור לפרויקט הזה?". אם כן - תשתמשו בתוסף, כי כל לקח שנשמר יחסוך לכם זמן בפעם הבאה. אם לא - תבקשו מקלוד ישירות ותמשיכו הלאה.
פותחים את Claude Code ומדביקים אחת אחרי השנייה:
אומרים לקלוד מאיפה להוריד אותו.
אחרי ההתקנה כדאי לסגור ולפתוח את Claude Code מחדש.
בתוך תיקיית הפרויקט שלכם. הוא בודק שהכל מותקן ויוצר קובץ הגדרות קטן.
זה הלב של התוסף. במקום "תבנה לי" ולקוות לטוב, עוברים שלב אחרי שלב. בדוגמה: אתם רוצים להוסיף לאתר של סטודיו פילאטיס מערכת הזמנת שיעורים.
הוא שואל אתכם שאלות, אחת בכל פעם. "אפשר לבטל הזמנה? עד כמה זמן לפני?", "משלמים מראש או בסטודיו?". הוא מאתגר את ההנחות שלכם, ומציע 2-3 דרכים לבנות עם המלצה על הטובה ביותר. בסוף - מסמך דרישות ברור.
הוא לומד את הפרויקט שלכם ומפרק את העבודה למשימות קטנות. לכל משימה: באילו קבצים היא נוגעת, מה צריך לבדוק שעובד, ומה יכול להשתבש. אחר כך הוא עובר על התוכנית בעצמו ומחזק את החלקים החלשים.
משימה אחרי משימה, לפי התוכנית. הוא בודק שכל חלק עובד לפני שהוא ממשיך לחלק הבא.
עובר על הקוד שנכתב ומנקה אותו: פחות כפילויות, יותר ברור. הקוד עושה בדיוק את אותו הדבר, רק מסודר יותר.
כמו לתת לכמה מומחים לעבור על הקוד במקביל: אחד מחפש באגים, אחד בודק אבטחה, אחד בודק מהירות, אחד בודק שיש בדיקות. הוא מציג לכם את מה שמצא, ומתקן רק כשאתם מאשרים.
זה כל הסוד, ויש לו פרק משלו למטה 👇
מה כותבים ב-brainstorm? אפשר לכתוב את הבקשה בעברית. הדוגמאות כאן באנגלית רק כדי שיהיה נוח להעתיק.
Compound זה "ריבית דריבית". בדיוק כמו בכסף: כל לקח שנשמר מרוויח ריבית על כל מה שתבנו אחר כך.
בסוף משימה, הוא כותב מסמך קצר בתוך הפרויקט: מה הייתה הבעיה, מה לא עבד, מה עבד, ואיך נמנעים מזה בפעם הבאה. בפעם הבאה שאתם מתכננים משהו, הוא קורא את המסמכים האלה לפני שהוא מתחיל.
באג מסובך. חצי שעה של חקירה עד שמוצאים את הפתרון.
הוא מוצא את המסמך שכתב, ופותר את זה בשתי דקות.
לא כל תיקון שווה שמירה. שומרים רק לקח שלא ברור מהקוד עצמו, שיישאר רלוונטי גם בעוד חודשים, ושבלעדיו תחזרו על אותה טעות. תיקון טעות כתיב? לא צריך. הסקיל עצמו יודע לדלג כשאין מה לשמור.
לא רוצים לאשר כל שלב? /lfg מריץ את כל הלולאה לבד: תכנון, בנייה, סידור, ביקורת, תיקונים, שמירת לקחים ובדיקה בדפדפן. אם הפרויקט מחובר ל-GitHub, הוא גם מעלה ופותח בקשת מיזוג (PR).
כשהדרישות ברורות (אחרי brainstorm), ואתם סומכים עליו שיביא את זה עד הסוף בלי לעצור אתכם.
כשאתם רוצים לאשר את התוכנית, את הקוד או את הביקורת בעצמכם. LFG לא עוצר לשאול, אז במקרה כזה תריצו את השלבים אחד-אחד.
רגוע: LFG לא ממזג את הקוד לגרסה הראשית בלי אישור שלכם. ההחלטה הסופית תמיד נשארת אצלכם.
ראיתם את 7 הגדולים. הנה כל השאר, מחולקים לפי מה הם עושים. לחצו על כל אחד כדי לראות מה הוא עושה, מתי להשתמש בו, ואת הפקודה.
לא צריך ללמוד את כולם. 90% מהזמן תשתמשו בלולאה וב-LFG. את השאר שולפים כשצריך.
הם לא שלב בלולאה, אבל הם מזינים אותה: מאיפה מגיעות המשימות, ואיך הזיכרון נשאר נקי.
כותב איתכם מסמך אסטרטגיה אחד לפרויקט: למי המוצר, מה המטרה, ומה חשוב עכשיו. כל שאר הכלים קוראים את המסמך הזה לפני שהם מתכננים, כדי שלא יבנו דברים שלא מתאימים לכיוון.
מתי: כשאתם מתחילים מוצר חדש, או משנים כיוון.
דוח קצר על מה קרה במוצר בתקופה האחרונה (24 שעות, שבוע): כמה משתמשים, שגיאות, ביצועים ומה צריך לטפל בו.
מתי: כשהמוצר כבר באוויר ויש לו משתמשים.
סורק את המקומות שבהם הלקוחות משאירים פידבק (Slack, GitHub, ובניסוי גם מייל), מאשר להם שראה, והופך הכל לתוכנית עבודה אחת שאפשר להריץ.
מתי: כשמגיע הרבה פידבק מלקוחות ואתם לא רוצים לפספס כלום.
עובר על כל הלקחים ששמרתם לאורך הזמן, ובודק מה עדיין נכון. משאיר, מעדכן, מאחד כפילויות, או מוחק מה שכבר לא רלוונטי.
מתי: פעם בכמה זמן, כשהפרויקט השתנה הרבה ואתם חוששים שחלק מהלקחים כבר לא נכונים.
לא משתמשים בהם כל יום. שולפים אותם כשצץ צורך מסוים.
כשאין לכם עדיין רעיון. הוא מציע כיוונים ששווה לבדוק בפרויקט שלכם, ומסנן בעצמו את החלשים.
מתי: לפני הבריינסטורם, כשאתם לא בטוחים מה לבנות הלאה.
בונה כמה פתרונות שונים לאותה בעיה, כל אחד בנפרד, משווה ביניהם ובוחר את המנצח. לפעמים התכנון מפעיל אותו לבד כשיש החלטה יקרה שקשה להחזיר אחורה.
מתי: כשיש כמה דרכים טובות ואתם לא בטוחים איזו לבחור.
נותן לכם עמדה ברורה: "כדאי" או "לא כדאי", על סמך מה שקורה בפרויקט שלכם. אפשר גם לבקש ממנו להתייעץ עם מודלים אחרים ולהשוות תשובות.
מתי: "להשתמש בכלי הזה או לא?", "איזו גישה עדיפה?".
מסביר איך משהו בפרויקט עובד ולמה הוא בנוי ככה, עם הוכחות מהקוד עצמו.
מתי: כשאתם נכנסים לחלק בפרויקט שאתם לא מכירים, לפני שאתם משנים אותו.
בונה גרסה זמנית וזריזה כדי שתוכלו לראות ולהרגיש איך משהו יעבוד, לפני שבונים אותו באמת.
מתי: כשטעות בהחלטה תהיה יקרה לתקן, ושיחה לבד לא מספיקה כדי להחליט.
לא מנחש תיקונים. מחפש את שורש הבעיה, מוכיח אותו, ורק אז מציע תיקון.
מתי: כשמשהו שבור, איטי, או שבאג חוזר שוב ושוב.
כמו ביקורת קוד, רק על תוכנית או מסמך דרישות. מוצא חורים לפני שמתחילים לבנות.
מתי: אחרי שכתבתם תוכנית גדולה, ולפני שמתחילים לבנות לפיה.
מודד מספר אחד (מהירות, עלות, ציון), מנסה שינויים, שומר רק את מה שבאמת שיפר ומבטל את השאר.
מתי: כשמשהו עובד, אבל אתם רוצים שהוא יהיה מהיר או זול יותר.
מכוונן אוסף סקילים למודל חדש, עם מדידות לפני ואחרי. דורש מערכת בדיקות מוכנה.
מתי: רק אם אתם כותבים סקילים בעצמכם ויצא מודל חדש. רוב האנשים לא יצטרכו אותו.
אם אתם עובדים עם GitHub, אלה חוסכים את כל העבודה הטכנית של שמירה והעלאה.
שומר את השינויים שלכם כגרסה ב-Git עם הודעה ברורה שמסבירה מה השתנה. לא מעלה כלום לרשת.
מתי: בכל פעם שסיימתם חלק שעובד ורוצים נקודת שמירה.
שומר, מעלה ל-GitHub ופותח בקשת מיזוג (PR) עם תיאור מסודר של מה שנעשה.
מתי: כשהפיצ'ר מוכן ואתם רוצים להעלות אותו.
משגיח על בקשת המיזוג לאורך זמן: עונה להערות, ואם בדיקה אוטומטית נכשלת, מנסה לתקן. לא ממזג לבד.
מתי: כשפתחתם PR ולא רוצים לשבת ולחכות לו.
עובר על כל ההערות שהשאירו לכם על ה-PR, מתקן, ועונה לכל אחת.
מתי: כשמישהו (או בוט) השאיר לכם הערות לתקן.
פותח עותק נפרד של הפרויקט כדי שתוכלו לעבוד על כמה דברים במקביל בלי שיתנגשו.
מתי: כשאתם רוצים לבנות פיצ'ר חדש בלי לגעת במה שכבר עובד.
קלוד לא רק בונה, הוא גם פותח את המוצר ובודק אותו כמו משתמש.
פותח דפדפן אמיתי ובודק את העמודים ששיניתם, כמו משתמש.
מתי: אחרי שינוי באתר או באפליקציית ווב.
עובר על המוצר כמו משתמש אמיתי, מתקן לבד תקלות קטנות שהוא מוצא, וכותב דוח.
מתי: לפני שמשחררים פיצ'ר גדול למשתמשים.
פותח את האתר בדפדפן ואתם מלטשים איתו יחד בשיחה: "תגדיל פה", "תזיז את זה".
מתי: כשפיצ'ר כבר עובד, ורק צריך שייראה ויורגש טוב יותר.
בונה ובודק אפליקציית iOS בסימולטור, עם צילומי מסך.
מתי: רק אם אתם בונים אפליקציה לאייפון.
הכלים הקטנים שתגלו שאתם משתמשים בהם הכי הרבה.
כותב סיכום של איפה עצרתם, כדי שסשן חדש (או אדם אחר) ימשיך בדיוק מאותה נקודה.
מתי: בסוף יום עבודה, או כשהשיחה ארוכה מדי ורוצים להתחיל נקייה.
מפרסם תוכנית או מסמך ב-Proof, עורך מסמכים אונליין, כדי שאחרים יוכלו לקרוא ולהגיב.
מתי: כשאתם רוצים להראות תוכנית ללקוח או לשותף.
כותב טיוטות להכרזה על פיצ'ר חדש: פוסט, ניוזלטר, לינקדאין. רק טיוטות, לא מפרסם לבד.
מתי: אחרי שהשקתם משהו ורוצים לספר עליו.
בודק שהכל מותקן ועובד, ויוצר קובץ הגדרות לפרויקט.
מתי: פעם אחת, מיד אחרי ההתקנה, בכל פרויקט חדש.
לא הבנתם מה קלוד כתב? הוא מסביר את ההודעה האחרונה בשפה פשוטה.
מתי: כל פעם שקלוד זורק עליכם מילים שאתם לא מכירים.
משכתב טקסט כך שלא יישמע כמו שנכתב ב-AI, בלי לאבד אף עובדה.
מתי: לתיעוד, למיילים, לכל טקסט שאנשים יקראו.
לוקח הקלטת מסך וקול של מישהו שמשתמש במוצר (בכלי Riffrec) והופך אותה לרשימת באגים ודרישות.
מתי: כשלקוח הקליט לכם מה לא עובד לו.
"מפעילים ידנית" אומר שקלוד לא יפעיל את הסקיל לבד - רק כשאתם כותבים את הפקודה. את כל השאר הוא יכול להפעיל בעצמו כשהוא מזהה שהם מתאימים.
שינוי צבע של כפתור לא צריך brainstorm ותוכנית. שמרו את התוסף לפרויקטים שאתם ממשיכים לבנות.
זה השלב שהכי מפתה לדלג עליו, והוא החשוב ביותר. בריינסטורם טוב = תוכנית טובה = פחות תיקונים.
בלי השלב האחרון, זה סתם עוד דרך לכתוב קוד. הלקחים השמורים הם מה שהופך את העבודה לקלה יותר עם הזמן.
בונוס: /ce-plan עובד גם על דברים שהם לא קוד - תוכנית לימודים, תכנון אירוע, השקה של מוצר. תנסו.
בליווי האישי אנחנו בונים יחד AI OS שלם סביב העסק שלכם - תוכן, לידים, תפעול - שעובד בשבילכם גם כשאתם לא ליד המחשב.
15 דקות ייעוץ בחינם