להזריק פלט של פקודה לסקיל לפני שהמודל קורא אותו

אחד הפיצ’רים השימושיים בסקילים הוא dynamic content: פקודה בצורת !`command` בקובץ SKILL.md — או בכל קובץ .md של סלאש-קומנד — מזריקה את הפלט שלה לתוך הפרומפט עוד לפני שהמודל רואה את הקובץ.

איך זה עובד

- Current branch: !`git branch --show-current`
- Staged diff: !`git diff --cached`
Review this diff against the project conventions.

קלוד קוד מריץ כל פקודת !`…` ברגע שהסקיל נטען, ומחליף את ה-token בפלט עצמו.
המודל אף פעם לא רואה את התחביר של ! — רק את הטקסט שיצא ממנו.
אפס עלות של קריאות כלים, והמודל מנתח את כל המידע כבר במעבר הראשון.

למה זה שווה

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

מתי להשתמש בזה

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

המבחן למה שמתאים להיכנס לשם: האם הפקודה קבועה (לא תלויה בערך שחושב קודם) ובלתי-מותנית (מופעלת בכל הרצה)?
git status עומדת בתנאי; git log $LAST_SHA..HEAD לא, אלא אם תכווץ את הכל לפקודה אחת.
ובאמת — ההחלטה הראשונה של המודל צריכה את המידע הזה? אם לא, השאר אותו במקום שבו הוא נחוץ.

יש גם את ה-${ARGUMENTS} / $1 הקשור — placeholder להעברת ארגומנטים לתוך פקודה.
מנגנון אחר, אבל הרבה פעמים משתמשים בו לצד !`cmd`.

איפה זה מצדיק את עצמו

כל סקיל שלי שמשתמש בזה — מה הסקיל עושה, ומה הטעינה-מראש של הקונטקסט נותנת דווקא לו.

deploy-gcp — פורס שירותים ל-Cloud Run עם בדיקות pre-flight שמונעות דיפלוי לסביבה הלא נכונה.

השאלה הראשונה תמיד היא “לאיזה account ו-project אני מחובר, וה-tree נקי?”
עד שהמודל קורא את הסקיל, הוא כבר יודע.
הוא יכול לסרב לדיפלוי ל-prod כבר במשפט הראשון, במקום להריץ gcloud, לקרוא את הפלט ואז להחליט.
כל ערך הביטחון נשען על שהמצב הזה קיים לפני שהוא פועל.

deploy-delta — מחשב את ה-backlog האמיתי של הקומיטים בין ה-SHA שנפרס לבין ה-HEAD המקומי (“כמה prod מפגר”).

HEAD וה-branch הם העוגנים שכל ה-diff נמדד מולם.
טעינה מראש שלהם אומרת שההשוואה מתחילה כבר ברגע הראשון.

tech-debt — ניקיון סוף-סשן שמוצא כפילויות וקוד מת, ואז מאחד.

הוא יכול לנקות רק את מה שהשתנה בסשן הזה, אז ה-diff מוזרק מראש.
המודל מתחיל לנתח את השינויים האמיתיים במקום לשאול את git “במה נגעתי?”.

remember — עובר על הזיכרון האוטומטי שלי ומציע קידומים, מסמן קונפליקטים.

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

skillify — הופך את הסשן הנוכחי לסקיל לשימוש חוזר.

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

standup — טוען קונטקסט בתחילת סשן: איפה הייתי, על מה עבדתי.

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

stuck — מאבחן סשן קלוד תקוע או איטי על המכונה שלי.

השלב הראשון תמיד הוא “מה רץ”.
הזרקה של רשימת ה-ps אומרת שהטריאז’ מתחיל על מידע אמיתי מיד.
פקודות חיות הוא מריץ רק אחר כך, כדי לדגום שוב CPU ולוודא שעלייה היא באמת לולאה.

ticket-sync — סוף-סשן: לסכם עבודה, לוודא שיש טיקטים ב-Linear, לעדכן סטטוס.

הוא צריך שני דברים מראש — איזה repo (שאומר לו את צוות ה-Linear) ומה השתנה (שאומר לו את הטיקטים).
שניהם מגיעים טעונים מראש, אז הוא הולך ישר להתאמה בין העבודה לטיקטים.

החוט המשותף לכל השמונה: כל אחד מהם טוען מראש את הקלט שההחלטה הראשונה שלו תלויה בו.
והרווח מגיע בשתי צורות.
ב-standup, tech-debt ו-remember, הקונטקסט שמוזרק הוא התוצר — הטעינה שלו היא רוב העבודה שהסקיל עושה.
ב-deploy-gcp ו-stuck, הוא שולט בהחלטה — הוא נותן למודל לשפוט או לסרב לפני שהוא פועל.

שני כללים שאני מקפידה עליהם

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

מקבצים את הפקודות לבלוק מסומן בראש הקובץ.
סקשן ## Context (auto-loaded at invocation), ישר אחרי הפתיח, עם כל ה-!`…` במקום אחד.
ואז אני משכתבת את השלבים שבהמשך כך שיקראו את הערכים האלה במקום להריץ את הפקודות שוב — שורה כמו “מכסה את שלב 1 ושלב 2. תקרא את אלה; אל תריץ שוב”.
בלי זה, המודל בשמחה מביא את ה-branch בפעם שנייה, וכל הפואנטה מתאדה.

עוטפים כל פקודה בהגנה.
הפלט נצרב לתוך הפרומפט כמו שהוא, אז fatal: not a git repository לא-מוגן נוחת כקונטקסט מילולי ומבלבל את המודל.
כל פקודה נגמרת ב-2>/dev/null || echo "no remote" או משהו דומה.
ה-fallback הופך כישלון לאות נקי שהמודל יכול להשתמש בו.

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

Uncommitted changes: !`git status --porcelain 2>/dev/null | wc -l | tr -d ' '` files

המודל בדרך כלל לא צריך את רשימת הקבצים שהשתנו.
הוא צריך לדעת אם ה-tree נקי.
3 files אומר את זה בשני טוקנים; קיר של נתיבי קבצים אומר את זה במאתיים.

העסקה

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