כיצד לאחסן — Web App, אתר, אינטגרציות

לאתר תדמית / בלוג:

Vercel + Markdown קבצים (ללא בסיס נתונים). הכי פשוט.

לאתר עם תוכן דינמי (e-commerce, פלטפורמה):

Vercel + Supabase (בסיס נתונים) + Cloudinary (מדיה).

לאפליקציה web עם משתמשים:

Vercel + Supabase (גם auth + בסיס נתונים) + Resend (אימיילים).

לאפליקציה עם תנועה גבוהה:

Google Cloud Run (שרת) + Cloud SQL (בסיס נתונים) + Cloudflare (CDN).

הבעיה הבסיסית שצריך להבין לפני שמתחילים#

ישנה טעות נפוצה מאוד: לבקש מהסוכן "עצב לי ממשק יפה". התוצאה היא תמיד אותה תוצאה: אתר גנרי, עם צבעים כחולים-לבנים, כפתורים מעוגלים ברדיוס ממוצע, פונט Sans-serif סטנדרטי, ופריסת "hero section" שרואים בכל מקום. הוא טכנית נכון — אבל לא שלך.

למה זה קורה?

הסוכן אומן על מיליוני אתרים. המשוקלל הממוצע שלהם הוא אתר גנרי. כשאתה לא נותן לו כיוון — הוא חוזר לממוצע.

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

מחקר שוק כבסיס לעיצוב — לא סקיצה, אלא מחקר#

שלב 1 — הגדר את המשתמש

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

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

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

• מי הוא? אישה בת 32, גרה בעיר גדולה, עובדת במשרה מלאה, רוצה ללמוד צילום לייחד את זכרונות הילדים שלה
• מה הפעולה הראשונה? מחפשת קורס מתחילים, מסתכלת על צילומי דוגמה של המדריך
• הרגש הרצוי: ביטחון ("אני אוכל ללמוד"), השראה ("כך יוצאות תמונות כאלה")
• מה מאיים: חוסר ודאות אם המדריך טוב, פחד מהשקעה בלי לדעת מה מקבלים

שלב 2 — מחקר מתחרים ו-References

בקש מהסוכן (ב-Antigravity עם web search מופעל):

