בלוג

Skills,‏ Subagents,‏ MCP ו-Plugins ב-Claude Code: במה לבחור

Markdown

Skills, subagents,‏ MCP ו-plugins הם ארבע שכבות להרחבת Claude Code. אני מסביר מתי להשתמש בכל אחת, עם מטריצת החלטה מוכנה ודוגמאות מפרויקטים.

קריאת המאמר המלא

כרגע ב-Claude Code יש חמש דרכים לבצע אותה סקירת קוד: פקודת slash,‏ skill,‏ subagent,‏ plugin או פשוט הנחיה בצ'אט. אף אחת מהדרכים אינה טובה יותר מאחרות כברירת מחדל — הבחירה תלויה במשימה, בתקציב הטוקנים ובמי עוד ישתמש בה מלבדך.

המדריך הזה הוא מה שהייתי נותן לעצמי לפני שנה. עץ החלטה של 4 שאלות, מטריצת “משימה → שכבה” מוכנה ו-5 טעויות נפוצות ששורפות טוקנים אצל כל מתכנת וייב אחר שאני עובד איתו.

על העבודה עם השירות — בתיעוד של Ailoot.

מה הם skills,‏ subagents,‏ MCP ו-plugins במשפט אחד?

הנקודה המרכזית

Skill הוא מתודולוגיה ארוזה ש-Claude טוען כשמפעילים אותה. Subagent הוא “עמית” מבודד עם הקשר משלו למשימה ארוכה. MCP הוא גשר למערכת חיצונית (מסד נתונים, GitHub,‏ Notion). Plugin הוא אוסף מוכן של כל האמור לעיל, שמישהו אחר יצר, ומתקינים בשורה אחת.

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

Skill הוא תיקייה עם קובץ SKILL.md שמתאר מתי ואיך ליישם מתודולוגיה מסוימת. Anthropic משווה skill להנחיות לעובד חדש: לא מכתיבים לו מדי יום כל שלב; נותנים לו נוהל.

Subagent הוא סשן Claude נפרד עם הקשר משלו, שמופעל מתוך השיחה הראשית. יש לו תכונה מרכזית אחת: בידוד. Subagent יכול לקרוא 30 קבצים, להפיק סיכום ולהחזיר רק אותו לצ'אט הראשי. ההקשר של השיחה הראשית נשאר נקי.

MCP (Model Context Protocol) הוא תקן פתוח של Anthropic לחיבור Claude למערכות חיצוניות. בפוסט בבלוג מ-13 בנובמבר 2025, Anthropic הסבירה את ההבחנה באופן הברור ביותר:

MCP מחבר את Claude לנתונים; Skills מלמדים את Claude מה לעשות עם הנתונים האלה. אם אתם מסבירים איך להשתמש בכלי או לפעול לפי נהלים — למשל, “כששואלים את מסד הנתונים שלנו, תמיד מסננים תחילה לפי טווח תאריכים” — זו Skill. אם אתם צריכים של-Claude תהיה גישה למסד הנתונים או לקובצי Excel מלכתחילה — זה MCP.

— Anthropic Engineering, https://claude.com/blog/skills-explained

Plugin הוא אוסף מוכן של skills,‏ subagents,‏ hooks ופקודות, שמישהו אחר יצר וארז ב-marketplace. מתקינים אותו בשורה אחת באמצעות /plugin install, ומקבלים הכול בבת אחת. אם skill הוא הנוהל שלכם, plugin הוא נוהל שקניתם מחברה אחרת.

בקצרה, skills הם מתכונים, subagents הם עמיתים מומחים, ו-MCP מספק כלים חיצוניים שבאמצעותם Claude יכול להגיע לשירותים ולנתונים. עלות הטוקנים משתנה: skill הוא הזול ביותר (הוא נטען כשמפעילים אותו), ואילו MCP יקר הרבה יותר (כל שרת מחובר תופס מקום בחלון ההקשר כל הזמן).

