Fleet ו-Sub-agents — עבודה במקביל

/fleet Refactor these 4 modules from callbacks to async/await, add proper TypeScript types, and implement consistent error handling with our AppError class:
1. src/payments/ — payment processing module
2. src/invoices/ — invoice generation module
3. src/webhooks/ — webhook handler module
4. src/reports/ — reporting module
Each module is independent. Use the patterns from src/shared/error-handler.ts as reference.

מה זה /fleet ולמה זה משנה את המשחק

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

/fleet (פליט) משנה את זה. זו פקודת slash ב-Copilot CLI שהופכת סוכן בודד לצוות שלם של סוכנים שעובדים במקביל. במקום שסוכן אחד יעבוד על 4 מודולים ברצף, fleet מפעיל 4 סוכנים שעובדים על כולם בו-זמנית.

תחשבו על זה כמו צוות פיתוח:

• בלי fleet = מפתח אחד שעובד על 4 משימות ברצף. משימה 1 ← משימה 2 ← משימה 3 ← משימה 4. זמן כולל: 4 שעות.
• עם fleet = 4 מפתחים שכל אחד לוקח משימה אחת. כולם עובדים במקביל. זמן כולל: שעה אחת (+ קצת זמן תיאום).

אתם ה-Tech Lead. אתם מגדירים את המשימה. /fleet לוקח את התפקיד של מנהל הצוות — מפרק, מחלק, מנטר, ומאחד תוצאות.

הנקודה הקריטית: fleet לא רק מאיץ — הוא משנה את אופי העבודה. במקום לחשוב "איך אני עושה את זה", אתם מתחילים לחשוב "איך אני מפרק את זה לחלקים עצמאיים." וזו חשיבה של מנהל פרויקט, לא של מפתח בודד.

מה fleet לא עושה

חשוב להבהיר מראש: fleet לא קסם. הוא לא הופך משימה סדרתית מטבעה לפתאום מקבילית. הוא לא פותר merge conflicts בשבילכם. והוא לא חוסך premium requests — הוא בדרך כלל צורך יותר. fleet חוסך זמן, לא כסף. אם המשימה שלכם היא "תתקן את הבאג הזה בקובץ X" — fleet לא יעזור כי אין מה לפרק. fleet מבריק כשיש לכם משימה שמורכבת מכמה חלקים עצמאיים שיכולים לרוץ בו-זמנית.

מי יכול להשתמש ב-fleet?

fleet זמין לכל מי שמשתמש ב-Copilot CLI עם מנוי פעיל (Pro, Pro+, Business, Enterprise). Copilot CLI הגיע ל-General Availability ב-25 בפברואר 2026, ו-fleet היה חלק מהשחרור. אם ה-CLI שלכם מעודכן לגרסה האחרונה — fleet זמין ומוכן לשימוש. אין צורך בהתקנה נפרדת או הפעלה — זו פקודת slash מובנית שעובדת מהרגע הראשון.

דרישות מינימום:

• Copilot CLI מותקן ומעודכן (גרסה GA ומעלה)
• מנוי Copilot פעיל (כולל Free tier — אבל שימו לב שב-Free יש מגבלת premium requests)
• פרויקט עם לפחות 2-3 קבצים שצריכים שינוי עצמאי

איך fleet עובד — מאחורי הקלעים

כשאתם כותבים /fleet לפני הפרומפט, Copilot CLI לא פשוט "מריץ מהר יותר". מופעל תהליך מסודר של 4 שלבים שמנוהל על ידי Orchestrator (מתזמר) — סוכן ראשי שלא כותב קוד בעצמו, אלא מנהל את הצוות:

שלב 1: ניתוח הפרומפט

ה-Orchestrator קורא את הפרומפט שלכם ומחליט: האם המשימה הזו ניתנת לפירוק? אם כתבתם "תתקן את הבאג בקובץ X" — אין מה לפרק, וfleet ירוץ כמו סוכן רגיל. אם כתבתם "תעדכן 4 מודולים" — ה-Orchestrator מזהה שזה ניתן לפיצול.

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

שלב 2: פירוק וזיהוי תלויות

