هذه الصفحة عبارة عن دليل تشغيل مكتوب لمساعد 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 مختبر ومُراجَع داخل مستودع المستخدم. اتبع هذه القواعد طوال العملية:
- المستخدم يتصرف؛ والمساعد يجهز. لا يمكنك التسجيل، تسجيل الدخول، قبول الشروط، تثبيت التطبيقات، أو منح الصلاحيات نيابةً عن المستخدم. أخبره بدقة بما يجب فعله وأين، ثم انتظر حتى يؤكد لك إتمامه.
- ابقِ المعلومات السرية بعيدًا عن المحادثة. لا تطلب كلمة مرور، أو رمز وصول شخصي، أو مفتاح مزوّد خدمة، أو رمز MCP أبداً. يدخل المستخدم المعلومات السرية في بوابة Coroid أو في واجهة سطر الأوامر الخاصة به. وإذا تم لصق أحدها في الدردشة، أخبر المستخدم بإلغائه وإنشاء واحد جديد.
- اسأل قبل كل تغيير: الالتزامات، الفروع، وطلبات السحب في مستودع المستخدم، ومشاريع Coroid، بالإضافة إلى الدعوات.
- تحقق من كل خطوة قبل الانتقال للخطوة التالية. إذا فشلت عملية التحقق، استخدم الملاحظات الموجودة في تلك الخطوة، واستمر فقط بعد نجاحها أو إذا قرر المستخدم تخطيها.
- اتبع المنتج، لا افتراضاتك. إذا أظهرت البوابة شيئًا لا يصفه هذا الدليل، أخبر المستخدم بما تراه واتبع تعليمات البوابة. لا تخترع إعدادات.
- احتفظ بسجل للإعداد لكل خطوة ونتائجها، لاستخدامه في النهاية.
ترتبط كل خطوة بالصفحات التي تحتوي على التفاصيل.
https://coroid.ai/llms.txt يُفهرس الوثائق بأكملها.
الخطوة 1: الاتفاق على الخطة
اطرح على المستخدم هذه الأسئلة معًا، وليس واحدًا تلو الآخر:
| السؤال | لماذا هو مهم؟ |
|---|---|
| على أي مستودعات يجب أن يعمل Coroid؟ | مشروع واحد لكل مستودع. |
| GitHub أم GitLab؟ هل يملكه فرد أم منظمة؟ | هذا يحدد طريقة اتصال Coroid ومن يوافق عليه. |
| هل يجب أن يفتح Coroid طلبات سحب (متزامن)، أم يحتفظ بالعمل داخل Coroid في البداية (محلي فقط)؟ | الوضع المحلي فقط لا يقوم بكتابة أي بيانات في المستودع أبداً. |
| هل توجد منظمة Coroid موجودة بالفعل، وما هي الخطة المستخدمة؟ | النسخة المجانية تسمح بمشروع واحد فقط ولا تدعم أعضاء آخرين. |
| من سيقوم بمراجعة العمل، وما هو دوره؟ | دعوة الأعضاء تتطلب اشتراك Professional. |
| هل يجب على Coroid استخدام مفاتيح مزود النماذج التابعة للمنظمة؟ | اختياري. النماذج الموجهة عبر Coroid لا تحتاج إلى مفاتيح. |
ثم أعد صياغة الخطة: الخطوات أدناه التي تتطلب تدخل المستخدم، والمستودعات المشمولة.
اطلع على الخطط والأسعار، الحدود والحصص و متزامن أو محلي فقط.
الخطوة 2: تحقق من أن كل مستودع يمكنه البناء والاختبار من نسخة نظيفة.
هذا هو أهم عمل يمكنك القيام به. كل مهمة في Coroid تُنفذ في بيئة عمل لينكس نظيفة وقابلة للتخلص منها: نسخة جديدة كلياً، بدون أي بيانات مؤقتة أو برامج مثبتة سوى أدوات الصورة الأساسية. الوكيل الذي لا يستطيع بناء المشروع واختباره لا يمكنه التحقق من عمله، وبالتالي تفشل مهامه في عملية التحقق لأسباب لا علاقة لها بالتغيير نفسه.
إذا كنت تستطيع العمل على المستودع محلياً، فقم بذلك لكل مستودع على حدة:
- حدد اللغات ومدير الحزم، وهل هو مستودع موحد أم لا.
- ابحث عن أوامر التثبيت والبناء والاختبار في ملف README وإعدادات CI والملفات الوصفية.
- اسأل قبل تنفيذ أي أمر. ثم قم بنسخ المستودع إلى مجلد مؤقت فارغ ونفذ أوامر التثبيت والبناء والاختبار هناك دون أي إعدادات إضافية. نسخة العمل الخاصة بالمستخدم تحتوي على ملفات مؤقتة و
.envملفات تخفي المشاكل. - سجل كل ما احتاجته عملية التشغيل ولم تتوفر في النسخة النظيفة:
- خدمات يتوقعها الاختبار، مثل قاعدة بيانات أو ذاكرة تخزين مؤقت أو قائمة انتظار
- خطوات تسبق الاختبارات، مثل توليد الكود أو عمليات الترحيل أو البيانات الاختبارية
- متغيرات بيئة أو
.envملف غير ملتزم به في المستودع - سجلات الحزم الخاصة
- بيئة تشغيل غير موجودة في بيئة الوكيل
لا تقم بتنفيذ أوامر تؤدي إلى النشر أو الإصدار أو التلاعب بالبيئات المشتركة. إذا كانت عملية الاختبار بطيئة أو تستخدم خدمات مدفوعة، فاطلب إذناً من المستخدم أولاً.
قم بتقديم تقرير عن فحص الجاهزية المختصر لكل مستودع: الأوامر المستخدمة، المدة التي استغرقها الاختبار، ما الذي نجح، وكل فجوة مع اقتراح حل لها.
| فجوة | اقتراح حل |
|---|---|
| تتطلب الاختبارات وجود قاعدة بيانات أو خدمة أخرى. | ملف Dockerfile أو Compose يُستخدم لتشغيل الاختبارات مع الخدمات المرتبطة بها. |
عنصر مطلوب .env ملف غير مُلتزم به في المستودع. | إعدادات الاختبار الافتراضية موجودة في الكود، أو ملف إعدادات اختبار مُلتزم به يحتوي على قيم غير سرية. |
| تتطلب الاختبارات وجود قيمة سرية حقيقية. | قم بمحاكاة ذلك الاعتماد في الاختبارات. لا تلتزم أبداً بقيمة سرية. |
| تأتي التبعيات من سجل خاص. | أخبر المستخدم: يتطلب Coroid بيانات اعتماد لهذا كجزء من إعدادات المشروع. |
| لا تعمل الأوامر إلا من داخل مجلد فرعي. | سجل المسار الدقيق للمجلد وأي مرشحات للمساحة العمل. |
عدم وجود بيئة تشغيل لا يُعتبر عائقًا: حاوية تحتوي على مجموعة الأدوات تحل هذه المشكلة. إذا لم تتمكن من الوصول إلى المستودع محليًا، جمع ما يمكنك من معلومات من المستخدم، وسجل أن فحص النسخة النظيفة لم يتم.
اطلع على إعدادات البناء والاختبار و دعم اللغات وبيئة الوكلاء.
الخطوة 3: كتابة التعليمات التي يقرأها وكلاء Coroid.
قبل كل مهمة، يقرأ وكلاء Coroid ملفات الذاكرة الموجودة في المستودع:
AGENTS.md، CLAUDE.md أو GEMINI.md في المسار الرئيسي، و .cursor/rules.
الأوامر التي تحققت منها في الخطوة 2 توضع هناك.
اقترح AGENTS.md، أو إضافة إلى الملف الموجود، يتضمن ما يلي:
- أوامر التثبيت والبناء والاختبار، التي تم التحقق منها من نسخة نظيفة، بالإضافة إلى المسار الذي تُجرى فيه.
- خطوات الخدمات التي تتطلبها الاختبارات.
- كيفية تشغيل أضيق مجموعة مفيدة من الاختبارات، مثل حزمة واحدة أو ملف واحد.
- القواعد والحدود التي لا تظهر في الكود: وحدات مجمدة، مناطق لا يجب التعديل عليها، تبعيات لا يجب إضافتها.
تجاهل ما هو واضح في الكود، وحافظ على قصر الملف. إذا CLAUDE.md
أو .cursor/rules يحتوي على نفس التعليمات، ضعها مرة واحدة في AGENTS.md
وقم باستيرادها من الملف الآخر باستخدام @AGENTS.md سطر.
اعرض على المستخدم الفرق في المحتوى. بعد موافقته، قم بإلتزام التغييرات في فرع جديد وافتح طلب سحب في pull request، أو اترك الأمر له لإلتزامه. يجب أن يصل هذا التغيير إلى الفرع الأساسي قبل بدء أي مهمة، لأن كل مهمة تقرأ ملفات الذاكرة من نسختها الخاصة من ذلك الفرع. تعامل مع الإصلاحات التي تم قبولها من المستخدم في الخطوة 2 بنفس الطريقة.
اطلع على إعدادات سياق المشروع و سياق المشروع.
الخطوة 4: الحساب والتنظيم (المستخدم)
تجاوز هذه الخطوة إذا كان المستخدم ينتمي بالفعل إلى تنظيم Coroid كمالك أو مشرف.
اطلب من المستخدم ما يلي:
- التسجيل في
https://client.coroid.ai/auth/signupباستخدام بريده الإلكتروني الوظيفي، ثم تأكيد العنوان. - قبول شروط الخدمة.
- إنشاء التنظيم.
تحقق من: أن المستخدم قادر على فتح https://client.coroid.ai/projects. الشخص الذي يكمل هذا الإعداد يحتاج إلى دور المالك أو المشرف، لأن هاتين الصفتين فقط هما اللتان تسمحان بربط نظام التحكم في المصدر وإضافة مفاتيح المزود.
اطلع على إنشاء حسابك وتنظيمك.
الخطوة 5: ربط نظام التحكم في المصدر (المستخدم)
راجع متطلبات الوصول مع المستخدم قبل أن يبدأ. عادةً ما يكون سبب استغراق هذه الخطوة يومًا بدلاً من دقيقة هو عملية تثبيت تتوقف في منتصفها في انتظار موافقة شخص آخر.
GitHub
يفتح المستخدم إعدادات → اتصالات → التحكم في المصدر
(https://client.coroid.ai/settings/connections/source-control).
| خيار | استخدمه عندما | ما يحتاجه المستخدم على GitHub |
|---|---|---|
| GitHub App (موصى به) | في أغلب الأحيان | تصريح لتثبيت التطبيقات على الحساب أو التنظيم الذي يملك المستودعات. في التنظيم، عادةً ما يكون هذا الدور من نصيب المالك؛ ويمكن للأعضاء الآخرين طلب التثبيت ليقوم المالك بالموافقة عليه. |
| رمز وصول شخصي | التطبيق يحتاج إلى موافقة لا يمكن للمستخدم الحصول عليها. | رمز تقليدي يحتوي على نطاق repo ، أو رمز دقيق يمنح صلاحيات القراءة والكتابة على المحتويات و طلبات السحب للمستودعات المختارة. |
| الربط عبر الرابط، بدون اتصال | مستودع عام، تم تجربته في محلي فقط | لا شيء |
GitHub App: في شاشة التثبيت الخاصة بـ GitHub، يختار المستخدم حدد المستودعات فقط ويختار العناصر المتفق عليها في الخطوة الأولى. يستمر التطبيق في العمل حتى عندما يغادر الشخص الذي قام بتثبيته، حيث يتلقى أحداث الويبهوك، وهذا ما يسمح لـ Coroid بنشر عمليات التحقق الخاصة به على طلبات السحب. لا يمكن لرمز الوصول نشر عمليات تحقق GitHub.
رمز الوصول الشخصي: يقوم المستخدم بإنشائه على GitHub مع تحديد تاريخ انتهاء صلاحيته، ثم يلصقه في بوابة Coroid. من الأفضل استخدام رمز وصول دقيق محدود إلى المستودعات المتفق عليها. تُنسب طلبات السحب إلى مالك الرمز، وينقطع الاتصال إذا فقد ذلك الشخص صلاحيته.
GitLab
GitLab في مرحلة المعاينة الخاصة ولا يظهر إلا على الحسابات التي تم تفعيله فيها.
يتصل باستخدام رمز وصول شخصي يحتوي على api نطاق. إذا لم يظهر GitLab ضمن قسم التحكم في المصدر، أخبر المستخدم بالتواصل مع Coroid، ولا تخطط لاستخدامه.
حماية الفرع
Coroid يفتح طلبات سحب عادية، لذا تظل قواعد حماية الفرع وعمليات التحقق المطلوبة وقواعد المراجعة سارية. يُنصح بالحفاظ على حماية الفرع. إذا تتطلب القواعد التزامًا بتوقيعات الالتزامات أو عملية تحقق من الحالة لا يمكن لـ Coroid إنتاجها، فستُفتح طلبات السحب وتظل غير قابلة للدمج. أخبر المستخدم بذلك، ولا تغيّر قواعده.
عملية التحقق: يظهر المزود كمتصل ضمن قسم التحكم في المصدر. يأتي الدليل الحقيقي في الخطوة السادسة، عندما تظهر المستودعات في قائمة المشاريع.
اطلع على ربط كودك البرمجي، GitHub، GitLab و إعدادات المستودع والفرع.
الخطوة السادسة: إنشاء المشاريع (المستخدم)
أنشئ مشروعًا واحدًا لكل مستودع، ولا تنشئ مشروعين لنفس المستودع. يفتح المستخدم مشاريع ← جديد (https://client.coroid.ai/projects/new) وبالنسبة لكل مستودع:
- يختاره من المزود المتصل، أو يستخدم الربط باستخدام عنوان URL لمستودع عام
- يختار وضع المستودع: متزامن، حيث يدفع Coroid الفروع ويفتح طلبات السحب، أو محلي فقط، حيث لا يكتب Coroid إلى المستودع أبدًا حتى يختار أحدهم بدء المزامنة
- يتحقق من الفرع الافتراضي
- ينشئ المشروع
إذا قام الفريق بدمج التغييرات في فرع غير الفرع الافتراضي، مثل
develop، فقم بضبط الفرع الأساسي في إعدادات مستودع المشروع. فرع أساسي خاطئ يؤدي إلى إرسال طلبات السحب إلى فرع لا يقوم أحد بمراجعته.
إذا كان مستودع ما مفقودًا من القائمة، فالسبب غالبًا أحد الأمور التالية:
- لم يتم منح تطبيق GitHub صلاحية الوصول إلى ذلك المستودع
- نطاق رمز الوصول ضيق جدًا لعرضه
- ينتمي المستودع إلى منظمة مختلفة عن المنظمة المتصلة
اطلع على إنشاء أول مشروع لك و إعدادات المستودع والفرع.
الخطوة 7: تحقق من ما اكتشفه Coroid
اطلب من المستخدم فتح نظرة عامة على كل مشروع وقراءة مستودع detalis وأي عناصر مدرجة تحت إنهاء الإعداد:
- الحالة و فرع: يتم استنساخ المستودع، ويكون على الفرع الأساسي الذي اتفقت عليه. إذا أظهرت النظرة العامة أن المستودع لم يتم استنساخه بعد، يختار المستخدم استنساخ المستودع.
- مجموعة: اللغات وإطار العمل ومدير الحزم وأدوات الاختبار التي اكتشفها Coroid. قارنها بفحص الاستعداد الخاص بك. إذا كانت المجموعة فارغة أو غير صحيحة بعد المزامنة الأولى، يمكن للمستخدم إعادة مسحها من هناك.
- إنهاء الإعداد: العناصر مثل "لم تُثبت التبعيات بشكل نظيف" تشير إلى نفس الفجوات الموجودة في الخطوة 2. تعامل معها مع المستخدم.
ثم يفتح المستخدم إعدادات المشروع إعدادات ← معرفة ← سياق. يجب أن تظهر ملف الذاكرة من الخطوة 3 تحت مصادر المستودع ويجب تفعيلها. إذا ظهر إنشاء بدلاً من ذلك، فهذا يعني أن الملف لم يصل بعد إلى الفرع المتصل.
انظر إلى إعدادات سياق المشروع و إعدادات البناء والاختبار.
الخطوة 8: إعدادات المنظمة (اختياري)
اسأل المستخدم عما إذا كان يريد تفعيل أي من هذه الإعدادات الآن. جميعها لها قيم افتراضية قابلة للعمل:
- أعضاء، تحت إعدادات → أعضاء: الأشخاص الذين سيقومون بمراجعة طلبات السحب، كمالك أو مشرف أو عضو أو مراجع. يُنصح بتعيين مشرف فقط للأشخاص الذين يجب أن يغيروا السياسات ومفاتيح المزود. يتطلب خطة احترافية.
- مفاتيح المزود، تحت إعدادات → مفاتيح المزود: للاستخدام فقط مع حسابات مزود نماذج المنظمة الخاصة. يدخل المستخدم المفتاح في البوابة. يُنصح باستخدام مفتاح محدود بحد إنفاق لدى المزود.
- إعدادات من منظمة أخرى: صدّر حزمة إعدادات إلى هناك واستوردها تحت إعدادات ← بيانات ← تصدير الإعدادات. تنتقل البيانات السرية كـ
مواضع احتفاظ، لذا كل
needsRebindعنصر في المعاينة يتطلب اهتمامًا.
اطلع على إنشاء حسابك ومنظمتك، مفاتيح المزود و تصدير وإستيراد الإعدادات.
الخطوة 9: قم بتوصيل نفسك بـ Coroid (اختياري)
إذا كان عميلك يدعم خوادم MCP البعيدة، يمكنك الوصول إلى Coroid عبر خادم MCP الخاص به في https://api.coroid.ai/mcp. لا يعتمد الإعداد عليه، لكنه
يتيح لك فحص المشاريع بنفسك ومساعدة المستخدم على تشغيل المهام لاحقًا.
- يفتح المستخدم إعدادات → اتصالات → Coroid MCP server
(
https://client.coroid.ai/settings/connections/coroid-mcp). إذا لم يكن متاحًا لمنظمته، تجاوز هذه الخطوة. - إعداد العميل يعرض الأوامر حسب العميل. مع بروتوكول OAuth، يوافق المستخدم على وصولك في متصفحه. مع رمز الوصول الشخصي، يقوم المستخدم بإنشائه تحت رموز الوصول ويخزنه في متغير بيئة في واجهة سطر الأوامر الخاصة به. لن تحتاج أبدًا إلى رؤية القيمة.
- نوصي بأقل مستوى وصول يعمل:
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.
التالي
إنشاء حسابك ومنظمتك — نفس الإعداد، يتم يدويًا.