למה צריך 4 שכבות אם אפשר להשתמש ב-CLAUDE.md אחד?

הנקודה המרכזית

CLAUDE.md הוא בקשה: Claude קורא אותו בתחילת סשן ועלול להתעלם ממנו אחרי 20 הודעות. Skills,‏ subagents,‏ MCP ו-plugins פותרים את מה ש-CLAUDE.md לא יכול: קנה מידה, בידוד הקשר, גישה לעולם החיצון ושיתוף מתודולוגיה עם צוות.

בפרויקט המתואר, CLAUDE.md הוא מפה גדולה של כללים: איפה הדברים נמצאים, איך מפרסמים ומהם ההסכמים. בלי הקובץ הזה, Claude היה מתחיל כל סשן חדש מאפס.

אבל ל-CLAUDE.md יש תקרה. אסביר באמצעות שלושה מצבים שבהם הוא מפסיק לעבוד.

מצב 1: כלל עובד רק לפעמים. ב-CLAUDE.md כתוב, “תמיד הריצו npm run build לפני git push.” Claude קורא אותו בתחילת הסשן, מהנהן, מתחיל לכתוב קוד אחרי 25 הודעות ושוכח. כבר תפסתי את עצמי דוחף בלי build שלוש פעמים; הדחיפות האלה נכשלו בפרודקשן. Hook שהוגדר ונבדק כראוי יכול להריץ בדיקת build דטרמיניסטית ולדחות את הפעולה המכוסה. הכיסוי תלוי באירוע ובמסלול הכלי: hook של Claude Code אינו מיירט כשלעצמו כל push ממסוף או מיישום אחר. אמתו ש-build שנכשל במכוון חוסם את המסלול שבו אתם משתמשים בפועל.

מצב 2: תהליך בן 15 שלבים שחוזר על עצמו. בדוגמה המתוארת, כל מדריך עובר 14 שלבים: מחקר → מבנה → MDX → 7 בדיקות QA במקביל → פרסום לפרודקשן → IndexNow. אם אכתוב בכל פעם הנחיה שאומרת “בצעו את שלב 1, ואז 2, ואז 3”, אשרוף טוקנים עוד לפני שאתחיל. לכן כל זרימת העבודה הזאת ארוזה ב-skill בשם build-masterskaya-guide — סט הוראות של 34 KB שמופעל עם הביטוי “בואו נכין מדריך חדש לפרויקט”.

מצב 3: משימה שזוללת הקשר. כדי לבדוק אם מדריך שכבר פורסם עדיין מעודכן, Claude צריך לקרוא תמליל של שידור חי בנפח 30 KB, 20 מסמכי רטרוספקטיבה של 5 KB כל אחד, ולהשוות אותם לאתר הנוכחי. אם אעשה זאת בצ'אט הראשי, עד סוף הבדיקה יהיו בהקשר שלי 200K טוקנים של זבל. Subagent מבצע את אותה עבודה, מחזיר לשיחה הראשית רק סיכום של 300 מילים ונסגר.

מצב 4: אני רוצה שהצוות יקבל את אותן תבניות שיש לי. סט מוכן של כללים לעיצוב frontend,‏ hooks לפרסום דרך Coolify ו-MCP לבדיקות Playwright. זה plugin: אני אורז את ההגדרה שלי, מפרסם אותה ב-marketplace ועמית מתקין אותה בשורה אחת.

CLAUDE.md מכסה את הבסיס: “כך עובדים אצלנו”. ארבע השכבות הנוספות מכסות את מה ש-CLAUDE.md לא יכול לעשות מבחינה מעשית: חזרתיות באמצעות triggers, בידוד הקשר, גישה לעולם החיצון ושיתוף.

מתי צריך skill במקום CLAUDE.md?

הנקודה המרכזית

Skill היא הבחירה הנכונה כשיש תהליך שניתן לחזור עליו, עם trigger ברור, ואתם מבצעים אותו יותר מפעם ביום. בניגוד ל-CLAUDE.md, skill נטענת רק כשצריך אותה ואינה שורפת את הקשר הבסיסי בכל סשן.

