דף זה תורגם מאנגלית.
כלים למפתחים
בניית אפליקציה מותאמת אישית עם אינטגרציה ל-GitHub
Kliv הוא בונה אפליקציות מבוסס AI. תארו את אינטגרציית ה-GitHub שתרצו — בקשות לקוח, issues מתויגים, טיוטות changelog, מיילי שחרור וחשבוניות — והוא בונה את האפליקציה.
פשוט הזן את הרעיון שלך בתיבת הטקסט ו-AI יבנה אותו עבורך
מה זה Kliv?
Kliv אינו תיבת סימון של אינטגרציה גנרית שנרשמים אליה ומגדירים — זהו בונה אפליקציות מבוסס AI שבונה עבורכם תוכנה.
אתם מתארים את מה שאתם צריכים במילים שלכם, ו-Kliv בונה את זה: מסד הנתונים, הלוגיקה, המסכים והכללים. מה שמתקבל היא אפליקציה אמיתית ופעילה, שהיא שלכם. תוכלו להשתמש בה, לשנות אותה בהמשך פשוט בבקשה לשינויים, ולהריץ אותה על החשבונות שלכם ועל הדומיין שלכם. זו לא תבנית עם השם שלכם עליה.
בעמוד הזה, האפליקציה היא אפליקציה מותאמת אישית שמתחברת ל-GitHub ומציגה את זרימת העבודה הנכונה לאנשים שמחוץ למאגר (repo). Kliv בונה כל מיני אפליקציות ווב; זו רק דוגמה אחת, וזה מה שיתר העמוד הזה עוסק בו.
למה המאגר זקוק לחזית מול הלקוח
עבודת המסירה יכולה כבר להתנהל ב-GitHub: issues, pull requests, אבני דרך (milestones) ו-releases. בדרך כלל, לקוחות לא צריכים לקרוא ב-GitHub כדי לדעת מה קרה.
Kliv יכול לבנות את המרכז שתתארו סביב המאגרים שלכם. בקשות לקוח יכולות לפתוח issues מתויגים. סטטוס ה-GitHub יכול להשתקף בחזרה ללקוח. pull requests שמוזגו יכולים לנסח רשומות changelog. releases יכולים להפיק מיילים קריאים וחשבוניות אבן דרך. הסטודיו ממשיך לעבוד ב-GitHub; הלקוח רואה מרכז מסירה ברור.
שני צידי ה-webhook
חמישה רשומות נושאות את סיפור המסירה בין GitHub למרכז הלקוחות.
הפרויקט
פרויקט ממפה לקוח אחד למאגרים ולאבני הדרך הרלוונטיים. בקשות, רשומות changelog וחשבוניות תלויות בפרויקט הזה.
הבקשה
לקוח מגיש בקשה בעברית פשוטה. האפליקציה פותחת issue ב-GitHub עם התיוגים הנכונים ושומרת על התאמת הסטטוס.
רשומת ה-changelog
כאשר pull request ממוזג, ה-webhook כותב טיוטה עם כותרת ה-PR, הפרויקט והבקשה המקושרת. אדם עורך אותה מחדש לפני שהלקוחות רואים אותה.
חשבונית אבן הדרך
כאשר release סוגר אבן דרך, המרכז יכול לנסח חשבונית מפורטת, למשל אבן דרך קבועה בסך ₪6,500, עם קופה בכרטיס אשראי בחשבון ה-Stripe שלכם.
החומה בין הלקוחות
כניסה של לקוח אחד מציגה רק את הפרויקטים של אותו לקוח. מאגר יחיד (monorepo) יכול לשרת מספר לקוחות כי הגישה עוקבת אחר שורות הפרויקט.
דוגמה: מרכז המסירה של סטודיו המוצרים של תמר
כך סטודיו אחד יכול להשתמש בזה. זו רק דוגמה — אתם תתארו את המאגרים שלכם, הגישה של הלקוחות, זרימת ה-issues, ה-releases וכללי החיוב.
בקשת לקוח פותחת את ה-issue הנכון
הלקוח של תמר כותב שני משפטים בעברית פשוטה במרכז. האפליקציה פותחת issue מתויג ב-GitHub במאגר הנכון ומקשרת אותו בחזרה לבקשת הלקוח.
המיון (triage) נשאר ב-GitHub
הסטודיו מעריך, מתייג ומתזמן את העבודה ב-GitHub כרגיל. המרכז משקף את הסטטוס בחזרה לתצוגת הלקוח.
מיזוג יוצר רשומת changelog בטיוטה
כאשר ה-pull request עולה, ה-webhook יוצר רשומת changelog ממתינה עם כותרת ה-PR, הפרויקט והבקשה שהיא פתרה.
אדם מאשר את הניסוח ללקוח
מישהו כותב מחדש את כותרת ה-PR הטכנית למשפט שלקוח אמור לקרוא, ואז מאשר אותה לשחרור.
מייל השחרור ספציפי ללקוח
פרסום ה-release הופך טיוטות מאושרות לעמוד changelog ושולח לכל לקוח מייל עם הפריטים מהפרויקט שלו בלבד.
החשבונית יודעת מה נשלח
אבן הדרך הסגורה מנסחת חשבונית מהבקשות שנמסרו, מפורטת עם קישור קופה בכרטיס אשראי, באותו עמוד שבו הלקוח צפה בעבודה.
תארו את אינטגרציית ה-GitHub שתרצו לבנות
Kliv בונה מהתיאור שלכם, אז ככל שתתנו יותר פרטים, כך הגרסה הראשונה תהיה קרובה יותר. כללו מאגרים, אירועים, תיוגים, גישת לקוחות, שלבי בדיקה, התראות וחיוב. הנה שלוש דוגמאות להתחיל מהן:
מרכז מסירה ללקוחות
בקשות נכנסות, changelogs יוצאים, גישה לפי לקוח.
“בנו מרכז מסירה ללקוחות המחובר לארגון ה-GitHub שלנו. לקוחות מגישים בקשות שהופכות ל-issues מתויגים במאגר הנכון, סטטוס ה-issue משתקף בחזרה ללקוח, pull requests שמוזגו הופכים לטיוטות רשומות changelog, כל לקוח רואה רק את הפרויקטים שלו, ואבני דרך קבועות בסך ₪6,500 יכולות לנסח חשבוניות אחרי השחרור.”
אתר changelog ציבורי
releases של GitHub הופכים לפוסטים קריאים.
“בנו אתר changelog ציבורי למוצר שלנו. הפכו releases של GitHub לפוסטים בטיוטה, דרשו אישור אנושי לפני פרסום, אפשרו למבקרים להירשם במייל, ושלחו הודעת שחרור עם קישורים לפריטים שנשלחו.”
טופס קליטת issues
דיווחי באגים שמגיעים ממוינים מראש.
“בנו טופס קליטת באגים לצוות התמיכה שלנו. המדווחים שולחים חומרה, דפדפן, שלבים לשחזור, צילומי מסך ומזהה חשבון; האפליקציה פותחת issue ב-GitHub עם תיוגי חומרה וקבצים מצורפים; והמדווח יכול לראות סטטוס בזמן אמת בלי צורך בחשבון GitHub.”
החלקים שלא בונים בעצמכם
החיבור הוא הרשאה אחת. אתם מחברים את ארגון ה-GitHub שלכם פעם אחת. האסימון (token) נשמר על ידי הפלטפורמה, לא מודבק בקוד של האפליקציה. האפליקציה יכולה לפתוח issues, להגיב, לקרוא releases ולקבל אירועי webhook.
טיוטות ממתינות לאדם. רשומות changelog מגיעות לתור בדיקה. שום דבר לא מגיע ללקוח עד שמישהו הופך כותרת PR טכנית לשפת שחרור ברורה ומאשר אותה.
גם לאפליקציה יש מאגר משלה. Kliv מסנכרן את קוד המקור של האפליקציה עם מאגר שאתם הבעלים שלו, כך שגם הכלי שמדווח על המסירה עובר בקרת גרסאות.
Slack יכול להיות קהל נוסף. release יכול לפרסם סיכום בערוץ שאתם משתפים עם לקוח.
GitHub הוא קונקטור אחד. אותה תבנית של פעולה-ותגובה מגיעה גם ל-Slack, Notion, Linear, HubSpot ועוד. בנייה והרחבה מציג את מדף הקונקטורים הרחב יותר.
שאלות נפוצות
מה זה בעצם Kliv?
Kliv הוא בונה אפליקציות מבוסס AI. אתם מתארים את התוכנה שאתם צריכים, הוא בונה את האפליקציה הפעילה, ואתם הבעלים של התוצאה. בעמוד הזה, זה אומר מרכז מסירה מחובר ל-GitHub, עם בקשות לקוח, יצירת issues, שיקוף סטטוס, טיוטות changelog, מיילי שחרור וחשבוניות.
אני מקבל אפליקציה אמיתית, או תבנית?
אפליקציה אמיתית. Kliv בונה את הנתונים, הכללים והמסכים למקרה הספציפי שלכם, לא ערכת נושא מוכנה שממלאים. אתם ממשיכים לשנות אותה על ידי תיאור מה שתרצו אחרת.
אפשר לשנות אותה אחרי שהיא נבנתה?
כן. בקשו שינויים במילים פשוטות ו-Kliv מעדכן את האפליקציה. תוכלו להתאים שדות, זרימות עבודה, עמודים, מיילים, כללי גישה ודוחות בלי להתחיל מחדש.
האם הלקוחות צריכים חשבונות GitHub?
לא. הלקוחות נכנסים למרכז באמצעות אימייל וסיסמה, Google, או מפתח גישה (passkey). GitHub נשאר הכלי של הסטודיו, והלקוחות רואים רשומות נגזרות.
מה קורה אם כותרת pull request טכנית מדי לפרסום?
כל רשומה יכולה להגיע כטיוטה לתור בדיקה. היא נשארת בלתי נראית עד שמישהו כותב אותה מחדש ומאשר אותה.
זה עובד עם מאגרים פרטיים?
כן. אתם מאשרים את הארגון פעם אחת, והחיבור נשמר בצד השרת. שום מפתח לא מופיע בקוד המקור של האפליקציה.
יכולים שני לקוחות לשתף מאגר אחד (monorepo)?
כן. בקשות ורשומות changelog נושאות היקף פרויקט, והגישה של כל לקוח נאכפת על השורות האלה.
האפליקציה יכולה ליצור issues ב-GitHub?
כן. בקשת לקוח יכולה לפתוח issue מתויג במאגר הנכון ולשמור קישור בחזרה לבקשה שמול הלקוח.
pull requests שמוזגו יכולים להפוך לרשומות changelog?
כן. webhooks יכולים ליצור רשומות טיוטה כאשר pull requests ממוזגים, ואז אדם מאשר ניסוח מוכן ללקוח.
releases יכולים לשלוח מיילים או פוסטים ב-Slack?
כן. אירוע release יכול לפרסם עמוד changelog, לשלוח מייל, ולפרסם סיכום בערוץ Slack משותף, אם תגדירו את הזרימה הזו.
חשבוניות אבן דרך יכולות להשתמש ב-Stripe?
כן. אם זרימת המסירה שלכם כוללת אבני דרך בתשלום, החשבוניות יכולות לכלול קופה בכרטיס אשראי בחשבון ה-Stripe שלכם.
אפשר להשתמש בדומיין שלי?
כן. מרכז הלקוחות וה-changelog יכולים לרוץ על הדומיין שלכם.
אפשר לעבור מ-Kliv בהמשך?
כן. קוד המקור של האפליקציה מסונכרן למאגר ה-Git שלכם.
הראו ללקוחות את העבודה בלי לחשוף את המאגר
תארו את אירועי ה-GitHub, כללי ה-issues, גישת הלקוחות, בדיקת ה-changelog, מיילי השחרור והחיוב. Kliv בונה סביבם את מרכז המסירה.
