Agent Skills: מיומנות חדשה לקלוד.

Skill הוא תיקייה עם קובץ הוראות

מבחינה טכנית זה פשוט עד אכזבה: תיקייה בתוך .claude/skills/, ובתוכה קובץ בשם SKILL.md. שם התיקייה הוא שם ה-skill, והקובץ מכיל שני חלקים: frontmatter קצר בראש (name ו-description), ואחריו ההוראות עצמן בטקסט חופשי.

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

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

כותבים skill ראשון

ניקח דוגמה אמיתית: תהליך הדיפלוי של הפרויקט. צרו את התיקייה .claude/skills/deploy-checklist/, ובתוכה קובץ SKILL.md שנראה כך:

---
name: deploy-checklist
description: הרצת דיפלוי לפרודקשן של האתר. השתמש כשמבקשים לעלות לאוויר, לפרוס גרסה, או לבדוק שהכל מוכן לדיפלוי.
---

# צ'קליסט דיפלוי

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

## 1. בדיקות מקומיות
- `pnpm lint` - חייב לעבור נקי
- `pnpm build` - חייב לעבור בלי שגיאות טיפוס
- אם יש שינוי בסכמה, ודא שהמיגרציה קיימת ב-migrations/

## 2. משתני סביבה
- השווה בין .env.example לבין המשתנים בפאנל ההוסטינג
- משתנה חדש שלא הוגדר בפרודקשן = הדיפלוי ייכשל בזמן ריצה

## 3. הרצה
- `vercel --prod`
- שמור את כתובת הדיפלוי שחוזרת

## 4. אימות אחרי עלייה
- טען את דף הבית ובדוק שאין שגיאות בקונסולה
- בדוק ש-/api/health מחזיר 200
- אם משהו שבור: `vercel rollback` לגרסה הקודמת

## מה לא לעשות
- אל תריץ דיפלוי מענף שאינו main
- אל תדלג על שלב 2 גם אם "לא נגענו בסביבה"

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

שתי דרכים להפעיל

אוטומטית.אתם כותבים “בוא נעלה לאוויר את הגרסה החדשה”, קלוד מזהה שהבקשה תואמת לתיאור של deploy-checklist, טוען את הקובץ, ומתחיל לעבוד לפי השלבים. לא ביקשתם skill - ביקשתם משימה.

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

skill אישי מול skill של פרויקט

יש שני מקומות לשים בהם skills, וההבדל ביניהם הוא שאלה של קהל:

• ~/.claude/skills/ - אישי. זמין לכם בכל הפרויקטים במחשב, ולא נכנס לשום ריפו. כאן שמים הרגלי עבודה שהם שלכם: הפורמט שאתם אוהבים להודעות קומיט, איך אתם רוצים שסיכומים ייכתבו, כלים אישיים שאתם גוררים בין פרויקטים.
• .claude/skills/ בשורש הפרויקט - צוותי. נכנס ל-git, ולכן כל מי שמושך את הריפו מקבל את אותם skills. כאן שמים תהליכים של הפרויקט: דיפלוי, מיגרציות, סקירת קוד לפי הסטנדרט של הצוות.

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

אותו פורמט עצמו נוסע גם מעבר ל-Claude Code: Agent Skills נתמכים ב-API של אנתרופיק ובמסלולים העסקיים של claude.ai, כך שתהליך שכתבתם פעם אחת לא נעול לכלי אחד.

Skill או CLAUDE.md?

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

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

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

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