המבחן ל-skill פשוט: אתם תופסים את עצמכם מעתיקים שוב ושוב את אותה הנחיה ארוכה מהפתקים שלכם לצ'אט. הפעם השלישית היא כבר סימן.

כרגע יש לי 7 תיקיות ב-~/.claude/skills/: build-masterskaya-guide,‏ build-vc-spoke,‏ build-reel-script,‏ build-practicum-instruction,‏ update-config,‏ simplify ו-keybindings-help. השימושית ביותר היא build-masterskaya-guide (המדריך הזה נכתב בעזרתה). בתוכה יש 34 KB של מתודולוגיה: אילו שלבים לעבור, אילו בדיקות QA מרובות סוכנים להריץ, אילו תנאי סף צריכים לעצור את התהליך ואילו תוצרים לשמור ב-/tmp/.

מתי לא ליצור skill.

  • כלל כמו “ענו בשפה המועדפת על המשתמש” שייך ל-CLAUDE.md, לא ל-skill. Skill נטענת כשמפעילים אותה, אבל הכלל הזה אמור לחול תמיד.
  • הוראה חד-פעמית כמו “הריצו עכשיו את השכתוב מחדש” שייכת לצ'אט, לא ל-skill.
  • משימה שצריכה הקשר נפרד יכולה להשתמש ב-subagent; אם היא גם פועלת לפי נוהל חוזר, שמרו את המתודולוגיה ב-skill.

האנטי-דפוס המרכזי. הטעות הנפוצה ביותר שמתכנתים בסגנון vibe עושים היא לדחוס תהליך לתוך subagent כשצריך להיות skill. Subagent עולה יותר טוקנים (יש לו הקשר משלו), מתחיל לאט יותר ולעיתים קרובות הוא מוגזם. אם המשימה מתאימה ל-1,500–2,000 מילים של מתודולוגיה בלי לקרוא קבצים חיצוניים, היא skill.

איך לבנות skill, מה לכלול ב-frontmatter ואילו ביטויי הפעלה עובדים — במדריך Claude Code Skills ב-2026: איך לבנות ספריית Skills אישית.

מתי צריך subagent במקום skill?

הנקודה המרכזית

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

Skill שומרת את המתודולוגיה; subagent מבצע את העבודה. אלה שכבות שונות, ולעיתים קרובות מבלבלים ביניהן משום ששתיהן מופעלות “מתוך הצ'אט”.

Subagent מועיל כשצריך בידוד הקשר או תפקיד ממוקד שמואצל; הוא יכול גם לפעול לפי נוהל שמוגדר ב-skill ולהשתמש בכלי MCP מורשים. לסשן Claude הראשי יש תקציב של 200,000 טוקנים (או מיליון בגרסת beta). אם תבקשו ממנו בצ'אט הראשי לקרוא 30 קבצים ולנתח כל אחד מהם, תשרפו חצי מהחלון על קריאת ביניים. Subagent מבצע את אותה עבודה בסשן נפרד ומחזיר לצ'אט הראשי רק את התוצאה.

דוגמה קונקרטית מפרויקט. כל מדריך עובר כמה בדיקות QA מקבילות: סגנון, ציטוטים ועובדות מול מקורות ראשוניים, מבנה עבור מנועי חיפוש ושלמות הקישורים הפנימיים והחיצוניים. כל בדיקה נעזרת בהקשר משלה: מילון מונחים של כללים, WebFetch לעשרות כתובות URL וחיפושי grep בטקסט.

אם הייתי מריץ את כל הבדיקות האלה בצ'אט אחד, ההקשר היה מחסל אותי לפני שהראשונה הייתה מסתיימת. הפעלת subagents במקביל עם run_in_background: true פותרת את זה: הם עובדים ברקע, הצ'אט הראשי ממשיך הלאה, ואחרי 4–6 דקות מתקבלים דוחות תמציתיים ואני מיישם את השינויים.