ה-Orchestrator מחלק את המשימה לwork items (יחידות עבודה) ובונה גרף תלויות (Dependency Graph). לכל work item הוא מגדיר:

• מה בדיוק צריך לעשות
• אילו קבצים מעורבים
• האם הוא תלוי ב-work item אחר (ואם כן — באיזה)

Work items עצמאיים מסומנים כ"מוכנים לשיגור". Work items תלויים נכנסים לתור המתנה.

שלב 3: שיגור מקבילי

ה-Orchestrator משגר sub-agents (סוכני משנה) — כל אחד מקבל work item אחד. הנקודה החשובה: כל sub-agent מקבל context window נפרד ומבודד. הוא לא רואה את מה שה-sub-agents האחרים עושים. זה כמו 4 מפתחים שכל אחד יושב בחדר נפרד עם מפרט ברור.

ההפרדה הזו היא גם יתרון וגם מגבלה:

• יתרון: אין התנגשויות context — כל sub-agent ממוקד במשימה שלו בלי רעש
• מגבלה: sub-agent לא יכול "לשאול" sub-agent אחר שאלה. אם יש תלות — זה חייב להיות דרך ה-Orchestrator

שלב 4: מיזוג תוצאות

ה-Orchestrator עושה polling — בודק כל כמה שניות אם sub-agents סיימו. כשכל ה-sub-agents של הגל הנוכחי מסיימים:

• אם יש עוד גל (work items שהמתינו לתלויות) — הוא משגר את הגל הבא
• אם הכל סיים — הוא ממזג את התוצאות לתוצאה אחודה ומציג לכם את הסיכום

המיזוג הוא החלק הרגיש ביותר. ה-Orchestrator צריך לחבר שינויים מכמה sub-agents לתוצאה אחת קוהרנטית. ברוב המקרים, כשה-sub-agents עבדו על קבצים שונים — זה פשוט: כל sub-agent שינה קבצים שלו, ואין התנגשות. אבל אם שני sub-agents נגעו באותו קובץ (למשל — שניהם הוסיפו exports ל-index.ts) — ייתכנו merge conflicts. ה-Orchestrator ינסה לפתור אותם, אבל לא תמיד יצליח.

למה context isolation חשוב: כל sub-agent מקבל context window נפרד — הוא לא רואה את הקבצים ששאר ה-sub-agents עובדים עליהם, ולא יודע מה השתנה מחוץ ל-scope שלו. זה מה שמאפשר parallelism אמיתי (אין "ריצה" על shared state), אבל גם מה שיוצר סיכון: שני sub-agents יכולים לקבל החלטות סותרות אם לא נתתם להם הנחיות ברורות. למשל — אם ביקשתם "add error handling" בלי לציין איך, כל sub-agent עלול ליצור מנגנון error שונה.

הפעלת /fleet — מהלכה למעשה

הסינטקס בסיסי — מוסיפים /fleet לפני הפרומפט:

/fleet [הפרומפט שלכם כאן]

אבל ההבדל בין fleet שעובד מעולה לבין fleet שרץ סדרתי ולא עוזר — הוא באיכות הפרומפט. הנה ההבדלים:

פרומפט חלש (fleet לא יצליח לפרק)

/fleet Fix all the issues in the project

למה זה נכשל: ה-Orchestrator לא יכול לזהות חלקים עצמאיים. "all the issues" זה כללי מדי. fleet יחזור לריצה סדרתית של סוכן בודד — בזבוז.

פרומפט טוב (fleet יפרק ביעילות)

/fleet Perform the following independent tasks:
1. Add input validation to src/api/users.ts — validate email, name length, password strength
2. Add input validation to src/api/products.ts — validate price range, SKU format, description length
3. Add input validation to src/api/orders.ts — validate order items, quantities, shipping address
4. Write unit tests for all 3 validators in tests/validators/

למה זה עובד: כל item ממופה לקבצים ספציפיים, כל item עצמאי, ויש deliverable ברור לכל אחד. ה-Orchestrator יזהה ש-items 1-3 יכולים לרוץ במקביל, ו-item 4 צריך לחכות שהם יסיימו (כי הטסטים תלויים בקוד שנכתב).

