كيف تُشرك صديقًا في الترميز دون أن تُصاب بالجنون: ضبط OpenCode عبر /add و /help

المشكلة: أدوات كثيرة، ولا شيء يُحفظ في الذاكرة

ظلّ فلاديمير بندوف، مطوّر الخلفية (backend) في شركة Domclick، لفترة طويلة ينكر الحاجة إلى الوكلاء. وعندما جرّب في النهاية OpenCode Desktop، واجه واقعًا صعبًا: عدد كبير من المهارات (Skills) وبروتوكولات MCP والأذونات (Permissions)، وعدة تهيئات في آن واحد. كان الوكيل يقوم باستمرار بخطوات زائدة، فيبتكر وينفّذ أمورًا لا تدخل في نطاق المهمة. سارت النصف ساعة الأولى من الإعداد بسلاسة، لكن تبيّن بسرعة أنه لا بد من حفظ أي مهارة تُستخدم لأي غرض، وشرح المنطق للوكيل — أولًا الخطة، ثم الأذونات، فالتهيئات، فالأوامر في الطرفية (terminal). بعد ليلتين من وقت الفراغ، توصل المؤلف إلى نهج أكثر كسلًا. يستهلك هذا النهج رموزًا (tokens) أكثر، لكنه يعمل كما يجب: الوكيل مساعد، لا مطوّر كامل يتطلب الرقابة.

المخطط: أربعة ملفات ومساعدة واحدة

يرتكز الحل على بنية بسيطة داخل مجلد ~/.config/opencode/: ملف مساعدة باسم HELP.md، ومجلدان يحتويان على المهارات والأوامر.

البنية:

• HELP.md — السجل الموحّد الذي يقرأه كلا الأمرين بدلًا من إجراء فحص مكلف
• skills/environment-manager/SKILL.md — المهارة الأساسية لإضافة قدرات جديدة
• skills/opencode-help/SKILL.md — مهارة مساعدة
• commands/add.md — أمر الإضافة
• commands/help.md — أمر المساعدة

/add: عبّر عن رغبتك، لا عن اسم الحزمة البرمجية

يُحوّل أمر /add طلب المستخدم إلى مهارة environment-manager. ترتيب التنفيذ ثابت وصارم.

خطوات التنفيذ: 1. التحقق: هل يمكن حل المهمة بالمهارات أو الأوامر أو أدوات MCP المثبّتة مسبقًا؟ 2. جدول مقارنة بين الخيارات بالأعمدة التالية: الخيار، النوع، ما سأحصل عليه، الأذونات/الأسرار، المخاطر، العبء الإضافي على السياق/الرموز (Context/token overhead)، التوصية 3. اختيار واحد صريح من الخيارات مع توضيح السبب 4. النص الكامل للملفات وعرض الفروقات (unified diff)، مع المسارات الدقيقة وقائمة الملفات المتأثرة 5. تحديث ملف HELP.md: تاريخ التحضير والمهارات والأوامر وأدوات MCP والأذونات المتأثرة 6. لا يُسجَّل أي شيء دون تأكيد صريح من المستخدم

الممنوعات: لا تغييرات بلا تأكيد؛ لا تعديل لملف opencode.jsonc، ولا تثبيت حزم، ولا ربط لأدوات MCP، ولا إنشاء OAuth/PAT، ولا قراءة للأسرار أو الرموز أو ملفات .env أو مفاتيح SSH أو service.json.

تُحدَّد داخل مهارة environment-manager حدود صارمة: استخدام المهارات القائمة (general-engineering، technical-research، prompt-engineering، token-efficient-workflow، project-learning) فقط فيما وُضعت له. تقييم أدوات MCP والإضافات (plugins) من جهات خارجية وفق: الجهة المُشرِفة (maintainer)، المصدر الرسمي، الرموز (tokens) المطلوبة، الأذونات، العمل المحلي أو عبر الشبكة، النشاط المستمر في الصيانة، مخاطر سلسلة التوريد (supply-chain risk)، العبء الإضافي على السياق/الرموز، التوافق مع OpenCode V2.

الأذونات الافتراضية هي وضع «ask» (طلب التأكيد). لا يُمنح حق الكتابة في GitHub أو قواعد البيانات أو البريد أو التخزين أو Sentry أو Jira أو Docker أو السحابة إلا بعد طلب صريح ومستقل.

/help: قراءة ما هو جاهز لا تدقيقًا شاملًا

كانت النسخة الأولى من /help تفحص المهارات والأوامر والأذونات في كل مرة — وهو أمر بطيء ومكلف. أما النسخة الثانية فهي تقرأ ببساطة ملف HELP.md.

يستجيب الأمر على ثلاث مراحل: يستخدم أولًا الجزء المناسب من HELP.md؛ وإذا لم يكن ذلك كافيًا، يبحث عن الإجابة في مصادر قراءة فقط موثوقة وفي وثائق OpenCode الرسمية؛ ويوضح صراحةً أن ملف HELP.md سجلٌ مُحضَّر مسبقًا، لا ضمانًا في الزمن الحقيقي (live-runtime). وإذا تعارض السجل مع الحقائق، يعرض التعارض ويقترح تحديث HELP.md عبر الأمر /add.

كيف يعمل هذا في الواقع

المستخدم: «/add أريد تكاملًا مع GitHub». تتحقق مهارة environment-manager من المتوفر مسبقًا، وتعرض جدولًا بالخيارات (مهارة مقابل MCP مقابل إضافة)، وتختار الأفضل بوضوح، وتعرض النص الكامل للملفات الجديدة والفروقات (diff)، وتُحدِّث HELP.md، وتنتظر التأكيد. لا يتغيّر شيء تلقائيًا.

المستخدم: «/help ماذا لديّ؟». يقرأ الأمر ملف HELP.md ويعرض قائمة المهارات والأوامر وأدوات MCP والأذونات المرتبطة. ويوضح أن المعلومة مأخوذة من السجل، لا من الزمن الحقيقي.

النتيجة: تجنّب فلاديمير بندوف الخطأ الأساسي — لم يحاول حفظ التهيئة في ذاكرته، ولم يُلقِ بها أيضًا على الوكيل بشكل أعمى. يقترح الوكيل خطة، ويعرض الفروقات (diff)، وينتظر التأكيد. أمران فقط، وسجل واحد، وقواعد بسيطة. رموز (tokens) أكثر، لكن عناء أقل بكثير.