דוגמה שנייה — מחקר כבד. כשאני בוחר נושא למדריך חדש, 4 subagents אוספים אותות במקביל:

  • V1 - פורומים וקהילות במשך 14 ימים
  • V2 - רשתות חברתיות
  • V3 - פלטפורמות וידאו + הבלוג של Anthropic
  • V4 - פערי SEO

כל אחד מחזיר 30–40 פריטים עם ציוני ויראליות. אני אוסף אותם למאגר, משקלל אותם ב-9 ממדים ובוחר מנצח. בלי subagents, השלב הזה מתארך ל-2–3 שעות של שריפת ההקשר הראשי.

מתי לא ליצור subagent.

  • משימה שאינה דורשת קריאת קבצים או שימוש ב-WebFetch שייכת לצ'אט הראשי.
  • נוהל חוזר שייך ל-skill, אך יכול לפעול בתוך subagent כשבידוד מועיל.
  • גישה חיצונית דורשת כלי מורשה כגון MCP או CLI; subagent יכול להשתמש בכלי הזה כשהמשימה מואצלת אליו.

האנטי-דפוס המרכזי. יצירת subagent בשם backend-engineer או qa בתקווה ש-Claude יבין מתי להשתמש בו. בוריס צ'רני מזהיר במפורש: subagents ספציפיים (כמו migration-test-writer או api-route-reviewer) מספקים איכות טובה בהרבה מכלליים. ככל שהשם וההוראות של ה-subagent מדויקים יותר, כך Claude יבחר בו בדיוק רב יותר.

איך ליצור subagents למשימות ספציפיות, תחביר frontmatter ו-5 דוגמאות מוכנות — במדריך Claude Code Subagents ב-2026: מדריך שלב אחר שלב.

מתי צריך MCP במקום skill או subagent?

הנקודה המרכזית

MCP מספק כלים וגישה לנתונים במערכות כגון מסדי נתונים, GitHub, ‏Sentry או דפדפן. השתמשו בו כשדרך העבודה זקוקה לגישה הזאת. Skill יכולה לספק את המתודולוגיה לשימוש באותם כלים; שתי השכבות משלימות זו את זו.

Anthropic נתנה בפוסט בבלוג את הנוסחה הקצרה ביותר להבחנה: MCP מחבר את Claude לנתונים; skills מלמדים את Claude מה לעשות עם הנתונים האלה.

למשל, skill לסקירת issue ב-GitHub צריכה את תוכן ה-issue. ספקו אותו באמצעות כלי MCP מורשה, CLI או טקסט שסופק. ה-skill מגדירה אז איך לסקור אותו ולבנות את הממצאים; גישת MCP לבדה אינה מכתיבה את הנוהל.

מחסנית ה-MCP הספציפית שלי.

  • Playwright MCP - בדיקת QA חזותית לכל מדריך. פותחים את הדף במחשב ובנייד, בודקים את רוחב המכל ואת השאלה אם הבלוקים עברו רינדור.
  • Stitch MCP - גישה למערכת העיצוב, יצירת רכיבים בסגנון המותג.
  • vidIQ MCP - ניתוח מגמות ובדיקת רעיונות לוויראליות.
  • Railway MCP - ניהול תשתית פריסה.

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

עלות הטוקנים. MCP היא השכבה היקרה ביותר. כל שרת מחובר תופס מקום בחלון ההקשר כל הזמן: הצהרות כלים, סכמות ארגומנטים ותיאורים. יש לי 4 שרתי MCP — זה בערך 8–12K טוקנים בכל סשן חדש, עוד לפני ששאלתי משהו.

המשמעות היא שמחברים MCP רק אם הוא באמת נחוץ ברוב הסשנים. אם משתמשים ב-Sentry MCP פעם בשבוע, עדיף להפעיל אותו לפי דרישה עם הדגל --mcp sentry במקום להשאיר אותו ברשימה הקבועה.

