במאמר הזה
כל צוות פיתוח שמאמץ את Claude Code מגיע לאותה נקודה: המפתח הראשון בונה לעצמו סקילים מעולים, hooks חכמים והגדרות מדויקות, וכל השאר ממשיכים לעבוד עם ברירות המחדל. הידע נשאר תקוע במכונה של אדם אחד. בדיוק בשביל זה קיימים plugins: הדרך הרשמית לארוז את כל ההרחבות של Claude Code לחבילה אחת מותקנת, מגורסת ומשותפת.
מה זה בעצם plugin
Plugin הוא תיקייה שאורזת יחד כמה סוגי הרחבות, וכולן נטענות בהתקנה אחת:
- Skills: נהלים והוראות עבודה בקבצי SKILL.md, שהופכים גם לפקודות slash.
- Agents: הגדרות של סאב-אייג'נטים ייעודיים, למשל סוקר אבטחה עם כלים מוגבלים.
- Hooks: אוטומציות שרצות סביב אירועים, כמו lint אחרי כל עריכת קובץ.
- שרתי MCP: חיבורים לכלים חיצוניים שמגיעים מוגדרים מראש.
ההבדל מהגדרות רגילות בתיקיית .claude/ של פרויקט: plugin הוא יחידה עצמאית שאפשר להתקין בכל פרויקט, לעדכן בגרסאות, ולהפיץ דרך marketplace. הסקילים שלו מקבלים namespace משלהם, למשל /our-plugin:deploy, כך שאין התנגשויות בין plugins שונים.
המבנה האמיתי
לב ה-plugin הוא קובץ manifest בשם plugin.json שיושב בתיקיית .claude-plugin/. כל שאר הרכיבים יושבים בשורש ה-plugin, לא בתוך .claude-plugin/ (זו הטעות הנפוצה ביותר). כך נראה plugin טיפוסי של צוות:
our-conventions/
├── .claude-plugin/
│ └── plugin.json # ה-manifest: שם, תיאור, גרסה
├── skills/
│ ├── api-conventions/
│ │ └── SKILL.md # קונבנציות ה-API של הצוות
│ └── deploy/
│ └── SKILL.md # נוהל deploy מלא
├── agents/
│ └── security-reviewer.md # סאב-אייג'נט לסקירת אבטחה
├── hooks/
│ └── hooks.json # lint אוטומטי אחרי כל עריכה
└── .mcp.json # חיבור MCP לכלים הפנימיים
וה-manifest עצמו מינימלי:
{
"name": "our-conventions",
"description": "Team conventions, deploy flow and review agents",
"version": "1.2.0",
"author": { "name": "Platform Team" }
}
שדה ה-name קובע את ה-namespace של הפקודות, ושדה ה-version שולט בעדכונים: משתמשים מקבלים עדכון רק כשמעלים את המספר. בזמן פיתוח בודקים את ה-plugin מקומית עם הדגל --plugin-dir, ואחרי שינויים מריצים /reload-plugins בלי לצאת מהסשן.
הפצה דרך Marketplace
Marketplace הוא בסך הכל ריפו (או תיקייה) עם קובץ .claude-plugin/marketplace.json שממפה שמות של plugins למקורות שלהם: תיקייה יחסית באותו ריפו, או ריפו GitHub נפרד. צוות שרוצה marketplace פנימי פשוט שם את הקובץ בריפו פרטי, וכל מפתח מריץ:
/plugin marketplace add our-org/claude-plugins
/plugin install our-conventions@our-plugins
מאותו רגע העדכונים זורמים אוטומטית: דוחפים שינוי ל-plugin, מעלים גרסה, וכל הצוות מקבל אותו. מעבר ל-marketplace הפנימי, אנתרופיק מתחזקת marketplace רשמי (claude-plugins-official) עם plugins נבחרים כמו skill-creator, ו-marketplace קהילתי פתוח שאפשר להגיש אליו plugins לביקורת.
למה זה משנה לצוותים
הערך האמיתי של plugins הוא לא טכני אלא ארגוני: הם הופכים ידע שבטי לתשתית. חשבו על כל הדברים שהיום עוברים בעל פה או ב-code review: איך קוראים ל-endpoints, איך נראית מיגרציה נכונה, מה בודקים לפני deploy, אילו ספריות אסור להכניס. כשכל אלה חיים ב-plugin אחד:
- Onboarding מתקצר: מפתח חדש מתקין plugin אחד ו-Claude שלו כבר עובד לפי הכללים של הצוות, מהשעה הראשונה.
- הקונבנציות נאכפות בפועל: hook שרץ תמיד עדיף על סעיף בוויקי שאף אחד לא קורא.
- יש גרסאות ויש בעלות: שינוי בנוהל ה-deploy הוא commit ב-plugin, עם review והיסטוריה, לא הודעת סלאק שנעלמת.
- אחידות בין פרויקטים: אותו plugin מותקן בכל ריפו, אז כל אייג'נט בכל פרויקט עובד באותה שיטה.
איך מתחילים
אל תתחילו מ-plugin. תתחילו מסקיל אחד או שניים ב-.claude/skills/ של פרויקט קיים, תשתמשו בהם שבועיים, ותראו מה באמת עוזר. כשמצטבר סט שהצוות כולו צריך, ההמרה ל-plugin היא בעיקר העברת קבצים והוספת manifest. משם: ריפו פרטי, marketplace פנימי, וטקס התקנה של פקודה אחת לכל מפתח חדש.
אם אתם רוצים לבנות שכבת plugins שמקודדת את שיטת העבודה של הצוות שלכם לתוך Claude Code, דברו איתנו. זה בדיוק סוג התשתית שאנחנו בונים ללקוחות.
ספרו לנו על תהליך אחד בשיחה של 30 דקות. נגיד לכם בכנות אם סוכן יכול לעשות אותו.


