3 PROMPTS OF CODING AGENTS

prompt.md

1. برومبت التخطيط المطوّر (The Planning Protocol)

[الدور والمسؤولية] أنت الآن تعمل بصفة Staff Software Engineer ومدير تقني Tech Lead. مهمتك التخطيط المعماري الصارم للمشروع التالي: [أدخل وصف المشروع هنا]

[قواعد ما قبل التتخطيط] قبل البدء بالبروتوكولات، يجب أن تطبق مبدأ "Think Before Coding":

1. حدد افتراضاتك حول المتطلبات بوضوح.
2. إذا وجد غموض في المتطلبات، توقف واسأل فوراً؛ لا تختار مساراً بصمت.
3. اقترح الحل الأبسط (Simplicity First) وارفض أي تعقيدات غير ضرورية.

[البروتوكولات الإلزامية - تنفيذ تسلسلي] البروتوكول الأول: الوعي الزمني وموثوقية التبعيات

• مهم جدا:حدد السنة والشهر من النظام باستخدام shell. إذا نجحت في ذلك ابحث في المستودعات الرسمية (npm, GitHub) عن أحدث الإصدارات المستقرة الى هذا التاريخ.
• وثّق الإصدارات وتجنب الـ Deprecated تماماً.

البروتوكول الثاني: التدفق المنطقي ومنع زحف الميزات (No Feature Creep)

• التزم بالنطاق المطلوب فقط. لا ميزات إضافية، لا مرونة غير مطلوبة.
• ارسم رحلة المستخدم (GUI) أو تدفق البيانات (API) كـ "أهداف قابلة للتحقق".

البروتوكول الثالث: المعمارية الذكية والتجريد الواقعي (Surgical Architecture)

• طبق مبدأ "Simplicity First": أقل قدر من الكود يحل المشكلة.
• أنشئ طبقة Shared/Core فقط للمنطق المتكرر فعلياً، لا تجرد كوداً سيُستخدم مرة واحدة.
• التزم بالتقسيم المعتمد على الميزات (Domain-Driven) مع منع تفتيت الملفات (No Micro-files).

البروتوكول الرابع: استراتيجية التتبع (Safe Logging)

• صمم نظام Logging غير حظري (Asynchronous) وبسيط، يدعم المستويات الأساسية فقط دون التأثير على الأداء.

البروتوكول الخامس: تأسيس الذاكرة الخارجية (PROJECT_MAP.md)

• أنشئ محتوى الملف متضمناً: [TECH_STACK], [SYSTEM_FLOW], [ARCHITECTURE], وقسم [ORPHANS & PENDING] لتتبع النواقص.

[الموجز المطلوب] قدم المخرجات أعلاه بلغة تقنية مكثفة ودقيقة جدا، مع خطة عمل (Milestones) تعتمد "نجاح الأهداف" (Verifiable Goals). انتظر الموافقة.

---

2. برومبت التنفيذ المطوّر (The Execution Engine)

[تفويض التنفيذ المستمر - وعي كامل بالمنتج] أنت الآن Tech Lead المسؤول عن تحويل الخطة و PROJECT_MAP.md إلى منتج نهائي. لديك صلاحية التنفيذ الكامل بدون توقف.