מתי לא להשתמש ב-MCP.

  • מתודולוגיה של “איך לעבוד עם נתונים” שייכת ל-skill, לא ל-MCP.
  • משימת קריאה ארוכה עשויה להפיק תועלת מ-subagent; אם חלק מהקבצים או הרשומות חיצוניים, גם הוא עשוי להזדקק לגישת MCP.
  • פרסום בפקודה אחת דורש hook או plugin, לא MCP.

האנטי-דפוס המרכזי. בניית שרת MCP למשהו ש-skill מתאים לו יותר. ראיתי דוגמה בדיון ב-HN (אותו שרשור עם 422 נקודות ב-27 במאי): הכותב בנה שרת MCP שמספק “הוראות לסקירת קוד”. אבל זו לא גישה לעולם החיצון; זה נוהל. Skill עושה את אותו הדבר בעשירית ממספר הטוקנים.

תקרית של התנגשות משאבים. פעם Playwright MCP נתקע עם השגיאה “Browser is already in use” — היה לי חלון Chrome פתוח באותו זמן, ו-MCP לא הצליח להשתלט על הדפדפן. זה לקח חשוב: שרת MCP משתמש במשאבי מערכת משותפים. אם יש התנגשות על משאב (דפדפן, יציאה או קובץ), כדאי לחשוב על בידוד כבר מההתחלה.

מדריך מוכן לחיבור 7 שרתי MCP פעילים נמצא ב-Claude Code MCP Servers ב-2026: 7 הגדרות מוכנות לשימוש.

מתי צריך plugin במקום skill או subagent?

הנקודה המרכזית

Plugin הוא אוסף שמישהו אחר ארז של skills,‏ subagents,‏ hooks ופקודות, ומתקינים בשורה אחת דרך ה-marketplace. השתמשו בו כשאינכם רוצים לבנות הכול מאפס וסומכים על יוצר החבילה — למשל, לעיצוב frontend, לבדיקות דרך Playwright או לשילוב עם Telegram.

Skills,‏ subagents ו-MCP עוסקים במתודולוגיה שלכם. Plugin הוא מתודולוגיה מוכנה של מישהו אחר, שאפשר לייבא להגדרה שלכם.

באוקטובר 2025 השיקה Anthropic את Claude Code Plugins, מנגנון הפצה רשמי. Plugin הוא תיקייה שיכולה להכיל:

  • פקודות slash משלה
  • skills משלה
  • subagents משלה
  • hooks משלה
  • הגדרות MCP משלה
  • סגנונות פלט משלה

כל זה נארז בחבילה אחת עם plugin.json. ההתקנה נעשית בשורה אחת ב-~/.claude/settings.json או באמצעות הפקודה /plugin install <name>.

מחסנית ה-plugins הספציפית שלי.

  • frontend-design מתוך claude-plugins-official הרשמי — 67 סגנונות, 96 פלטות, 57 זוגות גופנים, 13 מסגרות עבודה. כשאני יוצר בלוק חדש לאתר או תבנית דוא"ל, אני טוען את ה-plugin ומקבל את הספרייה כולה בבת אחת.
  • playwright מאותו marketplace רשמי — אוסף של skills והגדרות MCP לבדיקות דפדפן.
  • telegram — אוסף מוכן לניהול חשבון Telegram מתוך Claude Code (מדיניות, allowlist,‏ pairing).
  • trailofbits/skills — אוסף skills לאבטחה של Trail of Bits, חברה שאני סומך עליה בענייני אבטחה.

כל הארבעה הם שלוש שורות ב-settings.json. בלי plugins, הייתי משקיע שעות בבניית אותה ספרייה ידנית.

מתי לא להשתמש ב-plugin.

  • אם המתודולוגיה שייכת כולה לכם ואינה מיועדת לאחרים, השאירו אותה כ-skill.
  • אם אינכם יודעים עדיין מי ישתמש בה, נסו אותה קודם בעצמכם כ-skill.
  • אם צריך להעביר במהירות שלושה קבצים למחשב חדש, cp ~/.claude/skills/X /new/machine/.claude/skills/ יעשה זאת.

