הגדרה עם עוזר ה־AI שלכם

דף זה הוא מדריך הפעלה שנכתב עבור עוזר AI: Claude Code, Codex, Cursor, או כל עוזר אחר שיכול לקרוא דף אינטרנט ולעבוד באופן אידיאלי על עותק מקומי של מאגר הקוד שלך. המדריך מכוון את העוזר להגדרת Coroid עבור מאגר קוד אחד או יותר. הוא עוצר אותך בכל שלב שדורש פעולה אנושית: התחברות, מתן גישה, הזנת סיסמה סודית, או אישור שינוי.

מסרו אותו לעוזר שלכם#

פתחו את העוזר במאגר הקוד שבו ברצונכם ש־Coroid יעבוד, ותנו לו את ההנחיה הבאה:

Set up Coroid for this repository. Follow the runbook at
https://coroid.ai/docs/export/en-US/getting-started/assistant-setup.md
step by step. Ask me before you change anything, and never ask me to paste a
password or token into this chat.

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

כללי היסוד לעוזר#

אתם מגדירים את ההגדרות, והעוזר מבצע אותן. אתם מגדירים את Coroid, מפעל תוכנה מבוסס AI שממיר תיאור משימה ל־pull request שעבר בדיקות ואישור במאגר הקוד של המשתמש. הקפידו על הכללים הבאים לאורך כל התהליך:

1. המשתמש פועל; אתם מכינים. אינכם יכולים להירשם, להתחבר, לקבל תנאים, להתקין אפליקציות או לתת גישה בשם המשתמש. ציינו בדיוק מה לעשות ואיפה, וחכו עד שהמשתמש יאשר שזה בוצע.
2. הימנעו מלהזין סיסמאות סודיות לשיחה. לעולם לא בקשו סיסמה, טוקן גישה אישי, מפתח ספק או טוקן MCP. המשתמש מזין סיסמאות סודיות בפורטל של Coroid או בקונסולה שלו. אם סיסמה סודית נדבקת לשיחה בכל זאת, בקשו מהמשתמש לבטל אותה וליצור חדשה.
3. שאלו לפני כל שינוי: קבצי commit, ענפים ובקשות merge במאגר הקוד של המשתמש, פרויקטים של Coroid והזמנות.
4. בדקו כל שלב לפני המעבר לשלב הבא. אם הבדיקה נכשלת, השתמשו בהערות שבאותו שלב, והמשיכו רק לאחר שהיא תצליח או שהמשתמש יחליט לדלג עליה.
5. התאימו את עצמכם למוצר, לא להנחות שלכם. אם הפורטל מציג משהו שהמדריך אינו מתאר, ספרו למשתמש מה אתם רואים ופעלו לפי ההנחיות שבפורטל. אל תמציאו הגדרות.
6. שמרו רישום של תהליך ההגדרה של כל שלב ותוצאתו, לקראת הסוף.

כל שלב מקשר בין הדפים עם הפרטים הרלוונטיים. https://coroid.ai/llms.txt מאנדקס את כל המסמכים.

שלב 1: הסכימו על התוכנית#

שאלו את המשתמש את השאלות הבאות יחד, לא אחת אחת:

לאחר מכן, חזור על התוכנית: השלבים שלהלן, אלו הדורשים התערבות משתמש, והמאגרים שבטווח.

ראו תוכניות ומחירים, מגבלות ומכסות ו מסונכרן או רק מקומי.

שלב 2: בדוק שכל מאגר נבנה ונבדק מתוך עותק נקי#

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

אם אתה יכול לעבוד עם המאגר באופן מקומי, עשה זאת עבור כל אחד מהם:

1. זהה את השפות, מנהל החבילות ואם מדובר במונורפו.
2. מצא את פקודות ההתקנה, הבנייה והבדיקה ב-README, בהגדרות ה-CI ובקבצי התצורה.
3. שאל לפני שאתה מפעיל דברים. לאחר מכן, העתק את המאגר לתוך תיקייה זמנית ריקה והפעל שם את פקודות ההתקנה, הבנייה והבדיקה ללא כל הגדרות נוספות. בעותק העבודה של המשתמש יש זיכרונות ו .env קבצים שמסתירים בעיות.
4. רשום הכל – מה שהריצה דרשה ושאין בעותק החדש.
   • שירותים שהבדיקות מצפות להם, כגון מסד נתונים, זיכרון מטמון או תור הודעות
   • שלבים לפני הבדיקות, כגון יצירת קוד, הגירות או קבצי יסוד
   • משתנים סביבתיים או .env קובץ שאינו מחויב לקומיט
   • מאגרי חבילות פרטיים
   • סביבת ריצה שאינה נמצאת ב- סביבת הסוכן

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

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

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

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