מה לצפות אחרי ההרצה

כשfleet מתחיל לרוץ, תראו בטרמינל הודעה שמציינת כמה sub-agents נוצרו ומה כל אחד עושה. למשל:

Fleet: Decomposing task into 4 subtasks...
  [1/4] Adding validation to users.ts — dispatching sub-agent
  [2/4] Adding validation to products.ts — dispatching sub-agent
  [3/4] Adding validation to orders.ts — dispatching sub-agent
  [4/4] Writing tests — waiting for 1-3 to complete

ברגע שה-sub-agents הראשונים יוצאים, תראו התקדמות ב-output. כשכולם מסיימים, fleet מציג סיכום של מה בוצע, אילו קבצים שונו, ואם הייתה בעיה. תמיד בדקו את הסיכום — אם sub-agent נכשל, fleet יציין את זה.

מה קורה כשfleet לא מצליח לפרק?

אם הפרומפט שלכם כללי מדי, ה-Orchestrator לא יזהה חלקים עצמאיים. במקרה הזה, fleet פשוט ירוץ כסוכן רגיל — בלי parallelism. לא תקבלו שגיאה, אלא ריצה סדרתית רגילה. זה לא נורא — אבל זה מבזבז את ה-overhead של fleet (ניתוח הפרומפט) בלי תועלת. אם אתם רואים שfleet רץ סדרתי — תעצרו, שפרו את הפרומפט, ונסו שוב.

אנטומיה של fleet prompt מוצלח

בואו ננתח את הפרומפט הטוב שראינו למעלה ונבין למה כל חלק חשוב:

• "Perform the following independent tasks:" — המילה "independent" היא סיגנל ל-Orchestrator שאפשר להקביל. בלי המילה הזו, הוא ינסה לנחש
• מספור (1. 2. 3. 4.) — מספור ברור מאפשר ל-Orchestrator לזהות כל item כ-work unit נפרד
• שם קובץ מלא (src/api/users.ts) — ה-Orchestrator יודע בדיוק אילו קבצים כל sub-agent צריך. בלי שמות — הוא חייב לחפש, מה שמוסיף זמן ו-overhead
• תיאור ספציפי ("validate email, name length, password strength") — כל sub-agent יודע בדיוק מה לעשות, בלי לנחש
• "(depends on 1,2,3)" — תלות מפורשת שמונעת מ-item 4 לצאת לפני שהאחרים סיימו

5 כללים לכתיבת fleet prompt מנצח

תלויות בין משימות — מקביל vs סדרתי

לא כל משימה ניתנת להרצה מקבילית. ה-Orchestrator חייב להבין מה תלוי במה כדי להחליט מה רץ ביחד ומה מחכה. הנה שני דפוסים קלאסיים:

דפוס 1: מקביל מלא (Fully Parallel)

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

/fleet
1. Add error handling to src/services/auth.ts
2. Add error handling to src/services/payment.ts
3. Add error handling to src/services/notification.ts
4. Add error handling to src/services/search.ts

כאן כל 4 המשימות רצות בו-זמנית. שום אחת לא תלויה באחרת. זה התרחיש האידיאלי ל-fleet.

דפוס 2: גלים (Waves / Staged)

חלק מהמשימות תלויות בתוצאות של אחרות:

/fleet
1. Create shared error types in src/types/errors.ts
2. Create shared validation utils in src/utils/validation.ts
3. Refactor src/api/users.ts to use the new error types and validation (depends on 1,2)
4. Refactor src/api/products.ts to use the new error types and validation (depends on 1,2)
5. Update tests in tests/ for all changed files (depends on 3,4)

ה-Orchestrator יזהה 3 גלים:

• גל 1: items 1 + 2 (במקביל — שניהם עצמאיים)
• גל 2: items 3 + 4 (במקביל — שניהם תלויים ב-1+2, אבל עצמאיים ביניהם)
• גל 3: item 5 (מחכה ש-3+4 יסיימו)