האנטי-דפוס המרכזי. שימוש ב-plugin כתחליף ל-CLAUDE.md — למשל, plugin עם כללים על “איך עובדים בפרויקט הזה”. Plugin מיועד להפצה ולשימוש חוזר. אם הכללים ייחודיים למאגר אחד, הם שייכים ל-CLAUDE.md, לא ל-plugin.

במבט קדימה ל-2026: ברור ש-Anthropic מתקדמת לעבר marketplace צוותי ל-plugins. פירוש הדבר שחברות יוכלו לפרסם את המתודולוגיות הפנימיות שלהן כ-plugins, לנהל להן גרסאות ולעדכן אותן אצל כל העובדים בפקודה אחת. עבור יזם יחיד, המשמעות היא: להתקין את מה שכבר מוכן ולא להמציא אותו מחדש.

עץ החלטה: 4 שאלות שכדאי לשאול לפני כל משימה

הנקודה המרכזית

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

שאלה 1: האם יש נוהל חוזר שכדאי לשמור?

אם כן, ארזו את המתודולוגיה כ-skill בקובץ SKILL.md עם תיאור ברור של מועד השימוש. כך מספקים את הנוהל; הדבר אינו מספק כשלעצמו גישה חיצונית או הקשר נפרד.

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

אם כן, השתמשו ב-subagent. תנו לו משימה וכלים מדויקים. אותה משימה יכולה לפעול לפי מתודולוגיית skill בתוך ההקשר המבודד.

שאלה 3: האם המשימה דורשת כלי או גישה לנתונים חיצוניים?

אם כן, ספקו גישה מורשית באמצעות MCP או כלי מתאים אחר, כגון CLI שכבר הוגדר. Skill מתארת איך להשתמש בגישה הזאת; subagent יכול להיות הגורם שמשתמש בה.

שאלה 4: האם צריך להפיץ ולתחזק את ההגדרה כחבילה?

אם כן, השתמשו ב-plugin להפצת ה-skills, הגדרות הסוכנים, ה-hooks או תצורת MCP הרלוונטיים. החבילה יכולה להיות שלכם או של מחבר אחר.

דוגמה משולבת: סקירת issue חוזרת ב-GitHub. Skill מגדירה את נוהל הסקירה ופורמט התוצאה. MCP או CLI של GitHub שהוגדרו מספקים גישה מורשית ל-issue. Subagent יכול לקרוא שרשור ארוך בהקשר משלו ולהחזיר ממצאים. Plugin יכולה להפיץ את השילוב לצוות. כל ארבע התשובות יכולות להיות ״כן״; אף אחת אינה מבטלת אחרת.

5 טעויות בבחירת שכבה שמתכנתים בסגנון vibe עושים

הנקודה המרכזית

הטעויות היקרות ביותר הן שימוש ב-subagent במקום skill, ב-MCP במקום skill, ב-plugin במקום CLAUDE.md וב-skill דרך hook. כל אחת מהן שורפת טוקנים או משבשת התנהגות. אראה מה קרה ומה היה צריך לקרות באמצעות דוגמאות קונקרטיות.

אני רואה את חמשת הדפוסים האלה פעם בשבוע אצל מתכנתים בסגנון vibe שאני עובד איתם. לפחות אחד מכל שניים עושה לפחות אחת מהטעויות האלה בשבוע הראשון שלו.

טעות 1: subagent במקום skill.

תסמין: מחבר יצר subagent ל“כתיבת פוסט חדש בבלוג”. בכל פעם שהוא מפעיל את ה-subagent, הוא נטען, קורא 2 KB של מתודולוגיה, יוצר פוסט ונסגר. אחרי שבוע המחבר שם לב שכל הפעלה שורפת עוד 5K טוקנים בטעינת ה-subagent.

