Pillar · Claude Skills
Claude Skills הם חבילות ידע והוראות ש-Claude טוען אוטומטית כשהן רלוונטיות — כך הוא עובד בדיוק לפי הסטנדרט שלכם, בלי שתחזרו על ההנחיות בכל שיחה. אפשר לבנות סקיל גם בלי לתכנת.
Skill הוא תיקייה עם קובץ SKILL.md — הוראות בשפה טבעית שמלמדות את Claude איך להתנהג בתחום מסוים. כשהמשימה מתאימה לתיאור הסקיל, Claude טוען אותו ומיישם את הידע אוטומטית.
ההבדל מפרומפט: פרומפט הוא הוראה חד-פעמית; Skill הוא מומחיות קבועה שמתלווה ל-Claude מעכשיו והלאה — עקבית, מהירה, ומשותפת לכל הצוות.
סקיל טוב עושה דבר אחד היטב — לא "תעזור בהכול".
הוראות, טון, פורמט, ודוגמה אחת מנצחת.
התיאור הוא מה ש-Claude קורא כדי להחליט מתי להפעיל.
מריצים משימה אמיתית ומעדכנים עד תוצאה עקבית.
שלושתם מרחיבים את Claude, אבל בדרכים שונות. פרומפט הוא הוראה חד-פעמית בשיחה. Skill הוא ידע והוראות שנטענים אוטומטית כשרלוונטי — כלומר 'איך לעבוד'. MCP הוא חיבור לכלים ולמקורות מידע — כלומר 'במה לפעול'.
הם משלימים זה את זה: סקיל מלמד את Claude את שיטת העבודה שלכם, ו-MCP נותן לו גישה לכלים שעליהם יפעל. יחד מקבלים סוכן שגם יודע איך לעבוד וגם יכול לבצע.
פרומפט הוא הוראה חד-פעמית שמקלידים בכל פעם. Skill הוא ידע קבוע ש-Claude טוען אוטומטית כשהוא רלוונטי — בלי לחזור על ההוראות.
לא. סקיל בסיסי הוא קובץ טקסט (SKILL.md) בשפה טבעית. אפשר אפילו לבקש מ-Claude לכתוב לכם אותו.
בכל משימה חוזרת בסטנדרט קבוע — כתיבת תוכן בטון המותג, סקירת קוד, ניסוח מיילים, דוחות. הצוות מקבל אותה איכות בכל פעם.
Skill מלמד את Claude איך לעבוד (ידע והוראות). MCP נותן ל-Claude גישה לכלים ולמקורות מידע (במה לפעול). הם משלימים — סקיל לשיטת העבודה, MCP לחיבור הכלים.
כן. Skills הם חלק מליבת היכולות של Claude ו-Claude Code — אפשר להוסיף סקילים שמרחיבים את היכולות לתחומים ולתהליכים ספציפיים, וקיימות ספריות סקילים מוכנים.
נבנה יחד את ספריית ה-Skills שמקודדת את שיטות העבודה של הצוות.
דברו איתנוקלוד סקילס (Claude Skills) הם הדרך המהירה ביותר להפוך את קלוד (Claude) מעוזר כללי למומחה שעובד בדיוק לפי הסטנדרט שלכם — תיקייה אחת עם קובץ SKILL.md שקלוד טוען אוטומטית ברגע שהמשימה מתאימה, בלי שתצטרכו להסביר את עצמכם מחדש בכל שיחה. במדריך המעמיק הזה נרד לרזולוציה שהעמודים הקצרים לא מגיעים אליה: איך מנגנון הטעינה האוטומטית עובד מאחורי הקלעים, מה בדיוק כותבים בכל שדה של SKILL.md, מה ההבדל בין סקיל אישי לסקיל פרויקט, איך בונים סקיל ראשון צעד-אחר-צעד תוך רבע שעה, מתי נכון לבחור סקיל ומתי דווקא פרומפט, MCP או סאב-אייג'נט — ואיך מאתרים ומתקנים סקיל שלא נטען. המדריך נכתב מתוך עבודה יומיומית אמיתית: אנחנו בונים ומתחזקים עשרות סקילים בפעילות שלנו, מלמדים אותם ביותר מ-100 ארגונים, ומאחורי הקהילה שלנו עומדים יותר מ-100,000 חברים שמשתמשים בכלים האלה כל יום.
סקיל (Skill) הוא תיקייה שמכילה קובץ בשם SKILL.md — ובתוכו שני חלקים: כותרת מטא-דאטה (frontmatter) שמספרת לקלוד מתי להשתמש בסקיל, וגוף הוראות בשפה טבעית שמסביר לו איך לבצע. זה כל הסיפור מבחינה מבנית, וזו בדיוק הגאונות: אין קומפילציה, אין חבילות להתקין, אין API ללמוד. קובץ טקסט אחד בפורמט Markdown.
המבנה המינימלי נראה כך:
my-skill/
└── SKILL.md
וקובץ SKILL.md עצמו:
---
name: proposal-writer
description: כתיבת הצעות מחיר בפורמט החברה. השתמש כשמבקשים הצעת מחיר, quote או proposal.
---
# כתיבת הצעת מחיר
## מבנה קבוע
1. פתיח אישי בשם הלקוח
2. הבנת הצורך בשלוש שורות
3. טבלת מחירים...
מעבר לקובץ החובה, התיקייה יכולה להכיל כל דבר שהסקיל צריך: קבצי עזר נוספים (reference.md, examples.md), סקריפטים (Python, Bash), תבניות (templates), ואפילו נכסים גרפיים. קלוד קורא אותם רק כשצריך — וזה מוביל אותנו למנגנון החשוב באמת.
קלוד לא קורא את כל הסקילים שלכם בכל שיחה. הוא רואה רק את השורה של ה-description מכל סקיל — ורק כשהמשימה בשיחה מתאימה לתיאור, הוא טוען את גוף הסקיל המלא לזיכרון העבודה. המנגנון הזה נקרא Progressive Disclosure (חשיפה הדרגתית), והוא הסיבה שאפשר להחזיק עשרות סקילים בלי "לשרוף" את חלון ההקשר.
שווה להבין את שלוש הרמות של החשיפה ההדרגתית:
המסקנה הפרקטית החשובה ביותר מהמנגנון הזה: ה-description הוא הטריגר. לא השם, לא הכותרת — התיאור. אם התיאור כתוב עמום ("עוזר עם מסמכים"), קלוד לא יידע מתי להפעיל. תיאור טוב עונה על שתי שאלות בפירוש: מה הסקיל עושה, ומתי להשתמש בו — כולל מילות מפתח שהמשתמש באמת יגיד, בעברית ובאנגלית. למשל: "בניית מערכת תיאום פגישות עם סנכרון יומן, תשלומים ותזכורות. השתמש כשמבקשים booking, scheduling, תיאום פגישות או יומן תורים."
זה בדיוק אותו עיקרון שמלמדים במדריך הנדסת הפרומפטים שלנו — ספציפיות מנצחת כלליות — רק שכאן הפרומפט כתוב פעם אחת וחי לנצח.
ה-frontmatter של SKILL.md מכיל שדות ספורים, אבל כל אחד מהם עושה עבודה שונה — והבנה מדויקת שלהם היא ההבדל בין סקיל שנטען בזמן לסקיל שיושב מת בתיקייה.
| שדה | חובה? | מה הוא עושה | טעות נפוצה |
|---|---|---|---|
| name | כן | מזהה ייחודי, באותיות קטנות ומקפים (kebab-case) | רווחים או אותיות גדולות — הסקיל לא יזוהה |
| description | כן | הטריגר: קלוד מחליט לפיו מתי לטעון | תיאור עמום שלא כולל את המילים שהמשתמש אומר |
| allowed-tools | לא | מגביל אילו כלים מותר לסקיל להפעיל (למשל רק קריאה, בלי כתיבה) | לא להגדיר בכלל בסקילים רגישים |
| גוף הקובץ | כן | ההוראות עצמן: תהליך, טון, פורמט, דוגמאות | לדחוס הכול לגוף במקום לפצל לקבצי עזר |
ובגוף הקובץ, המבנה שעובד לנו שוב ושוב אחרי עשרות סקילים בפרודקשן:
עוד כלל זהב מהשטח: אם גוף הסקיל עובר 300–400 שורות, כנראה שהוא מנסה לעשות יותר מדבר אחד. מפצלים — או לקבצי עזר בתוך אותה תיקייה, או לשני סקילים נפרדים.
ההבדל בין סקיל אישי לסקיל פרויקט הוא רק מיקום התיקייה — אבל ההשלכה עצומה: סקיל אישי מלווה אתכם בכל פרויקט במחשב, וסקיל פרויקט משותף אוטומטית לכל מי שעובד על הריפו.
| סוג | מיקום | מתי לבחור |
|---|---|---|
| סקיל אישי | ~/.claude/skills/ בתיקיית הבית | שיטות עבודה שלכם: סגנון כתיבה, תהליכי מחקר, כלים אישיים |
| סקיל פרויקט | .claude/skills/ בתוך הריפו | סטנדרטים של הצוות: קונבנציות קוד, תהליך דיפלוי, טון המותג |
| סקיל ארגוני משותף | ריפו ייעודי שמסתנכרן לכולם | ספריית ידע ארגונית שמנוהלת כמו קוד |
הנקודה השלישית היא הגדולה מכולן לארגונים, ורוב האנשים מפספסים אותה: ברגע שסקיל פרויקט יושב בגיט, הידע הארגוני שלכם מקבל גרסאות, code review והיסטוריה. עובד חדש שמצטרף מקבל ביום הראשון את כל שיטות העבודה של הצוות — לא בחפיפה של שבועיים, אלא בקובץ שקלוד קוד (Claude Code) טוען אוטומטית. זה השינוי התרבותי שאנחנו רואים בארגונים שעברו את קורס קלוד קוד שלנו: הידע מפסיק לשבת בראש של אנשים ומתחיל לשבת במערכת.
חשוב לדעת: סקילים עובדים גם ב-Claude Code בטרמינל, גם באפליקציית קלוד וגם דרך ה-API — כך שסקיל שכתבתם פעם אחת משרת אתכם בכל הממשקים. עם המודלים של 2026 — קלוד פייבל 5 (Claude Fable 5) ו-Opus 4.8 למשימות המורכבות, סונט 4.6 (Sonnet 4.6) לעבודה השוטפת והייקו 4.5 (Haiku 4.5) למשימות מהירות — אותו סקיל בדיוק רץ על כל המודלים, כי הוא בסך הכול טקסט.
הדרך הכי טובה להבין סקילים היא לבנות אחד — והנה התהליך המלא, מרעיון לסקיל עובד, כפי שאנחנו מלמדים אותו בסדנאות.
הסימן המזהה: אתם מעתיקים-מדביקים את אותו פרומפט שוב ושוב, או מתקנים את קלוד באותן נקודות בכל פעם. דוגמאות קלאסיות: סיכום פגישות בפורמט קבוע, מיילים ללקוחות בטון החברה, בדיקת קוד לפי הצ'קליסט של הצוות.
mkdir -p ~/.claude/skills/meeting-summary
ובתוכה SKILL.md. אין צעדים נוספים — אין רישום, אין הפעלה, אין restart.
כתבו את התיאור אחרון, אחרי שגוף הסקיל מוכן, ושאלו את עצמכם: "אילו מילים בדיוק אני אגיד לקלוד כשארצה את זה?" אלה המילים שחייבות להופיע בתיאור. אם אתם עובדים בעברית — כללו את הניסוח העברי והאנגלי גם יחד ("סיכום פגישה, meeting summary, פרוטוקול").
קחו סיכום פגישה אמיתי שיצא לכם מושלם, הדביקו אותו כדוגמה, וכתבו מעליו את הכללים שהוא מדגים. אל תמציאו דוגמה סינתטית — דוגמה אמיתית מקודדת אינסוף ניואנסים שלא הייתם חושבים לנסח.
פותחים שיחה חדשה, נותנים משימה אמיתית, ובודקים: האם הסקיל נטען? האם הפלט לפי הסטנדרט? כל סטייה — מוסיפים כלל או מחדדים את הדוגמה. שניים-שלושה סבבים ואתם שם.
והטריק שחוסך את רוב העבודה: בקשו מקלוד לכתוב את הסקיל בשבילכם. תארו לו את המשימה, הדביקו דוגמה טובה של תוצר, ובקשו "כתוב לי SKILL.md לסקיל שעושה את זה". קלוד מכיר את הפורמט של עצמו טוב מכולם. מי שרוצה ללוות את התהליך הזה אחד-על-אחד — זה בדיוק סוג הדברים שאנחנו עושים בשיעור פרטי.
ארבעת המנגנונים האלה מרחיבים את קלוד בדרכים שונות, והבחירה הנכונה ביניהם היא אחת השאלות הכי שכיחות שאנחנו מקבלים בסדנאות. הכלל המהיר: פרומפט לחד-פעמי, סקיל ל"איך לעבוד", MCP ל"למה להתחבר", סאב-אייג'נט ל"מי יעשה את זה במקביל".
| מנגנון | מה הוא נותן | מתי לבחור | דוגמה |
|---|---|---|---|
| פרומפט | הוראה חד-פעמית בשיחה | משימה שלא תחזור | "נסח לי את המייל הזה מחדש" |
| סקיל (Skill) | ידע והוראות שנטענים אוטומטית | סטנדרט קבוע שחוזר | כתיבת הצעות מחיר בפורמט החברה |
| MCP | חיבור לכלים ומקורות מידע חיצוניים | קלוד צריך גישה למערכת אמיתית | שליפת נתונים מ-CRM או ממסד נתונים |
| סאב-אייג'נט (Subagent) | סוכן-משנה עם הקשר נפרד | משימות ארוכות/מקבילות שלא צריכות לזהם את השיחה | סריקת ריפו שלם וסיכום ממצאים |
ההבנה העמוקה יותר: המנגנונים לא מתחרים — הם נערמים. הסקילים החזקים באמת משלבים את כולם: סקיל שמגדיר את שיטת העבודה, קורא לשרת MCP כדי לגשת לנתונים אמיתיים (על כך בהרחבה במדריך ה-MCP המלא שלנו), ומשגר סאב-אייג'נטים לביצוע חלקים מקביליים. כך נראית אוטומציה ארגונית אמיתית ב-2026: לא פרומפט חכם, אלא מערכת שכבות שכל אחת עושה את תפקידה.
נקודה שכדאי להפנים: אם אתם מוצאים את עצמכם מדביקים לקלוד את אותו הסבר בפעם השלישית — זה הרגע המדויק שבו פרומפט צריך להפוך לסקיל. שלוש פעמים זה הסימן.
כל אחד מהרעיונות האלה מבוסס על סקילים שראינו עובדים בפועל אצלנו או אצל ארגונים שליווינו — לא רשימת השראה גנרית.
שימו לב לדפוס המשותף: כל סקיל טוב מקודד החלטה שכבר קיבלתם פעם, כדי שלא תצטרכו לקבל אותה שוב. זה המבחן הכי פשוט לרעיון לסקיל — אם אין לכם עדיין תשובה ל"איך זה צריך להיראות", עוד מוקדם לכתוב סקיל. קודם מגבשים סטנדרט, אחר כך מקודדים אותו.
סקיל הוא בסך הכול תיקייה — ולכן שיתוף שלו פשוט כמו שיתוף קבצים: git, קובץ zip, או תיקייה משותפת. אבל מעבר לטכניקה, נפתח כאן שוק שלם של סקילים מוכנים שחוסכים את הבנייה מאפס.
שלוש דרכים לשתף, מהפשוטה למסודרת:
היתרון של ערכה מוכנה על פני בנייה עצמית הוא לא רק הזמן — זה הניסיון המקודד. סקיל שרץ חודשים בפרודקשן כבר "אכל" את כל מקרי הקצה: תעריפים שהשתנו, API שהחזיר שגיאה, פורמט שנשבר במובייל. כשאתם קונים ערכה, אתם קונים את כל התיקונים האלה מראש.
תשעים אחוז מהבעיות עם סקילים מתנקזות לסיבה אחת: התיאור לא תואם את מה שהמשתמש באמת אומר. אבל בואו נעבור על הרשימה המלאה, מהנפוץ לנדיר.
צ'קליסט איתור תקלות:
טיפ דיבאג מתקדם שאנחנו משתמשים בו כל הזמן: שאלו את קלוד עצמו. "טענת את הסקיל X? למה לא?" — קלוד יגיד לכם בדיוק איך הוא פירש את התיאור, וזה בדרך כלל חושף את הפער בין מה שכתבתם למה שהתכוונתם.
ההבדל בין סקיל בסיסי לסקיל מקצועי הוא לרוב לא בהוראות — אלא במה שמסביבן: סקריפטים שהסקיל מריץ, תבניות שהוא ממלא, וקבצי ידע שהוא שולף לפי צורך. ברגע שמבינים שהתיקייה יכולה להכיל כל דבר, נפתחות אפשרויות חדשות לגמרי.
מבנה של סקיל מתקדם אמיתי נראה בערך כך:
booking-system/
├── SKILL.md ← התהליך והכללים (רזה!)
├── reference.md ← פירוט API, פרמטרים, מקרי קצה
├── templates/
│ ├── email-he.md ← תבנית מייל אישור בעברית
│ └── reminder.md ← תבנית תזכורת
└── scripts/
└── check-slots.mjs ← סקריפט שקלוד מריץ לבדיקת זמינות
שלושה עקרונות שהופכים את המבנה הזה לעובד:
הדפוס הזה — הוראות רזות + סקריפטים דטרמיניסטיים + תבניות — הוא בדיוק איך בנויות הערכות המקצועיות בחנות שלנו. כשתפתחו אחת מהן תראו את הארכיטקטורה הזאת בפעולה, וזו דרך מצוינת ללמוד איך בונים סקיל ברמת פרודקשן: לקרוא סקיל בשל של מישהו אחר לפני שכותבים משלכם.
כדי לחבר את כל התאוריה לקרקע, הנה תהליך אמיתי שאנחנו רואים שוב ושוב בארגונים שאנחנו מלווים — הפעם בדוגמה של צוות שיווק שהופך את כתיבת הניוזלטר לסקיל.
יום 1 — זיהוי. מנהלת השיווק שמה לב שהיא פותחת כל כתיבת ניוזלטר באותה הדבקה: שלוש פסקאות של הנחיות טון, רשימת איסורים, ושני ניוזלטרים ישנים כדוגמה. הסימן הקלאסי: פרומפט קבוע שחי בקובץ notes.
יום 2 — גיבוש הסטנדרט. לפני כתיבת הסקיל, הצוות יושב חצי שעה ומסכים על מה שעד עכשיו היה בראש של אדם אחד: אורך מקסימלי, מבנה קבוע (הוק → תוכן → CTA אחד בלבד), ומה לעולם לא נכנס (סופרלטיבים ריקים, יותר מקישור אחד לפסקה). זה הצעד שרוב הארגונים מדלגים עליו — ואז מתפלאים שהסקיל "לא עובד". הסקיל לא יכול לקודד הסכמה שלא קיימת.
יום 3 — כתיבה ובדיקה. את ה-SKILL.md כותב... קלוד עצמו, מתוך ההנחיות והדוגמאות. הצוות מריץ אותו על שלושה נושאים אמיתיים, מסמן כל סטייה, ומוסיף כלל על כל תיקון. בסוף היום: שלושה ניוזלטרים רצופים בלי תיקון ידני אחד.
יום 5 — שיתוף. הסקיל נכנס לריפו הצוותי תחת .claude/skills/newsletter/. מעכשיו כל חבר צוות — כולל העובד שיצטרף בעוד חצי שנה — כותב ניוזלטר באותו סטנדרט בדיוק.
שבוע 3 — האיטרציה שמוכיחה את השיטה. קמפיין חדש דורש טון שונה לסגמנט אחד. במקום לשבור את הסקיל, הצוות מוסיף סעיף "וריאציות לפי סגמנט" עם כללים לכל קהל. הסקיל גדל עם העסק — וכל שינוי עובר דרך pull request, עם היסטוריה מלאה של מי שינה מה ולמה.
התוצאה המצטברת היא הנקודה: לא "חסכנו עשר דקות בניוזלטר", אלא הידע השיווקי של הארגון קיבל בית מנוהל. כשמנהלת השיווק תצא לחופשה, הסטנדרט לא יוצא איתה. (אגב, מערכת ניוזלטר שלמה — כולל קמפיינים, סגמנטים ואנליטיקס — היא אחת הערכות המוכנות שלנו; אפשר לראות אותה בפעולה בניוזלטר שלנו.)
סקיל הוא קוד-מדיניות שרץ עם ההרשאות של המשתמש — ולכן בסביבה ארגונית צריך להתייחס אליו כמו לכל תוכנה: מי כתב, מה הוא מריץ, ולמה יש לו גישה. הנה ארבעת הכללים שאנחנו מנחילים בהטמעות ארגוניות:
החדשות הטובות: בדיוק בגלל שסקיל הוא קובץ טקסט שקוף, הביקורת עליו קלה לאין ערוך מביקורת על תוסף בינארי או שירות ענן. ארגון שמנהל את הסקילים שלו בגיט מקבל שרשרת אספקה שקופה לחלוטין.
אם 2023–2024 היו שנות הפרומפט ו-2025 הייתה שנת הסוכנים, 2026 היא השנה שבה ארגונים מבינים שהנכס האמיתי הוא לא המודל — אלא הידע הארגוני שמלביש אותו. המודלים מתחלפים ומשתפרים: פייבל 5 (Fable 5) ומיתוס 5 (Mythos 5) החליפו את הדור הקודם, ומחר יבוא הדור הבא. אבל הסקילים שלכם — הסטנדרטים, התהליכים, הטון, הידע — עוברים איתכם מדור לדור בלי לשנות שורה. סקיל שנכתב על סונט הוא אותו סקיל על אופוס.
זו הסיבה שאנחנו רואים בסקילים את ההשקעה עם התשואה הגבוהה ביותר בכל מסע ה-AI הארגוני: כל שעה שמושקעת בקידוד ידע לסקיל ממשיכה להחזיר את עצמה על כל מודל עתידי, על כל עובד חדש, על כל משימה חוזרת. הארגונים שבונים היום ספריית סקילים בונים למעשה את "מערכת ההפעלה" של הידע שלהם — ומי שמתחיל מוקדם צובר פער שקשה לסגור.
אחרי שליווינו מאות אנשים בבניית הסקילים הראשונים שלהם — באקדמיה החינמית, בסדנאות וב-100+ ארגונים — אלה הטעויות שחוזרות שוב ושוב:
סקיל בודד מחזיקים בקלות; ספרייה של עשרים סקילים דורשת משמעת קלה — ואלה ההרגלים שהופכים ספרייה חיה למשהו שלא מתפרק אחרי חודשיים.
הניסיון שלנו מ-100+ ארגונים חד-משמעי: ההבדל בין ארגון שהסקילים שלו משגשגים לארגון שנטש אותם הוא אף פעם לא טכני. זה תמיד ההרגל הקטן של להחזיר תיקונים לקובץ — ומי שמטמיע את ההרגל הזה בשבועיים הראשונים, נשאר עם ספרייה חיה לשנים.
"כמה סקילים זה יותר מדי?" אין מספר קסם, כי החשיפה ההדרגתית שומרת על העלות נמוכה — אבל יש מבחן איכות: אם אתם לא זוכרים מה סקיל עושה בלי לפתוח אותו, כנראה שיש כפילויות. אצלנו רצות עשרות סקילים במקביל בלי בעיה, כי לכל אחד גבול גזרה חד.
"אפשר סקיל שקורא לסקיל אחר?" סקילים לא "קוראים" זה לזה ישירות, אבל קלוד יכול לטעון כמה סקילים באותה משימה אם כמה תיאורים רלוונטיים. בפועל, עדיף לתכנן סקילים כשכבות משלימות: סקיל טון-מותג + סקיל מבנה-פוסט יעבדו יחד נהדר בלי לדעת אחד על השני.
"מה עדיף — סקיל ארוך או סקיל עם קבצי עזר?" קבצי עזר, כמעט תמיד. SKILL.md רזה עם התהליך והכללים הקריטיים, וכל השאר (מפרטים, טבלאות ארוכות, דוגמאות רבות) בקבצים שנקראים לפי צורך. ככה גם קל יותר לתחזק.
"סקילים עובדים בעברית?" לגמרי. גם התיאור וגם הגוף יכולים להיות בעברית מלאה (רק שדה ה-name באנגלית). בפועל אנחנו ממליצים על תיאור דו-לשוני — כי לפעמים תבקשו את המשימה באנגלית — וגוף בשפה שנוחה לצוות. כל הסקילים שאנחנו בונים לארגונים ישראליים כתובים בעברית.
"איך מודדים שסקיל באמת עוזר?" שני מדדים פשוטים: כמה פעמים תיקנתם את הפלט ידנית (צריך לרדת לכיוון אפס), וכמה זמן לוקחת המשימה מקצה לקצה. סקיל טוב מוריד את שניהם תוך שבוע.
"מה הקשר בין סקילים ל-CLAUDE.md?" קובץ CLAUDE.md הוא הוראות שנטענות תמיד, בכל שיחה בפרויקט — הוא מתאים להקשר קבוע וקצר (מה הפרויקט, איך בנוי, מה הקונבנציות). סקיל נטען רק כשצריך, ולכן מתאים לידע עמוק וממוקד-משימה. הכלל: מה שרלוונטי לכל שיחה → CLAUDE.md; מה שרלוונטי למשימה מסוימת → סקיל. שילוב נכון של שניהם הוא אחד הנושאים המרכזיים שאנחנו מלמדים בקורס קלוד קוד.
"מאיפה מתחילים כשאין שום ניסיון טכני?" מהאפליקציה הרגילה של קלוד, לא מהטרמינל: גם שם סקילים עובדים, וכתיבת SKILL.md לא דורשת שום קוד. מי שרוצה בסיס מסודר בחינם — האקדמיה שלנו בנויה בדיוק בשביל זה, בעברית ומאפס.
Claude Skills הם התשובה לשאלה ששאלתם את עצמכם בפעם המאה כשהעתקתם את אותו פרומפט: "למה הוא לא פשוט זוכר איך אני אוהב את זה?" — עכשיו הוא זוכר. תיקייה, קובץ SKILL.md אחד, תיאור מדויק — וקלוד עובד לפי הסטנדרט שלכם בכל שיחה, בכל ממשק, על כל מודל.
הצעדים המומלצים מכאן, לפי סדר:
הידע שלכם שווה יותר כשהוא מקודד. תתחילו לקודד אותו.