טיפ מעשי: אם אתם יודעים שיש תלויות, ציינו אותן במפורש בפרומפט. כתבו "(depends on 1,2)" או "after items 1-3 are done". ה-Orchestrator מנסה לזהות תלויות לבד, אבל הוא יעשה עבודה טובה יותר אם אתם עוזרים לו.

דפוס 3: סדרתי מלא (Fully Sequential)

לפעמים אין שום parallelism. כל שלב תלוי בשלב הקודם:

# לא מתאים ל-fleet!
1. Create database schema migration
2. Update ORM models to match new schema (depends on 1)
3. Update API routes to use new models (depends on 2)
4. Update frontend to match new API (depends on 3)

במקרה כזה, אל תשתמשו ב-fleet. ה-Orchestrator ירוץ סדרתי (גל 1 = item 1, גל 2 = item 2, וכו') — ותשלמו את ה-overhead של fleet בלי שום parallelism. עדיף סוכן בודד שיעבוד ברצף.

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

שאלו את עצמכם 3 שאלות על כל זוג items:

1. האם item B קורא קובץ ש-item A כותב? אם כן — B תלוי ב-A.
2. האם item B מייבא (import) מקובץ ש-item A משנה? אם כן — B תלוי ב-A.
3. האם ניתן להריץ את item B גם אם item A לא קיים? אם כן — הם עצמאיים.

אם כל שני items עוברים את שאלה 3 בהצלחה — הם מתאימים ל-parallelism. אם לא — סמנו תלות.

ניטור: /tasks ומעקב אחרי fleet

אחרי שfleet יוצא לדרך, אתם לא צריכים לשבת ולחכות בחושך. הפקודה /tasks היא חלון הבקרה שלכם — היא מציגה את כל המשימות הרקע בסשן הנוכחי, כולל כל sub-agent שfleet יצר.

איך להשתמש ב-/tasks

פשוט מקלידים /tasks בזמן שfleet רץ. נפתח דיאלוג עם רשימת כל המשימות:

מתי להתערב

• Sub-agent תקוע: אם sub-agent רץ כבר 10+ דקות על משימה שאמורה לקחת 2, לחצו k להרוג אותו. Fleet ימשיך עם שאר המשימות
• Sub-agent בלולאה: אם אתם רואים ב-details שהוא חוזר על אותה פעולה שוב ושוב — kill ותחשבו על ניסוח אחר למשימה הזו. לולאות קורות בדרך כלל כשהמשימה לא ברורה מספיק
• Sub-agent נכשל: אם sub-agent קיבל שגיאה ועצר, fleet ימשיך עם שאר המשימות. תוכלו לטפל במשימה שנכשלה ידנית אחרי שfleet מסיים
• כל ה-sub-agents סיימו: fleet יציג סיכום אוטומטי. בדקו אותו — האם כל המשימות הצליחו? האם יש שינויים שנראים לא נכונים?

טיפ: תזמון /tasks

אין סיבה להריץ /tasks מיד — fleet צריך כמה שניות להפעיל את ה-sub-agents. המלצה: חכו 10-15 שניות אחרי שfleet מתחיל, ואז הריצו /tasks. ככה תראו את כל ה-sub-agents כשהם כבר בפעולה, ולא רשימה ריקה.

אפשר להריץ /tasks כמה פעמים במהלך fleet — זה לא מפריע לריצה. כל פעם תראו סטטוס מעודכן. אם sub-agent סיים, הסטטוס שלו יעבור מ-"running" ל-"completed".

Background tasks (4 total):
  [1] ✅ Add validation to users.ts       — completed (2m 14s)
  [2] 🔄 Add validation to products.ts    — running (1m 48s)
  [3] ✅ Add validation to orders.ts       — completed (1m 52s)
  [4] ⏳ Write tests for validators        — waiting (depends on 1,2,3)

עלות fleet — חישוב premium requests מראש

זה אולי הנושא הכי חשוב בפרק הזה, וגם הכי מוזנח: fleet עולה יותר מסוכן בודד. לא "קצת יותר" — אלא כפולות. כל sub-agent הוא מופע עצמאי שצורך premium requests בנפרד.

הנוסחה

עלות fleet = סכום (אינטראקציות של כל sub-agent × מכפיל המודל)

בואו נראה דוגמה מעשית:

שימו לב: fleet עם 3 sub-agents לא בהכרח עולה 3 פעמים יותר, אבל הוא כמעט תמיד עולה יותר מסוכן בודד. הסיבה: כל sub-agent מתחיל מ-context ריק, כך שהוא צריך כמה אינטראקציות ראשוניות "להבין את הסביבה" — overhead שלא קיים בסוכן בודד שכבר מכיר את הפרויקט.

חישוב מעשי: כמה credits ל-fleet?

בואו נחשב דוגמה ריאלית. נניח שיש לכם משימה שדורשת refactoring של 4 מודולים:

• סוכן בודד: יעבוד סדרתית, ~10 אינטראקציות LLM (קריאת קובץ, תכנון, כתיבה, בדיקה — לכל מודול). סה"כ: 10 אינטראקציות
• fleet עם 4 sub-agents: כל sub-agent יעשה ~4-5 אינטראקציות (קריאת הקובץ שלו, תכנון, כתיבה, בדיקה). בנוסף ה-Orchestrator עושה ~2-3 אינטראקציות (ניתוח, שיגור, מיזוג). סה"כ: 4×5 + 3 = ~23 אינטראקציות

עם מודל 0x (חינם) — שני המקרים עולים 0 credits. fleet הוא כלי חינמי בפועל.

עם Claude Sonnet (0.5x): סוכן בודד = 10×0.5 = 5 credits. Fleet = 23×0.5 = 11.5 credits. fleet עולה כפול.

עם Opus (3x): סוכן בודד = 10×3 = 30 credits. Fleet = 23×3 = 69 credits. fleet עולה 2.3 פעמים יותר.

המסקנה ברורה: fleet + מודל 0x = win-win. fleet + מודל יקר = חישוב עלות-תועלת.

מתי העלות המוגברת מוצדקת?

התשובה תלויה בזמן שלכם. אם fleet חוסך שעה ועולה 20 credits נוספים — ושעת עבודה שלכם שווה יותר מ-$0.80 (20 × $0.04) — fleet מוצדק מבחינה כלכלית. ברוב המקרים, הזמן שfleet חוסך שווה הרבה יותר מהעלות הנוספת. אבל אם אתם קרובים למגבלת ה-credits החודשית ולא רוצים להיכנס ל-overage — כדאי לשקול.

Overage — מה קורה כשנגמרים הקרדיטים?

כל מנוי Copilot כולל מספר קבוע של premium requests לחודש (למשל: Pro = 300). כשנגמרים, כל request נוסף עולה $0.04. עכשיו תחשבו: fleet של 4 sub-agents עם Claude Opus (3x) שצורך ~70 credits בהפעלה אחת — אם אתם כבר ב-overage, זה $2.80 על הפעלה אחת. לא הרבה — אבל אם אתם מריצים fleet 5 פעמים ביום, זה $14 ביום, $280 בחודש עבודה. תמיד בדקו כמה credits נשארו לפני fleet עם מודל יקר.

מצד שני, fleet עם GPT-4.1 (0x) — אפס עלות, אפס overage, ללא הגבלה. לרוב המשימות (refactoring, docs, tests) GPT-4.1 מספיק. שמרו את Opus ו-Sonnet לסוכן בודד על משימות שדורשות הבנה עמוקה.

מתי fleet מושלם — 5 תרחישים אידיאליים

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

1. Refactoring מרובה קבצים

3-10 קבצים שצריכים את אותו סוג שינוי: מעבר ל-async/await, הוספת types, שינוי import style.

/fleet Refactor the following services from class-based to functional:
1. src/services/user-service.ts
2. src/services/order-service.ts
3. src/services/payment-service.ts
Use arrow functions, remove 'this' references, export individual functions.

2. יצירת Test Suite

כתיבת טסטים ל-N מודולים שכל אחד עצמאי:

/fleet Write comprehensive unit tests for each module:
1. tests/auth.test.ts for src/auth/ — test login, register, forgot-password
2. tests/cart.test.ts for src/cart/ — test add, remove, update quantity
3. tests/checkout.test.ts for src/checkout/ — test payment flow, validation

3. עדכון תיעוד

כתיבת/עדכון docs למספר components:

/fleet Update JSDoc documentation for all public functions in:
1. src/components/Button.tsx
2. src/components/Modal.tsx
3. src/components/Table.tsx
4. src/components/Form.tsx
Follow the documentation style in src/components/Input.tsx as reference.

4. Migration של dependencies

מעבר מספריה A לספריה B ב-N קבצים:

/fleet Migrate from moment.js to date-fns in all files:
1. src/utils/date-formatter.ts
2. src/components/DatePicker.tsx
3. src/api/reports.ts
4. src/hooks/useCountdown.ts
Replace all moment() calls with equivalent date-fns functions.

5. Feature חוצה שכבות

פיצ'ר שדורש שינויים ב-API + UI + tests כשכל שכבה עצמאית:

/fleet Implement dark mode support:
1. Add theme types and context in src/theme/
2. Update all CSS variables in src/styles/variables.css
3. Add toggle component in src/components/ThemeToggle.tsx
4. Write tests for theme switching in tests/theme.test.ts (depends on 1,3)

מה משותף ל-5 התרחישים?

שימו לב לדפוס: בכל 5 התרחישים יש הפרדה ברורה של קבצים. כל sub-agent עובד על קובץ/תיקייה אחרים, ואין חפיפה. זה הסוד של fleet: ככל שהחלוקה נקייה יותר — התוצאה טובה יותר. אם אתם יכולים להצביע על כל item ולומר "זה נוגע רק בקובץ X" — fleet יעבוד מצוין.

כלל האצבע: אם כל item בפרומפט ממופה ל-קובץ או תיקייה ייחודיים — fleet הוא הבחירה הנכונה. אם items חולקים קבצים — חשבו פעמיים.

מתי לא להשתמש ב-fleet — מלכודות נפוצות

fleet הוא לא "תמיד טוב יותר". יש מצבים שבהם fleet מזיק יותר מאשר עוזר:

❌ תרחיש 1: משימות סדרתיות

"תבנה את ה-database schema, אחר כך ה-API, אחר כך ה-UI." — כל שלב תלוי בקודם. fleet לא יוכל להקביל כלום. ה-Orchestrator ירוץ סדרתי ותשלמו overhead מיותר. פתרון: סוכן בודד שעובד ברצף — אותה תוצאה, פחות overhead.

❌ תרחיש 2: קוד מקושר (Tightly Coupled)

שני קבצים שמייבאים אחד מהשני, משתמשים באותם types, ותלויים בהתנהגות משותפת. למשל: user-service.ts ו-auth-service.ts ששניהם מייבאים מ-types/user.ts ומשתמשים זה בזה. אם שני sub-agents ישנו אותם במקביל — כל אחד עלול לשנות את ה-types בצורה שונה, ותקבלו קוד שלא מתקמפל. פתרון: סוכן בודד שרואה את כל התמונה.

❌ תרחיש 3: קבצים משותפים

אם כמה sub-agents נוגעים באותו קובץ (למשל — כולם צריכים לעדכן את index.ts כי הם מוסיפים exports) — ה-Orchestrator ינסה למזג, אבל הסיכוי לקונפליקט גבוה. דמיינו 3 sub-agents שכל אחד מוסיף שורה שונה לאותו קובץ — ה-merge עלול ליצור duplicate imports, missing exports, או סדר שגוי. פתרון: הוציאו את השינוי בקובץ המשותף ל-item נפרד שרץ אחרי כולם.

❌ תרחיש 4: משימה קטנה

Fleet מוסיף overhead: ניתוח, פירוק, שיגור, polling, מיזוג. ה-overhead הזה לוקח 30-60 שניות. אם המשימה כולה לוקחת 2 דקות עם סוכן בודד — fleet יהיה איטי יותר בגלל ה-overhead. כלל אצבע: fleet משתלם כשהמשימה הסדרתית לוקחת 10+ דקות. מתחת לזה — סוכן רגיל.

❌ תרחיש 5: תקציב קרדיטים מוגבל

אם נשארו לכם 20 premium requests החודש ואתם חושבים על fleet עם מודל 1x — fleet של 4 sub-agents עלול "לאכול" 20-30 credits במכה אחת. עדיף סוכן בודד עם מודל 0x שלא צורך credits כלל. זכרו: overage עולה $0.04 לכל credit. fleet של 4 sub-agents עם Opus (3x) שנכנס ל-overage עלול לעלות כמה דולרים בהפעלה אחת.

סוכנים מותאמים — .agent.md

עד עכשיו השתמשנו בסוכנים המובנים של Copilot CLI (Explore, Task, Plan, Code-review — מפרק 6). אבל מה אם אתם רוצים סוכן שמתמחה בדיוק במה שאתם צריכים? סוכן שיודע את ה-conventions של הפרויקט שלכם, משתמש רק בכלים מסוימים, ועובד עם מודל ספציפי?

זה בדיוק מה ש-Custom Agents (סוכנים מותאמים) עושים. הם מוגדרים בקבצי .agent.md — קבצי Markdown עם YAML frontmatter שמגדיר את הפרופיל של הסוכן.

מבנה קובץ .agent.md

---
name: docs-writer
description: Generates and updates documentation following project conventions
model: gpt-4.1
tools:
  - read
  - edit
  - search
---

# Documentation Writer Agent

You are a documentation specialist for this project.

## Rules
- Always follow JSDoc format for TypeScript files
- Include @param, @returns, and @example for every public function
- Use Hebrew for user-facing docs, English for code docs
- Never modify source code — only documentation

מאפייני YAML frontmatter

איפה שמים את הקובץ?

סדר עדיפויות: קובץ ברמת ריפוזיטורי דורס קובץ באותו שם ברמת ארגון או משתמש. זה מאפשר לפרויקט ספציפי "לדרוס" סוכן ארגוני עם גרסה מותאמת. למשל: הארגון הגדיר סוכן reviewer עם כללים כלליים, אבל הפרויקט שלכם צריך כללים ספציפיים ל-TypeScript — צרו .github/agents/reviewer.agent.md בריפוזיטורי ותדרסו את הגרסה הארגונית.

3 סוכנים מותאמים שכל צוות צריך

הנה 3 תבניות שמכסות את רוב הצרכים:

סוכן 1: Test Generator

---
name: test-generator
description: Generates comprehensive unit and integration tests
model: gpt-4.1
tools:
  - read
  - edit
  - search
---

# Test Generator Agent

## Rules
- Use the project's existing test framework (detect from package.json)
- Follow AAA pattern: Arrange, Act, Assert
- Include edge cases: null, undefined, empty string, boundary values
- Mock external dependencies — never call real APIs
- Aim for 80%+ code coverage on the target file
- Name test files: [original-name].test.ts

סוכן 2: Security Reviewer

---
name: security-review
description: Reviews code for security vulnerabilities and best practices
model: claude-sonnet-4
tools:
  - read
  - search
---

# Security Review Agent

## Focus Areas
- SQL injection, XSS, CSRF vulnerabilities
- Hardcoded secrets or API keys
- Missing input validation
- Insecure dependencies (check package.json)
- Authentication and authorization gaps
- OWASP Top 10 compliance

סוכן 3: Refactorer

---
name: refactorer
description: Refactors code for better readability and maintainability
model: gpt-4.1
tools:
  - read
  - edit
  - search
---

# Refactoring Agent

## Principles
- Extract repeated logic into shared utilities
- Replace magic numbers with named constants
- Simplify nested conditionals with early returns
- Ensure all changes pass existing tests
- Never change public API signatures without explicit approval

הפעלת סוכן מותאם

שתי דרכים:

1. מפורשת: /agent docs-writer — מפעיל את הסוכן ישירות. אתם שולטים מתי ועל מה הוא עובד
2. אוטומטית: Copilot קורא את ה-description ומפעיל את הסוכן כשהמשימה מתאימה. למשל, אם תבקשו "update the docs" ויש סוכן עם description של "documentation" — הוא יופעל אוטומטית. זה עובד כי Copilot משווה את הפרומפט שלכם ל-description של כל סוכן רשום ומחליט איזה מתאים

סוכנים מותאמים + fleet = קומבינציה חזקה

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

/fleet
1. /agent test-generator — write tests for src/api/users.ts
2. /agent test-generator — write tests for src/api/products.ts
3. /agent security-review — review src/api/auth.ts
4. /agent docs-writer — update docs for src/api/

כל sub-agent יקבל את ההנחיות של הסוכן המותאם הרלוונטי — כך שה-test-generator יכתוב טסטים לפי ה-conventions שהגדרתם, ה-security-reviewer יחפש לפי הכללים שלכם, וכו'. זו רמה גבוהה של אוטומציה שמשלבת customization (מה הסוכן עושה) עם parallelism (כמה סוכנים עובדים בו-זמנית).

השוואה: /fleet (CLI) מול runSubagent (VS Code)

שמעתם על runSubagent בפרק 2 (ארגז הכלים). עכשיו בואו נשווה אותו ל-/fleet — שניהם מפעילים sub-agents, אבל בצורה שונה מאוד. ההבדל המרכזי: /fleet הוא כלי CLI שרץ מקבילית, בעוד runSubagent הוא כלי VS Code שרץ סדרתית. למה הם עובדים שונה? כי ב-VS Code, המודל לא יכול לדעת בוודאות שמשימות עצמאיות — אז הוא שומר על צד שמרני ומריץ אחת אחרי השנייה.

דוגמה מעשית: אותה משימה בשתי דרכים

נניח שאתם רוצים לעשות code review ל-3 קבצים:

עם /fleet (CLI):

/fleet Review these 3 files for security issues:
1. src/api/auth.ts — focus on token handling
2. src/api/payment.ts — focus on input validation
3. src/api/admin.ts — focus on authorization checks

fleet ישגר 3 sub-agents שיעבדו במקביל. כל אחד סוקר קובץ אחד. תוצאה תוך 2-3 דקות.

עם runSubagent (VS Code):

ב-VS Code, תבקשו מ-Copilot: "Review these 3 files for security issues." הסוכן הראשי ישתמש ב-runSubagent כדי לשלוח כל קובץ ל-sub-agent נפרד — אבל אחד אחרי השני. סדרתית. תוצאה תוך 6-9 דקות.

התוצאה זהה, הזמן שונה. fleet = 3 דקות, runSubagent = 8 דקות. אבל אם אתם כבר עובדים ב-VS Code ולא רוצים לעבור לטרמינל — runSubagent עדיין מועיל כי הוא מבודד את ה-review מהשיחה הראשית.

מתי אין צורך ב-sub-agents בכלל?

לא כל משימה צריכה sub-agents. רוב העבודה היומיומית — כתיבת פיצ'ר, תיקון באג, שאלה על הקוד — מתאימה מצוין לסוכן רגיל (Agent Mode בבלי /fleet ובלי runSubagent). sub-agents, בין אם fleet ובין אם runSubagent, מתאימים למצבים ספציפיים:

• fleet: כשיש 3+ חלקים עצמאיים שאפשר לעשות בו-זמנית
• runSubagent: כשצריך בידוד — "תחקור את הנושא הזה בנפרד בלי לזהם את השיחה הראשית"
• סוכן רגיל: כל דבר אחר — וזה 80% מהעבודה

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

שגרת עבודה — fleet וסוכנים מותאמים

בנוסף לשגרה מפרק 6 (שימוש יומי ב-CLI), הוסיפו את הפעולות הבאות. שימו לב: השגרה הזו מתווספת לשגרות הקודמות, לא מחליפה אותן. אם בפרק 6 התחלתם עם "בדיקת זיכרון CLI" ו"שימוש ב-Explore agent" — אלה ממשיכים. הפעולות כאן הן ספציפיות ל-fleet ולסוכנים מותאמים.

אם אתם עושים רק דבר אחד מהפרק הזה

בדקו את עצמכם

סיכום הפרק