מה צריך לקרות: “איך לכתוב פוסט” זו מתודולוגיה — לכן זו skill. ביטוי ההפעלה הוא “פוסט חדש בבלוג”. ה-skill נטענת לצ'אט הראשי ואינה פותחת סשן נפרד. היא זולה פי 3–5.

טעות 2: שרת MCP במקום skill.

תסמין: מחבר כתב שרת MCP שמספק הוראות ל“איך לבצע סקירת קוד”. הצהרות הכלים, תיאורי סכמת הארגומנטים והתיעוד ממשיכים לתפוס מקום בהקשר. כל בקשה מבזבזת 2–3K טוקנים לשווא.

מה צריך לקרות: “איך לבצע סקירת קוד” הוא נוהל, לא גישה למערכת חיצונית. השתמשו ב-skill. MCP מוצדק רק אם נחוצה גישה חיה — למשל ל-Sentry כדי לאחזר את השגיאות האחרונות.

טעות 3: plugin במקום CLAUDE.md.

תסמין: מחבר ארז כללי פרויקט (“תמיד להשתמש במצב TypeScript strict”, “אל תשתמשו במקפים”, “להשתמש רק ב-pnpm, לא ב-npm”) ב-plugin והתקין אותו. עכשיו בכל סשן חדש נטען plugin שמכפיל את מה שאמור להופיע ב-CLAUDE.md.

מה צריך לקרות: כללים לפרויקט אחד שייכים ל-CLAUDE.md של אותו פרויקט. Plugin מיועד למתודולוגיה שמתאימה לכמה אנשים או מאגרים.

טעות 4: ניסיון ליצור skill דרך hook.

תסמין: מחבר ראה ש-hook פועל אוטומטית בעת אירוע (למשל, לפני שמירת קובץ). הוא החליט ליצור “skill דרך hook” כדי ש-Claude יישם אוטומטית את המתודולוגיה בכל עריכה. התוצאה הייתה לולאת הפעלה אינסופית, שריפת הקשר והתנהגות בלתי צפויה.

מה צריך לקרות: hook הוא קוד דטרמיניסטי שמריץ פקודה, מעצב את התוצאה או חוסם פעולה. Hook אינו טוען skill ואינו מפעיל את Claude. אם צריך “ליישם תמיד מתודולוגיה X”, השתמשו ב-skill עם trigger או ברשומה ב-CLAUDE.md.

טעות 5: שכבה נוספת כשלא צריך שום דבר.

תסמין: מחבר שומע על skills, קורא מדריכים, מחליט “צריך לארוז את המתודולוגיה הזאת” ומבלה ערב ביצירת skill למשימה שעולה פעם בחודש.

מה צריך לקרות: משימה חד-פעמית שייכת לצ'אט, לפי הצורך. Skill מוצדקת רק אם עושים זאת יותר מפעם ביום (הכלל של בוריס צ'רני). אחרת, זהו תכנון יתר שצריך אחר כך לתחזק.

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

מה Anthropic אומרת על הפיצול: לאן Claude Code מתקדם ב-2026

הנקודה המרכזית