שלב 3: כתיבת ההנחיות שהסוכנים של Coroid קוראים#

לפני כל משימה, הסוכנים של Coroid קוראים את קובצי הזיכרון במאגר: AGENTS.md, CLAUDE.md או GEMINI.md בשורש, ו .cursor/rules. הפקודות שאישרת בשלב 2 צריכות להיות שם.

הצע AGENTS.md, או תוספת לקיים, שתציין:

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

השאר בחוץ את מה שהקוד כבר מציג, ושמור על קובץ קצר. אם CLAUDE.md או .cursor/rules מכיל את אותן הוראות, שמור אותן פעם אחת ב- AGENTS.md ואִפַּר אותן מהקובץ האחר באמצעות @AGENTS.md שורה.

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

ראה הגדרות הקשר הפרויקט ו הקשר הפרויקט.

שלב 4: חשבון וארגון (המשתמש)#

דלג על שלב זה אם המשתמש כבר שייך לארגון Coroid בתור בעלים או מנהל.

בקש מהמשתמש ל:

1. להירשם ב- https://client.coroid.ai/auth/signup באמצעות כתובת האימייל של העבודה שלו, ולאשר את הכתובת.
2. לקבל את תנאי השימוש.
3. ליצור את הארגון.

בדוק: שהמשתמש יכול לפתוח https://client.coroid.ai/projects. האדם שמשלים תהליך זה צריך להיות בעל תפקיד בעלים או מנהל, מכיוון שרק תפקידים אלו יכולים לחבר מערכת בקרת גרסאות ולהוסיף מפתחות ספק.

ראה יצירת חשבון וארגון.

שלב 5: חיבור מערכת בקרת גרסאות (המשתמש)#

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

GitHub#

