זרימת העבודה המרכזית מאחורי אוסף ה-Skills של Matt Pocock, צעד אחר צעד

כבר תקופה שרציתי לשבת ברצינות עם אוסף ה-skills של Matt Pocock. זה פרויקט פופולרי באמת - 162,000 כוכבים ב-GitHub ו-7.5 מיליון הורדות נכון לרגע כתיבת השורות - וראיתי שוב ושוב את אותן השאלות: באיזה סדר משתמשים ב-skills האלה, איך מתקינים אותם, איך מגדירים אותם על פרויקט חדש. אז סוף סוף עברתי על כל הזרימה בעצמי, מההתחלה ועד הסוף, על בסיס קוד אמיתי.

התקנה

ההתקנה עוברת דרך פקודה אחת: npx skills@latest add mattpocock/skills. זה עובד אותו דבר בין אם מכוונים אותה על בסיס קוד קיים או על תיקייה ריקה. המתקין מוביל אתכם דרך כמה שאלות: אילו skills להתקין (יש סט ציבורי ומאושר וסט נפרד ניסיוני), באיזה סוכן משתמשים (Claude Code, Cursor, Codex ואחרים - כולם נתמכים), ואם ההתקנה ברמת פרויקט או גלובלית.

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

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

תצורה לפני שמתחילים

אחרי ההתקנה, מריצים skill של הגדרות שמחבר כמה דברים לתוך הריפו: איפה טיקטים וספציפיקציות נשמרים (GitHub, Jira, Linear, או סתם markdown מקומי - אומרים לו איזה ומתקנים בהתאם), סט תוויות טריאז' למעקב אחרי מצב הטיקט, ואם הפרויקט צריך מסמך הקשר משותף אחד או כמה נפרדים למונו-ריפו גדול עם כמה תחומים. לרוב הפרויקטים, הקשר יחיד מספיק.

הזרימה בפועל: מרעיון לקוד ששוגר

לזרימה המרכזית יש צורה ברורה ברגע שהרצתם אותה פעם אחת.

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

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

ה-spec מתפרק אז לטיקטים בודדים, כל אחד בגודל שמתאים לסשן עבודה יחיד. כאן נכנס מודל מנטלי שימושי: לחשוב על חלון ההקשר של המודל כבעל "אזור חכם" (smart zone) - בערך 140 אלף הטוקנים הראשונים - לפני שהקשב מתחיל להתדרדר ואיכות הפלט יורדת. התאמת גודל כל טיקט לתוך האזור הזה, וניקוי ההקשר בין טיקט לטיקט, שומרת על כל סשן עובד עם מודל חד באמת במקום אחד שהולך ומתבלבל.

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

למה סקירה בהקשר טרי חשובה

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

לסיכום

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