Lovable מוסיפה לפלטפורמת בניית האפליקציות שלה פיצ’ר חדש בשם Workspace Skills, שמאפשר למשתמשים ולצוותים לשמור הוראות עבודה חוזרות ולהפעיל אותן בפרויקטים שונים. במקום להסביר לאייג’נט בכל פעם מחדש איך לבצע פעולה מסויימת, אפשר להפוך את ההנחיות ליכולת קבועה שזמינה בתוך סביבת העבודה (Workspace). הפיצ’ר הוכרז ב-18 במאי 2026, כחלק מעדכון מוצר רחב יותר של Lovable. זה נשמע כמו שינוי קטן בממשק, אבל עבור משתמשים שעובדים עם Lovable לאורך זמן זו תוספת משמעותית. רוב העבודה עם כלי AI לבניית אפליקציות עדיין נשענת על פרומפטים חד-פעמיים. המשתמש צריך לזכור מה לכתוב, איך לנסח את הבקשה, איזה כללים להזכיר, ומה אסור למערכת לעשות. Skills נועדו לצמצם בדיוק את החיכוך הזה, להסביר פעם אחת איך לבצע תהליך מסוים, ואז להשתמש בו שוב.
רוצים לקבל עדכונים בלייב? רוצים מקום בו אתם יכולים להתייעץ עם מומחי AI, לשאול שאלות ולקבל תשובות? רוצים לשמוע על מבצעים והטבות לכלי ה-AI שמשנים את העולם? הצטרפו לקהילות ה-AI שלנו.
אפשר גם להרשם לניוזלטר שלנו
ב-Lovable, ה-Skill הוא מעין playbook קצר, קובץ הוראות בשם מוגדר, שנכתב ב-Markdown (קובץ טקסט) ונשמר בסביבת העבודה. לכל Skill יש שם, תיאור שמסביר מתי להשתמש בו, וגוף הוראות שמגדיר מה Lovable צריכה לעשות כשהיכולת מופעלת. Skills מיועדים למשימות חוזרות כמו צ’קליסט השקה, ניסוח הודעות מוצר, תשובות תמיכה, בדיקות QA, סקירות נגישות או תהליכים פנימיים של צוות.
ההבדל החשוב הוא בין Knowledge לבין Skills. ה-Knowledge הוא ידע קבוע של סביבת העבודה, ונטען תמיד כרקע. הוא מתאים לכללים שחלים על כל פעולה, למשל סטנדרטים של קוד, שפת מותג או מידע קבוע על המוצר. Skills, לעומת זאת, נטענים רק כאשר המשימה מתאימה להם. במילים פשוטות, Knowledge הוא “מה Lovable תמיד צריכה לדעת”, ו-Skill הוא “איך Lovable צריכה לבצע משימה מסוימת”.
הפעלת Skill יכולה לקרות בשתי דרכים. הראשונה אוטומטית: Lovable קוראת את תיאור ה-Skill ומחליטה אם הוא רלוונטי לבקשה הנוכחית. אם למשל קיימת יכולת בשם launch-checklist, והמשתמש כותב שהוא מתכונן להעלות פרויקט לאוויר, Lovable יכולה להשתמש בה בלי שהמשתמש יצטרך לקרוא לה ידנית.
הדרך השנייה היא הפעלה ידנית דרך תפריט / בצ’אט. המשתמש מקליד /, בוחר את ה-Skill הרצוי, ואז מוסיף את הבקשה שלו. Lovable מתייחסת ל-Skill כאל הוראות הביצוע, ולפרומפט שאחריו כאל המשימה עצמה. זה בעצם הצימוד בין ה-“איך” לבין ה-“מה”.
המשמעות הפרקטית היא שאפשר לבנות ספריית תהליכים קטנה בתוך Lovable, כמו Skill לבדיקת עמוד נחיתה לפני פרסום, Skill להפקת release notes, Skill לבדיקת הרשאות לפני השקה, Skill לשכתוב מסכים לפי שפת מותג, או Skill שמכריח את המערכת להציג תוכנית פעולה לפני שינוי משמעותי בקוד.
כדי להקל על ההתחלה, Lovable כוללת גם Skills מובנים מראש. Skills שנבנו על ידי Lovable זמינים בכל סביבת עבודה כברירת מחדל, מופיעים באותו תפריט לצד Skills מותאמים אישית, ויכולים להיות מופעלים ידנית או אוטומטית. המשתמשים יכולים לקרוא אותם ולהשתמש בהם, אבל לא לערוך, למחוק או להוריד אותם.
בצילום המסך מתוך הממשק של Lovable מופיעים חמישה Skills מובנים: accessibility, לבדיקת בעיות נגישות ותיקונן, redesign, לעיצוב מחדש של ממשק קיים, seo-review, שמריץ בדיקת SEO על הפרויקט, skill-creator, שעוזר ליצור או לעדכן Skills, ו-video-creator, שמיועד ליצירת וידאו או אנימציה באופן תכנותי. כך משתמשים יכולים להתנסות בפיצ’ר מיד, להבין איך Lovable מפעילה Skills בהקשר המתאים, ורק אחר כך לבנות יכולות מותאמות אישית לצרכים שלהם.
חמישה Skills מובנים בממשק Lovable
הנקודה החשובה היא שלא חייבים להתחיל מ-Skill מורכב. אפשר קודם להפעיל Skill מובנה, לראות איך הוא מתנהג בתוך פרויקט אמיתי, ואז לבנות גרסה מותאמת לתהליך עבודה שחוזר אצלכם.
כדי להגיע למסך הניהול של Skills, נכנסים דרך תפריט החשבון האישי ב-Lovable, בוחרים Settings, ואז עוברים באזור ההתאמה האישית אל Skills. באותו אזור מופיעה גם אפשרות Knowledge.
כך מגיעים למסך Skills ב-Lovable
את ה-Skills מנהלים כאמור דרך Settings → Skills. יש חמש דרכים להוסיף Skill: לבנות אחת בשיחה מונחית עם Lovable, לכתוב ידנית, לייבא ממאגר GitHub ציבורי שכולל קובץ SKILL.md, להעלות קובץ ZIP, או להפוך פעולה מוצלחת מתוך שיחת פרויקט ל-Skill קבוע באמצעות בקשה כמו “save that as a skill”.
כאן חשוב להבין ש-Skill לא חייב להיות רק פרומפט קצר ששומרים בצד. בדוגמה (המצורפת) של Lovable ל-Website Copywriter, היכולת בנויה כתיקייה עם קובץ מרכזי בשם SKILL.md, שמגדיר את שם היכולת, התיאור, ההוראות, הקלטים הנדרשים והתוצאה הרצויה. לצדו מופיעים קבצי עזר כמו tone-guide.md ו-website-example.md, שמאפשרים ל-Skill להישען על טון כתיבה ודוגמה קיימת. במילים אחרות, Skills יכולים לארוז תהליך עבודה שלם, ולא רק פקודה אחת.
הנה הדוגמה ל-Skill מותאם אישית ב-Lovable: קובץ SKILL.md מרכז את ההוראות, ולצדו קבצי עזר שמגדירים טון כתיבה ודוגמה רצויה:
Skill מותאם אישית ב-Lovable
האפשרות של להפוך פעולה מוצלחת מתוך שיחת פרויקט ל-Skill קבוע מומלצת במיוחד, כי היא מתאימה לאופן שבו אנשים באמת עובדים עם כלי AI. אם Lovable ביצעה משימה בצורה טובה, למשל ניסחה changelog מדויק או תיקנה עמוד לפי כללי עיצוב מסוימים, המשתמש לא צריך לשחזר את הפרומפט. הוא יכול לבקש להפוך את התהליך הזה ליכולת קבועה, לבדוק את הטיוטה, ולאשר את הפרסום שלה.
המעבר הזה חשוב כי הוא משנה את הדרך שבה משתמשים חושבים על פרומפטים. במקום להתייחס לכל בקשה כאל פעולה חד-פעמית, אפשר להתחיל לבנות ספריית תהליכים: איך כותבים קופי לאתר, איך בודקים עמוד לפני השקה, איך מנסחים הודעת עדכון, ואיך מוודאים ש-Lovable פועלת לפי הכללים של הצוות גם בפרויקטים חדשים.
Skills נשמרות ברמת ה-Workspace, ולכן הן זמינות כברירת מחדל בכל הפרויקטים באותה סביבת עבודה. אם Skill מסוימת לא מתאימה לפרויקט ספציפי, אפשר להשבית אותה בהגדרות הפרויקט בלי למחוק אותה מה-Workspace ובלי להשפיע על פרויקטים אחרים.
מבחינת הרשאות, בעלי Workspace ומנהלי Workspace יכולים ליצור, לערוך, למחוק ולייבא Skills מותאמות אישית. משתמשים עם הרשאות Workspace owner, admin או editor, או משתמשים בעלי הרשאת Project editor ומעלה בפרויקט מסוים, יכולים לצפות ב-Skills ולהפעיל אותן בצ’אט של הפרויקט. בארגוני Enterprise, שינויים ב-Skills מתועדים גם ב-audit log של סביבת העבודה.
לגבי עלות, Lovable מציינת שאין עלות נוספת על יצירה או שימוש ב-Skill. יחד עם זאת, ההודעה שנשלחת בצ’אט עדיין צורכת קרדיטים רגילים, בין אם הופעל Skill ובין אם לא.
הטעות הנפוצה תהיה לבנות Skill גדול מדי שמנסה לכסות הכול. Lovable עצמה ממליצה על עיקרון פשוט: Skill אחד - משימה אחת. יכולת טובה צריכה להיות ממוקדת, עם תיאור ברור שמתחיל ב-“Use when”, גבולות שימוש, דוגמאות, ומה לא לעשות. ככל שהתיאור עמום יותר, כך גדל הסיכוי ש-Lovable תפעיל את היכולת בזמן הלא נכון, או לא תפעיל אותה כשהיא דווקא נחוצה.
למשתמש מתחיל, שלושה Skills טובים להתחלה יכולים להיות צ’קליסט לפני השקה, בדיקת SEO לעמוד קיים, וסקירת UI לפי כללי מותג. לצוותים, הערך הגדול יותר נמצא בסטנדרטיזציה: כולם עובדים עם אותה רשימת בדיקות, אותו סגנון ניסוח ואותם גבולות פעולה.
חשוב לא להפריז במה שהפיצ’ר עושה. Skill זה לא סקריפט, לא בוט עצמאי ולא מנגנון שמריץ בדיקות לבדו. הוא סט הוראות ש-Lovable קוראת כאשר המשימה מתאימה. גם Lovable עצמה מדגישה ש-Skills לא מחליפים פרומפטים, אלא משפרים אותם. אם הבקשה עצמה כללית מדי, גם Skill טוב לא יצליח לנחש את המוצר, קהל היעד או מטרת העמוד.
יש גם מגבלות שכדאי להכיר. Skills לא מועילים במיוחד למשימות חד-פעמיות, יותר מדי Skills חופפים עלולות ליצור התנגשויות, ו-Skill שלא עודכן עלול להפוך עם הזמן למקור להנחיות שגויות. שינוי ב-Skill חל רק על שיחות עתידיות, כך שלא כדאי לצפות שעדכון באמצע שיחה ישנה מיד את ההתנהגות של Lovable באותה שיחה.
המהלך של Lovable משתלב במגמה רחבה יותר בכלי AI: מעבר מצ’אט חד-פעמי למערכות שמנהלות תהליכי עבודה מתמשכים. השאלה כבר אינה רק אם האייג’נט יכול לכתוב קוד או לעצב מסך, אלא האם אפשר ללמד אותו לעבוד לפי הסטנדרטים של המשתמש או הצוות לאורך זמן.
עבור משתמשי Lovable, ה-Skills יכולים להפוך את העבודה לפחות תלויה בזיכרון של המשתמש ויותר תלויה בתהליכים ברורים. במקום לשאול “איך ניסחנו את זה בפעם שעברה?”, אפשר לשמור את הדרך הנכונה כיכולת קבועה. זה לא מבטל את הצורך בבקרה אנושית, בפרומפטים טובים או בבדיקות לפני פרסום, אבל זה כן מקרב את Lovable מעוד כלי שמגיב לבקשות, לסביבת עבודה שמתחילה לזכור איך הצוות רוצה לבנות.
מי שרוצה להתנסות יכול לראות מגוון דוגמאות והסברים דרך התיעוד הרשמי של Lovable שם מרוכזים דרכי היצירה, ההפעלה, ההרשאות, המגבלות וההבדלים בין Skills לבין Knowledge.
רוצים לקבל עדכונים בלייב? רוצים מקום בו אתם יכולים להתייעץ עם מומחי AI, לשאול שאלות ולקבל תשובות? רוצים לשמוע על מבצעים והטבות לכלי ה-AI שמשנים את העולם? הצטרפו לקהילות ה-AI שלנו.
אפשר גם להרשם לניוזלטר שלנו
רוצים לקבל עדכונים על כל מה שחדש ומעניין בעולם ה-AI? הרשמו לניוזלטר שלנו!
תוצאות נוספות...
תוצאות נוספות...