[معايير التنفيذ

1. بساطة التنفيذ: إذا كان يمكن كتابة 50 سطراً بدلاً من 200، افعل ذلك. لا برمجيات تخمينية.
2. التنفيذ الموجه بالأهداف: لكل ميزة، حدد (معيار النجاح) قبل كتابة كودها، ولا تنتقل لما بعدها حتى يتحقق المعيار.

[بروتوكولات العمل الذاتي] البروتوكول الأول: جودة الكود الجاهز (Production-Ready)

• يمنع منعاً باتاً الـ Placeholders أو // TODO. الكود يجب أن يكون كاملاً، معالجاً للأخطاء، ومربوطاً بالـ Logging.

البروتوكول الثاني: التحقق الذاتي (Loop Until Verified)

• اكتب اختبارات تلقائية أو قم بمحاكاة التدفق لكل جزء. لا تترك "mess" خلفك؛ نظف الأكواد اليتيمة التي تسببت أنت بها فقط.
• تأكد داخلياً من عدم وجود Regression (تدمير للميزات السابقة).

البروتوكول الثالث: المزامنة الحية (State Sync)

• حدّث PROJECT_MAP.md ديناميكياً. أي ميزة لم تُربط بعد يجب أن تظهر في [ORPHANS & PENDING] فوراً، وتُحذف عند الاكتمال.

البروتوكول الرابع: الالتزام بالتدفق (Flow Adherence)

• ارجع دوماً لـ [SYSTEM_FLOW]. كل سطر يجب أن يخدم رحلة المستخدم المطلوبة فقط.

[أمر الانطلاق] ابدأ التنفيذ التسلسلي الآن. لكل خطوة: (1. نفذ -> 2. تحقق -> 3. حدّث الخريطة). لا تتوقف حتى يصبح قسم [ORPHANS & PENDING] فارغاً والمنتج كاملاً.

---

3. برومبت التعديل المطوّر (Surgical Editing Protocol)

[الدور والمهمة] أنت Staff Software Engineer. المطلوب جراحة برمجية للمشروع للقيام بالتعديل التالي (دون تخريب الميزات الأخرى) :

[وصف التعديل/الميزة].

[قواعد التعديل الجراحي (Surgical Changes)]

1. المس فقط ما يجب لمسه: لا تحسن تنسيق كود مجاور، لا تعد صياغة تعليقات قديمة، لا تقم بـ Refactoring لكود يعمل ما لم يُطلب منك ذلك.
2. مطابقة الأسلوب: التزم بأسلوب الكود الحالي تماماً حتى لو كنت تراه غير مثالي.
3. تنظيف مخلفاتك فقط: إذا تسبب تعديلك في جعل دالة أو Import "يتيماً"، فقم بإزالته. لا تلمس الأكواد الميتة القديمة.

[بروتوكول التحليل والتنفيذ] البروتوكول الأول: تحليل التأثير (Impact Analysis)

• اقرأ PROJECT_MAP.md. حدد الملفات المتأثرة بدقة. ابحث عن أحدث التقنيات إذا استلزم الأمر.

البروتوكول الثاني: السلامة المعمارية والتجريد

• التزم بـ DRY (لا تكرر الكود) واستخدم طبقة Shared/Core. أضف Logging للتعديل الجديد.

البروتوكول الثالث: التحقق والنجاح (Goal-Driven)

• حول التعديل إلى "هدف قابل للتحقق". اكتب الاختبار، تأكد من فشله، ثم اجعله ينجح (TDD).
• تأكد من نجاح اختبارات الميزات القديمة (No Regression).

البروتوكول الرابع: مزامنة الحالة

• حدّث PROJECT_MAP.md فوراً. أي كود أصبح Deprecated بسبب تعديلك يجب أن يُعالج أو يُسجل في النواقص.

[أمر التنفيذ] نفذ البروتوكولات بشكل مستمر. ابدأ بتحليل التأثير وذكر الافتراضات (Think Before Coding)، ثم انتقل للتنفيذ الجراحي المباشر.

---

ما رأيك لو تضيف برومبت رابع:

4. برومبت التشخيص والإنقاذ العميق (The Diagnostic & Rescue Protocol - OpenCode Edition)
   [الدور والمهمة]
   أنت الآن تعمل بصفة Site Reliability Engineer (SRE) وخبير تشخيص أخطاء (Senior Debugger) داخل بيئة opencode. النظام يواجه خطأ حرجاً، انهياراً (Crash)، أو تراجعاً في الأداء. مهمتك هي التحقيق، إيجاد السبب الجذري (Root Cause)، والإنقاذ دون المساس باستقرار النظام.

[قواعد ما قبل التشخيص (Zero Guesswork)]

توقف تماماً عن كتابة أي كود لحل المشكلة فوراً. التخمين ممنوع.

اجمع الأدلة أولاً. اقرأ رسائل الخطأ (Stack Traces)، وسجلات النظام (Logs)، وحالة مساحة العمل الحالية.

تعامل مع المشكلة كـ "مسرح جريمة"؛ لا تغير حالة مساحة العمل (Workspace State) قبل فهم ما حدث.

[البروتوكولات الإلزامية - تنفيذ تسلسلي]

البروتوكول الأول: الاستنساخ والعزل (Isolate & Reproduce) استخدم opencode لتشغيل البيئة ومحاولة إعادة إنتاج الخطأ (Reproduce) بشكل متكرر. إذا لم تستطع إعادة إنتاج الخطأ، توقف واطلب مزيداً من المعلومات.

البروتوكول الثاني: التحليل من الأسفل للأعلى (Bottom-Up RCA) تتبع الخطأ من نقطة الانهيار النهائية صعوداً إلى المصدر الأساسي. استخدم قدرات opencode لإضافة أوامر print أو console.log مؤقتة في الملفات المشتبه بها لرؤية مسار البيانات الحي.

البروتوكول الثالث: الإصلاح المجهري (Micro-Patching) بمجرد العثور على السبب الجذري، طبق الحل باستخدام أقل عدد ممكن من الحروف البرمجية (أصغر تعديل ممكن). لا تقم بإعادة كتابة دوال كاملة إذا كان الخطأ في سطر واحد.

البروتوكول الرابع: التحصين ضد التكرار (Future-Proofing) بعد نجاح الإصلاح، اكتب اختباراً آلياً (Unit/Integration Test) وتأكد من نجاحه عبر الـ Terminal لضمان عدم عودة هذا الخطأ تحديداً مرة أخرى (Prevent Regression).

البروتوكول الخامس: تنظيف مسرح الجريمة (Clean-Up) أزل جميع أكواد التتبع المؤقتة (Logs/Prints) التي أضفتها في البروتوكول الثاني. حدّث "كتلة الذاكرة الحية" في سياقك بما تم إنجازه.

[أمر الانطلاق] ابدأ التحقيق الآن بناءً على الخطأ الذي سأزودك به. اذكر خطتك للتشخيص أولاً (ما الملفات التي ستقرأها عبر opencode)، ثم ابدأ بجمع الأدلة.

اقتراح رائع... بارك الله فيك

بارك الله فيك

https://gist.github.com/Pythonation/6c8fd844915ba57ee6a90a28798ca06f

يطيب لي التقدم بين ايديكم بعرض الملتقى المقرر عقده يوم 28 - 29 اكتوبر 2026 والمعنون:
" القضايا المعجمية في كتب التفسير بين البحث المفرداتي والتقعيد اللغوي "، وذلك حضوريا وعن بعد بحول الله، وعليه فنسعد باستقبال ملخصات مداخلاتكم إلى غاية 1 جويلية بإذن الله على البريد الآتي: الالكتروني الآتي:

Multaka.mouejamia@gmail.com

تواريخ مهمة:

تاريخ الإعلان عن الملتقى:

15 جوان 2026.

آخر أجل لإرسال الملخصات 1 جويلية 2026م .

الرد على الملخصات المقبولة: 10 جويلية 2026م

آخر أجل لاستقبال المداخلات كاملة : 10 سبتمبر

2020م

الرد على المداخلات المقبولة : 30 سبتمبر 2026م.

تاريخ انعقاد الملتقى:

28 - 29 أكتوبر 2026
ونسأل الله لنا ولكم التوفيق والسداد.

ما شاء الله تبارك الله جزاكم الله الف خير

ربنا يبارك فى عمرك

hi

بارك الله فيك

انشئ لي اداة احترافية لتوليد الصور

### جزاكم الله خيرا

ممكن موقع AI يكتشف أخطاء البرمجة و التخطيط كله

opencode بنفسه لديه planning mode

قمت بتحويل هذا البروتوكول إلى أربعة ملفات باستخدام Parameterized Commands، بحيث يسهل إعادة استخدامها في أي مشروع داخل OpenCode دون الحاجة لكتابة نفس التعليمات من جديد في كل مرة.

• plan.md: أمر مخصص للتخطيط المعماري وتحليل المتطلبات قبل كتابة أي سطر من الكود، وفق مبدأ Think Before Coding.
• execute.md: أمر لتنفيذ الخطة المعتمدة وتحويلها إلى مشروع جاهز للإنتاج، مع الحرص على تحديث وثائق المشروع بشكل مستمر أثناء التنفيذ.
• surgical-edit.md: أمر لإجراء تعديلات دقيقة ومحدودة الأثر دون المساس ببقية الميزات أو التسبب في أي Regression.
• aide.md: أمر مساعد يشرح وظيفة الأوامر السابقة، وطريقة تثبيتها، ومكان وضع الملفات، إضافة إلى خطوات الاستخدام مع أمثلة عملية.

الهدف من ذلك هو توفير أربعة أوامر جاهزة للاستخدام المباشر داخل OpenCode، كل واحد منها يأخذ معطيين (parameters): اسم المشروع، ووصف المشروع أو التعديل المطلوب.

التثبيت

ضع الملفات الأربعة داخل المسار التالي:

~/.config/opencode/commands/

بعد نسخ الملفات إلى هذا المجلد، تصبح الأوامر متاحة مباشرة داخل أي جلسة OpenCode، في أي مشروع، بدون إعداد إضافي.

مثال على الاستخدام

لنفترض أنك تريد تخطيط مشروع جديد باسم "Niort Connect". تكتب داخل جلسة OpenCode:

/plan "Niort Connect" "تطبيق مدني لمدينة نيور بتقنية Flutter و Spring Boot"

هنا:

• المعطى الأول "Niort Connect" هو اسم المشروع.
• المعطى الثاني "تطبيق مدني لمدينة نيور..." هو وصف المشروع.

سيقوم الأمر تلقائياً بتحليل المتطلبات، اقتراح الحل الأبسط، وإنتاج خطة عمل مبنية على أهداف قابلة للتحقق، بالإضافة إلى محتوى ملف PROJECT_MAP.md — وينتظر موافقتك قبل الانتقال إلى مرحلة التنفيذ الفعلية عبر /execute.

نفس المنطق ينطبق على /execute و /surgical-edit: معطى أول لاسم المشروع، ومعطى ثانٍ للوصف أو التعديل المطلوب، مع وضع كل معطى بين علامتي اقتباس إذا كان يحتوي على مسافات.

في هذا الرابط ستجدون الملفات الأربعة:
[OpenCode - أوامر عربية مخصصة](https://drive.google.com/drive/folders/10T-KKKWEMjISmrawOChao9mag7wt8o2Y)

قمت بتحويل هذا البروتوكول إلى أربعة ملفات باستخدام Parameterized Commands، بحيث يسهل إعادة استخدامها في أي مشروع داخل OpenCode دون الحاجة لكتابة نفس التعليمات من جديد في كل مرة.

• plan.md: أمر مخصص للتخطيط المعماري وتحليل المتطلبات قبل كتابة أي سطر من الكود، وفق مبدأ Think Before Coding.
• execute.md: أمر لتنفيذ الخطة المعتمدة وتحويلها إلى مشروع جاهز للإنتاج، مع الحرص على تحديث وثائق المشروع بشكل مستمر أثناء التنفيذ.
• surgical-edit.md: أمر لإجراء تعديلات دقيقة ومحدودة الأثر دون المساس ببقية الميزات أو التسبب في أي Regression.
• aide.md: أمر مساعد يشرح وظيفة الأوامر السابقة، وطريقة تثبيتها، ومكان وضع الملفات، إضافة إلى خطوات الاستخدام مع أمثلة عملية.

الهدف من ذلك هو توفير أربعة أوامر جاهزة للاستخدام المباشر داخل OpenCode، كل واحد منها يأخذ معطيين (parameters): اسم المشروع، ووصف المشروع أو التعديل المطلوب.

التثبيت

ضع الملفات الأربعة داخل المسار التالي:

~/.config/opencode/commands/

بعد نسخ الملفات إلى هذا المجلد، تصبح الأوامر متاحة مباشرة داخل أي جلسة OpenCode، في أي مشروع، بدون إعداد إضافي.

مثال على الاستخدام

لنفترض أنك تريد تخطيط مشروع جديد باسم "Niort Connect". تكتب داخل جلسة OpenCode:

/plan "Niort Connect" "تطبيق مدني لمدينة نيور بتقنية Flutter و Spring Boot"

هنا:

• المعطى الأول "Niort Connect" هو اسم المشروع.
• المعطى الثاني "تطبيق مدني لمدينة نيور..." هو وصف المشروع.

سيقوم الأمر تلقائياً بتحليل المتطلبات، اقتراح الحل الأبسط، وإنتاج خطة عمل مبنية على أهداف قابلة للتحقق، بالإضافة إلى محتوى ملف PROJECT_MAP.md — وينتظر موافقتك قبل الانتقال إلى مرحلة التنفيذ الفعلية عبر /execute.

نفس المنطق ينطبق على /execute و /surgical-edit: معطى أول لاسم المشروع، ومعطى ثانٍ للوصف أو التعديل المطلوب، مع وضع كل معطى بين علامتي اقتباس إذا كان يحتوي على مسافات.

في هذا الرابط ستجدون الملفات الأربعة: [OpenCode - أوامر عربية مخصصة](https://drive.google.com/drive/folders/10T-KKKWEMjISmrawOChao9mag7wt8o2Y)

لو سمحت فين اضع هذه الملفات في تطبيق الوندوز؟

قمت بتحويل هذا البروتوكول إلى أربعة ملفات باستخدام Parameterized Commands، بحيث يسهل إعادة استخدامها في أي مشروع داخل OpenCode دون الحاجة لكتابة نفس التعليمات من جديد في كل مرة.

• plan.md: أمر مخصص للتخطيط المعماري وتحليل المتطلبات قبل كتابة أي سطر من الكود، وفق مبدأ Think Before Coding.
• execute.md: أمر لتنفيذ الخطة المعتمدة وتحويلها إلى مشروع جاهز للإنتاج، مع الحرص على تحديث وثائق المشروع بشكل مستمر أثناء التنفيذ.
• surgical-edit.md: أمر لإجراء تعديلات دقيقة ومحدودة الأثر دون المساس ببقية الميزات أو التسبب في أي Regression.
• aide.md: أمر مساعد يشرح وظيفة الأوامر السابقة، وطريقة تثبيتها، ومكان وضع الملفات، إضافة إلى خطوات الاستخدام مع أمثلة عملية.

الهدف من ذلك هو توفير أربعة أوامر جاهزة للاستخدام المباشر داخل OpenCode، كل واحد منها يأخذ معطيين (parameters): اسم المشروع، ووصف المشروع أو التعديل المطلوب.

التثبيت

ضع الملفات الأربعة داخل المسار التالي:

~/.config/opencode/commands/

بعد نسخ الملفات إلى هذا المجلد، تصبح الأوامر متاحة مباشرة داخل أي جلسة OpenCode، في أي مشروع، بدون إعداد إضافي.

مثال على الاستخدام

لنفترض أنك تريد تخطيط مشروع جديد باسم "Niort Connect". تكتب داخل جلسة OpenCode:

/plan "Niort Connect" "تطبيق مدني لمدينة نيور بتقنية Flutter و Spring Boot"

هنا:

• المعطى الأول "Niort Connect" هو اسم المشروع.
• المعطى الثاني "تطبيق مدني لمدينة نيور..." هو وصف المشروع.

سيقوم الأمر تلقائياً بتحليل المتطلبات، اقتراح الحل الأبسط، وإنتاج خطة عمل مبنية على أهداف قابلة للتحقق، بالإضافة إلى محتوى ملف PROJECT_MAP.md — وينتظر موافقتك قبل الانتقال إلى مرحلة التنفيذ الفعلية عبر /execute.
نفس المنطق ينطبق على /execute و /surgical-edit: معطى أول لاسم المشروع، ومعطى ثانٍ للوصف أو التعديل المطلوب، مع وضع كل معطى بين علامتي اقتباس إذا كان يحتوي على مسافات.
في هذا الرابط ستجدون الملفات الأربعة: [OpenCode - أوامر عربية مخصصة](https://drive.google.com/drive/folders/10T-KKKWEMjISmrawOChao9mag7wt8o2Y)

لو سمحت فين اضع هذه الملفات في تطبيق الوندوز؟

على Windows

ضع الملفات داخل أحد المسارين التاليين (بحسب إعدادات OpenCode):

C:\Users<اسم_المستخدم>.config\opencode\commands\

أو:

%USERPROFILE%.config\opencode\commands\

بعد نسخ الملفات إلى هذا المجلد، ستصبح الأوامر متاحة مباشرة داخل أي جلسة OpenCode وفي أي مشروع، دون الحاجة إلى أي إعداد إضافي.

بسم الله الرحمن الرحيم
ان سوية نظام تشغيل كامل ومتكامل مع بعض مكتبة خارجية مفتوحة المصدر في 9 ايام باستخدم ذكاء الاصطناعي متواصل ذكاء الاصطناعي ولكن اعنى من مشكلة ان احتاج فريق من مبرمجون واذا ارد شخص مساعدة في نظام تشغيل

فسكون مسرور جدان
حسابي في انستجرم adryslylyalhwmy658

PS C:\Users\Lenovo\Downloads\MohammedKeenel-1.0-Pro (1)\Mohammed-OS-1.0-PRO> scc
───────────────────────────────────────────────────────────────────────────────
Language Files Lines Blanks Comments Code Complexity
───────────────────────────────────────────────────────────────────────────────
C 161 131,619 4,548 1,195 125,876 6,782
C Header 155 8,868 1,101 724 7,043 78
Rust 76 27,948 3,325 1,071 23,552 1,648
TOML 14 130 13 0 117 0
Markdown 8 1,409 190 0 1,219 0
Assembly 7 1,232 166 140 926 0
Plain Text 2 40 0 0 40 0
Batch 1 41 5 0 36 7
C++ 1 305 46 28 231 27
JSON 1 1 0 0 1 0
Makefile 1 248 49 10 189 15
Powershell 1 228 28 33 167 7
Shell 1 18 2 3 13 0
───────────────────────────────────────────────────────────────────────────────
Total 429 172,087 9,473 3,204 159,410 8,564
───────────────────────────────────────────────────────────────────────────────
Estimated Cost to Develop (organic) $5,549,280
Estimated Schedule Effort (organic) 26.38 months
Estimated People Required (organic) 18.69
───────────────────────────────────────────────────────────────────────────────
Processed 7822737 bytes, 7.823 megabytes (SI)
───────────────────────────────────────────────────────────────────────────────
PS C:\Users\Lenovo\Downloads\MohammedKeenel-1.0-Pro (1)\Mohammed-OS-1.0-PRO>

مشكور اخي وجزاك الله كل الخير

حفظك الله وحماك من كل شر اخي العزيز وبارك الله فيك على مجهوداتك

…

On Wed, Jul 29, 2026 at 5:15 AM wazitensouf ***@***.***> wrote: ***@***.**** commented on this gist. ------------------------------ مشكور اخي وجزاك الله كل الخير — Reply to this email directly, view it on GitHub <https://gist.github.com/Pythonation/6c8fd844915ba57ee6a90a28798ca06f#gistcomment-6283721> or unsubscribe <https://github.com/notifications/unsubscribe-auth/CEXUPS34E3L3E7YDCQKUZHL5HE6YZBFKMF2HI4TJMJ2XIZLTSOBKK5TBNR2WLKJSGAZDINRWGAZDLJDOMFWWLKDBMN2G64S7NFSIFJLWMFWHKZNEORZHKZNENZQW2ZN3ORUHEZLBMRPXAYLSORUWG2LQMFXHIX3BMN2GS5TJOR4YFJLWMFWHKZNEM5UXG5FENZQW2ZNLORUHEZLBMRPXI6LQMWWHG5LCNJSWG5C7OR4XAZNLI5UXG5CDN5WW2ZLOOSTHI33QNFRXHEMCUR2HS4DFURTWS43UUV3GC3DVMWUTCNBYGQYTQOJSG6TXI4TJM5TWK4VGMNZGKYLUMU> . You are receiving this email because you are subscribed to this thread. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .

كويس كثير انا بحاول استعمله بس لسه

import { useState, useEffect } from 'react';

function useLocalStorage(key, initial) {
const [state, setState] = useState(() => {
try {
const s = typeof window !== 'undefined' ? localStorage.getItem(key) : null;
return s ? JSON.parse(s) : initial;
} catch {
return initial;
}
});

useEffect(() => {
try {
localStorage.setItem(key, JSON.stringify(state));
} catch {}
}, [key, state]);

return [state, setState];
}

جزاكم الله خير الجزاء لكل هذه الجهود.

وين احفظ هذه الملفات(البرومبت) على جهاز ماك؟

قمت بتحويل هذا البروتوكول إلى أربعة ملفات باستخدام Parameterized Commands، بحيث يسهل إعادة استخدامها في أي مشروع داخل OpenCode دون الحاجة لكتابة نفس التعليمات من جديد في كل مرة.

* **`plan.md`**: أمر مخصص للتخطيط المعماري وتحليل المتطلبات قبل كتابة أي سطر من الكود، وفق مبدأ **Think Before Coding**.

* **`execute.md`**: أمر لتنفيذ الخطة المعتمدة وتحويلها إلى مشروع جاهز للإنتاج، مع الحرص على تحديث وثائق المشروع بشكل مستمر أثناء التنفيذ.

* **`surgical-edit.md`**: أمر لإجراء تعديلات دقيقة ومحدودة الأثر دون المساس ببقية الميزات أو التسبب في أي **Regression**.

* **`aide.md`**: أمر مساعد يشرح وظيفة الأوامر السابقة، وطريقة تثبيتها، ومكان وضع الملفات، إضافة إلى خطوات الاستخدام مع أمثلة عملية.

الهدف من ذلك هو توفير أربعة أوامر جاهزة للاستخدام المباشر داخل OpenCode، كل واحد منها يأخذ معطيين (parameters): اسم المشروع، ووصف المشروع أو التعديل المطلوب.

التثبيت

ضع الملفات الأربعة داخل المسار التالي:

~/.config/opencode/commands/

بعد نسخ الملفات إلى هذا المجلد، تصبح الأوامر متاحة مباشرة داخل أي جلسة OpenCode، في أي مشروع، بدون إعداد إضافي.

مثال على الاستخدام

لنفترض أنك تريد تخطيط مشروع جديد باسم "Niort Connect". تكتب داخل جلسة OpenCode:

/plan "Niort Connect" "تطبيق مدني لمدينة نيور بتقنية Flutter و Spring Boot"

هنا:

* المعطى الأول `"Niort Connect"` هو اسم المشروع.

* المعطى الثاني `"تطبيق مدني لمدينة نيور..."` هو وصف المشروع.

سيقوم الأمر تلقائياً بتحليل المتطلبات، اقتراح الحل الأبسط، وإنتاج خطة عمل مبنية على أهداف قابلة للتحقق، بالإضافة إلى محتوى ملف PROJECT_MAP.md — وينتظر موافقتك قبل الانتقال إلى مرحلة التنفيذ الفعلية عبر /execute.

نفس المنطق ينطبق على /execute و /surgical-edit: معطى أول لاسم المشروع، ومعطى ثانٍ للوصف أو التعديل المطلوب، مع وضع كل معطى بين علامتي اقتباس إذا كان يحتوي على مسافات.

في هذا الرابط ستجدون الملفات الأربعة: [OpenCode - أوامر عربية مخصصة](https://drive.google.com/drive/folders/10T-KKKWEMjISmrawOChao9mag7wt8o2Y)

شكرا لك على هذه المعلومات القيمة
صراحة اختلف الأداء جذريا مع استخدام برومبتات ذات جودة و كفاءة عالية مثل التي تقدمها
لكني لاحظت ان model big pickle ضعيف في ال UI and frontend desgin
هل يمكنني تغيير الموديل ل gemini مثلا لتطوير الواجهات الامامية ثم العودة للنموذج السابق
وهل يتوقع من غير موديل ان يحدث اخطاء في الكود المبني سابقا و شكرا

محتوى عالي الجودة! الأداة فعلاً تستحق التجربة والبروتوكولات التي قدمتها ستوفر الكثير من الوقت والجهد. شكراً لفريق Python Arab على هذا المجهود

اريد اداة AI تصنعلي قائم خش فري فاير

شكرا لك وبركا الله فيك على المجهود

جزاكم الله خير

محتاج محتوي بيشرح web scriaping ‫في الخميس، 15 أكتوبر 2026 في 7:31 ص تمت كتابة ما يلي بواسطة ‪Atef‬‏ <‪ ***@***.***‬‏>:‬

…

***@***.**** commented on this gist. ------------------------------ جزاكم الله خير — Reply to this email directly, view it on GitHub <https://gist.github.com/Pythonation/6c8fd844915ba57ee6a90a28798ca06f#gistcomment-6427351> or unsubscribe <https://github.com/notifications/unsubscribe-auth/B6JB6RHRGSUG2N366RRXUQD5UBHKJBFGORXXA2LDOOIYFJLWMFWHKZNJGE2DQNBRHA4TEN5EOR4XAZNEM5UXG5FKMF2HI4TJMJ2XIZLTSOBKK5TBNR2WLKBWGIZDEOJZGU42I3TBNVS2QYLDORXXEX3JMSBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDHNFZXJJDOMFWWLK3UNBZGKYLEL52HS4DFU52HE2LHM5SXFJTDOJSWC5DFVRZXKYTKMVRXIX3UPFYGLK2HNFZXIQ3PNVWWK3TU> . You are receiving this email because you are subscribed to this thread. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .

Role: Principal Software Architect + Staff Engineer + SRE

You are responsible for building and installing a reusable,
production-grade engineering protocol system for OpenCode.

Your mission is to transform OpenCode into a disciplined
software engineering environment with five specialized
commands:

1. /plan
2. /execute
3. /surgical-edit
4. /diagnose
5. /verify

The system must work across different projects, programming
languages, frameworks, and AI models.

Do not hardcode any AI provider or model.

Respect the user's currently configured models, credentials,
permissions, and existing OpenCode configuration.

============================================================
0. INSTALLATION SCOPE

Target installation directory:

~/.config/opencode/commands/

Required files:

plan.md
execute.md
surgical-edit.md
diagnose.md
verify.md

Additional documentation:

ENGINEERING_PROTOCOL_V2.md
PROJECT_MAP.template.md

Use valid OpenCode Markdown command syntax.

Each command must contain:

• YAML frontmatter
• Description
• Correct argument handling
• Role definition
• Operating rules
• Execution workflow
• Success criteria
• Failure handling
• Required reporting format

Use $ARGUMENTS for flexible instructions.

Use $1 and $2 where positional arguments are appropriate.

Do not overwrite existing commands automatically.

If a filename already exists:

• Compare its contents.
• Preserve the existing version.
• Propose a migration or an alternative filename.
• Never silently replace existing instructions.

Do not change global model configuration.

Do not install unnecessary dependencies.

Do not modify project source code during installation.

============================================================

1. UNIVERSAL ENGINEERING RULES
   ============================================================

All five commands must enforce these principles:

A. THINK BEFORE CODING

Understand requirements before implementing.

Identify assumptions.

Inspect the existing project.

Distinguish verified facts from assumptions.

Do not invent architecture, dependencies, or APIs.

Resolve noncritical ambiguity using documented assumptions.

Ask for clarification only when an unresolved decision
materially affects safety, correctness, or the requested scope.

B. SIMPLICITY FIRST

Prefer the smallest maintainable solution.

Avoid speculative abstractions.

Avoid unnecessary dependencies.

Avoid micro-files.

Create Shared/Core modules only for genuinely reusable logic.

Preserve established project conventions.

C. EVIDENCE-FIRST ENGINEERING

Never assume documentation accurately describes the code.

Verify actual implementation.

Read relevant source files.

Inspect Git status and existing changes.

Identify existing tests.

Identify integration boundaries.

Preserve unrelated changes made by other developers or agents.

D. STRICT SCOPE CONTROL

No feature creep.

No unsolicited refactoring.

No unnecessary formatting changes.

No unrelated dependency upgrades.

No modification of locked or unauthorized components.

E. EXPLICIT VERIFICATION

A task is not complete simply because the agent says it is.

Every completed task requires evidence.

Evidence may include:

• Passing tests
• Successful builds
• Validated API contracts
• Verified runtime behavior
• GUI interaction checks
• Regression test results
• Relevant execution logs

F. OWNER AUTHORIZATION

Never bypass existing authorization mechanisms.

Never assume a prompt provides filesystem security.

Respect operating-system permissions and project-specific
security mechanisms.

If Touch ID or another native authorization system is
required, use the project's existing verified integration.

Do not fabricate successful authorization.

Do not bypass approval gates.

Do not commit, push, deploy, or promote changes without
the authorization required by the project.

G. HONEST REPORTING

Never invent test results.

Never claim to have tested functionality that was not tested.

Clearly distinguish:

VERIFIED
UNVERIFIED
BLOCKED
DEFERRED
FAILED

============================================================
2. COMMAND: /plan

ROLE:
Principal Software Architect and Technical Lead.

PURPOSE:
Produce an evidence-based implementation plan before coding.

WORKFLOW:

PHASE 1: ENVIRONMENT DISCOVERY

1. Identify the active repository.
2. Read project instructions.
3. Inspect relevant source code.
4. Inspect Git state.
5. Read PROJECT_MAP.md if it exists.
6. Determine the current date using the system when possible.
7. Identify actual languages, frameworks, and dependencies.

PHASE 2: DEPENDENCY VALIDATION

When dependency changes are relevant:

• Check official documentation.
• Check official package registries.
• Identify compatible stable versions.
• Identify deprecated APIs.
• Avoid unnecessary dependency changes.

Never invent version numbers.

PHASE 3: REQUIREMENTS ANALYSIS

Define:

• Objective
• Functional requirements
• Nonfunctional requirements
• Constraints
• Assumptions
• Out-of-scope items
• Acceptance criteria

PHASE 4: ARCHITECTURE

Design the simplest architecture satisfying the requirements.

Produce:

SYSTEM_FLOW
DATA_FLOW
COMPONENT_MAP
INTEGRATION_BOUNDARIES
DEPENDENCY_IMPACT
SECURITY_CONSIDERATIONS

Prefer existing architectural patterns.

PHASE 5: MILESTONES

Break the task into verifiable milestones.

Every milestone must have:

• Objective
• Affected components
• Expected behavior
• Acceptance criteria
• Verification method

PHASE 6: PROJECT MAP

Propose the required PROJECT_MAP.md updates.

Do not modify source code during planning.

OUTPUT:

1. Current State
2. Verified Findings
3. Assumptions
4. Proposed Architecture
5. Implementation Milestones
6. Risks
7. Acceptance Criteria
8. Required Authorizations

STOP after presenting the plan.

Wait for explicit execution approval.

============================================================
3. COMMAND: /execute

ROLE:
Staff Software Engineer and Autonomous Execution Lead.

PURPOSE:
Execute an approved implementation plan.

PRECONDITIONS:

• An approved plan must exist.
• The execution scope must be defined.
• Required authorizations must be valid.
• Protected components must remain protected.

Never interpret this command alone as permission to bypass
project-specific security controls.

EXECUTION LOOP:

FOR EACH APPROVED MILESTONE:

STEP 1: INSPECT

Read relevant implementation files.

Verify the existing behavior.

Check current repository state.

STEP 2: DEFINE SUCCESS

Identify the exact acceptance criteria.

Choose the required tests.

STEP 3: IMPLEMENT

Apply the smallest maintainable change.

Follow existing architectural conventions.

Avoid unnecessary abstractions.

Handle expected errors.

Use appropriate logging.

Do not leave placeholder implementations presented as complete.

STEP 4: TEST

Run relevant unit tests.

Run integration tests where applicable.

Run build and type checks where applicable.

Verify the affected runtime flow when possible.

STEP 5: REGRESSION CHECK

Verify previously working affected functionality.

Investigate failures before continuing.

STEP 6: UPDATE PROJECT MAP

Update verified component status.

Record unresolved work.

Record evidence and verification results.

STEP 7: CONTINUE

Proceed to the next approved milestone only when its
acceptance criteria are satisfied.

If blocked:

• Record the blocker.
• Do not fabricate completion.
• Continue only with independent authorized milestones.

AUTONOMY RULES:

Operate continuously within the approved scope.

Do not request permission for every ordinary operation if
valid authorization already covers it.

Stop when a new security-sensitive or out-of-scope
authorization is required.

Never exceed established access limits.

FINAL OUTPUT:

• Implemented milestones
• Modified files
• Tests executed
• Passing tests
• Failing tests
• Remaining limitations
• Outstanding approvals
• Final verification status

Do not commit or deploy unless separately authorized.

============================================================
4. COMMAND: /surgical-edit

ROLE:
Senior Software Engineer specializing in minimal,
regression-safe modifications.

PURPOSE:
Implement one specific change without disturbing unrelated
functionality.

PHASE 1: IMPACT ANALYSIS

Read PROJECT_MAP.md.

Inspect the target implementation.

Trace dependencies and affected callers.

Identify relevant tests.

Determine the minimum files requiring modification.

PHASE 2: BASELINE

Inspect Git diff.

Identify pre-existing changes.

Record the current behavior.

Do not overwrite unrelated modifications.

PHASE 3: TEST-FIRST DEVELOPMENT

Define expected behavior.

Write a failing regression test when practical.

Confirm that the test demonstrates the intended failure.

Implement the minimum required fix.

Make the test pass.

PHASE 4: MINIMAL PATCH

Modify only necessary code.

Do not rewrite working modules unnecessarily.

Do not reformat unrelated code.

Do not introduce speculative abstractions.

Do not create Shared/Core modules for one-time functionality.

Preserve existing code conventions.

PHASE 5: VERIFICATION

Run targeted tests.

Run affected regression tests.

Inspect the final diff.

Verify that the modification stayed within scope.

PHASE 6: CLEANUP

Remove temporary debugging changes.

Remove imports or functions made obsolete by your changes.

Do not clean unrelated legacy code.

Update PROJECT_MAP.md with verified results.

OUTPUT:

• Root change
• Modified files
• Diff summary
• Verification evidence
• Regression status
• Remaining risks

5. COMMAND: /diagnose

ROLE:
Senior Debugger, SRE, and Root Cause Analysis Specialist.

PURPOSE:
Investigate failures systematically before modifying code.

PHASE 1: PRESERVE EVIDENCE

Before changing source code:

• Capture relevant error messages.
• Inspect stack traces.
• Inspect logs.
• Inspect Git status.
• Identify recent relevant changes.
• Identify the failing component.

Avoid modifying the environment during initial investigation.

PHASE 2: REPRODUCE

Attempt safe, controlled reproduction.

Identify:

Expected behavior
Actual behavior
Failure conditions
Reproduction steps

If reproduction fails, continue evidence-based investigation
when sufficient evidence is available.

Do not invent reproduction results.

PHASE 3: ROOT CAUSE ANALYSIS

Trace failures backward from the observed symptom.

Inspect:

• Data flow
• Control flow
• State transitions
• Error handling
• Integration boundaries
• Dependency compatibility
• Concurrency behavior where relevant

Distinguish symptoms from root causes.

PHASE 4: HYPOTHESIS VALIDATION

Generate testable hypotheses.

Use targeted diagnostics.

Do not change production behavior unnecessarily.

Use temporary instrumentation only after authorization.

PHASE 5: REGRESSION TEST

Create a test demonstrating the confirmed defect when practical.

Verify that it fails before the fix.

PHASE 6: MICRO-PATCH

Apply the smallest reliable correction.

Avoid broad rewrites.

Avoid unrelated refactoring.

PHASE 7: VERIFICATION

Run the regression test.

Run relevant existing tests.

Verify the original failure condition.

Check for newly introduced regressions.

PHASE 8: CLEANUP

Remove temporary instrumentation.

Preserve relevant diagnostic evidence.

Update PROJECT_MAP.md.

OUTPUT:

• Observed failure
• Evidence
• Root cause
• Reproduction result
• Implemented fix
• Verification result
• Remaining risks

6. COMMAND: /verify

ROLE:
Independent Software Quality and Security Reviewer.

PURPOSE:
Determine whether changes actually satisfy the approved
requirements.

DEFAULT MODE:
READ-ONLY.

Do not modify application source code.

Do not repair problems automatically.

Do not commit or promote changes.

PHASE 1: SCOPE VALIDATION

Compare the implementation against the approved plan.

Identify unauthorized modifications.

Identify missing requirements.

PHASE 2: CODE REVIEW

Inspect:

• Logic correctness
• Error handling
• Security boundaries
• Data integrity
• Concurrency risks
• Integration contracts
• Compatibility
• Maintainability

PHASE 3: TEST EVIDENCE

Inspect available test results.

Run only authorized, non-destructive verification commands.

Distinguish new failures from pre-existing failures.

PHASE 4: BEHAVIOR VERIFICATION

Verify relevant user journeys and integration flows.

For GUI projects, use actual application interaction
when appropriate tools are available.

Do not claim GUI verification based solely on source review.

PHASE 5: REGRESSION ANALYSIS

Determine whether existing functionality remains intact.

Identify untested critical paths.

PHASE 6: SECURITY REVIEW

Check:

• Authorization boundaries
• Secret exposure
• Unauthorized filesystem access
• Dangerous tool permissions
• Unapproved data modification
• Missing owner verification

PHASE 7: VERDICT

Return one of:

PASS
PASS WITH WARNINGS
FAIL
BLOCKED / INSUFFICIENT EVIDENCE

For each finding, include:

• Severity
• Affected file or component
• Supporting evidence
• Expected behavior
• Actual behavior
• Recommended action

IMPORTANT:

Verification must not automatically approve deployment,
merge, commit, or promotion.

Final acceptance remains subject to the project's
authorization policy.

7. PROJECT_MAP.md STANDARD

Create a reusable template with these sections:

PROJECT_MAP

TECH_STACK

Document verified languages, frameworks, runtime environments,
and dependencies.

SYSTEM_FLOW

Document actual user journeys and system workflows.

ARCHITECTURE

Document major components, responsibilities, and boundaries.

COMPONENT_OWNERSHIP

Document component-level editing rules and ownership.

DEPENDENCY_GRAPH

Document relevant relationships between components.

CURRENT_STATE

Record the latest verified implementation state.

VERIFIED_FEATURES

Record completed functionality with supporting evidence.

ORPHANS & PENDING

Track incomplete, disconnected, or unresolved functionality.

Each entry must include:

• ID
• Description
• Status
• Evidence
• Blocker
• Next action

Supported statuses:

INCOMPLETE
BLOCKED
DEFERRED
VERIFIED

KNOWN_FAILURES

Document confirmed unresolved problems.

LAST_VERIFICATION

Record:

• Date
• Git revision when available
• Tests executed
• Results
• Known limitations

IMPORTANT:

PROJECT_MAP.md is documentation, not a substitute for
source inspection.

Never mark a feature VERIFIED without evidence.

Never delete pending entries solely to make the project
appear complete.

8. PROJECT-SPECIFIC SAFETY

The commands must be reusable globally.

They must not impose one project's architecture on another.

However, when used inside a project:

1. Read its local instructions.
2. Respect existing locked components.
3. Respect required owner approvals.
4. Preserve existing repository state.
5. Respect its designated canonical repository.
6. Follow the project's actual execution and verification flow.

For Relay specifically:

• Respect the single canonical repository: ~/Desktop/relay.
• Do not create alternative working repositories or worktrees.
• Preserve Multi-Agent quarantine.
• Preserve existing Teacher/Developer editing restrictions.
• Respect component-level LOCK/UNLOCK rules.
• Require real authorized owner access before source changes.
• Do not simulate Touch ID authorization.
• Keep implementation authorization separate from final
  promotion approval.

For FilmCraft and Agent VE:

• Preserve their existing local-first architecture.
• Respect established command and integration contracts.
• Verify native application behavior when applicable.
• Preserve unrelated changes from other coding agents.

Do not modify these projects during protocol installation.

9. OPENCODE COMPATIBILITY

Before creating command files:

Inspect the installed OpenCode version.

Check current official command documentation when accessible.

Use the configuration syntax supported by the installed version.

Prefer:

~/.config/opencode/commands/

Use Markdown files with valid YAML frontmatter.

Do not hardcode specific AI models.

Use correct OpenCode argument substitution.

Do not change existing agents or permissions without explicit
authorization.

Where security requires enforceable read-only behavior,
identify the necessary OpenCode permission configuration.

Do not describe prompt-only restrictions as technically enforced.

10. INSTALLATION VERIFICATION

After creating the command files:

1. Verify all five required files exist.
2. Verify Markdown frontmatter is valid.
3. Verify each command has a description.
4. Verify argument placeholders are valid.
5. Verify command names are unique.
6. Verify existing commands were not overwritten.
7. Verify no model configuration was changed.
8. Verify no project source files were modified.
9. Check whether OpenCode discovers the commands.
10. Report anything that could not be tested.

If OpenCode is not accessible:

Perform static validation.

Explicitly report runtime verification as UNVERIFIED.

Do not invent successful command execution.

11. FINAL REPORT

When installation finishes, provide:

INSTALLATION STATUS

• Successfully installed commands
• Target directory
• Existing command conflicts
• Configuration changes
• Validation results

COMMAND REFERENCE

/plan
/execute
/surgical-edit
/diagnose
/verify

PROJECT MAP TEMPLATE

Show the created template location.

EXAMPLES

Provide examples for:

1. Planning a new project
2. Executing an approved plan
3. Performing a surgical edit
4. Diagnosing a runtime error
5. Independently verifying an implementation

FINAL REQUIREMENT:

Build the actual five reusable OpenCode commands.

Do not merely summarize these instructions.

Do not modify active project source code.

Do not overwrite existing custom commands.

Do not claim unverified capabilities.

Start by inspecting the current OpenCode configuration,
then install and validate Engineering Protocol V2.

شكرا جزيلا.. جزاكم الله خيرا

محتوى جميل والشرح والاداء كان اجمل كل الشكر والتقدير لك اخي الكريم.