כשקלוד מפעיל את הקלוד הבא
Skill שהופך את המעבר בין סשנים של קלוד ל-command אחד. הסשן הקודם כותב את ה-handoff, פותח pane חדש, מריץ שם קלוד חדש — והוא מתחיל לעבוד. בלי פרומפט ממני, בלי טרמינל חדש, בלי הסברים מחדש. אני עושה review ל-PRים.
הוורקפלואו החדש שלי עוזר לי לעשות אוטומציה, לשחרר פיצ’רים מהר יותר, לשמור את קלוד חד, ולעקוב אחרי העבודה לאורך זמן.
עבודה על פיצ’ר לאורך כמה סשנים זה לא משהו חדש. כבר הרבה זמן שפיצ’רים מורכבים נפרסים על כמה סשנים, והתוכניות שלהם חיות בתוך ה-repo כך שכל אייג׳נט יכול לקרוא אותן.
מה שהשתנה אצלי לאחרונה זה שהמעברים בין הסשנים התחילו לעבוד לבד.
הקלוד הקודם כותב את ה-handoff. הוא פותח pane חדש לידו, מריץ שם קלוד חדש, ומכוון אותו למסמך. האייג׳נט החדש קורא את המסמך ומתחיל לעבוד, בלי שאני אגשר ביניהם.
הוורקפלואו
אנחנו מתכננים פיצ’ר שגדול מדי בשביל סשן אחד, וקלוד מתחיל לעבוד עליו.
כשהסשן מתמלא, הוא כותב מסמך handoff ומריץ קלוד חדש ב-pane חדש. החדש ממשיך בדיוק מהמקום שהקודם עצר.
כשהוא מתמלא, גם הוא עושה אותו דבר. הלולאה ממשיכה כמה שצריך — רצף של קלודים שמעבירים את העבודה ביניהם.
ה-handoff נותן לי ארבעה יתרונות מאוד ברורים:
- אוטומציה — כל הדבק שפעם עשיתי ידנית (לפתוח pane, לכתוב
claude, להדביק brief, לחכות לטעינה, לכתוב את הפרומפט הראשון) נעשה עכשיו על ידי האייג׳נט הקודם. - לעבוד מהר יותר — כל שלב בריליי רץ על context נקי ובמהירות מלאה, במקום סשן אחד ארוך שמתחיל להיסחב תחת המשקל של עצמו.
- לשמור את קלוד חד — ה-context מתאפס בכל handoff לפני שהמודל מתחיל להיגרר.
- לעקוב אחרי העבודה — כל relay משאיר אחריו handoff doc וסט של PRים שמספרים ביחד את הסיפור של מה שנשלח.
החלקים שמרכיבים את זה
זה התחיל בכלל מניסיון לחסוך לעצמי רצף פעולות שחזר על עצמו שוב ושוב.
השתמשתי כבר תקופה ב-skill של handoff, ובכמה פעמים רצופות עשיתי אחריו בדיוק את אותו רצף ידני: לפתוח pane חדש, לכתוב claude, ולהפנות אותו למסמך.
אחרי כמה סבבים כאלה שאלתי את השאלה המתבקשת: למה זה לא command אחד? אז קלוד כתב את החיווט.
יש שני דברים קיימים שמאפשרים את כל הוורקפלואו הזה, ועוד אחד שביקשתי מקלוד לכתוב מעליהם:
- cmux — ה-terminal multiplexer שכל המערכת רצה עליו, שמאפשר לקלוד ב-pane אחד לפתוח pane אחר בצורה פרוגרמטית ולהריץ בו קלוד נוסף.
- skill בשם
handoff— הפרימיטיב שכותב את מסמך ה-handoff ומכווץ את הסשן הנוכחי ל-brief של עמוד אחד. מבוסס על מערכת ה-skills שהקהילה משתפת (אני משתמשת הרבה ב-repo של Matt Pocock). - skill בשם
handoff-launch— הדבר הקטן שקלוד כתב כדי לחבר ביניהם: לכתוב את המסמך, לפתוח pane חדש, לשלוח את פקודת ההרצה, ולהפעיל את הקלוד הבא. הכל מ-slash command אחד בתוך הסשן הקודם ובלי הקלדה ממני.
ה-handoff הוא גבול ה-context
לקח לי זמן להבין שה-relay הזה הוא לא רק דרך להוריד עבודה ידנית. זו גם טכניקת ניהול context.
סשן ארוך של קלוד מתמלא. חלון ה-context סופי, וה-auto compactor כל הזמן מתקרב.
אחרי כמה שעות המודל כבר סוחב דברים שהוא לא צריך: כל סמטה מתה שניסיתם, כל misunderstanding שכבר פתרתם, כל טסט שנכשל לפני שתיקנתם. המידע הזה אולי עדיין נכון. זה לא אומר שהוא עדיין מועיל.
מסמך ה-handoff מעביר רק את מה ששרד:
- הנתיבים הלא נכונים נעלמים.
- misunderstandings שתוקנו מופיעים כהחלטות, לא כוויכוחים.
- האייג׳נט החדש לא צריך ללמוד מה לא לעשות — הוא פשוט מקבל את התוכנית.
זה יתרון מבני ששום prompting חכם בתוך הסשן הישן לא באמת משחזר. ה-handoff הוא המנוף. ה-skill פשוט הופך את השימוש בו לחינמי.
מה ה-skill באמת עושה
ה-skill נקרא handoff-launch. הוא רץ בתוך הסשן הנוכחי, בדרך כלל כשיחידת עבודה נקייה הסתיימה: PR עלה, checkpoint נסגר, או שהשלב הבא מוגדר היטב.
Slash command אחד מפעיל אותו. בלי עוד input ממני, קלוד עושה ארבעה דברים:
-
כותב מסמך handoff. קצר, עם דעה, בלי transcript. המסמך מתאר מה נעשה, מה השלב הבא, אילו קבצים חשובים, אילו החלטות סגורות ואילו עדיין פתוחות. הוא מפנה לתוכנית ול-PRים שעלו במקום לשכתב אותם.
-
פותח pane חדש ב-terminal multiplexer, מימין ל-pane הנוכחי, בפוקוס.
-
שולח פקודת
claudeל-pane החדש עם הנתיב של ה-handoff: לקרוא את המסמך ולהתחיל לעבוד. -
מהבהב את ה-pane החדש כדי שהעין שלי תלך לשם.
זה כל האינטראקציה מהצד שלי. שש שניות, slash command אחד, בלי הקלדה, בלי ניווט בין טרמינלים.
הקלוד החדש עולה, קורא את המסמך, ומתחיל את ה-PR הבא. אני עוברת אליו כשבא לי להסתכל.
שני פרטים קטנים שהם בעצם מאוד משמעותיים
יש כמה החלטות קטנות במנגנון הזה שנושאות הרבה יותר משקל ממה שנראה.
cmux מתייחס ל-panes כמשטחים שאפשר לכתובת אותם. אייג׳נט בתוך pane אחד יכול לפתוח pane אחר בצורה דטרמיניסטית, לשלוח אליו keystrokes, ולקרוא בחזרה את המסך שלו. בלי זה, אין דרך לקלוד אחד להפעיל קלוד אחר לידו. כל הוורקפלואו נשען על זה.
מסמך ה-handoff חי ב-$TMPDIR, לא בתוך ה-repo. Handoffs הם זמניים. לא מגיע להם git commit. הם קיימים בשביל משימה אחת בלבד — להרים את הסשן הבא — ואז נעלמים. זה מונע handoff rot: מסמכים ישנים בפרויקט שנראים authoritative אבל מתארים מצב מלפני שלושה סבבים.
ההפרדה: cmux הוא הטופולוגיה. ה-handoff skill הוא המסמך. ה-handoff-launch skill הוא החיווט. אף אחד מהם לא מעניין לבד. ביחד הם הופכים את גבול הסשן לכמעט חסר עלות.
למה ה-”autonomous start” זה החלק שבאמת משנה
הנקודה הכי חשובה בכל הסיפור הזה: אני לא פותחת את הקלוד החדש, והקלוד החדש לא מחכה לי.
אני אומרת לקלוד הישן “תעשה handoff” וממשיכה לדברים אחרים. הוא כותב את המסמך, פותח pane חדש, מפעיל שם קלוד, ומכוון אותו למסמך. הקלוד החדש לא קורא את המסמך ואז שואל “מה לעשות עכשיו?” — המסמך כבר הגדיר את זה. הוא פשוט מתחיל לעבוד על ה-PR הבא.
זה נשמע כמו tweak קטן. זה לא.
אם הצד הזה היה דורש ממני משהו — לפתוח את הקלוד החדש, או לתת לו פרומפט אחרי שעלה — הייתי חייבת להיות ליד המקלדת בדיוק ברגע ה-handoff. כשהאוטונומיה משני הצדדים, ה-relay ממשיך גם אם אני בחלון אחר, בפרויקט אחר, או לא ליד המחשב בכלל. הפיצ’ר ממשיך לזוז.
עדיין יש interactive mode בשביל המקרים הנדירים שבהם אני רוצה לנהוג ידנית. אבל זאת החריגה, לא ברירת המחדל.
הבחירה באוטונומיה כברירת מחדל היא מה שהופך את זה לריליי אמיתי, ולא לשרשרת restartים בפיקוח אנושי.
והאוטונומיה הזאת תחומה. התוכנית נמצאת ב-repo, העבודה בנויה סביב PRים, ושום דבר לא נכנס ל-production בלי review. האייג׳נט יכול לקדם את ה-branch. הוא לא יכול למזג את שיקול הדעת של עצמו ל-production.
מה אני בעצם עושה היום
בין PR ל-PR, שלושה דברים:
- קוראת את ה-diff.
- מעירה אם משהו לא טוב.
- עושה merge.
מה אני כבר לא עושה:
- לא כותבת פרומפטים.
- לא פותחת טרמינלים.
- לא מסכמת את הסשן הקודם בשביל הבא — הסשן הקודם כבר עשה את זה.
- לא מסבירה מחדש את התוכנית — היא כבר נמצאת ב-repo ושני הקלודים יכולים לקרוא אותה.
רק כשהתחלתי לספור הבנתי כמה glue work ירד לי מהיום. לא שעות דרמטיות. פשוט כמות עצומה של context switches קטנים שכבר לא קיימים. כל אחד מהם היה זול. ביחד הם היו מס.
התפקיד שלי התחיל להידחס יותר ויותר לכיוון של reviewer. וזו הצורה הנכונה. Review על diffs זה עבודה אנושית עם leverage גבוה. להדביק boilerplate לטרמינלים זה לא.
מה באמת מחזיק את הלולאה הזאת
יש שלושה דברים שהופכים את כל זה ליציב.
התוכנית חיה ב-repo, לא בשיחה. אם התוכנית הייתה קיימת רק בתוך ה-scrollback של הסשן, מסמך ה-handoff היה צריך להכיל אותה, ואז הוא היה מתנפח והסשן הבא היה פותח מחדש דיונים שכבר נסגרו. כשהתוכנית versioned בתוך ה-repo, ה-handoff פשוט מפנה אליה.
מסמך ה-handoff אגרסיבי לגבי מה שהוא לא כולל. Handoff שמנסה לסכם את כל השיחה הוא פשוט גרסה גרועה יותר של השיחה. המטרה של המסמך היא להיות ה-prompt של האייג׳נט הבא, לא ה-transcript שלו.
- הפניות במקום כפילויות.
- החלטות במקום דיונים.
- שאלות פתוחות במקום כאלה שכבר נפתרו.
ה-skill אוטונומי כברירת מחדל. ה-relay מרגיש כמו relay רק אם האייג׳נט הבא מתחיל לרוץ בלי שאני אדחוף אותו. אחרת זו פשוט שרשרת restartים בפיקוח ידני, והעבודה הידנית חוזרת בצורה אחרת.
מה זה משנה בפועל
ההשפעה downstream ברורה: ה-relays ממשיכים להתקדם גם כשאני לא שם, אז פיצ’רים נוחתים מהר יותר.
אבל ההשפעה upstream על איך אני משתמשת בקשב שלי היא מה שאני מרגישה יותר.
צוואר הבקבוק חזר למקום שבו הוא אמור להיות: איכות התוכנית. איכות ה-review.
כל האמצע המשעמם — החלק שבו בן אדם מעביר context בין אייג׳נטים — פשוט נמחק. מה שנשאר זה החלק שבאמת שווה את שיקול הדעת שלי.