איך בונים Claude Skill שבאמת עובד

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

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

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

פרומפט הוא הוצאה. Skill הוא נכס.

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

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

בוחן חוזק ל-description

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

description: Helps with client documents and pricing.

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

1. 1שופכים את הידע הגולמי

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

   העתק

   יש לי תהליך שאני חוזר עליו כל שבוע: [תיאור חופשי].
   הנה דוגמה לפלט טוב: [להדביק].
   דברים שתמיד משתבשים: [רשימה].

2. 2מריצים את skill-creator
3. 3עונים על השאלות שלו
4. 4עוברים על הטיוטה
5. 5מתקינים ומריצים בדיקת עשן

מודלים הם סטוכסטיים. אותו כישור, אותה פנייה - ריצה אחת מצליחה ואחת נכשלת. בדיקה של כישור היא לא "ניסיתי פעם ועבד", היא טבלה: 5-6 מקרים, כמה ריצות לכל אחד, ושלושה דברים שמודדים - האם הכישור הופעל בכלל (טריגר), האם הפלט עומד בדרישות (איכות), וכמה התוצאה יציבה בין ריצות (שונות).

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

כלל אצבע: מקרה שעובר 4 מתוך 4 ריצות - יציב. 3 מתוך 4 - חשוד. 2 מתוך 4 זה מטבע הוגן, ומטבע הוגן זה לא כלי עבודה.

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

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

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

• טריגרים: 4/4 על ניסוחים אמיתיים, כולל עברית
• איכות: 3/4 ומעלה על כל מקרה
• טריגר שלילי: לא יורה על בקשות שכנות
• כל כישלון מהשטח נכנס לטבלה לפני שמתקנים