برومبتات Cursor وClaude Code فى هذا الدليل يقدّم ثلاثة قوالب برومبت جاهزة للاستخدام مع محرر Cursor أو أداة سطر الأوامر Claude Code: قالب لكتابة ميزة جديدة، وقالب لتصحيح خطأ، وقالب لإعادة هيكلة الكود دون كسر سلوكه الحالي. القوالب نماذج توضيحية لم تُختبر تنفيذيًا داخل الأداتين في إطار هذا الدليل؛ عدّلها وفق مشروعك واحكم على النتيجة من خلال فحص فعلي (اختبارات، تشغيل تجريبي) لا من صياغة البرومبت وحدها.
قبل النسخ: ما المعلومات التي يحتاجها البرومبت؟
البرومبت الجيد لمهمة برمجية يحتاج أربعة عناصر، سواء كتبته لـ Cursor أو لـ Claude Code:
- المهمة: ماذا تريد بالضبط؟ صياغة محددة، لا وصف عام.
- السياق: أي الملفات ذات صلة، وما الأنماط التي يجب الالتزام بها في هذا المشروع تحديدًا.
- النطاق والحدود: ما الذي يُسمح بتعديله، وما الذي يجب ألا يُمس.
- معيار القبول: كيف يتحقق النموذج من أن عمله صحيح — أمر فحص محدد، أو سلوك متوقع، أو كلاهما. إن لم تعرف أمر الفحص بدقة، اطلب من النموذج اكتشافه من إعدادات المشروع (مثل package.json أو Makefile أو ما يعادلهما) بدل افتراض أمر بعينه؛ وإن تعذّر تشغيل أي فحص، يجب أن يصرّح بذلك بدل ادعاء النجاح. هذا يتوافق مع توصية توثيق Anthropic لأفضل الممارسات بإعطاء النموذج وسيلة واضحة يتحقق بها من عمله.
الفرق بين طلب مبهم مثل «أصلح المشكلة في صفحة تسجيل الدخول» وطلب محدد يذكر الملف والسلوك المتوقع والفعلي وأمر الفحص، هو أن الطلب المحدد يمنحك أساسًا واضحًا تراجع عليه التعديل، بدل تعديل تحكم على جودته بالتخمين. القوالب الثلاثة التالية تبني هذه العناصر الأربعة بشكل جاهز؛ ما عليك سوى تعبئة الأقواس المربعة [ ].
💡 ملاحظة حول لغة التعليمات (Prompt Language):
القوالب الواردة في هذا الدليل مكتوبة باللغة العربية لتوضيح الهيكلية والمفاهيم. ورغم أن النماذج الذكية تتهم اللغة العربية بطلاقة، إلا أن تجارب المطورين الميدانية تؤكد أن كتابة تعليمات البرومبت (Instructions) باللغة الإنجليزية تُعطي غالبًا أداءً أعلى وأدق في فهم التفاصيل البرمجية المعقدة والاستجابة لقيود الأكواد، خصوصًا عند التعامل مع المكتبات الحديثة. يمكنك استخدام القوالب بالعربية كما هي للمهام العادية، أو ترجمة نص القالب إلى الإنجليزية مع الإبقاء على الشروحات والملاحظات بالعربية للحصول على أعلى دقة ممكنة.
إذا كنت لا تزال محتارًا في اختيار الأداة المناسبة لمشروعك، يمكنك الاطلاع على مقارنة Claude Code وCursor 3 لمعرفة الفروق بينهما في كتابة الكود، تصحيح الأخطاء، وإعادة هيكلة المشاريع الكبيرة.
برومبت كتابة ميزة جديدة داخل مشروع قائم
استخدم هذا القالب عند إضافة وظيفة جديدة إلى كود موجود مسبقًا، حيث يحتاج النموذج إلى فهم الأنماط الحالية قبل الكتابة فوقها.
المهمة: أضف ميزة [وصف الميزة بجملة واحدة] إلى [اسم الوحدة/الملف/الصفحة].
السياق:
- اقرأ هذه الملفات قبل أي تعديل: [مسار1، مسار2، ...]
- التزم بأنماط الكود المستخدمة حاليًا (التسمية، تنظيم المجلدات، المكتبات المعتمدة بالفعل في المشروع).
- إن كان هناك ملف تعليمات للمشروع (مثل CLAUDE.md أو .cursor/rules)، اتبعه.
النطاق والحدود:
- عدّل فقط داخل: [المسار أو المجلد]
- لا تُعدّل: [ملفات أو وحدات مستثناة صراحة]
- لا تضف مكتبة أو تبعية جديدة قبل أن تسألني.
السلوك المتوقع:
- [وصف دقيق لما يجب أن يحدث عند نجاح الميزة]
- الحالات الحدّية التي يجب معالجتها: [قائمة، مثل إدخال فارغ، قيمة سالبة، عدم اتصال بالشبكة]
معيار القبول:
- شغّل [أمر الفحص]. إذا لم تكن متأكدًا منه، اكتشفه أولًا من ملفات إعداد المشروع بدل افتراضه، وصرّح إن تعذّر تشغيل أي فحص بدل ادعاء النجاح.
- تأكد أن كل الفحوص القائمة سابقًا لا تزال تنجح.
- أضف اختبارًا جديدًا إن كانت بنية المشروع تحتوي فحوصًا آلية، يغطي [الحالة المطلوبة تحديدًا].
عند الانتهاء لخّص: الملفات التي غيّرتها، نتيجة تشغيل الفحوص، وأي افتراض اتخذته لم أذكره صراحة.مثال تعبئة
لنفترض مشروع قائمة مهام بسيط يحتوي بالفعل على بحث نصي، وتريد إضافة فلتر لعرض المهام «المكتملة» أو «غير المكتملة» فقط دون التأثير في البحث القائم. تعبئة القالب أعلاه تصبح تقريبًا:
المهمة: أضف فلتر "مكتمل / غير مكتمل" إلى صفحة قائمة المهام.
السياق:
- اقرأ: src/components/TaskList.tsx وsrc/hooks/useTasks.ts
- الفلتر يجب أن يعمل مع خاصية البحث النصي الموجودة، لا أن يستبدلها.
النطاق والحدود:
- عدّل فقط داخل src/components/ وsrc/hooks/
- لا تُعدّل واجهة API الخلفية.
السلوك المتوقع:
- عند اختيار "مكتمل" تظهر فقط المهام المنجزة، مع بقاء نتائج البحث النصي سارية.
- القيمة الافتراضية "الكل" تعرض كل المهام كما هي حاليًا.
معيار القبول:
- شغّل npm test
- أضف اختبارًا يتحقق من عمل الفلتر والبحث معًا في آنٍ واحد.هذا مثال توضيحي لتبيان طريقة التعبئة، وليس نتيجة تشغيل فعلي على مشروع حقيقي. أمر npm test هنا يفترض أن هذا المشروع الافتراضي يعرّف بالفعل script بهذا الاسم في package.json؛ في مشروعك الفعلي استخدم أمر الفحص المعتمد لديك، أو اطلب من النموذج اكتشافه إن لم تكن متأكدًا منه.
برومبت تصحيح خطأ مع دليل على سببه
الفرق الجوهري في هذا القالب عن سابقه: هو يطلب من النموذج تشخيصًا مستندًا إلى الكود والسجل، لا تخمينًا سريعًا يزيل العرض دون معالجة السبب.
المشكلة: [وصف الخطأ كما يظهر للمستخدم أو في الواجهة]
خطوات إعادة الإنتاج:
1. [خطوة]
2. [خطوة]
3. [النتيجة التي تظهر]
السلوك المتوقع: [ما كان يجب أن يحدث]
السلوك الفعلي: [ما يحدث فعلاً]
الأدلة المرفقة:
- رسالة الخطأ أو سجل التنفيذ (بعد حذف أي مفاتيح أو بيانات حساسة): [الصق السجل هنا]
- الملفات التي تظن أنها مرتبطة، إن عرفتها: [قائمة، أو اترك فارغًا واطلب من النموذج تحديدها]
المطلوب منك:
- افحص الملفات ذات الصلة وحدد السبب الأرجح استنادًا إلى الكود والسجل، وليس تخمينًا عامًا.
- إن تعذّر عليك تأكيد السبب من المعطيات المتاحة، صرّح بذلك واطلب معلومة إضافية بدل افتراض حل.
- طبّق أصغر تعديل يعالج السبب الجذري، دون تغيير سلوك غير متعلق بالمشكلة.
- أعد تشغيل [أمر الفحص]. إذا لم تكن متأكدًا منه، اكتشفه من إعدادات المشروع بدل افتراضه، وصرّح إن تعذّر تشغيله بدل ادعاء النجاح.
- أضف اختبارًا جديدًا يمنع تكرار الخطأ، إن كانت بنية المشروع تحتوي فحوصًا آلية.
سلّم: السبب الذي توصلت إليه ودليله، التعديل الذي طبّقته، ونتيجة إعادة الفحص.لاحظ البند الخاص بالتصريح عند عدم التأكد: هذا البند يطلب من النموذج إظهار عدم اليقين بدل إخفائه. لا يوجد برومبت يضمن اكتشاف السبب الصحيح دائمًا؛ القالب يطلب إظهار عدم اليقين وتقديم دليل على التشخيص؛ وتظل صحة الإجابة بحاجة إلى التحقق.
برومبت إعادة الهيكلة مع الحفاظ على السلوك
إعادة الهيكلة (Refactoring) تختلف عن إصلاح خطأ أو إضافة ميزة: الهدف هنا تحسين البنية الداخلية للكود دون أن يتغير أي شيء من منظور من يستخدمه. هذا القالب يفصل بوضوح بين ما يجب أن يبقى ثابتًا وما يمكن تغييره.
الهدف: إعادة هيكلة [اسم الدالة/الوحدة/الملف] دون تغيير سلوكه الظاهري.
ما يجب أن يبقى ثابتًا تمامًا:
- المخرجات لكل المدخلات الحالية.
- الواجهة العامة (أسماء الدوال/التوابع المستخدمة من خارج هذا الملف): [قائمة إن وجدت]
- سلوك الحالات الخاصة التالية: [اذكرها إن كانت معروفة]
ما يمكن تغييره بحرية:
- التنظيم الداخلي، التسمية، تقسيم الدوال، إزالة التكرار، تبسيط الشروط.
النطاق:
- التزم فقط بـ: [قائمة الملفات]
- لا تُصلح أخطاء ولا تُضِف ميزات في نفس الوقت؛ إن لاحظت مشكلة منفصلة اذكرها في الملخص النهائي ولا تعالجها هنا.
قبل البدء:
- اقرأ الفحوص الحالية المرتبطة بهذا الجزء إن وجدت. إن كانت غير كافية لتغطية السلوك الحالي، أخبرني قبل المتابعة بدل الاعتماد على تخمين أنها كافية.
بعد التعديل:
- شغّل [أمر الفحص]. إذا لم تكن متأكدًا منه، اكتشفه من إعدادات المشروع بدل افتراضه. تأكد أن كل الفحوص القائمة تنجح دون تعديل محتواها لتمريرها قسرًا، وصرّح إن تعذّر تشغيل أي فحص بدل ادعاء النجاح.
- إن أمكن، قارن مخرجات عيّنة من الحالات قبل التعديل وبعده.
سلّم: ملخص ما تغيّر داخليًا فعلاً، نتيجة الفحص، وأي جزء لم تتمكن من التحقق منه بثقة.تنظيف الكود وتحسين سرعته ليسا الشيء نفسه؛ إن كان هدفك تحسين الأداء فهذا يحتاج قياسًا فعليًا (زمن تنفيذ، استهلاك ذاكرة) خارج نطاق هذا القالب، لا وعدًا ضمنيًا بأن إعادة الهيكلة تُسرّع الكود تلقائيًا.
استخدام برومبتات دقيقة داخل Cursor وClaude Code هو أحد التطبيقات العملية لما يعرف باسم Vibe Coding أو البرمجة بالذكاء الاصطناعي، حيث يتحول وصفك للمهمة إلى خطوات وكود قابل للتنفيذ.
كيف تكيّف القوالب مع Cursor وClaude Code؟
جوهر المهمة في القوالب الثلاثة أعلاه لا يتغير بين الأداتين؛ ما يتغير هو كيفية إعطاء السياق الدائم للمشروع، لأن كل أداة تقرأ تعليماتها من موقع مختلف.
تعليمات المشروع في Cursor
يوثّق دليل Cursor الرسمي للقواعد (Rules) طريقة تنظيم تعليمات المشروع داخل مجلد .cursor/rules/ باستخدام ملفات بامتداد .mdc. سنستخدم هذه الصيغة في النموذج التالي، مع تحديد نطاق الملفات التي تنطبق عليها التعليمات.
كل ملف .mdc يحمل ترويسة (frontmatter) تحدد وصفه ونطاق تطبيقه (globs) ونوع تفعيله. حسب الوثائق الرسمية، تفعيل alwaysApply: true يجعل القاعدة تُحمَّل دائمًا بغض النظر عن globs؛ أما alwaysApply: false مع تحديد globs فيجعل القاعدة من نوع «Auto Attached»: تُرفَق عندما يعمل النموذج على ملفات تطابق النمط المحدد، لا مع كل برومبت بلا شرط.
احفظ النموذج التالي في: .cursor/rules/project-quality.mdc
---
description: إرشادات العمل على ملفات TypeScript في هذا المثال
globs: src/**/*.ts, src/**/*.tsx
alwaysApply: false
---
- اتبع أنماط المشروع الموجودة قبل اقتراح أسلوب جديد.
- افحص إعدادات المشروع لمعرفة أوامر التحقق المتاحة؛ لا تفترض وجود أمر بعينه.
- اذكر ما غيّرته وما فحصته وما تعذر فحصه.نطاق TypeScript في هذا المثال خاص به وحده؛ غيّره وفق لغة مشروعك وامتداداته. هذا نموذج توضيحي لبنية الملف لم يُختبر تشغيله فعليًا داخل Cursor في إطار هذا الدليل.
وقبل إعداد قواعد المشروع والبرومبتات، من المفيد التعرف على أحدث مميزات Cursor AI وكيف يتعامل المحرر مع المشاريع والوكلاء ونماذج الذكاء الاصطناعي المختلفة.
تعليمات المشروع في Claude Code
وفق توثيق الذاكرة (Memory) في Claude Code، يقرأ Claude Code ملف CLAUDE.md (في جذر المشروع أو داخل .claude/CLAUDE.md) في بداية كل جلسة، ويحمل تعليمات ثابتة مثل أوامر الفحص، وقواعد أسلوب الكود، وبنية المشروع. لمشاريع كبيرة يمكن تقسيم التعليمات إلى ملفات متعددة داخل .claude/rules/. التوثيق نفسه يوضح أن هذا المحتوى يُحمَّل كسياق يوجّه سلوك النموذج، وليس طبقة تنفيذ صلاحيات صارمة؛ التعليمات الأكثر تحديدًا واختصارًا هي الأكثر التزامًا بها عمليًا.
# تعليمات المشروع
## تعريف المشروع
- الغرض: [وصف مختصر]
- راجع ملف الإعداد أو التوثيق المعتمد: [المسار الفعلي]
## الفحص
- أمر الفحص المعتمد إن كان معروفًا: [الأمر الفعلي أو غير محدد]
- إن لم يُحدد، افحص إعدادات المشروع واستخدم الفحوص المتاحة ذات الصلة.
- إذا تعذر الفحص، صرّح بالسبب ولا تدّع نجاحه.
## حدود المهمة
- حافظ على التغييرات القائمة غير المتعلقة بالمهمة.
- المسارات المستثناة إن وجدت: [المسارات الفعلية أو لا يوجد]
- اتبع مدير الحزم والأنماط المعتمدة في المشروع؛ لا تفترضها.هذا نص إرشادي مقترح تملأ حقوله المربعة [ ] أو تحذف ما لا ينطبق منها قبل الاستخدام، وليس إعدادًا يفرض صلاحيات تقنية. لم يُختبر تشغيله فعليًا داخل الأداة في إطار هذا الدليل.
وتعتمد جودة نتائج Claude Code أيضًا على فهم إمكانات نماذج Claude واختيار النموذج المناسب للمهمة؛ ويمكنك الرجوع إلى دليل Claude AI ونماذجه واستخدامه في البرمجة لمعرفة الفروق بالتفصيل.
اختيار النموذج المناسب ونمط التفكير (Reasoning)
تتأثر مدى استجابة هذه القوالب وقدرتها على تطبيق القيود بالنموذج البرمجي (Model) المعتمد خلف الكواليس داخل Cursor أو Claude Code. المهام البرمجية الروتينية (مثل إضافة مكون بسيط أو تصحيح خطأ سطحي) تعمل بكفاءة مع النماذج السريعة والمعيارية.
أما المهام المعقدة التي تتطلب استيعابًا عميقًا للبنية التحتية — مثل إعادة هيكلة ملفات متعددة (Refactoring) أو تتبع أخطاء غامضة (Complex Debugging) — فتستفيد بشكل جوهري من استخدام نماذج التفكير المتقدمة (مثل Claude 3.7 Sonnet المدمج مع ميزة التفكير Extended Thinking، أو نماذج OpenAI المخصصة للاستدلال).
توجيه البرومبت لنماذج التفكير يتيح للنموذج فحص كافة الاحتمالات وسلسلة الأسباب قبل توليد أي كود، مما يقلل احتمالية التعديل الخاطئ. ولا يقتصر الاختيار على Cursor وClaude Code؛ فإذا كنت تريد مقارنة الخيارات المتاحة، راجع دليل أفضل أدوات الذكاء الاصطناعي للبرمجة لمعرفة الأنسب لكتابة الكود وتصحيح الأخطاء وتحسين الإنتاجية.
ما الذي يتغير فعليًا عند نقل القالب بين الأداتين؟
| الجانب | Cursor | Claude Code |
|---|---|---|
| الواجهة | محرر كود مبني على VS Code، تفاعل داخل الملفات المفتوحة | أداة سطر أوامر (CLI) أساسًا، إلى جانب واجهات إضافية مثل امتداد المحرر وتطبيق سطح المكتب |
| ملف تعليمات المشروع | .cursor/rules/*.mdc في النموذج المستخدم هنا | CLAUDE.md أو .claude/rules/*.md |
| تنفيذ الأوامر والفحوصات | عبر الطرفية المدمجة في المحرر، بموافقة أو تلقائيًا حسب الإعداد | مباشرة من سطر الأوامر (Bash)، بموافقة أو تلقائيًا حسب إعداد الصلاحيات |
| استكشاف ملفات المشروع | وضع Agent يستكشف شجرة المشروع تلقائيًا (بحث وقراءة ملفات)، إلى جانب الإشارة المباشرة لملفات محددة عبر رموز مثل @ | يقرأ ويبحث في شجرة المشروع وفق الحاجة أثناء التنفيذ |
كلتا الأداتين قادرة على تعديل الكود، والبحث في ملفات المشروع، وتشغيل أوامر الطرفية، ضمن حدود الصلاحيات التي تُمنح لها؛ راجع توثيق Agent في Cursor ونظرة عامة على Claude Code للتفاصيل. تركيز هذا الجدول على واجهة الطرفية عند شرح Claude Code لا يعني اقتصار الأداة عليها؛ الجدول مقارنة تشغيلية مختصرة، لا مقارنة أداء أو سرعة أو تفوّق. لم يُجرَ أي قياس من هذا النوع في إطار هذا الدليل.
وإذا كنت تفضل مساعدًا مدمجًا في بيئة التطوير بدل الاعتماد الكامل على Cursor أو Claude Code، يمكنك الاطلاع على تجربتنا مع GitHub Copilot وهل يستحق الاشتراك في 2026.
كيف تراجع التعديل قبل الاعتماد عليه؟
ملف التعليمات (سواء .cursor/rules أو CLAUDE.md) يوجّه سلوك النموذج، لكنه لا يمنعه تقنيًا من الخطأ أو من تجاوز ما طلبته. المراجعة اليدوية بعد كل تعديل تبقى ضرورية، ولا يوجد برومبت يلغي هذه الحاجة. استخدم هذه القائمة بعد أي تعديل تلقائي كبير:
- راجع الملفات المتغيرة فعليًا: هل التعديل اقتصر على النطاق الذي حددته في البرومبت؟
- شغّل الفحوص المناسبة وراجع نتائجها بنفسك، ولا تكتفِ بجملة “الفحوص نجحت” من النموذج دون رؤية المخرجات.
- قارن النتيجة بمعيار القبول الذي كتبته في البرومبت، لا بانطباع عام أن الكود “يبدو صحيحًا”.
- احفظ نسخة من العمل القائم قبل التعديلات الكبيرة (commit أو نسخة احتياطية)، حتى تستطيع التراجع بسهولة.
- لا تشارك أسرارًا أو مفاتيح API داخل البرومبت أو السجلات الملصقة فيه.
- اطلب ملخصًا للقرار والدليل بعد التعديل (ما الذي تغيّر ولماذا)، بدل طلب سرد مطوّل للتفكير الداخلي للنموذج.
وأخيرًا: صلاحيات تنفيذ الأوامر تلقائيًا (سواء في Cursor أو Claude Code) ميزة مفيدة لتسريع العمل، لكنها تقلل الفرصة لمراجعة كل خطوة قبل تنفيذها. راجع إعدادات الصلاحيات في كل أداة بشكل مستقل عن ملف التعليمات؛ الاثنان يخدمان غرضين مختلفين وفق توثيق الصلاحيات في Claude Code: التعليمات توجّه السلوك، والصلاحيات تضبط ما يُسمح للنموذج فعله دون موافقتك.
اقرأ أيضًا
إذا كنت تريد الانتقال من كتابة البرومبتات إلى بناء مشاريع أكثر تقدمًا بالذكاء الاصطناعي، فهذه الأدلة ستساعدك:
- شرح AI Agents: كيف تعمل وكيف تبني أول وكيل ذكي في 2026
- كيف تحول فكرتك إلى تطبيق بالذكاء الاصطناعي؟ أفضل أدوات Prompt-to-App
- سكربت بايثون لكتابة مقالات متوافقة مع السيو 2026 [دليل عملي + أكواد جاهزة]
خلاصة: من برومبت إلى مراجعة
القوالب الثلاثة أعلاه — لكتابة ميزة، وتصحيح خطأ، وإعادة هيكلة — تغطي معظم ما تحتاجه برومبتات Cursor وClaude Code اليومية في مشروع قائم. الفرق بين نتيجة مفيدة وأخرى تحتاج إصلاحًا لا يصنعه طول البرومبت، بل وضوح المهمة والنطاق ومعيار القبول فيه، إلى جانب ملف تعليمات يناسب أداتك (سواء .cursor/rules في Cursor أو CLAUDE.md في Claude Code).
الخطوة التالية المنطقية ليست حفظ القوالب، بل تجربتها على مهمة صغيرة في مشروعك، ومراجعة التعديل والفحوص بنفسك قبل أن تعتمد عليه. عدّل الحقول بين الأقواس المربعة وفق حالتك، وابدأ بالقالب الأقرب لما تعمل عليه الآن.