Claude Code מאחדת את השכבות: חמש הדרכים לבצע סקירת קוד (פקודה, skill,‏ subagent,‏ plugin או צ'אט) מתכנסות ל-skill מובנית אחת בשם /code-review. כלומר, אל תיבהלו מ“יותר מדי שכבות” — ב-2026 הגבולות מיטשטשים והכול נעשה פשוט יותר.

בוריס צ'רני השיב בפומבי לתגובה:

מה המשמעות של זה במהלך ששת החודשים עד השנה הקרובה.

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

שנית: subagents נעשים ייעודיים יותר. הסיפור המרכזי של subagents הוא בידוד הקשר למשימות כבדות. Subagents כלליים כמו qa-engineer ייעלמו; ספציפיים כמו migration-test-writer ו-api-route-reviewer יישארו.

שלישית: ההודעות החדשות של Anthropic במהלך 14 ימים — הפקודה /workflows (28 במאי 2026) לתזמור עשרות subagents, והפרדת החיוב של Agent SDK החל מ-15 ביוני — משמעותן ששימוש פרוגרמטי עובר למאגר נפרד. זהו סימן לכך ש-Anthropic בונה תשתית למערכות אוטומטיות של 10+ agents, ולא לסשנים אישיים.

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

מטריצה מוכנה: 10 משימות טיפוסיות → השכבה המתאימה

הנקודה המרכזית

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

#מצב מפעילהשכבה המתאימהלמה דווקא היא
1Claude מפספס את אותו כלל 2–3 פעמים בסשןCLAUDE.mdתגובתי, תמיד בהקשר, לא דורש trigger
2אני מקליד את אותה הנחיה ארוכה יותר מפעם ביוםSkillנטענת לפי דרישה, לא שורפת את הקשר הבסיסי
3זו הפעם השלישית שאני מדביק playbook של 1,500 מילים לצ'אטSkillמתודולוגיה פרוצדורלית, נטענת באמצעות ביטוי הפעלה
4משימה שואבת לצ'אט הראשי יותר מ-20 קבצים לקריאהSubagentבידוד הקשר; רק סיכום חוזר לצ'אט הראשי
5צריך 5 בדיקות זהות במקביל (QA, סקירה, lint)Subagentsמופעלים עם run_in_background; משך הזמן הכולל מתקצר פי חמישה
6אני רוצה לקרוא issues ב-GitHub או את השגיאות האחרונות מ-SentryMCPגישה ישירה למערכת חיצונית באמצעות פרוטוקול תקני
7אני רוצה לבדוק אוטומטית פעולת push מכוסהHook שנבדקבדיקה דטרמיניסטית; אמתו את הטריגר ואת החסימה בפועל
8אני רוצה להעביר את ההגדרה שלי למאגר שני או למחשב חדשPluginהפצה דרך marketplace יחד עם namespace
9צוות של 10 צריך לפעול לפי אותם כלליםPlugin ב-marketplace צוותיגרסאות מנוהלות, מתקינים פעם אחת, עדכון מרכזי
10צריך להגיב ל-webhook משירות חיצוני (Telegram,‏ GitHub Actions)ערוץ MCP או Agent SDKדחיפת הודעות לתוך הסשן מהעולם החיצון

הכלל המרכזי לשימוש בטבלה הוא לא לנסות “לעשות את כל 10 הדברים בבת אחת”. רוב מתכנתי ה-vibe העצמאיים מסתדרים עם CLAUDE.md ועוד 5–7 skills ו-2–4 שרתי MCP. מוסיפים subagents ו-plugins כשהפרויקט גדל.

מה הלאה: איך לבנות את סביבת העבודה שלכם ב-Claude Code

הנקודה המרכזית

CLAUDE.md מכיל את כללי הבסיס של הפרויקט, skills אורזות מתודולוגיה, subagents מפזרים הקשר כבד, MCP מחבר לעולם החיצון ו-plugins מפיצים אוסף מוכן של מישהו אחר. אלה חמש אבני הבניין של הגדרת Claude Code שלכם ב-2026.

חמש השכבות האלה אינן מונחות זו אחרי זו; הן משתלבות זו בתוך זו. CLAUDE.md הוא היסוד של הפרויקט, וארבע האחרות מתחברות ככל שהמשימות גדלות.

הכירו את Ailoot.

פרטים נוספים

שאלות ותשובות: Skills,‏ Subagents,‏ MCP ו-Plugins ב-Claude Code: במה לבחור

האם סקירת GitHub אחת יכולה להזדקק ל-skill, ל-subagent ול-MCP יחד?

כן. Skill מגדירה את הנוהל, MCP או CLI מורשה מספקים נתוני issue ו-subagent יכול לבצע סקירה ארוכה בהקשר משלו. Plugin יכולה להפיץ את השילוב.

איך להשתמש ברשימת ארבע השאלות?

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

כל המאמרים