המשתמש פותח הגדרות → חיבורים → בקרת קוד מקור (https://client.coroid.ai/settings/connections/source-control).

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

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

GitLab#

GitLab נמצא בגרסת תצוגה מקדימה פרטית ומופיע רק בחשבונות שבהם הוא מופעל. הוא מתחבר באמצעות טוקן גישה אישי עם ה־ api טווח. אם GitLab לא מופיע תחת בקרת קוד מקור, יש לבקש מהמשתמש ליצור קשר עם Coroid, ואין לתכנן סביבו.

הגנה על ענף#

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

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

ראו חברו את הקוד שלכם, GitHub, GitLab ו־ הגדרות של מאגר וענף.

שלב 6: יצירת הפרויקטים (המשתמש)#

יש ליצור פרויקט אחד לכל מאגר, ולא שני פרויקטים לאותו מאגר. המשתמש פותח פרויקטים → חדש (https://client.coroid.ai/projects/new) ולגבי כל מאגר:

1. הוא בוחר אותו מהספק המחובר, או משתמש ב־ חיבור באמצעות כתובת URL עבור מאגר ציבורי
2. הוא בוחר את מצב מאגר: מסונכרן, כאשר Coroid מעלה ענפים ופותח בקשות משיכה, או מקומי בלבד, כאשר Coroid אינו כותב למאגר עד שמישהו בוחר ב־ התחל סינכרון
3. בודק את הענף המוגדר כברירת מחדל
4. יוצר את הפרויקט

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

אם מאגר חסר ברשימה, הסיבה היא כמעט תמיד אחת מהבאות:

• לא ניתנה לאפליקציית GitHub גישה למאגר הזה
• טווח הטוקן צר מכדי לרשום אותו
• המאגר שייך לארגון שונה מזה שחובר

ראו צור את הפרויקט הראשון שלך ו הגדרות מאגר וענף.

שלב 7: בדוק מה גילה Coroid#

בקש מהמשתמש לפתוח את תצוגת הכלל של כל פרויקט ולקרוא את מאגר הפרטים וכל מה שרשום תחת סיים את ההגדרה:

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

לאחר מכן המשתמש פותח את הגדרות → ידע → הקשר. קובץ הזיכרון משלב 3 חייב להופיע תחת מקורות מאגר ולהיות מופעל. אם הוא מציג יצירה במקום זאת, הקובץ עדיין לא הגיע לענף המחובר.

ראה הגדרות הקשר הפרויקט ו תצורת בנייה ובדיקה.

שלב 8: הגדרות ארגון (אופציונלי)#

שאל האם המשתמש רוצה להגדיר אחת מהאפשרויות האלה כעת. לכולן יש ברירות מחדל מתפקדות:

• חברים, תחת הגדרות → חברים: האנשים שיבצעו סקירה של בקשות משיכה, כבעלים, מנהל, חבר או מבקר. מומלץ למנות מנהל רק לאנשים שצריכים לשנות מדיניות ומפתחות ספק. נדרשת רישיון Professional.
• מפתחות ספק, תחת הגדרות → מפתחות ספק: רק כדי להשתמש בחשבונות ספקי המודלים של הארגון עצמו. המשתמש מזין את המפתח בפורטל. מומלץ להשתמש במפתח מוגבל עם הגבלת הוצאות אצל הספק.
• הגדרות מארגון אחר: ייצא חבילת הגדרות לשם ו ייבא אותה תחת הגדרות → נתונים → ייצוא הגדרות. הסודות נעים כ‑תוויות תחליף, ולכן כל needsRebind פריט בתצוגה מקדימה דורש תשומת לב.

ראו יצירת החשבון והארגון שלך, מפתחות ספק ו־ ייצוא וה imports של הגדרות.

שלב 9: התחברו ל‑Coroid (אופציונלי)#

אם הלקוח שלכם תומך בשרתי MCP מרוחקים, תוכלו להגיע ל‑Coroid דרך שרת ה‑MCP שלו ב‑ https://api.coroid.ai/mcp. ההגדרה אינה תלויה בכך, אך היא מאפשרת לכם לבדוק את הפרויקטים בעצמכם ולסייע למשתמש להפעיל משימות מאוחר יותר.

1. המשתמש פותח הגדרות → חיבורים → Coroid MCP server (https://client.coroid.ai/settings/connections/coroid-mcp). אם הוא אינו זמין לארגון שלהם, דלגו על שלב זה.
2. הגדרת לקוח מציג את הפקודות לפי לקוח. עם OAuth, המשתמש מאשר את הגישה שלכם בדפדפן שלו. עם טוקן גישה אישי, המשתמש יוצר אותו תחת אסימוני גישה ושומר אותו במשתנה סביבה בקליפ שלו. אינכם צריכים לראות את הערך.
3. המליצו על רמת הגישה המינימלית המתאימה: mcp.read כדי לבדוק את ההגדרה, ו־ mcp.work.write רק אם אתם מתכוונים ליצור משימות. הגבילו את הטוקן לפרויקטים אלו, קבעו לו תאריך תפוגה, והגדירו מדיניות אוטומציה לפני שכל לקוח מפעיל משימות באופן אוטומטי.

בדקו: קראו ל‑ list_projects, ואז get_project עבור כל פרויקט משלב 6, ואשרו את המאגר ואת הענף.

השתמשו רק ב‑ api.coroid.ai עבור MCP. שם המארח של פורטל הלקוח אינו מספק זאת.

ראו Coroid כשרת MCP.

שלב 10: נסחו משימה ראשונה#

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

תארו את התוצאה, לא את היישום: מה צריך להיות נכון כשהעבודה תסתיים, אילו קבצים רלוונטיים ואילו לא לגעת בהם. המשתמש שולח אותה מ‑ עבודה חדשה (https://client.coroid.ai/work/new), קורא את ההגדרות ומאשר את התוכנית. הפעלת משימות משתמשת בשעות סוכן, ותוכנית החינם כוללת 2 ליום UTC; לכן תנו למשתמש להחליט מתי להפעיל אותן.

ראו הפעילו את המשימה הראשונה שלכם ו־ מפרטים.

שלב 11: מסרו את השליטה#

מסרו למשתמש את רשימת ההגדרות:

• כל מאגר, הפרויקט שלו, מצב המאגר וענף הבסיס
• כיצד בקרת הקוד מחוברת, ומי אחראי על החיבור: מי שמתקין את האפליקציה, או בעל הטוקן ותאריך התפוגה שלו
• לפי מאגר, התיקונים שבוצעו, אלו שעדיין תלויים (כגון בקשת משיכה פתוחה עם AGENTS.md), ואלו שהמשתמש בחר להשאיר כך
• ההגדרות האופציונליות שבוצעו ודולגו עליהן, והמשימה הראשונה שנוסחה

לאחר מכן הפנו את המשתמש ל‑ סקירה ואיחוד של התוצאה כדי לראות מה מגיע עם ה‑pull request הראשון.

הבא#

יצירת חשבון וארגון שלכם — אותה הגדרה, שבוצעה ידנית.