חפש לי 5-7 אתרים של פלטפורמות לימוד מקוונות (Skillshare, MasterClass, Domestika וכו'). עבור כל אחד, צלם מסך של דף הבית ורשום: מה הצבע הראשי, מה גודל הכיתוב הראשי, איך מוצגים המדריכים, ומה הפעולה הראשונה שרואים.

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

"אני אוהב את הגדלת הכיתוב של MasterClass ואת הצבע הכהה הפרמיום שלהם. אני לא אוהב את העומס של Udemy. הפשטות של Domestika מדברת אלי אבל היא קצת קרה — אני רוצה יותר חמימות."

זה הבסיס לעיצוב שמתאים לפרויקט שלך.

יצירת Design System Skill — הלב של עיצוב אמיתי#

Design System הוא "חוקת הסגנון" של המוצר שלך. כשהסוכן יש לו Design System skill מוגדר — כל דף שהוא בונה ישתמש בצבעים הנכונים, הפונטים הנכונים, הריווח הנכון. בלי זה — כל דף ייראה מעט שונה מהשני.

כיצד לבנות Design System Skill:

name: design-system

description: חוקת העיצוב של הפרויקט. טען skill זה בכל פעם שאתה בונה רכיב UI, דף, או כל אלמנט ויזואלי. זו האמת הבלעדית לעניין עיצוב — אין לחרוג ממנה ללא אישור מפורש.

Design System — [שם הפרויקט]#

המשתמש שאנחנו מעצבים עבורו#

[העתק כאן את פרופיל המשתמש שכתבת]

כל החלטת עיצוב צריכה לשרת את המשתמש הזה.

Palette צבעים#

• Primary: #[צבע ראשי] — פעולות ראשיות, קישורים
• Primary Dark: #[גרסה כהה] — hover states
• Secondary: #[צבע משני] — אקצנטים
• Background: #[צבע רקע]
• Surface: #[צבע כרטיסים/panels]
• Text Primary: #[טקסט ראשי]
• Text Secondary: #[טקסט משני/sub-text]
• Error: #DC2626
• Success: #16A34A
• Warning: #D97706

חשוב: אל תשתמש בשום צבע שאינו ברשימה זו.

Typography (פונטים)#

• Heading font: [שם פונט] — מגוגל פונטס
• Body font: [שם פונט]

| גודל | שימוש | weight |

| 14px | caption, labels | 400 |

| 16px | body text | 400 |

| 20px | section headers | 600 |

| 28px | page titles | 700 |

| 40px+ | hero headlines | 800 |

Spacing System (ריווח)#

בסיס: 4px. כל ריווח הוא כפולה שלו: 4, 8, 12, 16, 24, 32, 48, 64.

אל תשתמש בריווחים שרירותיים כמו 7px, 15px.

Border Radius (עיגול פינות)#

• כפתורים קטנים: 6px
• כפתורים גדולים: 10px
• כרטיסים: 12px
• Modal / Popup: 16px
• אל תשתמש ב-9999px (עיגול מלא) אלא לאלמנטים ספציפיים שנאושרו

Shadow (צל)#

--shadow-sm: 0 1px 2px rgba(0,0,0,0.05);

--shadow-md: 0 4px 12px rgba(0,0,0,0.08);

--shadow-lg: 0 12px 32px rgba(0,0,0,0.12);

רכיבים#

כפתורים#

Primary Button: רקע [צבע ראשי], טקסט לבן, padding 12px 24px, border-radius 10px

Secondary Button: border 1.5px [צבע ראשי], טקסט [צבע ראשי], רקע שקוף

Ghost Button: ללא border וללא רקע, טקסט [צבע ראשי]

Destructive Button: רקע אדום #DC2626, טקסט לבן

כרטיסים (Cards)#

רקע [Surface color], border-radius 12px, shadow-md, padding 24px.

ב-hover: shadow-lg ועלייה עדינה (transform: translateY(-2px)).

שדות קלט (Input Fields)#

border 1.5px [צבע גבול], border-radius 8px, padding 12px 16px.

ב-focus: border [צבע ראשי], צל עדין בצבע ראשי.

ב-error: border #DC2626.

Layout#

• מקסימום רוחב דף: 1280px
• padding צדדי ב-mobile: 16px
• padding צדדי ב-desktop: 32px
• Grid columns: 12 עמודות

אנימציות#

• transition בסיסית: 150ms ease
• כניסת אלמנטים: 200ms ease-out
• ללא אנימציות מורכבות ללא אישורי

מה שמגדיר את הטון הויזואלי#

[כתוב 3-4 משפטים: "אנחנו רוצים שהמוצר ירגיש כמו..."]

References#

• [לינק לאתר 1 שאהבת]
• [לינק לאתר 2]

Visual Self-Correction — איך הסוכן רואה ומתקן את עצמו#

Antigravity, באמצעות ה-Browser Subagent שמצלם את המסך, יכול לראות מה הוא בנה. זה פיצ'ר שצריך לנצל באופן אקטיבי.

Workflow מומלץ לכל בניית דף:

שלב 1 — ניסוח בקשה שמפעיל Visual Verification:

בנה את דף [שם הדף].

לאחר שתסיים לכתוב את הקוד:

1. הפעל את השרת המקומי

2. פתח את הדפדפן ונווט לדף

3. צלם מסך מלא

4. השווה את הצילום לDesign System skill שלנו

5. אם יש חריגות — תקן ותצלם שוב

6. הצג לי את הצילום הסופי עם רשימה של כל שינוי שעשית ולמה

שלב 2 — כשמגיע Screenshot Artifact:

אתה רואה תמונה. השאלות שצריך לשאול עצמך:

• האם הצבעים נכונים? (השווה ל-Design System)
• האם הרווחים נראים מאוזנים?
• האם יש אלמנט שנראה "לא במקום"?
• האם הדף נראה כמו מוצר שאתה תרצה להשתמש בו?

שלב 3 — פידבק ספציפי:

אל תכתוב "לא מצא חן בעיני". כתוב: "הכפתור בשורה 3 גדול מדי ביחס לטקסט. הפונט בkeyboard ניראה כמו Inter לא Poppins. הריווח בין הכרטיסים גדול מדי".

מוקאפים — איך ליצור תרשימי עיצוב לפני שכותבים קוד#

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

Prompt לדוגמה:

לפני שנתחיל לבנות, אני רוצה לדמיין את הדף.

בהתבסס על ה-design system skill שלנו ועל פרופיל המשתמש,

בנה לי wireframe בHTML פשוט (בלי CSS מורכב) שמראה:

• מה נמצא ב-header
• מה המבנה של hero section
• כמה כרטיסי קורסים נראים בעמוד ראשי
• מה נמצא ב-footer

אני לא צריך עיצוב מלא — רק מבנה כדי שנסכים על הפריסה לפני שנמשיך.

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

Prompting לעיצוב — הפרש בין אמנות לביצוע#

כשאתה רוצה תוצאות עיצוב ספציפיות, יש הבדל בין שני סוגי prompt:

Prompt ראשי (Design Directive):

מגדיר מה המוצר אמור להרגיש ולהיות. נכתב פעם אחת ב-CONTEXT.md או ב-Design System skill.

המוצר הזה הוא [תיאור]. הוא מיועד ל[קהל]. הוא צריך לתת תחושה של [רגש].

הוא לא צריך להרגיש כמו [מה שלא רוצים — דוגמה: "סטארטאפ ישראלי גנרי"].

כל החלטת עיצוב צריכה לשרת את המטרה הזו.

Prompt טקטי (Element-Level):

נכתב כשאתה מבקש לבנות רכיב ספציפי.

בנה כרטיס מוצר לחנות שלנו.

הכרטיס מציג: תמונה של המוצר, שם, מחיר, כפתור "הוסף לסל".

שים לב:

• התמונה צריכה לתפוס 60% מגובה הכרטיס
• המחיר בולט יותר מהשם — גדול יותר, צבע ראשי
• כשמרחפים על הכרטיס — כפתור "הוסף לסל" מופיע עם אנימציה עדינה
• השתמש בDesign System skill לכל צבע וריווח
• בדוק שנראה טוב גם ב-mobile (רוחב 375px) וגם ב-desktop (רוחב 1280px)

מה שאסור לכתוב בprompts עיצוב:

• "עשה יפה" — לא מוגדר
• "מודרני" — כולם חושבים משהו שונה
• "כמו Apple" — אין לך מותג של Apple, ותקבל פלגיאט גנרי
• "Clean" — כל מעצב מגדיר זאת אחרת

UX — הזרימה שקובעת יותר מהצבעים#

UI הוא הצבעים, הפונטים, האלמנטים. UX (User Experience) הוא הסיפור שהמשתמש חווה כשהוא משתמש במוצר שלך. אפשר להיות לא מעצב ועדיין לתכנן UX טוב — כי UX הוא בעיקר לוגיקה, לא אסתטיקה.

שאלות UX שצריך לענות לפני שהסוכן מתחיל:

1. מה המשתמש עושה כשהוא נכנס לדף הראשי? מה הוא יראה ראשון?

2. כמה קליקים עד שהוא מגיע לפעולה הראשית? הפחית למינימום.

3. מה קורה כשהוא עושה טעות? הודעת שגיאה? הדרכה? איפוס?

4. מה קורה כשפעולה מצליחה? confirmation? redirect? אנימציה?

5. מה קורה אם אין נתונים? (Empty State) — מסך ריק ללא הסבר הוא בעיה UX קשה.

Prompt לבניית Empty State טוב:

הדף [שם הדף] מציג רשימת [פריטים].

כשהרשימה ריקה (לדוגמה, משתמש חדש שאין לו עדיין פריטים) — אל תציג רשימה ריקה.

הצג:

1. איור/אייקון שמתקשר לנושא

2. כותרת: "[שם הפרויקט] מחכה לך"

3. פסקה קצרה: "[הסבר מה המשתמש יכול לעשות]"

4. כפתור ראשי: "[פעולה ראשונה]"

Mobile-First — למה זה לא עוד מילה טכנית#

חלק גדול מהגלישה (בישראל ובעולם) מתבצע מטלפון. אם האתר שלך לא עובד טוב בנייד — הפסדת חלק גדול מהקהל שלך.

הנחיה שצריך לכלול בכל Design System skill:

Mobile-First חובה:

תמיד כתוב עיצוב למסך נייד קודם (375px רוחב), ואז הרחב לdesktop.

בדוק תמיד שניהם לפני שאתה מדווח שסיימת.

Prompt שמוודא mobile:

לאחר שתסיים לבנות את הדף:

1. צלם מסך ברוחב 375px (iPhone SE)

2. צלם מסך ברוחב 1280px (desktop רגיל)

3. הצג לי את שניהם ורשום אם יש בעיות layout בנייד

תהליך עבודה מסודר — מחקר עד פרודקשן#

הנה תהליך שלם שאפשר לחזור אליו בכל פרויקט:

שלב 1 — הבנת המוצר:

• כתוב את פרופיל המשתמש
• כתוב את מטרת המוצר (3 משפטים)
• רשום את הדפים/מסכים הנדרשים ל-MVP

שלב 2 — מחקר ויזואלי:

• בקש מהסוכן לסרוק מתחרים ולסכם מה כל אחד עושה ויזואלית
• בחר מה אתה אוהב ומה לא
• כתוב את ה"אופי הויזואלי" שלך (3-5 משפטים)

שלב 3 — בניית Design System skill:

• צבעים, פונטים, ריווח, צל, border-radius
• הגדרת רכיבים ראשיים
• Rules על מה אסור

שלב 4 — מוקאפים:

• לכל דף ראשי — wireframe מהיר לאישור פריסה

שלב 5 — בנייה:

• דף אחד בשיחה אחת
• Visual Self-Correction אחרי כל דף
• פידבק ספציפי, תיקון, אישור

שלב 6 — בדיקת QA:

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

שלב 7 — פרודקשן:

• Git push ל-main
• Vercel מפרס
• בדיקה על ה-URL הציבורי לפני שמשתפים

הצעד שמפריד בין מי שמצליח למי שלא#

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

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

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

מי שיגיע לכלי עם רעיון מטושטש — יקבל מוצר מטושטש.

מי שיגיע עם מסמך ברור, Design System skill, הגדרת משתמש, ורשימת פיצ'רים — יקבל מוצר.

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

מדריך זה מבוסס על תיעוד רשמי של Google Antigravity, מדריכי Google Codelabs, מאמרים של Google Cloud, ומקורות קהילה עדכניים (נובמבר 2025 — מרץ 2026). Google Antigravity משתנה בקצב מהיר (תוכנית Individuals החינמית מסומנת כיום Generally Available בדף התמחור הרשמי, נכון ל־22.10.2026). מומלץ לאמת פרטים ספציפיים מול התיעוד הרשמי ב-antigravity.google/docs.

אם אחד מהפרקים לא היה ברור — זו הבעיה שלנו, לא שלך. שאל, ונרחיב.

חלק ב׳ — מדריך תפעולי מתקדם#

כל מה שאדם מגלה אחרי ההורדה — לפני שהוא מתייאש#

חלק א׳ — ממשק: כל החלון, כל כפתור, כל מצב תצוגה#

א.1 — מפת ממשק המשתמש: מה רואים ומה עושים#

כשפותחים את Antigravity לראשונה, יש שישה אזורים עיקריים. הבנת תפקיד כל אחד מהם חוסכת שעות של אי-נוחות:

[1] Agent Manager Panel — הלוח השמאלי הצר

זה "לוח הבקרה שלך". ממנו מנהלים הכל, כמו שולחן עבודה של מנהל.

מה בתוכו, מלמעלה למטה:

• Workspaces (בתיעוד הרשמי העדכני הסוכנים פועלים בתוך Projects שמגדירים את גבולות הריפו) — רשימת הפרויקטים שלך. כל שם שלחצת בו — מחליף את הפרויקט הפעיל. לחיצה ימנית על שם פרויקט פותחת תפריט: שנה שם, הסר מהרשימה (לא מוחק את הקבצים — רק מסיר מהתצוגה), פתח בסייר.
• Inbox — הם זה שגוגל דוק עשה לממשק: כל הודעה שהסוכן שלח אליך (תכנית, צילום מסך, שאלת אישור) מופיעה כאן. ה-Inbox הוא המקום שאתה פותח כשחוזר אחרי שעה ורוצה לדעת מה קרה.
• Playground — אזור ניסיונות ללא workspace מוגדר. שמח לשחק עם רעיון בלי לגעת בפרויקט אמיתי. מה שבניתה ב-Playground אפשר להעביר לWorkspace אמיתי בכל שלב. עדכון: לפי ה-Changelog הרשמי, תכונת Playground ב-Manager סומנה כ-deprecated בגרסה 1.21.6 (25.03.2026).
• Global Rules — כפתור הגדרות כללי לכל הפרויקטים. כאן תכתוב Rules שחלים על כל סוכן בכל workspace.

[2] Conversation View — החלון הגדול האמצעי

הצ'אט עם הסוכן. כאן אתה כותב משימות ופה הסוכן מדווח. שני מצבי שיחה:

• Plan Mode: לפני שהסוכן מתחיל לכתוב קוד, הוא עוצר ומייצר Implementation Plan Artifact לאישורך. זה המצב המומלץ למשימות חדשות. בחר את זה תמיד למשימות חדשות.
• Fast Mode (ב-CLI הפקודות /planning ו-/fast הוחלפו ב-/plan בגרסה 1.1.0, 08.07.2026, ובאפליקציה ההגדרה נקראת כיום Plan Review Policy מגרסה 2.17.0): הסוכן מבצע מיד, בלי לעצור. מתאים לתיקונים זריזים ("שנה את הטקסט בכותרת", "תקן שגיאת כתיב ב-readme").

כיצד לבחור: יש כפתור dropdown מעל שדה הכתיבה שמאפשר לעבור בין שני המצבים. ברירת המחדל היא Plan Mode — אל תשנה אותה כברירת מחדל.

[3] Artifacts Panel — הלוח הימני

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

[4] Browser Subagent Panel — שתי האפשרויות

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

• Embedded Browser (ברירת מחדל): חלון קטן בתוך Antigravity עצמו. אתה רואה בזמן אמת מה הסוכן עושה בדפדפן, אבל הוא קטן.
• External Chrome Window: לחצן בתחתית ה-Browser Panel שפותח חלון Chrome נפרד. מומלץ — גדול יותר, נוח לבדיקה.

[5] Terminal Panel — הטרמינל

חלון שחור שמריץ פקודות. הסוכן פותח אותו ומשתמש בו בעצמו. אתה יכול לפתוח Terminal חדש ב: Terminal > New Terminal בתפריט העליון — אם אתה רוצה להריץ פקודה בעצמך (נדיר, אבל שימושי לפקודות גיבוי).

[6] Editor View — מצב עריכה ידני

לחיצה על כפתור "Focus Editor" (מצד שמאל, ליד שם ה-Workspace) עוברת ל-Editor View הקלאסי: עץ קבצים בשמאל, תוכן קובץ במרכז. כאן רואים את כל מה שהסוכן כתב. אפשר לערוך ישירות, אפשר להוסיף הוראות inline (לכתוב הוראה בתוך הקוד, הסוכן יקרא ויבצע).

מתי להשתמש ב-Editor View לעומת Agent Manager View?

זו שאלה שכולם שואלים.

השתמש ב-Agent Manager כשאתה:

• נותן משימה חדשה
• בודק מה הסוכן עשה
• מנהל כמה סוכנים בו-זמנית
• פשוט רוצה לדעת מה קורה

השתמש ב-Editor View כשאתה:

• רוצה לראות קובץ ספציפי לעומק
• עורך טקסט קטן ישירות (שינוי שגרסה, תיקון שגיאת כתיב)
• רוצה לראות את עץ הקבצים ולהבין מה נוצר

הכלל הכי פשוט: רוב הזמן תהיה ב-Agent Manager. תעבור ל-Editor רק כשיש סיבה ספציפית. אם אתה מוצא את עצמך גולש בין הקבצים ב-Editor בלי מטרה — זה סימן שאתה מנסה לשלוט בפרטים שהסוכן יכול לנהל טוב יותר ממך.

א.2 — תצוגה מפוצלת: מה זה, מתי כן, מתי לא#

Split View ב-Antigravity פירושה: מסך אחד, שני חלקים זה לצד זה. השכיח ביותר הוא:

• צד שמאל: Agent Manager (הצ'אט)
• צד ימין: Browser (האפליקציה שלך בפעולה)

כיצד לפתוח: View > Editor Layout > Split Right — או גרור Tab לצד ימין של המסך.

מתי תצוגה מפוצלת עוזרת:

כשאתה מבקש מהסוכן שינוי ויזואלי ורוצה לראות את התוצאה בזמן אמת — בלי לעבור בין חלונות. לדוגמה: "שנה את הכפתור לאדום" — ואתה רואה אותו משתנה בצד הימני בזמן שהסוכן עובד.

מתי תצוגה מפוצלת מפריעה:

כשיש הרבה Artifacts, כשמנהלים כמה Workspace-ים, וכשהמסך קטן. אל תכריח תצוגה מפוצלת על לאפטופ 13 אינץ׳ — זה יוצר עומס ויזואלי.

מסך חיצוני — המלצת זהב: אם יש לך מסך חיצוני, שים את Agent Manager ואת ה-Browser בשני מסכים נפרדים. זה משנה לחלוטין את חוויית העבודה.

א.3 — ההגדרות החשובות שצריך לקבוע מיד אחרי ההורדה#

פתח: Antigravity > Settings (macOS) או File > Preferences > Settings (Windows/Linux).

הגדרה 1 — Terminal Command Auto Execution

| מצב | מה זה אומר | מתי להשתמש |

| Off | הסוכן מציע פקודות, אתה מריץ ידנית | לעולם לא — מנוע פיתוח שבור |

| Auto (מומלץ להתחלה) | הסוכן מריץ לבד בהתבסס על שיקול דעת | ברוב המקרים |

| Turbo | הסוכן מריץ הכל בלי לשאול | לפרויקטים ניסיוניים בלבד |

| Custom | אתה קובע Allow List ו-Deny List | לאחר חודשיים של ניסיון |

עדכון מול התיעוד הרשמי (22.10.2026): ההרשאות מוגדרות כיום כ-presets בשם Default, Request Review ו-Turbo (Settings > General, עם אפשרות לדרוס לכל Project), ובנוסף רשימות Allow / Deny / Ask. Deny גובר על Ask, ו-Ask גובר על Allow. Turbo מתיר פקודות טרמינל בלי הגבלה. השמות Off / Auto / Custom מהטבלה אינם מופיעים בתיעוד הרשמי.

Allow List — רשימה לבנה: פקודות שהסוכן תמיד יכול להריץ בלי לשאול. לדוגמה:

npm install

npm run dev

npm run build

npm test

git status

git add .

git commit -m

pip install

python

Deny List — רשימה שחורה: פקודות שלעולם לא יורצו אוטומטית. מניחים כאן את הפקודות שמשמידות נתונים:

rm -rf

git push --force

DROP TABLE

DELETE FROM

npm publish

הגדרה 2 — Artifact Review Policy

| מצב | מה קורה |

| Request Review | כל Artifact מחכה לאישור שלך לפני שהסוכן ממשיך |

| Agent Decides (מומלץ) | הסוכן מחליט מה דרוש אישור |

| Always Proceed | הסוכן מתקדם בלי לעצור בשום Artifact |

עדכון מול התיעוד הרשמי (22.10.2026): בתיעוד ובשינויים הרשמיים ההגדרה מופיעה בשם Artifact review (ללא המילה Policy). ערכי המצבים Request Review / Agent Decides / Always Proceed עשויים שלא להתאים לשמות בממשק.

בחר "Agent Decides" בהתחלה. זה מאפשר לסוכן לעצור אוטומטית כשיש משהו שנראה לו חשוב לאשר — בלי לעצור כל שלושים שניות.

הגדרה 3 — Browser JavaScript Execution

| מצב | משמעות |

| Always Proceed | הסוכן מריץ JavaScript בדפדפן לבד — מהיר, אפקטיבי |

| Request Review | מבקש אישור לפני כל JavaScript |

הגדרת Browser JavaScript Execution לא נמצאה בדפי ההרשאות והדפדפן הרשמיים.

בחר "Always Proceed" — בלי זה הסוכן לא יכול לבדוק את האפליקציה כמו שצריך.

הגדרה 4 — Secure Mode (שונה ל-strict mode בגרסה 1.16.5, 03.02.2026)

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

הגדרה 5 — Auto Save

בחר "afterDelay" עם 1000ms. כל שינוי נשמר אוטומטית שנייה אחרי שנעשה. לעולם לא תאבד עבודה של הסוכן בגלל ש"לא שמרת".

הגדרה 6 — Git Auto Commit

כשמופעל — הסוכן עושה Git commit אוטומטי בסיום כל משימה שאישרת. הפעל את זה. זה עושה את Git לרשת בטיחות שעובדת לבד. ההגדרה בשם Git Auto Commit ומספר הגרסה שצוין בעבר לא נמצאו ב-Changelog הרשמי.

חלק ב׳ — ניהול פרויקטים: כמה, איך, ואיפה#

ב.1 — יצירת פרויקט חדש — צעד אחר צעד#

בדרך הרגילה:

1. לחץ על + ליד "Workspaces" ב-Agent Manager Panel

2. בחר Open Folder

3. נווט למקום שאתה רוצה את הפרויקט — המלצה: צור תיקיה ~/Projects/ ובתוכה תיקיה לכל פרויקט

4. שמות תיקיות: באנגלית, ללא רווחים, ללא תווים מיוחדים. my-yoga-app — כן. האפליקציה שלי — לא.

5. לחץ Select Folder

דרך חלופית — Playground:

לחץ Playground בלוח השמאלי. Playground (תכונה שסומנה deprecated ב-Manager בגרסה 1.21.6, 25.03.2026) הוא Workspace זמני — מה שבניתה שם לא נשמר לקובץ עד שתחליט לשמור. שלח לסוכן שאלה, ראה מה הוא עושה, ואז:Right Click > Convert to Workspace אם אתה רוצה להמשיך עם זה כפרויקט.

ב.2 — כמה פרויקטים מנהלים בו-זמנית — ומה זה אומר בפועל#

Antigravity מאפשר Workspaces מרובים פתוחים בו-זמנית. אתה יכול לראות אותם כולם בלוח השמאלי ולשלוח סוכנים לכל אחד.

אין מגבלה טכנית על מספר הWorkspaces — המגבלה היא ה-RAM שלך ויכולת הקשב שלך.

המלצה מעשית:

• 1-2 פרויקטים פעילים בו-זמנית — נוח (המלצה מעשית של המחבר, לא נתון רשמי)
• 3-4 — מחייב ניהול מדויק של Inbox
• 5+ — מתחיל לייצר בלבול. מי בנה מה? איזה סוכן מחכה לי?

טיפ ל-Inbox Management: כשיש כמה פרויקטים פעילים, ה-Inbox יכול להצטבר. אחת לשעה — פתח את ה-Inbox, ענה לכל מה שמחכה, ואז המשך. אל תנסה לנהל בזמן אמת כמה שיחות מקבילות — זה מוביל לטעויות.

ב.3 — ניהול קבצים ומבנה תיקיות מומלץ#

~/Projects/

├── my-yoga-app/ ← פרויקט 1

│ ├── .agent/

│ │ ├── rules.md

│ │ ├── context.md

│ │ └── skills/

│ ├── src/ ← הקוד

│ └── .git/ ← Git (נוצר אוטומטית)

│

├── portfolio-site/ ← פרויקט 2

│ ├── .agent/

│ └── ...

│

└── _shared-skills/ ← Skills גלובליות שאתה משתמש בכמה פרויקטים

├── deploy-to-vercel/

└── my-brand-style/

Skills גלובליות: Antigravity מאפשר להגדיר Skills שזמינות לכל ה-Workspaces — לא רק לאחד. הגדר אותן ב: Settings > Global Skills > Add Folder ובחר את _shared-skills/. לפי התיעוד הרשמי, התיקייה הגלובלית של Skills באפליקציה וב-IDE היא ~/.gemini/config/skills/, והנתיב ברמת הפרויקט הוא <workspace-root>/.agents/skills/ (הנתיב .agent/skills נתמך לתאימות לאחור). במבנה התיקיות שלמעלה, .agent/rules.md לא מופיע בתיעוד הרשמי של Rules: המבנה הנוכחי הוא AGENTS.md או .agents/rules/*.md עם frontmatter וערך trigger.

חלק ג׳ — מצב אוטונומי מלא: לישון בלילה כשהסוכן עובד#

ג.1 — הבעיה שכולם נתקלים בה: "Accept! Accept! Accept!"#

מפתחים נתקלו בבעיה הזו מאז השקת Antigravity: ה-AI האוטונומי מתעכב בכל שלב בגלל שצריך ללחוץ "Accept All" — מה שמסכל את כל הרעיון של פיתוח אוטונומי.

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

אבל יש דרך לעקוף אותה — ולשלוח את הסוכן לעבוד לבד כל הלילה.

ג.2 — הגדרת מצב "לך לישון" — כל הצעדים#

שלב 1 — הגדרות ב-Settings:

Settings > Advanced > Terminal:

Terminal Command Auto Execution → Turbo

Settings > Agent:

Artifact Review Policy → Always Proceed

Settings > Agent > Browser:

JavaScript Execution → Always Proceed

זהירות: Turbo + Always Proceed פירושו שהסוכן עושה הכל לבד, כולל פקודות שעלולות לגרום נזק. לפי התיעוד הרשמי, רשימת Deny גוברת על ה-preset, ולכן:

שלב 2 — הגדר Deny List לפני שמפעיל Turbo:

Settings > Advanced > Terminal > Deny List

הוסף לשם:

rm -rf

git push --force

DROP TABLE

DELETE FROM

npm publish

vercel --prod

זה מונע מהסוכן לעשות דברים הרסניים, גם ב-Turbo mode.

שלב 3 — Allow List לכל מה שהסוכן צריך:

Settings > Advanced > Terminal > Allow List

npm install

npm run dev

npm run build

npm test

npm run lint

git add

git commit

git status

pip install

python

pytest

curl

שלב 4 — כתוב Instructions שמכינות את הסוכן לעבודה עצמאית:

לפני שאתה הולך לישון, שלח לסוכן הודעה כזו:

אתה הולך לעבוד בצורה עצמאית לחלוטין. לא אהיה זמין לאישורים.

המשימה שלך:

[תאר בפירוט את מה שאתה רוצה שיבנה]

הנחיות לעבודה עצמאית:

• לפני כל שינוי גדול — כתוב Git commit עם תיאור מה עשית
• אם אתה נתקע ביותר מ-2 ניסיונות לפתרון — עצור, תכתוב Artifact שמסביר היכן נתקעת, ואל תמשיך
• אחרי שסיימת — הרץ את הבדיקות (%run test), צלם מסך, ושמור Artifact סיכום
• אל תמחוק שום קובץ קיים
• אל תפרוס לפרודקשן
• אם משהו שובר את ה-dev server — תקן אותו לפני שממשיך

Git: עשה commit עם הודעה ברורה כל 30-40 דקות של עבודה.

מוכן? תתחיל.

שלב 5 — בוקר: מה לבדוק כשחוזרים

1. פתח את ה-Inbox — ראה את כל ה-Artifacts שנוצרו בלילה

2. בדוק את Git Log: ב-Terminal כתוב git log --oneline — תראה רשימת כל ה-commits שהסוכן עשה

3. פתח את Browser ובדוק שה-app עובד

4. אם הסוכן עצר (Artifact "נתקעתי") — קרא מה הבעיה והמשך משם

ג.3 — הפתרון הטכני לבעיית ה-Auto-Accept שנשברת#

אזהרה חמורה: זהו תוסף צד שלישי של הקהילה, לא רשמי. התוסף מבטל את אישור האדם: הוא לוחץ "אשר" במקומך ונותן לסוכן, בפועל, הרשאה להריץ פקודות טרמינל ולערוך קבצים בלי שתראה אותן. טעות של הסוכן או הוראה זדונית שנקלטה מתוך קובץ או אתר יכולות לרוץ בלי שום עצירה. בנוסף, הוא מחייב להפעיל את Antigravity עם פורט debug פתוח (--remote-debugging-port), שהוא עצמו חשיפה אבטחתית. אם בכל זאת בוחרים להשתמש: רק בפרויקט מבודד ובלי מידע רגיש. ה-FAQ הרשמי של Antigravity קובע: "Using third-party software, tools, or services to access Antigravity is a violation of our Terms of Service", ופעולות כאלה עלולות להוביל להשעיית החשבון. ייתכן שהתוסף הזה נכלל בכך, ולכן לא מומלץ למתחילים. הדרך הרשמית היא ה-preset Turbo יחד עם רשימות Deny.

יש extension לChrome שנקרא AntiGravity AutoAccept. כשסוכן Antigravity מציע עריכות בקבצים, פקודות טרמינל, או מבקש הרשאות — ה-extension מאשר אותם אוטומטית בלי שתצטרך ללחוץ.

קישור: github.com/yazanbaker94/AntiGravity-AutoAccept

כיצד מתקינים:

1. הורד את Extension מה-GitHub

2. פתח Chrome → כתובת: chrome://extensions

3. לחץ "Load unpacked" ובחר את תיקיית ה-Extension

4. פתח את Antigravity עם פרמטר מיוחד:

ב-macOS: פתח את Terminal (אפליקציית Terminal המובנית) וכתוב:

open -a "Antigravity" --args --remote-debugging-port=9333

ב-Windows: לחץ ימני על קיצור הדרך של Antigravity, בחר Properties, ובשדה Target — הוסף בסוף:

--remote-debugging-port=9333

מדוע פורט 9333 ולא 9222? כי הפורט 9222 הוא ברירת המחדל של ה-Browser Control המובנה של Antigravity, ושימוש בו יוצר קונפליקט. פורט 9333 נמנע מהבעיה הזו.

מה ה-Extension עושה ולא עושה:

• עושה: מאשר אוטומטית כפתורי Run, Accept, Allow
• לא עושה: קורא קוד, שולח מידע, מתקשר עם שרתים חיצוניים

רשימת פקודות שמומלץ לא לכלול ב-AutoAccept (הגדר ב-Extension):

rm -rf

git push --force

npm publish

DROP TABLE

חלק ד׳ — בדיקות אוטומטיות: הסוכן שבודק את עצמו#

ד.1 — הבעיה: "תבדוק ככה ותבדוק ככה"#

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

למה זה קורה: הסוכן ב-Planning Mode ניסח את עצמו כ"מדווח" ולא כ"בודק". הוא לא קיבל הרשאה מפורשת לבדוק בעצמו.

הפתרון: Rules ו-Skills שמגדירים בדיקה עצמית כחובה.

ד.2 — Rule שפותר את הבעיה לתמיד#

הוסף לקובץ .agent/rules.md (בתיעוד הרשמי: AGENTS.md, או .agents/rules/*.md עם frontmatter וערך trigger; rules.md לא מופיע):

כלל בדיקה עצמית — חובה#

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

1. הרץ npm run dev (או הפקודה המקבילה) אם השרת לא פועל

2. פתח את הדפדפן ונווט לדף הרלוונטי

3. בצע בעצמך את כל הפעולות שהמשתמש צפוי לבצע:

• אם בניתה טופס — מלא אותו ושלח
• אם בניתה כפתור — לחץ עליו
• אם בניתה ניווט — נווט דרכו
• אם בניתה animation — וודא שהיא מופעלת

4. אם שום דבר לא נשבר — צלם מסך וצרף כ-Artifact

5. אם משהו נשבר — תקן לפני שאתה מדווח לי

6. אל תכתוב לי "תבדוק" שום דבר — אתה הבודק

ד.3 — הגדרת בדיקות אוטומטיות אמיתיות (E2E Testing)#

מעבר לבדיקה הויזואלית, ישנן "בדיקות אמיתיות" — קוד שבודק קוד. זה נשמע מורכב אבל הסוכן עושה את רובו.

Workflow לכתיבת בדיקה אוטומטית:

אחרי שסיימנו לבנות [שם הפיצ'ר], כתוב בדיקה אוטומטית שבודקת:

1. [פעולה 1 שמשתמש יכול לעשות]

2. [פעולה 2]

3. [מה המצב הצפוי אחרי הפעולות]

השתמש ב-Playwright לבדיקות E2E (בדיקות שמשחקות מבחינת משתמש).

לאחר שכתבת את הבדיקה — הרץ אותה.

אם עוברת — דווח ב-Artifact.

אם נכשלת — תקן ורוץ שוב.

מה זה Playwright? כלי שכותב קוד שפותח דפדפן, לוחץ על כפתורים, ממלא טפסים, ובודק שהתוצאה נכונה — הכל אוטומטי. הסוכן יתקין אותו לבד (npm install playwright).

Skill לבדיקות — עבור .agent/skills/automated-testing/SKILL.md:

name: automated-testing

description: טען כשצריך לכתוב, לנהל, או להריץ בדיקות E2E, Unit Tests, או Integration Tests

בדיקות אוטומטיות#

כלי בדיקה בפרויקט זה#

• E2E (בדיקות כמו משתמש): Playwright
• Unit Tests (בדיקות של פונקציות בודדות): Vitest
• הרצה: npm test להרצת הכל

מתי לכתוב בדיקה#

• כל פיצ'ר חדש — בדיקה E2E אחת לפחות
• כל פונקציה שמבצעת חישוב או לוגיקה — Unit Test

תהליך בדיקה עצמית חובה#

לאחר כל בנייה:

1. הרץ: npm test

2. אם יש כשלונות — תקן לפני שאתה מדווח

3. הרץ שוב

4. דווח על התוצאה ב-Artifact עם: מה נבדק, כמה עברו, כמה נכשלו

מה לא לבדוק#

• אל תכתוב בדיקות לCSS או לצבעים
• אל תכתוב בדיקות לתמונות
• בדוק פונקציונליות, לא מראה

חלק ה׳ — MVP + Scalability: לבנות נכון מהתחלה#

ה.1 — הבעיה שמוציאה כסף: "בנינו ועכשיו צריך לשבור הכל"#

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

הפתרון הוא Skill שמלמד את הסוכן לבנות MVP שמוכן לגדול.

ה.2 — Skill לארכיטקטורת MVP-First עם מחשבה לעתיד#

צור: .agent/skills/architecture/SKILL.md

name: architecture

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

כללי ארכיטקטורה#

עיקרון ה-MVP-First#

כל פיצ'ר נבנה בשני שלבים:

שלב MVP (מה בונים עכשיו)#

• הפשטות שעובדת
• ללא Optimization מוקדמת
• ללא קוד "לכשנגדל"
• Hardcode (ערכים קבועים בקוד) מותר אם הוא ברור ומסומן

שלב Future-Ready (מה לא בונים, אבל לא חוסמים)#

• אל תבנה "כבר עכשיו" — אבל אל תסגור את הדלת
• תמיד שאל: "אם מחר נרצה X — האם מה שבניתי היום יאפשר זאת בלי לשבור הכל?"

כללי בנייה שמכינים לגדול#

API / Backend#

• כל endpoint (כתובת API) חייב להיות ב-/api/v1/...
• למה: מחר נרצה /api/v2/ עם שינוי — לא נשבור לקוחות ישנים
• כל פונקציה שמגיעה לבסיס הנתונים — שכבה נפרדת (Repository Pattern)
• למה: אם נחליף בסיס נתונים — נשנה רק שכבה אחת

Database#

• כל טבלה חייבת: id, created_at, updated_at
• אל תשמור JSON בלתי-מובנה בשדות אלא אם אין ברירה — ותסביר למה
• כל שינוי בטבלה — דרך Migration (קובץ שינוי מסודר), לא ידני

Frontend#

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

Authentication (זיהוי משתמשים)#

• תמיד Middleware (שכבת בדיקה) — לא בדיקות בתוך כל endpoint
• טוקן JWT — תמיד עם תוקף פג (לא לנצח)

לפני שמתחיל לכתוב כל פיצ'ר — שאל את השאלות האלה#

1. אם יהיו 100 משתמשים — האם הקוד הזה יעבוד? אם לא — מה צריך לשנות כדי שכן?

2. אם נוסיף עוד שדה לטבלה הזאת בעתיד — האם צריך לשנות 10 מקומות בקוד, או אחד?

3. האם אני יוצר קוד "שבור" שאנחנו מסכימים לשבור מאוחר יותר? אם כן — סמן אותו עם TODO: REFACTOR-BEFORE-SCALE

TODO: REFACTOR-BEFORE-SCALE#

כשאתה בונה משהו שאתה יודע שלא יתאים לגדילה — כתוב בקוד מעליו:

ה.3 — כיצד לשלב את ה-Skill הזה בפועל#

בכל שיחה שבה אתה מתחיל לבנות פיצ'ר חדש, כתוב:

לפני שמתחיל — טען את architecture skill ושאל את השאלות הארכיטקטוניות.

רק אחרי שענית עליהן ב-Artifact — תתחיל לכתוב קוד.

דוגמה לאיך Artifact ארכיטקטוני נראה:

ניתוח ארכיטקטורי — מערכת תשלומים#

MVP שנבנה עכשיו:#

• Stripe Checkout (הפניה לדף תשלום של Stripe, לא עיבוד מקומי)
• שמירת מצב הזמנה בבסיס נתונים: pending/paid/failed
• שליחת מייל אחרי תשלום מוצלח

מה לא נבנה עכשיו (אבל לא נחסום):#

• ניהול Subscriptions — לא עכשיו, אבל הטבלאות ייבנו עם subscription_id כשדה nullable (ריק)
• תמיכה בכמה מטבעות — נשמור currency כשדה בכל עסקה כבר עכשיו
• Refunds — נסמן TODO: REFACTOR-BEFORE-SCALE בendpoint של ה-webhook

שאלות שענינו עליהן:#

• 100 משתמשים? ✓ Stripe מטפל בעומס, לא אנחנו
• שדה נוסף בעסקה? ✓ Migration יטפל בזה

חלק ו׳ — צוות סוכנים: הגדרה, הפעלה, מניעת קונפליקטים#

ו.1 — מה זה "צוות סוכנים" ואיך הוא שונה מסוכן אחד#

הקצה סוכנים מרובים ל-Workspaces שונים בתוך פרויקט אחד — אחד לפרונטאנד, אחד ל-API, אחד לבדיקות. כל סוכן שומר על Context עצמאי, מה שמונע קונפליקטים ומאפשר פיתוח מקבילי אמיתי. (בתיעוד הרשמי העדכני הסוכנים פועלים בתוך Projects.)

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

ו.2 — שלוש דרכים לבנות צוות סוכנים#

דרך 1 — ה"טהורה" (מומלצת למתחילים):

פרויקט אחד = Workspace אחת = סוכן אחד בכל פעם.

שולחים סוכן לפרונטאנד, מחכים לסיום, שולחים לבאקאנד.

יתרון: פשוט, ללא קונפליקטים.

חיסרון: איטי — עובדים בסדרה, לא במקביל.

דרך 2 — מקבילית עם הפרדת Workspaces:

פרויקט אחד, שלושה Workspaces נפרדים:

• my-app-frontend/ — Workspace לפרונטאנד
• my-app-backend/ — Workspace לבאקאנד (API)
• my-app-tests/ — Workspace לבדיקות

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

חיסרון: שינויים שמשפיעים על שניים (לדוגמה: שינוי ב-API שמשפיע על הפרונטאנד) צריכים תיאום ידני.

דרך 3 — מקבילית עם הפרדת Branch-ים ב-Git:

Workspace אחד, כמה סוכנים, כל סוכן עובד על Branch נפרד ב-Git.

זה מתקדם יותר — ונסביר בהמשך.

ו.3 — מניעת קונפליקטים: מה יכול להישבר ואיך מונעים#

קונפליקט Git = שני סוכנים ערכו את אותו קובץ בו-זמנית. Git לא יודע מה לשמור.

הפתרון המרכזי: כל סוכן עובד על Branch (ענף) נפרד ב-Git.

Branch הוא "עותק" של הקוד שמאפשר לעבוד בלי לפגוע בגרסה הראשית.

הוסף ל-rules.md (ראו הערה בחלק ד.2 על מבנה Rules הרשמי):

כלל עבודת Branch#

כל שיחה עם סוכן מתחילה ביצירת Branch חדש:

1. git checkout -b agent/[שם-המשימה] — ליצור Branch

2. עבוד על ה-Branch

3. בסיום — git commit -am "תיאור מה נבנה"

4. אל תעשה merge (איחוד) לבד — השאר לי

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

ו.4 — מי עובד על מה: מפת אחריות ל-3 סוכנים#

עקרון ה-Ownership: כל סוכן "מחזיק" בתחום מוגדר. תחומים לא חוצים זה את זה.

| סוכן | תחום | קבצים שנוגע בהם | קבצים שלא נוגע |

| Frontend Agent | כל מה שהמשתמש רואה | src/app/, components/, styles/ | api/, server/, database/ |

| Backend Agent | לוגיקה ו-API | api/, server/, middleware/ | components/, styles/ |

| QA Agent | בדיקות | tests/, e2e/ | לעולם לא קוד ייצור |

הוסף ל-CONTEXT.md של כל Workspace:

מפת אחריות#

Frontend Agent (הסוכן בWorkspace הזה):

• מחזיק ב: src/app/, src/components/, src/styles/
• אסור לו לגעת ב: api/, server/, database/
• כשצריך נתון מה-API — כתוב ב-Artifact מה ה-endpoint שאתה צריך, לא תכתוב אותו בעצמך

ו.5 — האם ריצת כמה סוכנים במקביל מאיטה את המחשב?#

תשובה קצרה: כן, קצת — אבל פחות ממה שנדמה.

מה קורה כשסוכן רץ:

• ה-AI עצמו רץ על שרתי גוגל — לא על המחשב שלך. הכוח החישובי של המודל הוא שם, לא כאן.
• מה שרץ על המחשב: עורך הקוד, Terminal, הדפדפן, Node.js server

כמה RAM לצפות לצריכה:

כל אחד מהרכיבים הבאים צורך זיכרון: Antigravity עצמו, כל Terminal process שהסוכן פותח, כל חלון Chrome שהסוכן פותח, ו-dev server של Node.js. הערכות המספריות שהופיעו כאן בעבר (ובהן סכום כולל לשלושה סוכנים והמלצות לפי 8GB / 16GB) הוסרו כי אין להן מקור רשמי; ראו את דרישות המערכת הרשמיות ב-antigravity.google/docs/getting-started.

טיפ לחסכון: אל תפתח שלושה Chrome Windows במקביל. תן לכל סוכן לפתוח Chrome רק כשהוא צריך לבדוק, ולסגור אחר כך.

חלק ז׳ — שמירת עבודה: Git, גיבויים, ואיך לא לאבד כלום#

ז.1 — Git: מה זה ולמה אי אפשר בלעדיו#

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

מטאפורה: Git הוא כמו ה"Undo History" של Photoshop, אבל לכל קבצי הפרויקט ביחד — ועם אפשרות לקפוץ לכל נקודה בהיסטוריה, לא רק "אחורה" ו"קדימה".

Git פועל בלי שתגע בו — אם הסוכן שלך מוגדר נכון. הוסף ל-rules.md (ראו הערה בחלק ד.2):

כלל Git#

• לאחר כל משימה שהסתיימה בהצלחה — עשה commit
• הודעת commit תתאר מה נעשה: "Add user registration form" ולא "Changes"
• אל תצבור שינויים גדולים ב-commit אחד — commit קטן וממוקד עדיף
• אל תעשה git push לבד (שליחה לשרת) — שאל אותי קודם

כיצד רואים את ההיסטוריה: ב-Terminal: git log --oneline

ז.2 — GitHub: איפה הגיבוי האמיתי חי#

GitHub הוא שירות אינטרנטי שמאחסן את ה-Git repository שלך בענן. אם המחשב שלך נשרף — הקוד שלך בטוח.

הגדרה ראשונית:

1. פתח חשבון ב-github.com (חינמי)

2. צור Repository חדש (כמו תיקיה בענן לפרויקט שלך)

3. בקש מהסוכן: "חבר את הפרויקט ל-GitHub Repository שיצרתי. ה-URL הוא: [URL]"

4. הסוכן יריץ את פקודות הגדרת ה-Remote לבד

מכאן: כל פעם שתבקש git push — הקוד עולה לענן.

ז.3 — גיבוי נוסף: קובץ CONTEXT.md ידני#

מעבר ל-Git (שמגבה קוד), יש עוד דבר חשוב לגבות: הידע — הסיכומים, ההחלטות, מה שהסוכן עשה ולמה.

כתוב עבור הסוכן:

בסיום כל שיחה שבה בנינו משהו, עדכן את קובץ .agent/context.md עם:

• מה בנינו בשיחה זו
• כל החלטה ארכיטקטונית שקיבלנו ולמה
• מה ה-endpoints שיצרנו
• מה עדיין לא גמור (TODO)

למה זה קריטי: כשתפתח שיחה חדשה עם סוכן, הוא יקרא את CONTEXT.md ויידע הכל — בלי שתצטרך להסביר מחדש.

חלק ח׳ — סקיצת מסכים ו-Wireframing: האם Antigravity יודע לצייר?#

ח.1 — שאלה ישירה, תשובה ישירה#

Antigravity לא מפעיל Figma. הוא לא מייצר קובץ עיצוב. אבל הוא כן יכול לייצר סקיצות מסכים — בשלוש צורות שונות, שכל אחת מתאימה לשלב אחר.

ח.2 — שלוש שיטות לסקיצת מסכים עם Antigravity#

שיטה 1 — HTML Wireframe (הכי מהיר, לסכמה בלבד)

לפני שמתחיל לבנות את [שם הדף], אני רוצה לאשר את הפריסה.

בנה wireframe ב-HTML פשוט — ללא CSS מורכב, ללא צבעים.

רק קופסאות אפורות שמייצגות:

• Header עם הלוגו ו-Navigation
• Hero Section עם כותרת וCTA
• 3 כרטיסי מוצרים בשורה
• Footer

הרץ את ה-HTML בדפדפן וצלם מסך. אני רוצה לאשר פריסה לפני שמתחילים עיצוב.

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

שיטה 2 — Figma-Style ASCII בMarkdown (לתיעוד מבנה)

צור תרשים תוכן של [שם המסך] בפורמט Markdown.

תאר כל סקשן, מה בתוכו, ואיפה הוא ממוקם.

לדוגמה:

┌─────────────────────────────┐

│ HEADER: לוגו + ניווט │

├─────────────────────────────┤

│ HERO: כותרת + כפתור CTA │

├────────────┬────────────────┤

│ SIDEBAR │ MAIN CONTENT │

│ (40%) │ (60%) │

└────────────┴────────────────┘

תוצאה: תרשים טקסטואלי שמסביר מבנה.

שיטה 3 — Interactive Prototype ב-HTML/CSS (הכי קרוב לאמת)

בנה prototype אינטראקטיבי מלא של [שם הדף] ב-HTML+CSS+JavaScript.

השתמש ב-Design System Skill שלנו לצבעים ולפונטים.

אין צורך ב-backend — כל הנתונים יהיו hard-coded (מזויפים).

מטרת הpageוtype: שאני אוכל להסתובב בו ולחוש את הזרימה לפני שמתחיל לבנות את הגרסה האמיתית.

אחרי שגמרת — פתח בדפדפן וצלם Browser Recording שמראה את כל הזרימה.

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

ח.3 — מתי להשתמש בכל שיטה#

| שלב | שיטה | משך |

| בתחילת פרויקט — אישור מבנה | HTML Wireframe | 5-10 דק׳ |

| לפני שיחה עם משקיע/לקוח | Interactive Prototype | 30-60 דק׳ |

| לפני כל דף חדש | ASCII Markdown Diagram | 2-5 דק׳ |

| לאחר שבנינו — בדיקה | Browser Recording Artifact | אוטומטי |

ח.4 — Prompt מלא לbuild תהליך UX לפני כתיבת קוד#

זה ה-Prompt שמוודא שהסוכן מבין את הזרימה לפני שהוא בונה:

לפני שמתחיל לבנות את [שם הפרויקט], אני רוצה לעבור יחד על User Journey.

1. תאר בArtifact את הזרימה של משתמש חדש מהרגע שהוא נכנס לאתר ועד שמבצע את הפעולה הראשית ([פעולה: רכישה / הרשמה / שליחת טופס]).

2. כמה clicks יש מהדף הראשי לפעולה? רשום.

3. אילו מסכים צריכים להיות? רשום כל מסך בשורה אחת.

4. בנה HTML Wireframe פשוט לשלושת המסכים הכי חשובים.

5. אחרי שאאשר — תתחיל לבנות.

חלק ט׳ — טבלת עזר מהירה: כל מצב, כל תרחיש, מה עושים#

ט.1 — שאלות נפוצות בפורמט מהיר#

| מצב | מה לעשות |

| "הסוכן ביקש ממני לבדוק" | הוסף לrules.md את כלל הבדיקה העצמית (חלק ד.2) |

| "הסוכן עשה commit על הכל בbranch ראשי" | הוסף לrules.md כלל Branch (חלק ו.3) |

| "אני הולך לישון" | הגדר Turbo + Deny List + הוראות עצמאות (חלק ג.2) |

| "שני סוכנים שברו קבצים ביחד" | עבור לשיטת הפרדת Workspaces (חלק ו.2, דרך 2) |

| "המחשב איטי מדי עם שלושה סוכנים" | סגור Chrome windows שלא בשימוש, עבוד עם 2 סוכנים |

| "הסוכן בנה דבר שיצטרך refactor" | הוסף Architecture Skill (חלק ה.2) לפני המשימה הבאה |

| "רוצה לראות סקיצה לפני הבנייה" | בקש HTML Wireframe (חלק ח.2, שיטה 1) |

| "אבדתי עבודה של שעה" | הפעל git log --oneline ו-git checkout [hash] לשחזור |

| "הסוכן מציע שינויים שאני לא בטוח בהם" | בקש Planning Mode + Implementation Plan לפני כל עריכה |

| "רוצה פרויקט שני בלי לגעת בראשון" | פתח Workspace חדש (חלק ב.1), אין קשר |

ט.2 — מחזור חיים של שיחה אידיאלית#

[פתיחת שיחה]

↓

שלח: "סרוק את הפרויקט ודווח מה אתה מבין"

↓

קרא את ה-Artifact — ודא שהסוכן מבין את ההקשר

↓

תן משימה ברורה (Plan Mode)

↓

קרא Implementation Plan — הוסף הערות אם צריך → Approve

↓

הסוכן עובד — אתה עושה משהו אחר

↓

קרא Artifacts (Screenshot + Summary)

↓

אם טוב: תן משימה הבאה

אם לא: הוסף הערה ספציפית על ה-Artifact → הסוכן מתקן

↓

בסיום פיצ'ר: "עדכן context.md, עשה Git commit"

↓

[סגור שיחה — פתח חדשה לפיצ'ר הבא]

המדריך הזה משלים את הפרקים 1-6 של המדריך המחקרי הראשי. יחד הם מהווים תמונה מלאה — מהורדה ועד בניית מוצר פועל.