توجيهات «Claude Code»: 25 توجيهًا جاهزًا للنسخ وكيفية كتابة توجيهاتك الخاصة

يتلقى العملاء الذين يستخدمون قسيمة منتهية الصلاحية خطأً برقم 500 عند إتمام عملية الدفع. افحص ملف @src/checkout/coupons.ts واختباراته. السلوك المتوقع هو ظهور رسالة تفيد بأن القسيمة غير صالحة دون إنشاء طلب شراء. اكتب اختبارًا فاشلًا يعيد إنتاج الخطأ، ثم أصلحه دون تغيير سلوك «القسيمة الصالحة». قم بتشغيل [أمر اختبار الدفع] واعرض النتائج قبل وبعد. إذا لم تتمكن من إعادة إنتاج الخطأ، فقم بالإبلاغ عما قمت بفحصه قبل تغيير التنفيذ.

أضف أداة اختيار التاريخ إلى [مسار نموذج الحجز]. اتبع قواعد المكونات والتحقق من الصحة الموجودة في @src/components/TimeSelect.tsx. يجب أن يتمكن المستخدمون من اختيار [التواريخ المسموح بها]، بينما تظل [التواريخ غير المتاحة] معطلة. لا تضف أي مكتبات. قم بتشغيل [أمر اختبار المكون] و[أمر التحقق من النوع]، وأبلغ عن أي معايير لا تغطيها تلك الفحوصات.

قسّم ملف @src/reports/export.py إلى دوال أصغر مع الحفاظ على مدخلاته وتنسيق مخرجاته وسلوكه في حالة حدوث أخطاء. قم بتشغيل [أمر اختبار التصدير] قبل التعديل وأبلغ عن أي أخطاء موجودة. بعد إعادة الهيكلة، أعد تشغيل الاختبارات واعرض كلا النتيجتين. لا تغير الواجهة العامة أو الملفات غير ذات الصلة.

“يقوم Claude باختبار كل تغيير أقوم بإدخاله على claude.ai/code باستخدام ملحق Claude لمتصفح Chrome. فهو يفتح المتصفح، ويختبر واجهة المستخدم، ويكرر العملية حتى يعمل الكود وتصبح تجربة المستخدم جيدة. ”

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

راجع سجل Git الخاص بـ [ملف أو دالة أو فئة]، مع التركيز على [سؤال يتعلق بالسلوك أو التصميم]. حدد عمليات التسجيل التي أدخلت هذا السلوك أو غيرته بشكل جوهري. بالنسبة لكل عملية تسجيل ذات صلة، قدم رمز التجزئة الخاص بها، ولخص التغيير، وشرح أي مبررات موثقة في رسالة التسجيل أو المناقشة المرتبطة بها التي يمكنك الوصول إليها. قم بتصنيف الأسباب المستنتجة على أنها استنتاجات. إذا كان السجل لا يفسر قرارًا ما، فاذكر ذلك. لا تقم بتعديل الملفات أو سجل Git.

تتبع ما يحدث عند [إجراء المستخدم أو حدث النظام]، بدءًا من [مسار معروف أو معالج أو مجلد]. تابع الاستدعاءات ذات الصلة عبر عمليات التحقق من الصحة، ومنطق الأعمال، وأي عمليات كتابة في قاعدة البيانات أو طلبات خارجية. قم بإدراج الملفات والوظائف بترتيب التنفيذ، مع الإشارة إلى أرقام الأسطر حيثما أمكن. اشرح مسارات الفشل الرئيسية وحدد الاختبارات الحالية التي تغطي مسار التنفيذ. ضع علامة على أي اتصال لا يمكنك تأكيده من الكود. لا تقم بتنفيذ المسار، أو استدعاء خدمات خارجية، أو تعديل الملفات.

خطط لكيفية تنفيذ [الميزة] في [منطقة المستودع]. السلوك المتوقع هو [المتطلبات]، ويجب أن تظل هذه المجالات دون تغيير: [القيود]. افحص الكود ذي الصلة والاختبارات الحالية. حدد الملفات التي تحتاج إلى تغيير، وترتيب التنفيذ، وأي مخاطر تتعلق بالتوافق أو ترحيل البيانات. ربط كل متطلب باختبار مقترح أو خطوة تحقق أخرى. أدرج الأسئلة والافتراضات التي لم يتم حلها بشكل منفصل. لا تقم بتنفيذ الميزة بعد. أرسل الخطة إليّ لمراجعتها.

أريد إنشاء [وصف موجز] لـ [المستخدمين وحالة الاستخدام]. اقرأ [الملفات أو المتطلبات ذات الصلة] أولاً، ثم استخدم AskUserQuestion لتوضيح القرارات التي من شأنها أن تؤثر بشكل جوهري على التنفيذ. ركز على الحالات الاستثنائية، ومعالجة البيانات، والأذونات، والسلوك المتوقع لواجهة المستخدم، والمفاضلات. لا تطرح أسئلة يجيب عليها السياق المقدم بالفعل. بمجرد حسم القرارات الرئيسية، قم بصياغة مواصفات تغطي المتطلبات ومعايير القبول والقيود وما هو خارج النطاق. ضع علامة على أي افتراضات متبقية. أرني المواصفات قبل حفظها في [مسار المواصفات]، ولا تقم بالكتابة فوق ملف موجود دون موافقة.

قم بتقييم تأثير تغيير [وظيفة أو مكون أو واجهة] من [السلوك الحالي] إلى [السلوك المقترح]. ابحث في [نطاق المستودع أو الدليل] عن تعريفها، والمستدعين المباشرين، وعمليات الاستيراد، والاختبارات ذات الصلة. قم بإدراج الملفات التي من المحتمل أن تحتاج إلى تغييرات وشرح كيف يمكن أن يتأثر كل منها، مع الإشارة إلى الملف والسطر حيثما كان ذلك متاحًا. قم بتمييز المكالمات التي يتم حلها ديناميكيًا، أو المستخدمين الخارجيين، أو التبعيات الأخرى التي لا يمكنك التحقق منها. حدد أي مسائل تتعلق بالتوافق تحتاج إلى إجابة قبل التنفيذ. لا تقم بتغيير الملفات؛ أرسل تقييم التأثير وانتظر مراجعتي.

أضف [الميزة] إلى [الملف أو الصفحة] مع هذا السلوك: [معايير القبول]. افحص [التنفيذ الحالي] واتبع قواعده فيما يتعلق بجلب البيانات، ومعالجة الأخطاء، وتنظيم المكونات. استخدم فقط المكتبات المثبتة بالفعل في المشروع. حافظ على التغييرات ضمن [النطاق] وحافظ على [السلوك الحالي أو الواجهة العامة]. أضف أو حدّث الاختبارات الخاصة بمعايير القبول. شغّل [أمر الاختبار] و[أمر التحقق من النوع أو lint]، ثم أبلغ عن الملفات التي تم تغييرها والنتائج وأي فحوصات لم تتمكن من إكمالها. إذا تعارض النمط الحالي مع أحد المتطلبات، فاشرح هذا التعارض قبل المتابعة.

قم بتنفيذ [اسم الدالة] في [الملف] لتلبية [المتطلبات]. قم بتغطية [الحالة العادية] و[الحالة الاستثنائية] و[سلوك المدخلات غير الصالحة]. قم بتشغيل [أمر الاختبار ذي الصلة] أولاً وأبلغ عن أي حالات فشل موجودة. اكتب اختبارات للسلوك المطلوب، ثم قم بتشغيلها قبل التنفيذ. تأكد من فشل الاختبارات الجديدة للسبب المتوقع. قم بتنفيذ الدالة وأعد تشغيل الاختبارات. لا تضعف التأكيدات، ولا تتخطى الاختبارات، ولا تغير السلوك المتوقع لجعلها تنجح. إذا تعارضت المتطلبات مع الاختبارات الحالية، فتوقف وشرح التعارض. اعرض النتائج قبل وبعد.

قم بتنفيذ التصميم المرفق في [المكون أو الصفحة]، باستخدام المكونات والأنماط الموجودة في المشروع. حافظ على [السلوك المطلوب] وتجنب إجراء تغييرات خارج [النطاق]. استخدم [المتصفح المُهيأ أو أداة التقاط الشاشة] لالتقاط [المسار المحلي] عند [أبعاد نافذة العرض] مع [بيانات الاختبار وحالة واجهة المستخدم]. إذا كانت الأداة أو التطبيق غير متاحين، فقم بالإبلاغ عما هو مطلوب بدلاً من الادعاء بإجراء فحص بصري. قارن اللقطة مع المرجع، مع التركيز على [التخطيط، أو التباعد، أو الطباعة، أو معايير القبول الأخرى]. قم بما يصل إلى [عدد] جولات تصحيح، ثم أبلغ عن الاختلافات المتبقية. لا تقم بتعديل الصورة المرجعية. قم بتشغيل [اختبارات المكونات ذات الصلة] و[أمر فحص النوع أو البناء]. قم بتضمين لقطة الشاشة الملتقطة ونتائج الفحص الفعلية في ملخصك.

يواجه المستخدمون [الأعراض] عند [المحفز أو المدخلات]. السلوك المتوقع هو [النتيجة المتوقعة]. ابدأ بفحص [المجلد أو الدالة أو المسار] والاختبارات ذات الصلة. أنشئ اختبارًا فاشلًا يعيد إنتاج السلوك المبلغ عنه. إذا لم تتمكن من إعادة إنتاجه، فاشرح ما قمت بفحصه والمعلومات الناقصة قبل تغيير التنفيذ. بمجرد إعادة إنتاجه، قم بإصلاح السبب دون تغيير [السلوك الذي يجب أن يظل كما هو]. قم بتشغيل الاختبار الجديد و[أمر الاختبار ذي الصلة]. اعرض الفشل قبل الإصلاح، والنتائج بعده، وأي حالات فشل متبقية.

[أمر البناء] يفشل في [البيئة المحلية أو بيئة التكامل المستمر (CI)] مع ظهور هذا الناتج: [سجل الأخطاء المُعالج]. افحص الكود والإعدادات ذات الصلة لتحديد السبب. تحقق من وجود اختلافات في البيئة أو التبعيات إذا لم يتكرر الفشل محليًّا. قم بإجراء أقل تغيير ممكن يعالج السبب. لا تقم بتعطيل عمليات الفحص، أو إخفاء الأخطاء، أو تخطي الاختبارات، أو تخفيف إعدادات المُجمِّع لمجرد الحصول على عملية بناء ناجحة. أعد تشغيل عملية البناء بعد التغيير. إذا استمر الفشل بعد [عدد] محاولات إصلاح، فتوقف وأبلغ عما حاولت فعله، والخطأ الحالي، والخطوة التشخيصية التالية. لخص السبب وأرفق نتيجة عملية البناء الفعلية.

ساعدني في تحديد الخلل بدقة قبل اقتراح حل. السلوك الملحوظ: [ما يحدث] السلوك المتوقع: [ما ينبغي أن يحدث] متى يحدث: [الشروط أو التكرار] ما جربته: [الخطوات والنتائج] اطرح سؤالًا واحدًا في كل مرة، واختر السؤال الذي يميز بشكل أفضل بين الأسباب المحتملة. لا تكرر الأسئلة التي تجيب عليها المعلومات المقدمة بالفعل. بمجرد توفر أدلة كافية، لخص التفسير الأرجح، وما يظل غير مؤكد، وأصغر اختبار يمكنه تأكيد ذلك أو استبعاده. لا تقم بتعديل الملفات بعد.

استخدم وكيلًا فرعيًّا لمراجعة [الاختلافات أو الفرع مقارنةً بالأساس] مقابل [الخطة المعتمدة أو ملف المتطلبات]. إذا كانت المتطلبات مفقودة أو غامضة، فقم بالإبلاغ عن ذلك قبل تقييم الاكتمال. تحقق مما إذا كان كل متطلب قد تم تنفيذه، وما إذا كانت الحالات الحدية ذات الصلة خاضعة للاختبارات، وما إذا كانت أي تغييرات تقع خارج النطاق المتفق عليه. افحص الكود المحيط عند الحاجة لفهم الاختلاف. أبلغ عن مشكلات الصحة والمتطلبات غير المستوفاة مع الإشارة إلى الملف والسطر، وتأثيرها، والأدلة الداعمة لكل نتيجة. افصل المشكلات المؤكدة عن الأسئلة التي لم يتم حلها. لا تختلق نتائج لملء حصة أو تضمين تفضيلات أسلوبية غير ذات صلة. لا تقم بتحرير الملفات.

راجع [الملفات أو الفروق] بحثًا عن مخاطر الحقن، وفحوصات التفويض المفقودة، والأسرار المكشوفة، والتعامل غير الآمن مع مدخلات المستخدم. افحص المستدعين ذوي الصلة ومنطق التحقق من الصحة قبل الإبلاغ عن أي اكتشاف. بالنسبة لكل مشكلة، حدد الملف والأسطر المتأثرة، والشروط اللازمة لتفعيلها، والتأثير المحتمل، والإصلاح المقترح. ميز بين المسار الذي تم تأكيد وجود ثغرة فيه وبين المشكلة التي تحتاج إلى مزيد من الاختبار. لا تكرر القيم السرية في التقرير، ولا تُعدّل الملفات، ولا تُجرِ اختبارات على الخدمات الحية. اذكر المجالات التي قمت بمراجعتها وما الذي يبقى خارج نطاق المراجعة.

لخص كيفية التحقق من التغيير المكتمل مقابل [معايير القبول]. بالنسبة لكل معيار، اذكر الفحص الذي تم إجراؤه، والأمر الدقيق عند الاقتضاء، والنتيجة التي تمت ملاحظتها. قم بتضمين المخرجات ذات الصلة، مع حجب المعلومات السرية والبيانات الحساسة. حدد أي حالات فشل موجودة مسبقًا بشكل منفصل. ميز بوضوح بين الفحوصات التي نجحت، وتلك التي فشلت، وتلك التي لم يتم إجراؤها. اشرح أي فحوصات تم تخطيها أو أي قيود في التغطية. لا تصف التغيير بأكمله على أنه تم التحقق منه إذا بقيت بعض المعايير دون فحص.

أعد هيكلة [ملف أو وحدة] لتحقيق [هدف محدد، مثل تقسيم دالة كبيرة أو إزالة الاستدعاءات المتداخلة]. حافظ على واجهته العامة وقيم الإرجاع وسلوك الأخطاء والآثار الجانبية. قم بتشغيل [أمر الاختبار ذي الصلة] قبل التعديل لإنشاء خط أساس. إذا فشل، فقم بالإبلاغ عن حالات الفشل قبل المتابعة. حدد أي سلوك لا تغطيه الاختبارات الحالية وأضف اختبارات مركزة عند الحاجة. قم بإعادة الهيكلة دون إجراء تغييرات غير ذات صلة أو تبعيات جديدة. لا تضعف التأكيدات الحالية لتتناسب مع التنفيذ. أعد تشغيل الاختبارات و[أمر التحقق من النوع أو lint]. اعرض النتائج قبل وبعد، ولخص التغييرات الهيكلية، وقم بتمييز أي سلوك لم تتمكن من التحقق منه.

ابحث عن استخدامات [واجهة برمجة التطبيقات أو المكتبة القديمة] ضمن [نطاق الدليل]، باستثناء الملفات التي تم إنشاؤها تلقائيًا والملفات الموردة من الجهات الخارجية. قم بإدراج الملفات المتأثرة وأي تكوينات أو تبعيات مشتركة قد تتأثر بعملية الترحيل. اقترح ثلاثة ملفات تمثيلية لإجراء ترحيل تجريبي إلى [واجهة برمجة التطبيقات أو الإصدار الجديد]، باستخدام [دليل الترحيل أو مثال موجود]. اشرح سبب اختيارك لهذه الملفات وأشر إلى أي تغييرات مطلوبة في السلوك. انتظر موافقتي قبل التعديل. بعد الموافقة، قم بترحيل الملفات التجريبية فقط وأي تبعيات مشتركة تمت الموافقة عليها صراحةً. قم بتشغيل [الاختبارات ذات الصلة] و[أمر البناء أو فحص النوع]. لا توسع نطاق الترحيل ليشمل ملفات أخرى. أبلغ عن الاختلافات ونتائج الاختبارات ومشكلات التوافق وأي تغييرات مطلوبة في نهج الترحيل. توقف للمراجعة قبل متابعة الملفات المتبقية.

افحص الفرع الحالي وحالة Git وفروق [الميزة أو الإصلاح]. حدد الملفات التي تنتمي إلى هذا التغيير وقم بإدراج الملفات غير ذات الصلة أو غير المتعقبة بشكل منفصل. قم بصياغة رسالة التزام تتبع تنسيق آخر 10 التزامات. قم بإعداد وصف لطلب السحب يشمل ما تم تغييره، والسبب، والاختبارات التي تم إجراؤها فعليًا، وأي قيود متبقية. اعرض قائمة الملفات المقترحة ورسالة الالتزام ووصف طلب السحب قبل وضع أي شيء في مرحلة الاستعداد أو نشره. انتظر موافقتي. بعد الموافقة، ضع في مرحلة الاستعداد الملفات المتفق عليها فقط، وقم بالالتزام على [فرع الميزة]، وقم بالدفع إلى [البعيد]، وافتح طلب سحب مقابل [فرع الأساس]. لا تقم بتعديل عمليات الالتزام الحالية، أو الدفع القسري، أو الدمج. أرسل هاش الالتزام ورابط طلب السحب.

قم بصياغة قسم «README» لـ [الوحدة النمطية] موجهًا إلى [القارئ، مثل مهندس البنية الخلفية الذي ينضم إلى المشروع]. قم بتغطية المتطلبات الأساسية، والإعداد، والأوامر الثلاثة التي سيستخدمونها أكثر من غيرها، والأخطاء الشائعة التي يدعمها الكود أو الوثائق الموجودة. تحقق من أسماء الأوامر وخياراتها بمقارنتها بـ [نصوص الحزمة، أو ملف Makefile، أو تعليمات واجهة سطر الأوامر، أو تكوين التكامل المستمر]. ضع علامة على أي شيء لا يمكنك تأكيده. اختبر الأوامر المحلية الآمنة في [بيئة الاختبار] حيثما كانت متاحة. قبل تشغيل الأوامر التي تقوم بتثبيت التبعيات، أو حذف الملفات، أو ترحيل البيانات، أو النشر، أو الوصول إلى الخدمات الخارجية، اشرح آثارها واطلب الموافقة. ميز بوضوح بين الأوامر التي قمت بتشغيلها بنجاح والأوامر التي تم التحقق منها فقط مقابل التكوين أو الوثائق. اعرض قسم README المقترح قبل تحرير [مسار الوثائق]، واحتفظ بالمحتوى غير ذي الصلة.

راجع [مسار إلى CLAUDE.md] مقارنةً بالهيكل الحالي للمستودع، والنصوص البرمجية، والاصطلاحات. لا تقم بتحرير الملف بعد. حدد التعليمات القديمة، والتكرارات، والتناقضات، والقواعد التي يمكن استنتاجها بشكل موثوق من الكود. اشرح كل حذف مقترح بدلاً من حذف التعليمات لمجرد تقصير الملف. اقترح أوامر البناء أو الاختبار المفقودة فقط عندما يمكنك التحقق منها في نصوص المشروع البرمجية، أو ملف Makefile، أو تكوين التكامل المستمر (CI)، أو الوثائق الموجودة. اذكر المصدر لكل إضافة. أرسل ملف diff مقترحًا يحافظ على قيود المشروع المهمة. ضع علامة على التعليمات الخاصة بالمهام التي قد تكون أكثر ملاءمة في قاعدة نطاق مهارة أو مسار، وانتظر الموافقة قبل تطبيق التغييرات.

اقترح ربطًا لأمر Claude Code يقوم بتشغيل [أمر المنسق الحالي] بعد إجراء تغييرات «تحرير» أو «كتابة» على [أنماط الملفات]. افحص أولاً التكوين الحالي في ملف claude/settings.json وتكوين المنسق. استخدم تكوين PostToolUse المناسب لإصدار Claude Code المثبت. قم بتنسيق الملف المتأثر فقط، وتعامل مع المسارات بأمان، واستبعد [الملفات التي تم إنشاؤها أو المسارات المستبعدة الأخرى]. لا تقم بتثبيت التبعيات أو استبدال الـhooks الموجودة. اعرض الفروق في الإعدادات المقترحة وشرح كيف سيتم الإبلاغ عن حالات فشل أداة التنسيق. انتظر الموافقة قبل تطبيقها. بعد الموافقة، اختبرها باستخدام ملف مؤقت في المشروع وأبلغ عن النتيجة. حدد مسارات التحرير التي تغطيها وتلك التي لا تغطيها، بما في ذلك التغييرات التي تم إجراؤها من خلال أوامر shell.

افحص [الأداة] –help والمساعدة الخاصة بالأوامر الفرعية ذات الصلة بـ [المهمة]. لا تقم بتثبيت الأداة إذا كانت مفقودة؛ بل قم بالإبلاغ عن هذا الشرط المسبق بدلاً من ذلك. اقترح الأوامر الدقيقة اللازمة لإكمال المهمة. اشرح مدخلاتها ومخرجاتها، وما إذا كانت تقوم بكتابة ملفات أو تغيير موارد بعيدة أو استخدام بيانات اعتماد. قم بتضمين خيار التشغيل التجريبي إذا كانت الأداة توثق ذلك. قم بالإبلاغ عن أي تكوينات أو أذونات مفقودة، واطلب توضيحًا بدلاً من التخمين بشأن أسماء الموارد أو وجهاتها. انتظر الموافقة قبل تشغيل أوامر المهمة. بعد الموافقة، قم بتشغيل الأوامر المتفق عليها فقط وأبلغ عن نتائجها الفعلية، بما في ذلك أي أخطاء أو خطوات غير مكتملة.

قارن بين [invoices.csv] و[payments.csv] باستخدام [معرف الفاتورة أو مفتاح المطابقة]. لا تقم بتعديل الملفات المصدرية. طبق القواعد التالية: [العملة وتفاوت التقريب]، و[تخصيص الدفعات الجزئية]، و[معالجة المبالغ المستردة والائتمانات والمبالغ الزائدة المدفوعة]. إذا كانت هناك قاعدة مفقودة أو كانت المطابقة غامضة، فقم بوضع علامة عليها بدلاً من تخصيص الدفعة تلقائيًا. احتفظ بمعرفات الصفوف المصدرية. بالنسبة لكل فاتورة، اعرض المبلغ المفوتر، والدفعات المطبقة، والرصيد المتبقي. أبلغ عن معرّفات مكررة، والفواتير غير المطابقة، والمدفوعات غير المطابقة، والأرصدة التي تتجاوز حدود التفاوت المسموح به. قم بمطابقة إجماليات الفواتير والمدفوعات بشكل منفصل. قم بحساب كل صف من الصفوف المصدرية دون احتساب مزدوج؛ إذا تم تقسيم دفعة ما على عدة فواتير، فاعرض كل تخصيص وتأكد من أن التخصيصات لا تتجاوز مبلغ الدفعة. اكتب النتائج في [مسارات الإخراج الجديدة] ولخص الاستثناءات التي تتطلب المراجعة.

اكتب برنامجًا نصيًّا يلخص ملف [export.csv] للفترة من [تاريخ ووقت البدء، شموليًا] حتى [تاريخ ووقت الانتهاء، استثناءً]، باستخدام [المنطقة الزمنية] و[عمود التاريخ]. قم بتجميع السجلات حسب [قواعد الفئات] واحسب [المقاييس المطلوبة]. تعامل مع المعرّفات المكررة والقيم المفقودة وفقًا لـ [القواعد]. لا تقم بتعديل ملف الإدخال. قم بتشغيل البرنامج النصي على [ملف الإدخال الدقيق]. قم بالإبلاغ عن عدد الصفوف المضمنة والمستبعدة، وإجماليات الفئات، والسجلات التي تعذر تصنيفها. قارن النتائج الخاصة بـ [ثلاث فئات] مع الأعداد التي تم التحقق منها بشكل مستقل في [ملف مرجعي]. إذا كانت هذه الأعداد غير متوفرة، فاذكر أن التحقق المستقل لا يزال معلّقًا. اعرض التباينات واحفظ التقرير في [مسار الإخراج الجديد].

اقرأ [الملفات أو المجلد المحدد] وقم بصياغة [نوع الوثيقة وطولها] لـ [الجمهور المستهدف]، بحيث تغطي [الأسئلة أو الموضوعات]. ادعم كل ادعاء واقعي مادي باسم الملف وإشارة إلى الصفحة أو القسم أو السطر، إن أمكن. ميز بين الاقتباسات المباشرة وإعادة الصياغة، ولا تعامل الاقتراح أو الوثيقة القديمة على أنها قرار حالي مؤكد. أشر إلى المصادر المتضاربة والمعلومات الناقصة والادعاءات التي لا يمكنك التحقق منها. لا تملأ الفجوات بالافتراضات ولا تقم بتعديل الملفات المصدرية. أعد المسودة مع مراجعها وقائمة قصيرة بالأسئلة التي لم يتم حلها للمراجع.

لتكييف القالب، استبدل العناصر النائبة فيه بتفاصيل من مشروعك وحدد ما يجب أن يفعله Claude قبل إجراء التغييرات. اتبع هذه الخطوات لإعداد الطلب ومراجعة النتيجة.

بالنسبة للتغييرات الصغيرة والمحددة جيدًا، يمكنك أن تطلب من Claude تنفيذها مباشرةً. أما بالنسبة للكود غير المألوف، أو التغييرات التي تشمل عدة ملفات، أو المتطلبات التي لم يتم حلها بعد، فابدأ بوضع خطة.

اضغط على Shift+Tab حتى يظهر وضع «التخطيط» (Plan)، أو قم بتشغيل Claude Code باستخدام الأمر claude --permission-mode plan. في هذا الوضع، يمكن لـ Claude فحص الملفات وتشغيل الأوامر للقراءة فقط دون تعديل كود المصدر الخاص بك. راجع الملفات والتبعيات والاختبارات المقترحة قبل الموافقة على التنفيذ. اضغط على Ctrl+G لفتح الخطة المقترحة في محررك.

زوّد كلود بالأدلة اللازمة لفهم المهمة: مرجع ملف، أو سجل أخطاء تم تنقيته، أو لقطة شاشة، أو وثيقة متطلبات. استخدم الرمز @ متبوعًا بمسار الملف لتضمين محتويات ذلك الملف.

اختر أصغر مجموعة مفيدة من المصادر. فقد يؤدي تضمين سجل أو دليل كامل إلى إضافة مواد غير ذات صلة واستهلاك السياق. قم بإزالة بيانات الاعتماد والبيانات الحساسة قبل مشاركة السجلات، وتأكد من أن Claude يمتلك الأدوات اللازمة لاسترداد أي عناوين URL للوثائق التي تقدمها.

على سبيل المثال، الأمر cat error.log | claude -p "Explain this error" يرسل سجلاً مع طلب غير تفاعلي. استخدمه فقط بعد التحقق من محتويات الملف. هذه هي القيمة العملية للذكاء الاصطناعي السياقي: تزويد النموذج بالمعلومات ذات الصلة بالمهمة.

عند إضافة ميزة، حدد مكونًا أو وظيفة مشابهة في المستودع. أخبر «كلود» بالمعايير التي يجب اتباعها، مثل عميل واجهة برمجة التطبيقات (API)، ومنطق التحقق من الصحة، ومعالجة الأخطاء، أو بنية الاختبار.

تمنح عبارة «اتبع كيفية قيام @src/widgets/Weather.tsx بجلب البيانات وتخزينها مؤقتًا» كلود مرجعًا ملموسًا. كما يجب تحديد أي اختلافات تتطلبها الميزة الجديدة حتى لا يتم نسخ سلوك لم يعد مناسبًا. يجب أن تعكس هذه القواعد سير عمل فريقك في تطوير البرمجيات.

بالنسبة لتغييرات الكود، حدد الأمر ذي الصلة للاختبار أو البناء أو lint والسلوك الذي يجب التحقق منه. بالنسبة للأبحاث، اطلب مراجع الملفات أو معرّفات الالتزامات. بالنسبة لأعمال واجهة المستخدم، قدم صورة مرجعية وطريقة مكونة لالتقاط التنفيذ في نفس نافذة العرض.

اطلب من «كلود» تقديم تقرير بما تم فحصه فعليًّا، بما في ذلك حالات الفشل وعمليات الفحص التي تم تخطيها. تحقق مما إذا كانت الأدلة تغطي المتطلبات؛ فنجاح عملية البناء لا يثبت أن كل سلوك مطلوب يعمل بشكل صحيح.

بالنسبة للمهام الأطول، يوفر Claude Code أيضًا شرط /goal و«Stop hooks». يقوم مُقيّم الهدف بتقييم الأدلة التي تظهر في المحادثة بدلاً من فحص الملفات أو إجراء الاختبارات بشكل مستقل. يمكن لـ«Stop hook» المُهيأ أن يمنع إتمام المهمة، ولكنه يخضع لقيود على الحجب المتكرر. ولا يحل أي منهما محل الاختبارات المناسبة والمراجعة البشرية.

إذا لم تؤدِ التصحيحات المتكررة إلى حل المشكلة، فتوقف وحدد ما الذي لم يتضح في الطلب الأصلي. احفظ النتائج المفيدة، وحالة Git الحالية، والعمل المتبقي قبل مسح المحادثة.

يوصي دليل أفضل الممارسات الصادر عن Anthropic بالبدء من جديد بعد محاولتين فاشلتين لتصحيح نفس المشكلة. استخدم الأمر /clear، ثم أدخل موجهًا منقحًا يتضمن ما تعلمته. لا يؤدي مسح المحادثة إلى التراجع عن التغييرات التي أُجريت على الملفات.

اضغط على مفتاح Esc لمقاطعة استجابة قيد التشغيل. عندما يكون حقل الإدخال فارغًا، اضغط على مفتاح Esc مرتين لفتح قائمة «الرجوع للخلف» واختيار ما تريد استعادته. لا تؤدي ميزة «الرجوع للخلف» إلى التراجع عن كل التأثيرات الخارجية، لذا استخدم نقاط فحص Git وإجراءات استعادة منفصلة للتغييرات التي تطرأ على قواعد البيانات أو الخدمات البعيدة.

احفظ الإرشادات الخاصة بالمشروع بأكمله في ملف CLAUDE.md، والإجراءات القابلة للتكرار في «المهارات»، والتعليمات الخاصة بملفات معينة في القواعد ذات نطاق المسار. استخدم «الخطافات» (hooks) للإجراءات المرتبطة بأحداث محددة، مثل تشغيل أداة التنسيق بعد إجراء تعديل.

اختر بناءً على الوقت الذي يجب أن تُطبق فيه التعليمات:

عادةً ما تنتمي متطلبات ميزة ما إلى موجه المهمة أو المواصفات الخاصة بها، وليس إلى ملف CLAUDE.md. وإضافة تعليمات مؤقتة إلى ملف يشمل المشروع بأكمله يجعل من الصعب تمييزها عن القواعد التي ينبغي تطبيقها في جميع أنحاء المستودع.

على سبيل المثال، احتفظ بأمر اختبار المشروع في ملف CLAUDE.md، وضع القواعد الخاصة بالمكونات في قاعدة ذات نطاق مسار، واحفظ إجراء المراجعة المتكرر كمهارة. راجع هذه الملفات عند تغيير الأوامر أو القواعد، تمامًا كما تفعل مع وثائق المشروع الأخرى.

تعمل المطالبات وملف CLAUDE.md ودليل المهارات على توجيه سلوك Claude؛ لكنها لا تضمن اتباع التعليمات. يمكن أن تقوم «الخطافات» (hooks) بإجراء فحوصات عند وقوع أحداث محددة، لكن موثوقيتها تعتمد على نوع الخطاف وطريقة تنفيذه.

يعمل «خطاف الأوامر» (command hook) على تشغيل برنامج نصي. أما «خطاف المطالبة» (prompt hook) أو «خطاف الوكيل» (agent hook) فيعتمد على تقدير النموذج. وكما يوضح دليل أفضل الممارسات الصادر عن شركة Anthropic: «يطلب خطاف المطالبة أو خطاف الوكيل من نموذج آخر اتخاذ القرار، لذا فهو ليس حتميًا أيضًا». بالنسبة للقاعدة التي يجب تطبيقها، استخدم ضوابط الأذونات المناسبة واختبر الأمر ذي الصلة أو خطاف HTTP، بما في ذلك كيفية تعامله مع حالات الفشل.

تعد الوكلاء الفرعيون المخصصون طريقة أخرى لتنظيم الأعمال المتكررة. قم بتعريف متخصص في claude/agents/ عندما تحتاج إلى دور مراجعة متميز أو نطاق أداة محدد، بدلاً من إضافة كل تعليمات المتخصص إلى الجلسة الرئيسية. توفر هذه الأدلة الخاصة بأفضل نموذج Claude للعمل وأنواع وكلاء الذكاء الاصطناعي سياقًا إضافيًا.

إذا كان فريقك يدير المطالبات عبر عدة منتجات للذكاء الاصطناعي، فاطلع على أدوات هندسة المطالبات هذه لإدارة المكتبات خارج نطاق Claude Code.

عندما تسفر جلسة العمل عن نتيجة غير مكتملة أو غير مناسبة، تحقق مما إذا كان الطلب قد ترك قرارات مهمة دون حل. فهذه الأخطاء الخمسة قد تجعل تشخيص المشكلة ومراجعتها أكثر صعوبة.

تمنح عبارة «تحقق من المستودع» كلود توجيهات قليلة بشأن الملفات المهمة أو متى يتوقف. وقد تتلقى ملخصًا عامًا دون إجابة على المشكلة التي دفعتك إلى إرسال الطلب.

حدد السلوك أو القرار الذي تحتاج إلى فهمه، وحدد نقطة البداية، وحدد الناتج المتوقع. على سبيل المثال: «تتبع كيفية قيام نقطة النهاية هذه بالتحقق من الأذونات واذكر الوظائف ذات الصلة». إذا كنت تستخدم وكلاء فرعيين، فاطرح على كل واحد منهم سؤالًا محددًا بدلاً من تفويضهم بنفس البحث غير المقيد.

التنقل بين ميزة ما، وخطأ غير ذي صلة، وطلب توثيق، يترك المحادثة محملة بسياق قد لا ينطبق على المهمة الحالية. وتصبح الإشارات مثل «ذلك الملف» أو «النهج السابق» غامضة.

استخدم جلسات منفصلة للأعمال غير ذات الصلة. إذا كانت هناك جلسات متعددة ستقوم بتحرير المستودع، فاستخدم أشجار عمل Git منفصلة حتى لا تقوم بتعديل نفس دليل العمل. ولطرح سؤال جانبي موجز، فإن الأمر /btw في Claude Code يبقي التبادل خارج سجل المحادثة الرئيسي.

قد ينجح البناء (build) في حين أن إحدى الميزات تعمل بشكل غير صحيح. وقد تنجح مجموعة الاختبارات لأنها لم تختبر أبدًا المدخلات التي تؤدي إلى الفشل. إن مطالبة «كلود» بـ«تشغيل الاختبارات» لا يحدد المتطلبات التي تتحقق منها تلك الاختبارات.

اربط معايير القبول بفحوصات محددة. عند إصلاح خطأ برمجي، اطلب دليلاً على أن اختبار إعادة إنتاج الخطأ قد فشل قبل التغيير ونجح بعده. اجعل المعايير التي لم يتم اختبارها مرئية بدلاً من اعتبار أمر واحد ناجح بمثابة تحقق من التغيير بأكمله.

قد يحتوي ملف CLAUDE.md المتوسع على أوامر قديمة وقواعد مكررة وتعليمات تتعارض مع المتطلبات الخاصة بالمهمة. ولا تؤدي إضافة صياغة أكثر صرامة إلى حل هذه التعارضات.

قم بمراجعة الملف مقارنةً بالمستودع الحالي. قم بإزالة الإرشادات التي عفا عليها الزمن، وتوضيح القواعد المتعارضة، ونقل التعليمات ذات التطبيق المحدود إلى قواعد أو مهارات محددة النطاق. إذا كان هناك متطلب يحتاج إلى فرض، فقم بتكوين واختبار الضوابط المناسبة بدلاً من الاعتماد على التذكيرات المتكررة.

يمكن أن تكشف المراجعة عن عيوب حقيقية ومخاوف غير مؤكدة واقتراحات اختيارية لإعادة هيكلة الكود في آن واحد. وقد يؤدي تطبيق كل اقتراح إلى توسيع نطاق التغيير دون تحسين السلوك المطلوب.

اطلب الأدلة والتأثيرات الكامنة وراء كل نتيجة. أعط الأولوية لمشكلات الدقة والمتطلبات غير المستوفاة، وتحقق من الادعاءات غير المؤكدة، واستبعد التحسينات غير ذات الصلة من الفروق الحالية. يجب أن يكون المراجع قادرًا على الإبلاغ بعدم وجود نتائج قابلة للتنفيذ عندما تدعم الأدلة هذا الاستنتاج.

لتكييف القالب، استبدل العناصر النائبة فيه بتفاصيل من مشروعك وحدد ما يجب أن يفعله Claude قبل إجراء التغييرات. اتبع هذه الخطوات لإعداد الطلب ومراجعة النتيجة.

بالنسبة للتغييرات الصغيرة والمحددة جيدًا، يمكنك أن تطلب من Claude تنفيذها مباشرةً. أما بالنسبة للكود غير المألوف، أو التغييرات التي تشمل عدة ملفات، أو المتطلبات التي لم يتم حلها بعد، فابدأ بوضع خطة.

اضغط على Shift+Tab حتى يظهر وضع «التخطيط» (Plan)، أو قم بتشغيل Claude Code باستخدام الأمر claude --permission-mode plan. في هذا الوضع، يمكن لـ Claude فحص الملفات وتشغيل الأوامر للقراءة فقط دون تعديل كود المصدر الخاص بك. راجع الملفات والتبعيات والاختبارات المقترحة قبل الموافقة على التنفيذ. اضغط على Ctrl+G لفتح الخطة المقترحة في محررك.

زوّد كلود بالأدلة اللازمة لفهم المهمة: مرجع ملف، أو سجل أخطاء تم تنقيته، أو لقطة شاشة، أو وثيقة متطلبات. استخدم الرمز @ متبوعًا بمسار الملف لتضمين محتويات ذلك الملف.

اختر أصغر مجموعة مفيدة من المصادر. فقد يؤدي تضمين سجل أو دليل كامل إلى إضافة مواد غير ذات صلة واستهلاك السياق. قم بإزالة بيانات الاعتماد والبيانات الحساسة قبل مشاركة السجلات، وتأكد من أن Claude يمتلك الأدوات اللازمة لاسترداد أي عناوين URL للوثائق التي تقدمها.

على سبيل المثال، الأمر cat error.log | claude -p "Explain this error" يرسل سجلاً مع طلب غير تفاعلي. استخدمه فقط بعد التحقق من محتويات الملف. هذه هي القيمة العملية للذكاء الاصطناعي السياقي: تزويد النموذج بالمعلومات ذات الصلة بالمهمة.

عند إضافة ميزة، حدد مكونًا أو وظيفة مشابهة في المستودع. أخبر «كلود» بالمعايير التي يجب اتباعها، مثل عميل واجهة برمجة التطبيقات (API)، ومنطق التحقق من الصحة، ومعالجة الأخطاء، أو بنية الاختبار.

تمنح عبارة «اتبع كيفية قيام @src/widgets/Weather.tsx بجلب البيانات وتخزينها مؤقتًا» كلود مرجعًا ملموسًا. كما يجب تحديد أي اختلافات تتطلبها الميزة الجديدة حتى لا يتم نسخ سلوك لم يعد مناسبًا. يجب أن تعكس هذه القواعد سير عمل فريقك في تطوير البرمجيات.

بالنسبة لتغييرات الكود، حدد الأمر ذي الصلة للاختبار أو البناء أو lint والسلوك الذي يجب التحقق منه. بالنسبة للأبحاث، اطلب مراجع الملفات أو معرّفات الالتزامات. بالنسبة لأعمال واجهة المستخدم، قدم صورة مرجعية وطريقة مكونة لالتقاط التنفيذ في نفس نافذة العرض.

اطلب من «كلود» تقديم تقرير بما تم فحصه فعليًّا، بما في ذلك حالات الفشل وعمليات الفحص التي تم تخطيها. تحقق مما إذا كانت الأدلة تغطي المتطلبات؛ فنجاح عملية البناء لا يثبت أن كل السلوكيات المطلوبة تعمل بشكل صحيح.

بالنسبة للمهام الأطول، يوفر Claude Code أيضًا شرط /goal و«Stop hooks». يقوم مُقيّم الهدف بتقييم الأدلة التي تظهر في المحادثة بدلاً من فحص الملفات أو إجراء الاختبارات بشكل مستقل. يمكن لـ«Stop hook» المُهيأ أن يمنع إتمام المهمة، ولكنه يخضع لقيود على الحجب المتكرر. ولا يحل أي منهما محل الاختبارات المناسبة والمراجعة البشرية.

إذا لم تؤدِ التصحيحات المتكررة إلى حل المشكلة، فتوقف وحدد ما الذي لم يتضح في الطلب الأصلي. احفظ النتائج المفيدة وحالة Git الحالية والعمل المتبقي قبل مسح المحادثة.

يوصي دليل أفضل الممارسات الصادر عن Anthropic بالبدء من جديد بعد محاولتين فاشلتين لتصحيح نفس المشكلة. استخدم الأمر /clear، ثم أدخل موجهًا منقحًا يتضمن ما تعلمته. لا يؤدي مسح المحادثة إلى التراجع عن التغييرات التي أُجريت على الملفات.

اضغط على مفتاح Esc لمقاطعة استجابة قيد التشغيل. عندما يكون حقل الإدخال فارغًا، اضغط على مفتاح Esc مرتين لفتح قائمة «الرجوع» واختيار ما تريد استعادته. لا تؤدي ميزة «الرجوع» إلى التراجع عن كل التأثيرات الخارجية، لذا استخدم نقاط فحص Git وإجراءات استعادة منفصلة للتغييرات التي تطرأ على قواعد البيانات أو الخدمات البعيدة.

احفظ الإرشادات الخاصة بالمشروع بأكمله في ملف CLAUDE.md، والإجراءات القابلة للتكرار في «المهارات»، والتعليمات الخاصة بملفات معينة في القواعد ذات نطاق المسار. استخدم «الخطافات» (hooks) للإجراءات المرتبطة بأحداث محددة، مثل تشغيل أداة التنسيق بعد إجراء تعديل.

اختر بناءً على الوقت الذي يجب أن تُطبق فيه التعليمات:

عادةً ما تنتمي متطلبات ميزة ما إلى موجه المهمة أو المواصفات الخاصة بها، وليس إلى ملف CLAUDE.md. وإضافة تعليمات مؤقتة إلى ملف يشمل المشروع بأكمله يجعل من الصعب تمييزها عن القواعد التي ينبغي تطبيقها في جميع أنحاء المستودع.

على سبيل المثال، احتفظ بأمر اختبار المشروع في ملف CLAUDE.md، وضع القواعد الخاصة بالمكونات في قاعدة ذات نطاق مسار، واحفظ إجراء المراجعة المتكرر كمهارة. راجع هذه الملفات عند تغيير الأوامر أو القواعد، تمامًا كما تفعل مع وثائق المشروع الأخرى.

تعمل المطالبات وملف CLAUDE.md ودليل المهارات على توجيه سلوك Claude؛ إلا أنها لا تضمن اتباع أي تعليمات. يمكن لـ«الخطافات» (hooks) إجراء عمليات فحص عند وقوع أحداث محددة، لكن موثوقيتها تعتمد على نوع الخطاف وطريقة تنفيذه.

يعمل «خطاف الأوامر» (command hook) على تشغيل برنامج نصي. أما «خطاف المطالبة» (prompt hook) أو «خطاف الوكيل» (agent hook) فيعتمد على تقدير النموذج. وكما يوضح دليل أفضل الممارسات الصادر عن شركة Anthropic: «يطلب خطاف المطالبة أو خطاف الوكيل من نموذج آخر اتخاذ القرار، لذا فهو ليس حتميًا أيضًا». بالنسبة للقاعدة التي يجب تطبيقها، استخدم ضوابط الأذونات المناسبة واختبر الأمر ذي الصلة أو خطاف HTTP، بما في ذلك كيفية تعامله مع حالات الفشل.

تعد الوكلاء الفرعيون المخصصون طريقة أخرى لتنظيم الأعمال المتكررة. قم بتعريف متخصص في claude/agents/ عندما تحتاج إلى دور مراجعة متميز أو نطاق أداة محدد، بدلاً من إضافة كل تعليمات المتخصص إلى الجلسة الرئيسية. توفر هذه الأدلة الخاصة بأفضل نموذج Claude للعمل وأنواع وكلاء الذكاء الاصطناعي سياقًا إضافيًا.

إذا كان فريقك يدير المطالبات عبر عدة منتجات للذكاء الاصطناعي، فاطلع على أدوات هندسة المطالبات هذه لإدارة المكتبات خارج نطاق Claude Code.

عندما تسفر جلسة العمل عن نتيجة غير مكتملة أو غير مناسبة، تحقق مما إذا كان الطلب قد ترك قرارات مهمة دون حل. فهذه الأخطاء الخمسة قد تجعل تشخيص المشكلة ومراجعتها أكثر صعوبة.

تمنح عبارة «تحقق من المستودع» كلود توجيهات قليلة بشأن الملفات المهمة أو متى يتوقف. وقد تتلقى ملخصًا عامًا دون إجابة على المشكلة التي دفعتك إلى تقديم الطلب.

حدد السلوك أو القرار الذي تحتاج إلى فهمه، وحدد نقطة البداية، وحدد الناتج المتوقع. على سبيل المثال: «تتبع كيفية قيام نقطة النهاية هذه بالتحقق من الأذونات واذكر الوظائف ذات الصلة». إذا كنت تستخدم وكلاء فرعيين، فاطرح على كل واحد منهم سؤالًا محددًا بدلاً من تفويضهم بنفس البحث غير المقيد.

التنقل بين ميزة ما، وخطأ غير ذي صلة، وطلب توثيق، يترك المحادثة محملة بسياق قد لا ينطبق على المهمة الحالية. وتصبح الإشارات مثل «ذلك الملف» أو «النهج السابق» غامضة.

استخدم جلسات منفصلة للأعمال غير ذات الصلة. إذا كانت هناك جلسات متعددة ستقوم بتحرير المستودع، فاستخدم أشجار عمل Git منفصلة حتى لا تقوم بتعديل نفس دليل العمل. ولطرح سؤال جانبي موجز، فإن الأمر /btw في Claude Code يبقي التبادل خارج سجل المحادثة الرئيسي.

قد ينجح البناء (build) في حين أن إحدى الميزات تعمل بشكل غير صحيح. وقد تنجح مجموعة الاختبارات لأنها لم تختبر أبدًا المدخلات التي تؤدي إلى الفشل. إن مطالبة «كلود» بـ«تشغيل الاختبارات» لا يحدد المتطلبات التي تتحقق منها تلك الاختبارات.

اربط معايير القبول بفحوصات محددة. عند إصلاح خطأ برمجي، اطلب دليلاً على أن اختبار إعادة إنتاج الخطأ قد فشل قبل التغيير ونجح بعده. اجعل المعايير التي لم يتم اختبارها مرئية بدلاً من اعتبار أمر واحد ناجح بمثابة تحقق من التغيير بأكمله.

قد يحتوي ملف CLAUDE.md المتوسع على أوامر قديمة وقواعد مكررة وتعليمات تتعارض مع المتطلبات الخاصة بالمهمة. ولا تؤدي إضافة صياغة أكثر صرامة إلى حل هذه التعارضات.

قم بمراجعة الملف مقارنةً بالمستودع الحالي. قم بإزالة الإرشادات التي عفا عليها الزمن، وتوضيح القواعد المتعارضة، ونقل التعليمات ذات التطبيق المحدود إلى قواعد أو مهارات محددة النطاق. إذا كان هناك متطلب يحتاج إلى فرض، فقم بتكوين واختبار الضوابط المناسبة بدلاً من الاعتماد على التذكيرات المتكررة.

يمكن أن تكشف المراجعة عن عيوب حقيقية ومخاوف غير مؤكدة واقتراحات اختيارية لإعادة هيكلة الكود في آن واحد. وقد يؤدي تطبيق كل اقتراح إلى توسيع نطاق التغيير دون تحسين السلوك المطلوب.

اطلب الأدلة والتأثيرات الكامنة وراء كل نتيجة. أعط الأولوية لمشكلات الدقة والمتطلبات غير المستوفاة، وتحقق من الادعاءات غير المؤكدة، واستبعد التحسينات غير ذات الصلة من الفروق الحالية. يجب أن يكون المراجع قادرًا على الإبلاغ بعدم وجود نتائج قابلة للتنفيذ عندما تدعم الأدلة هذا الاستنتاج.

لتكييف القالب، استبدل العناصر النائبة فيه بتفاصيل من مشروعك وحدد ما يجب أن يفعله Claude قبل إجراء التغييرات. اتبع هذه الخطوات لإعداد الطلب ومراجعة النتيجة.

بالنسبة للتغييرات الصغيرة والمحددة جيدًا، يمكنك أن تطلب من Claude تنفيذها مباشرةً. أما بالنسبة للكود غير المألوف، أو التغييرات التي تشمل عدة ملفات، أو المتطلبات التي لم يتم حلها بعد، فابدأ بوضع خطة.

اضغط على Shift+Tab حتى يظهر وضع «التخطيط» (Plan)، أو قم بتشغيل Claude Code باستخدام الأمر claude --permission-mode plan. في هذا الوضع، يمكن لـ Claude فحص الملفات وتشغيل الأوامر للقراءة فقط دون تعديل كود المصدر الخاص بك. راجع الملفات والتبعيات والاختبارات المقترحة قبل الموافقة على التنفيذ. اضغط على Ctrl+G لفتح الخطة المقترحة في محررك.

زوّد كلود بالأدلة اللازمة لفهم المهمة: مرجع ملف، أو سجل أخطاء تم تنقيته، أو لقطة شاشة، أو وثيقة متطلبات. استخدم الرمز @ متبوعًا بمسار الملف لتضمين محتويات ذلك الملف.

اختر أصغر مجموعة مفيدة من المصادر. فقد يؤدي تضمين سجل أو دليل كامل إلى إضافة مواد غير ذات صلة واستهلاك السياق. قم بإزالة بيانات الاعتماد والبيانات الحساسة قبل مشاركة السجلات، وتأكد من أن Claude يمتلك الأدوات اللازمة لاسترداد أي عناوين URL للوثائق التي تقدمها.

على سبيل المثال، الأمر cat error.log | claude -p "Explain this error" يرسل سجلاً مع طلب غير تفاعلي. استخدمه فقط بعد التحقق من محتويات الملف. هذه هي القيمة العملية للذكاء الاصطناعي السياقي: تزويد النموذج بالمعلومات ذات الصلة بالمهمة.

عند إضافة ميزة، حدد مكونًا أو وظيفة مشابهة في المستودع. أخبر «كلود» بالمعايير التي يجب اتباعها، مثل عميل واجهة برمجة التطبيقات (API)، ومنطق التحقق من الصحة، ومعالجة الأخطاء، أو بنية الاختبار.

تمنح عبارة «اتبع كيفية قيام @src/widgets/Weather.tsx بجلب البيانات وتخزينها مؤقتًا» كلود مرجعًا ملموسًا. كما يجب تحديد أي اختلافات تتطلبها الميزة الجديدة حتى لا يتم نسخ سلوك لم يعد مناسبًا. يجب أن تعكس هذه القواعد سير عمل فريقك في تطوير البرمجيات.

بالنسبة لتغييرات الكود، حدد الأمر ذي الصلة للاختبار أو البناء أو lint والسلوك الذي يجب التحقق منه. بالنسبة للأبحاث، اطلب مراجع الملفات أو معرّفات الالتزامات. بالنسبة لأعمال واجهة المستخدم، قدم صورة مرجعية وطريقة مكونة لالتقاط التنفيذ في نفس نافذة العرض.

اطلب من «كلود» تقديم تقرير عما قام بفحصه فعليًّا، بما في ذلك حالات الفشل وعمليات الفحص التي تم تخطيها. تحقق مما إذا كانت الأدلة تغطي المتطلبات؛ فنجاح عملية البناء لا يثبت أن كل سلوك مطلوب يعمل بشكل صحيح.

بالنسبة للمهام الأطول، يوفر Claude Code أيضًا شرط /goal و«Stop hooks». يقوم مُقيّم الهدف بتقييم الأدلة التي تظهر في المحادثة بدلاً من فحص الملفات أو إجراء الاختبارات بشكل مستقل. يمكن لـ«Stop hook» المُهيأ أن يمنع إتمام المهمة، ولكنه يخضع لقيود على الحجب المتكرر. ولا يحل أي منهما محل الاختبارات المناسبة والمراجعة البشرية.

إذا لم تؤدِ التصحيحات المتكررة إلى حل المشكلة، فتوقف وحدد ما الذي لم يتضح في الطلب الأصلي. احفظ النتائج المفيدة، وحالة Git الحالية، والعمل المتبقي قبل مسح المحادثة.

يوصي دليل أفضل الممارسات الصادر عن Anthropic بالبدء من جديد بعد محاولتين فاشلتين لتصحيح نفس المشكلة. استخدم الأمر /clear، ثم أدخل موجهًا منقحًا يتضمن ما تعلمته. لا يؤدي مسح المحادثة إلى التراجع عن التغييرات التي أُجريت على الملفات.

اضغط على مفتاح Esc لمقاطعة استجابة قيد التشغيل. عندما يكون حقل الإدخال فارغًا، اضغط على مفتاح Esc مرتين لفتح قائمة «الرجوع» واختيار ما تريد استعادته. لا تؤدي ميزة «الرجوع» إلى التراجع عن كل التأثيرات الخارجية، لذا استخدم نقاط فحص Git وإجراءات استعادة منفصلة للتغييرات التي تطرأ على قواعد البيانات أو الخدمات البعيدة.

احفظ الإرشادات الخاصة بالمشروع بأكمله في ملف CLAUDE.md، والإجراءات القابلة للتكرار في «المهارات»، والتعليمات الخاصة بملفات معينة في القواعد ذات نطاق المسار. استخدم «الخطافات» (hooks) للإجراءات المرتبطة بأحداث محددة، مثل تشغيل أداة التنسيق بعد إجراء تعديل.

اختر بناءً على الوقت الذي يجب أن تُطبق فيه التعليمات:

عادةً ما تنتمي متطلبات ميزة ما إلى موجه المهمة أو المواصفات الخاصة بها، وليس إلى ملف CLAUDE.md. وإضافة تعليمات مؤقتة إلى ملف يشمل المشروع بأكمله يجعل من الصعب تمييزها عن القواعد التي ينبغي تطبيقها في جميع أنحاء المستودع.

على سبيل المثال، احتفظ بأمر اختبار المشروع في ملف CLAUDE.md، وضع القواعد الخاصة بالمكونات في قاعدة ذات نطاق مسار، واحفظ إجراء المراجعة المتكرر كمهارة. راجع هذه الملفات عند تغيير الأوامر أو القواعد، تمامًا كما تفعل مع وثائق المشروع الأخرى.

تعمل المطالبات وملف CLAUDE.md ودليل المهارات على توجيه سلوك Claude؛ لكنها لا تضمن اتباع أي تعليمات. يمكن أن تقوم «الخطافات» (hooks) بإجراء فحوصات عند وقوع أحداث محددة مسبقًا، لكن موثوقيتها تعتمد على نوع الخطاف وطريقة تنفيذه.

يعمل «خطاف الأوامر» (command hook) على تشغيل برنامج نصي. أما «خطاف المطالبة» (prompt hook) أو «خطاف الوكيل» (agent hook) فيعتمد على تقدير النموذج. وكما يوضح دليل أفضل الممارسات الصادر عن شركة Anthropic: «يطلب خطاف المطالبة أو خطاف الوكيل من نموذج آخر اتخاذ القرار، لذا فهو ليس حتميًا أيضًا». بالنسبة للقاعدة التي يجب تطبيقها، استخدم ضوابط الأذونات المناسبة واختبر الأمر ذي الصلة أو خطاف HTTP، بما في ذلك كيفية تعامله مع حالات الفشل.

تعد الوكلاء الفرعيون المخصصون طريقة أخرى لتنظيم الأعمال المتكررة. قم بتعريف متخصص في claude/agents/ عندما تحتاج إلى دور مراجعة متميز أو نطاق أداة محدد، بدلاً من إضافة كل تعليمات المتخصص إلى الجلسة الرئيسية. توفر هذه الأدلة الخاصة بأفضل نموذج Claude للعمل وأنواع وكلاء الذكاء الاصطناعي سياقًا إضافيًا.

إذا كان فريقك يدير المطالبات عبر عدة منتجات للذكاء الاصطناعي، فاطلع على أدوات هندسة المطالبات هذه لإدارة المكتبات خارج نطاق Claude Code.

عندما تسفر جلسة العمل عن نتيجة غير مكتملة أو غير مناسبة، تحقق مما إذا كان الطلب قد ترك قرارات مهمة دون حل. فهذه الأخطاء الخمسة قد تجعل تشخيص المشكلة ومراجعتها أكثر صعوبة.

تمنح عبارة «تحقق من المستودع» كلود توجيهات قليلة بشأن الملفات المهمة أو متى يتوقف. وقد تتلقى ملخصًا عامًا دون إجابة على المشكلة التي دفعتك إلى إرسال الطلب.

حدد السلوك أو القرار الذي تحتاج إلى فهمه، وحدد نقطة البداية، وحدد الناتج المتوقع. على سبيل المثال: «تتبع كيفية قيام نقطة النهاية هذه بالتحقق من الأذونات واذكر الوظائف ذات الصلة». إذا كنت تستخدم وكلاء فرعيين، فاطرح على كل واحد منهم سؤالًا محددًا بدلاً من تفويضهم بنفس البحث غير المقيد.

التنقل بين ميزة ما، وخطأ غير ذي صلة، وطلب توثيق، يترك المحادثة محملة بسياق قد لا ينطبق على المهمة الحالية. وتصبح الإشارات مثل «ذلك الملف» أو «النهج السابق» غامضة.

استخدم جلسات منفصلة للأعمال غير ذات الصلة. إذا كانت هناك جلسات متعددة ستقوم بتحرير المستودع، فاستخدم أشجار عمل Git منفصلة حتى لا تقوم بتعديل نفس دليل العمل. ولطرح سؤال جانبي موجز، فإن الأمر /btw في Claude Code يبقي التبادل خارج سجل المحادثة الرئيسي.

قد ينجح البناء (build) في حين أن إحدى الميزات تعمل بشكل غير صحيح. وقد تنجح مجموعة الاختبارات لأنها لم تختبر أبدًا المدخلات التي تؤدي إلى الفشل. إن مطالبة «كلود» بـ«تشغيل الاختبارات» لا يحدد المتطلبات التي تتحقق منها تلك الاختبارات.

اربط معايير القبول بفحوصات محددة. عند إصلاح خطأ برمجي، اطلب دليلاً على أن اختبار إعادة إنتاج الخطأ قد فشل قبل التغيير ونجح بعده. اجعل المعايير التي لم يتم اختبارها ظاهرة للعيان بدلاً من اعتبار أمر واحد ناجح بمثابة تحقق من التغيير بأكمله.

قد يحتوي ملف CLAUDE.md المتوسع على أوامر قديمة وقواعد مكررة وتعليمات تتعارض مع المتطلبات الخاصة بالمهمة. ولا تؤدي إضافة صياغة أكثر صرامة إلى حل هذه التعارضات.

قم بمراجعة الملف مقارنةً بالمستودع الحالي. قم بإزالة الإرشادات التي عفا عليها الزمن، وتوضيح القواعد المتعارضة، ونقل التعليمات ذات التطبيق المحدود إلى قواعد أو مهارات محددة النطاق. إذا كان هناك متطلب يحتاج إلى فرض، فقم بتكوين واختبار الضوابط المناسبة بدلاً من الاعتماد على التذكيرات المتكررة.

يمكن أن تكشف المراجعة عن عيوب حقيقية ومخاوف غير مؤكدة واقتراحات اختيارية لإعادة هيكلة الكود في آن واحد. وقد يؤدي تطبيق كل اقتراح إلى توسيع نطاق التغيير دون تحسين السلوك المطلوب.

اطلب الأدلة والتأثيرات الكامنة وراء كل نتيجة. أعط الأولوية لمشكلات الدقة والمتطلبات غير المستوفاة، وتحقق من الادعاءات غير المؤكدة، واستبعد التحسينات غير ذات الصلة من الفروق الحالية. يجب أن يكون المراجع قادرًا على الإبلاغ بعدم وجود نتائج قابلة للتنفيذ عندما تدعم الأدلة هذا الاستنتاج.

لتكييف القالب، استبدل العناصر النائبة فيه بتفاصيل من مشروعك وحدد ما يجب أن يفعله Claude قبل إجراء التغييرات. اتبع هذه الخطوات لإعداد الطلب ومراجعة النتيجة.

بالنسبة للتغييرات الصغيرة والمحددة جيدًا، يمكنك أن تطلب من Claude تنفيذها مباشرةً. أما بالنسبة للكود غير المألوف، أو التغييرات التي تشمل عدة ملفات، أو المتطلبات التي لم يتم حلها بعد، فابدأ بوضع خطة.

اضغط على Shift+Tab حتى يظهر وضع «التخطيط» (Plan)، أو قم بتشغيل Claude Code باستخدام الأمر claude --permission-mode plan. في هذا الوضع، يمكن لـ Claude فحص الملفات وتشغيل الأوامر للقراءة فقط دون تعديل كود المصدر الخاص بك. راجع الملفات والتبعيات والاختبارات المقترحة قبل الموافقة على التنفيذ. اضغط على Ctrl+G لفتح الخطة المقترحة في محررك.

زوّد كلود بالأدلة اللازمة لفهم المهمة: مرجع ملف، أو سجل أخطاء تم تنقيته، أو لقطة شاشة، أو وثيقة متطلبات. استخدم الرمز @ متبوعًا بمسار الملف لتضمين محتويات ذلك الملف.

اختر أصغر مجموعة مفيدة من المصادر. فقد يؤدي تضمين سجل أو دليل كامل إلى إضافة مواد غير ذات صلة واستهلاك السياق. قم بإزالة بيانات الاعتماد والبيانات الحساسة قبل مشاركة السجلات، وتأكد من أن Claude يمتلك الأدوات اللازمة لاسترداد أي عناوين URL للوثائق التي تقدمها.

على سبيل المثال، الأمر cat error.log | claude -p "Explain this error" يرسل سجلاً مع طلب غير تفاعلي. استخدمه فقط بعد التحقق من محتويات الملف. هذه هي القيمة العملية للذكاء الاصطناعي السياقي: تزويد النموذج بالمعلومات ذات الصلة بالمهمة.

عند إضافة ميزة، حدد مكونًا أو وظيفة مشابهة في المستودع. أخبر «كلود» بالمعايير التي يجب اتباعها، مثل عميل واجهة برمجة التطبيقات (API) أو منطق التحقق من الصحة أو معالجة الأخطاء أو بنية الاختبار.

تمنح عبارة «اتبع كيفية قيام @src/widgets/Weather.tsx بجلب البيانات وتخزينها مؤقتًا» كلود مرجعًا ملموسًا. كما يجب تحديد أي اختلافات تتطلبها الميزة الجديدة حتى لا يتم نسخ سلوك لم يعد مناسبًا. يجب أن تعكس هذه القواعد سير عمل فريقك في تطوير البرمجيات.

بالنسبة لتغييرات الكود، حدد الأمر ذي الصلة للاختبار أو البناء أو lint والسلوك الذي يجب التحقق منه. بالنسبة للأبحاث، اطلب مراجع الملفات أو معرّفات الالتزامات. بالنسبة لأعمال واجهة المستخدم، قدم صورة مرجعية وطريقة مكونة لالتقاط التنفيذ في نفس نافذة العرض.

اطلب من «كلود» تقديم تقرير بما تم فحصه فعليًّا، بما في ذلك حالات الفشل وعمليات الفحص التي تم تخطيها. تحقق مما إذا كانت الأدلة تغطي المتطلبات؛ فنجاح عملية البناء لا يثبت أن كل سلوك مطلوب يعمل بشكل صحيح.

بالنسبة للمهام الأطول، يوفر Claude Code أيضًا شرط /goal و«Stop hooks». يقوم مُقيّم الهدف بتقييم الأدلة التي تظهر في المحادثة بدلاً من فحص الملفات أو إجراء الاختبارات بشكل مستقل. يمكن لـ«Stop hook» المُهيأ أن يمنع إتمام المهمة، ولكنه يخضع لقيود على الحجب المتكرر. ولا يحل أي منهما محل الاختبارات المناسبة والمراجعة البشرية.

إذا لم تؤدِ التصحيحات المتكررة إلى حل المشكلة، فتوقف وحدد ما الذي لم يتضح في الطلب الأصلي. احفظ النتائج المفيدة، وحالة Git الحالية، والعمل المتبقي قبل مسح المحادثة.

يوصي دليل أفضل الممارسات الصادر عن Anthropic بالبدء من جديد بعد محاولتين فاشلتين لتصحيح نفس المشكلة. استخدم الأمر /clear، ثم أدخل موجهًا منقحًا يتضمن ما تعلمته. لا يؤدي مسح المحادثة إلى التراجع عن التغييرات التي أُجريت على الملفات.

اضغط على مفتاح Esc لمقاطعة استجابة قيد التشغيل. عندما يكون حقل الإدخال فارغًا، اضغط على مفتاح Esc مرتين لفتح قائمة «الرجوع» واختيار ما تريد استعادته. لا تؤدي ميزة «الرجوع» إلى التراجع عن كل التأثيرات الخارجية، لذا استخدم نقاط فحص Git وإجراءات استعادة منفصلة للتغييرات التي تطرأ على قواعد البيانات أو الخدمات البعيدة.

احفظ الإرشادات الخاصة بالمشروع بأكمله في ملف CLAUDE.md، والإجراءات القابلة للتكرار في «المهارات»، والتعليمات الخاصة بملفات معينة في القواعد ذات نطاق المسار. استخدم «الخطافات» (hooks) للإجراءات المرتبطة بأحداث محددة، مثل تشغيل أداة التنسيق بعد إجراء تعديل.

اختر بناءً على الوقت الذي يجب أن تُطبق فيه التعليمات:

عادةً ما تنتمي متطلبات ميزة ما إلى موجه المهمة أو المواصفات الخاصة بها، وليس إلى ملف CLAUDE.md. وإضافة تعليمات مؤقتة إلى ملف يشمل المشروع بأكمله يجعل من الصعب تمييزها عن القواعد التي ينبغي تطبيقها في جميع أنحاء المستودع.

على سبيل المثال، احتفظ بأمر اختبار المشروع في ملف CLAUDE.md، وضع القواعد الخاصة بالمكونات في قاعدة ذات نطاق مسار، واحفظ إجراء المراجعة المتكرر كمهارة. راجع هذه الملفات عند تغيير الأوامر أو القواعد، تمامًا كما تفعل مع وثائق المشروع الأخرى.

تعمل المطالبات وملف CLAUDE.md ودليل المهارات على توجيه سلوك Claude؛ إلا أنها لا تضمن اتباع أي تعليمات. يمكن أن تقوم «الخطافات» (hooks) بإجراء فحوصات عند وقوع أحداث محددة، لكن موثوقيتها تعتمد على نوع الخطاف وطريقة تنفيذه.

يعمل «خطاف الأوامر» (command hook) على تشغيل برنامج نصي. أما «خطاف المطالبة» (prompt hook) أو «خطاف الوكيل» (agent hook) فيعتمد على تقدير النموذج. وكما يوضح دليل أفضل الممارسات الصادر عن شركة Anthropic: «يطلب خطاف المطالبة أو خطاف الوكيل من نموذج آخر اتخاذ القرار، لذا فهو ليس حتميًا أيضًا». بالنسبة للقاعدة التي يجب تطبيقها، استخدم ضوابط الأذونات المناسبة واختبر الأمر ذي الصلة أو خطاف HTTP، بما في ذلك كيفية تعامله مع حالات الفشل.

تعد الوكلاء الفرعيون المخصصون طريقة أخرى لتنظيم الأعمال المتكررة. قم بتعريف متخصص في claude/agents/ عندما تحتاج إلى دور مراجعة متميز أو نطاق أداة محدد، بدلاً من إضافة كل تعليمات المتخصص إلى الجلسة الرئيسية. توفر هذه الأدلة الخاصة بأفضل نموذج Claude للعمل وأنواع وكلاء الذكاء الاصطناعي سياقًا إضافيًا.

إذا كان فريقك يدير المطالبات عبر عدة منتجات للذكاء الاصطناعي، فاطلع على أدوات هندسة المطالبات هذه لإدارة المكتبات خارج نطاق Claude Code.

عندما تسفر جلسة العمل عن نتيجة غير مكتملة أو غير مناسبة، تحقق مما إذا كان الطلب قد ترك قرارات مهمة دون حل. فهذه الأخطاء الخمسة قد تجعل تشخيص المشكلة ومراجعتها أكثر صعوبة.

تمنح عبارة «تحقق من المستودع» كلود توجيهات قليلة بشأن الملفات المهمة أو متى يتوقف. وقد تتلقى ملخصًا عامًا دون إجابة على المشكلة التي دفعتك إلى إرسال الطلب.

حدد السلوك أو القرار الذي تحتاج إلى فهمه، وحدد نقطة البداية، وحدد الناتج المتوقع. على سبيل المثال: «تتبع كيفية قيام نقطة النهاية هذه بالتحقق من الأذونات واذكر الوظائف ذات الصلة». إذا كنت تستخدم وكلاء فرعيين، فاطرح على كل واحد منهم سؤالًا محددًا بدلاً من تفويضهم بنفس البحث غير المقيد.

التنقل بين ميزة ما، وخطأ غير ذي صلة، وطلب توثيق، يترك المحادثة محملة بسياق قد لا ينطبق على المهمة الحالية. وتصبح الإشارات مثل «ذلك الملف» أو «النهج السابق» غامضة.

استخدم جلسات منفصلة للأعمال غير ذات الصلة. إذا كانت هناك جلسات متعددة ستقوم بتحرير المستودع، فاستخدم أشجار عمل Git منفصلة حتى لا تقوم بتعديل نفس دليل العمل. ولطرح سؤال جانبي موجز، فإن الأمر /btw في Claude Code يبقي التبادل خارج سجل المحادثة الرئيسي.

قد ينجح البناء (build) رغم أن إحدى الميزات تعمل بشكل غير صحيح. وقد تنجح مجموعة الاختبارات لأنها لم تختبر أبدًا المدخلات التي تؤدي إلى الفشل. إن مطالبة «كلود» بـ«تشغيل الاختبارات» لا يحدد المتطلبات التي تتحقق منها تلك الاختبارات.

اربط معايير القبول بفحوصات محددة. عند إصلاح خطأ برمجي، اطلب دليلاً على أن اختبار إعادة إنتاج الخطأ قد فشل قبل التغيير ونجح بعده. اجعل المعايير التي لم يتم اختبارها ظاهرة للعيان بدلاً من اعتبار أمر واحد ناجح بمثابة تحقق من التغيير بأكمله.

قد يحتوي ملف CLAUDE.md المتوسع على أوامر قديمة وقواعد مكررة وتعليمات تتعارض مع المتطلبات الخاصة بالمهمة. ولا تؤدي إضافة صياغة أكثر صرامة إلى حل هذه التعارضات.

قم بمراجعة الملف مقارنةً بالمستودع الحالي. قم بإزالة الإرشادات التي عفا عليها الزمن، وتوضيح القواعد المتعارضة، ونقل التعليمات ذات التطبيق المحدود إلى قواعد أو مهارات محددة النطاق. إذا كان هناك متطلب يحتاج إلى فرض، فقم بتكوين واختبار الضوابط المناسبة بدلاً من الاعتماد على التذكيرات المتكررة.

يمكن أن تكشف المراجعة عن عيوب حقيقية ومخاوف غير مؤكدة واقتراحات اختيارية لإعادة هيكلة الكود في آن واحد. وقد يؤدي تطبيق كل اقتراح إلى توسيع نطاق التغيير دون تحسين السلوك المطلوب.

اطلب الأدلة والتأثيرات الكامنة وراء كل نتيجة. أعط الأولوية لمشكلات الدقة والمتطلبات غير المستوفاة، وتحقق من الادعاءات غير المؤكدة، واستبعد التحسينات غير ذات الصلة من الفروق الحالية. يجب أن يكون المراجع قادرًا على الإبلاغ بعدم وجود نتائج قابلة للتنفيذ عندما تدعم الأدلة هذا الاستنتاج.

لتكييف القالب، استبدل العناصر النائبة فيه بتفاصيل من مشروعك وحدد ما يجب أن يفعله Claude قبل إجراء التغييرات. اتبع هذه الخطوات لإعداد الطلب ومراجعة النتيجة.

بالنسبة للتغييرات الصغيرة والمحددة جيدًا، يمكنك أن تطلب من Claude تنفيذها مباشرةً. أما بالنسبة للكود غير المألوف، أو التغييرات التي تشمل عدة ملفات، أو المتطلبات التي لم يتم حلها بعد، فابدأ بوضع خطة.

اضغط على Shift+Tab حتى يظهر وضع «التخطيط» (Plan)، أو قم بتشغيل Claude Code باستخدام الأمر claude --permission-mode plan. في هذا الوضع، يمكن لـ Claude فحص الملفات وتشغيل الأوامر للقراءة فقط دون تعديل كود المصدر الخاص بك. راجع الملفات والتبعيات والاختبارات المقترحة قبل الموافقة على التنفيذ. اضغط على Ctrl+G لفتح الخطة المقترحة في محررك.

زوّد كلود بالأدلة اللازمة لفهم المهمة: مرجع ملف، أو سجل أخطاء تم تنقيته، أو لقطة شاشة، أو وثيقة متطلبات. استخدم الرمز @ متبوعًا بمسار الملف لتضمين محتويات ذلك الملف.

اختر أصغر مجموعة مفيدة من المصادر. فقد يؤدي تضمين سجل أو دليل كامل إلى إضافة مواد غير ذات صلة واستهلاك السياق. قم بإزالة بيانات الاعتماد والبيانات الحساسة قبل مشاركة السجلات، وتأكد من أن Claude يمتلك الأدوات اللازمة لاسترداد أي عناوين URL للوثائق التي تقدمها.

على سبيل المثال، الأمر cat error.log | claude -p "Explain this error" يرسل سجلاً مع طلب غير تفاعلي. استخدمه فقط بعد التحقق من محتويات الملف. هذه هي القيمة العملية للذكاء الاصطناعي السياقي: تزويد النموذج بالمعلومات ذات الصلة بالمهمة.

عند إضافة ميزة، حدد مكونًا أو وظيفة مشابهة في المستودع. أخبر «كلود» بالمعايير التي يجب اتباعها، مثل عميل واجهة برمجة التطبيقات (API)، ومنطق التحقق من الصحة، ومعالجة الأخطاء، أو بنية الاختبار.

تمنح عبارة «اتبع كيفية قيام @src/widgets/Weather.tsx بجلب البيانات وتخزينها مؤقتًا» كلود مرجعًا ملموسًا. كما يجب تحديد أي اختلافات تتطلبها الميزة الجديدة حتى لا يتم نسخ سلوك لم يعد مناسبًا. يجب أن تعكس هذه القواعد سير عمل فريقك في تطوير البرمجيات.

بالنسبة لتغييرات الكود، حدد الأمر ذي الصلة للاختبار أو البناء أو lint والسلوك الذي يجب التحقق منه. بالنسبة للأبحاث، اطلب مراجع الملفات أو معرّفات الالتزامات. بالنسبة لأعمال واجهة المستخدم، قدم صورة مرجعية وطريقة مكونة لالتقاط التنفيذ في نفس نافذة العرض.

اطلب من «كلود» تقديم تقرير بما تم فحصه فعليًّا، بما في ذلك حالات الفشل وعمليات الفحص التي تم تخطيها. تحقق مما إذا كانت الأدلة تغطي المتطلبات؛ فنجاح عملية البناء لا يثبت أن كل السلوكيات المطلوبة تعمل بشكل صحيح.

بالنسبة للمهام الأطول، يوفر Claude Code أيضًا شرط /goal و«Stop hooks». يقوم مُقيّم الهدف بتقييم الأدلة التي تظهر في المحادثة بدلاً من فحص الملفات أو إجراء الاختبارات بشكل مستقل. يمكن لـ«Stop hook» المُهيأ أن يمنع إتمام المهمة، ولكنه يخضع لقيود على الحجب المتكرر. ولا يحل أي منهما محل الاختبارات المناسبة والمراجعة البشرية.

إذا لم تؤدِ التصحيحات المتكررة إلى حل المشكلة، فتوقف وحدد ما الذي لم يتضح في الطلب الأصلي. احفظ النتائج المفيدة، وحالة Git الحالية، والعمل المتبقي قبل مسح المحادثة.

يوصي دليل أفضل الممارسات الصادر عن Anthropic بالبدء من جديد بعد محاولتين فاشلتين لتصحيح نفس المشكلة. استخدم الأمر /clear، ثم أدخل موجهًا منقحًا يتضمن ما تعلمته. لا يؤدي مسح المحادثة إلى التراجع عن التغييرات التي أُجريت على الملفات.

اضغط على مفتاح Esc لمقاطعة استجابة قيد التشغيل. عندما يكون حقل الإدخال فارغًا، اضغط على مفتاح Esc مرتين لفتح قائمة «الرجوع» واختيار ما تريد استعادته. لا تؤدي ميزة «الرجوع» إلى التراجع عن كل التأثيرات الخارجية، لذا استخدم نقاط فحص Git وإجراءات استعادة منفصلة للتغييرات التي تطرأ على قواعد البيانات أو الخدمات البعيدة.

احفظ الإرشادات الخاصة بالمشروع بأكمله في ملف CLAUDE.md، والإجراءات القابلة للتكرار في «المهارات»، والتعليمات الخاصة بملفات معينة في القواعد ذات نطاق المسار. استخدم «الخطافات» (hooks) للإجراءات المرتبطة بأحداث محددة، مثل تشغيل أداة التنسيق بعد إجراء تعديل.

اختر بناءً على الوقت الذي يجب أن تُطبق فيه التعليمات:

عادةً ما تنتمي متطلبات ميزة ما إلى موجه المهمة أو المواصفات الخاصة بها، وليس إلى ملف CLAUDE.md. وإضافة تعليمات مؤقتة إلى ملف يشمل المشروع بأكمله يجعل من الصعب تمييزها عن القواعد التي ينبغي تطبيقها في جميع أنحاء المستودع.

على سبيل المثال، احتفظ بأمر اختبار المشروع في ملف CLAUDE.md، وضع القواعد الخاصة بالمكونات في قاعدة ذات نطاق مسار، واحفظ إجراء المراجعة المتكرر كمهارة. راجع هذه الملفات عند تغيير الأوامر أو القواعد، تمامًا كما تفعل مع وثائق المشروع الأخرى.

تعمل المطالبات وملف CLAUDE.md ودليل المهارات على توجيه سلوك Claude؛ إلا أنها لا تضمن اتباع أي تعليمات. يمكن لـ«الخطافات» (hooks) إجراء عمليات فحص عند وقوع أحداث محددة، لكن موثوقيتها تعتمد على نوع الخطاف وطريقة تنفيذه.

يعمل «خطاف الأوامر» (command hook) على تشغيل برنامج نصي. أما «خطاف المطالبة» (prompt hook) أو «خطاف الوكيل» (agent hook) فيعتمد على تقدير النموذج. وكما يوضح دليل أفضل الممارسات الصادر عن شركة Anthropic: «يطلب خطاف المطالبة أو خطاف الوكيل من نموذج آخر اتخاذ القرار، لذا فهو ليس حتميًا أيضًا». بالنسبة للقاعدة التي يجب تطبيقها، استخدم ضوابط الأذونات المناسبة واختبر الأمر ذي الصلة أو خطاف HTTP، بما في ذلك كيفية تعامله مع حالات الفشل.

تعد الوكلاء الفرعيون المخصصون طريقة أخرى لتنظيم الأعمال المتكررة. قم بتعريف متخصص في claude/agents/ عندما تحتاج إلى دور مراجعة متميز أو نطاق أداة محدد، بدلاً من إضافة كل تعليمات المتخصص إلى الجلسة الرئيسية. توفر هذه الأدلة الخاصة بأفضل نموذج Claude للعمل وأنواع وكلاء الذكاء الاصطناعي سياقًا إضافيًا.

إذا كان فريقك يدير المطالبات عبر عدة منتجات للذكاء الاصطناعي، فاطلع على أدوات هندسة المطالبات هذه لإدارة المكتبات خارج نطاق Claude Code.

عندما تسفر جلسة العمل عن نتيجة غير مكتملة أو غير مناسبة، تحقق مما إذا كان الطلب قد ترك قرارات مهمة دون حل. فهذه الأخطاء الخمسة قد تجعل تشخيص المشكلة ومراجعتها أكثر صعوبة.

تمنح عبارة «تحقق من المستودع» كلود توجيهات قليلة بشأن الملفات المهمة أو متى يتوقف. وقد تتلقى ملخصًا عامًا دون إجابة على المشكلة التي دفعتك إلى إرسال الطلب.

حدد السلوك أو القرار الذي تحتاج إلى فهمه، وحدد نقطة البداية، وحدد الناتج المتوقع. على سبيل المثال: «تتبع كيفية قيام نقطة النهاية هذه بالتحقق من الأذونات واذكر الوظائف ذات الصلة». إذا كنت تستخدم وكلاء فرعيين، فاطرح على كل واحد منهم سؤالًا محددًا بدلاً من تفويضهم بنفس البحث غير المقيد.

التنقل بين ميزة ما، وخطأ غير ذي صلة، وطلب توثيق، يترك المحادثة محملة بسياق قد لا ينطبق على المهمة الحالية. وتصبح الإشارات مثل «ذلك الملف» أو «النهج السابق» غامضة.

استخدم جلسات منفصلة للأعمال غير ذات الصلة. إذا كانت هناك جلسات متعددة ستقوم بتحرير المستودع، فاستخدم أشجار عمل Git منفصلة حتى لا تقوم بتعديل نفس دليل العمل. ولطرح سؤال جانبي موجز، فإن الأمر /btw في Claude Code يبقي التبادل خارج سجل المحادثة الرئيسي.

قد ينجح البناء (build) في حين أن إحدى الميزات تعمل بشكل غير صحيح. وقد تنجح مجموعة الاختبارات لأنها لم تختبر أبدًا المدخلات التي تؤدي إلى الفشل. إن مطالبة «كلود» بـ«تشغيل الاختبارات» لا يحدد المتطلبات التي تتحقق منها تلك الاختبارات.

اربط معايير القبول بفحوصات محددة. عند إصلاح خطأ برمجي، اطلب دليلاً على أن اختبار إعادة إنتاج الخطأ قد فشل قبل التغيير ونجح بعده. اجعل المعايير التي لم يتم اختبارها مرئية بدلاً من اعتبار أمر واحد ناجح بمثابة تحقق من التغيير بأكمله.

قد يحتوي ملف CLAUDE.md المتوسع على أوامر قديمة وقواعد مكررة وتعليمات تتعارض مع المتطلبات الخاصة بالمهمة. ولا تؤدي إضافة صياغة أكثر صرامة إلى حل هذه التعارضات.

قم بمراجعة الملف مقارنةً بالمستودع الحالي. قم بإزالة الإرشادات التي عفا عليها الزمن، وتوضيح القواعد المتعارضة، ونقل التعليمات ذات التطبيق المحدود إلى قواعد أو مهارات محددة النطاق. إذا كان هناك متطلب يحتاج إلى فرض، فقم بتكوين واختبار الضوابط المناسبة بدلاً من الاعتماد على التذكيرات المتكررة.

يمكن أن تكشف المراجعة عن عيوب حقيقية ومخاوف غير مؤكدة واقتراحات اختيارية لإعادة هيكلة الكود في آن واحد. وقد يؤدي تطبيق كل اقتراح إلى توسيع نطاق التغيير دون تحسين السلوك المطلوب.

اطلب الأدلة والتأثيرات الكامنة وراء كل نتيجة. أعط الأولوية لمشكلات الدقة والمتطلبات غير المستوفاة، وتحقق من الادعاءات غير المؤكدة، واستبعد التحسينات غير ذات الصلة من الفروق الحالية. يجب أن يكون المراجع قادرًا على الإبلاغ بعدم وجود نتائج قابلة للتنفيذ عندما تدعم الأدلة هذا الاستنتاج.

لتكييف القالب، استبدل العناصر النائبة فيه بتفاصيل من مشروعك وحدد ما يجب أن يفعله Claude قبل إجراء التغييرات. اتبع هذه الخطوات لإعداد الطلب ومراجعة النتيجة.

بالنسبة للتغييرات الصغيرة والمحددة جيدًا، يمكنك أن تطلب من Claude تنفيذها مباشرةً. أما بالنسبة للكود غير المألوف، أو التغييرات التي تشمل عدة ملفات، أو المتطلبات التي لم يتم حلها بعد، فابدأ بوضع خطة.

اضغط على Shift+Tab حتى يظهر وضع «التخطيط» (Plan)، أو قم بتشغيل Claude Code باستخدام الأمر claude --permission-mode plan. في هذا الوضع، يمكن لـ Claude فحص الملفات وتشغيل الأوامر للقراءة فقط دون تعديل كود المصدر الخاص بك. راجع الملفات والتبعيات والاختبارات المقترحة قبل الموافقة على التنفيذ. اضغط على Ctrl+G لفتح الخطة المقترحة في محررك.

زوّد كلود بالأدلة اللازمة لفهم المهمة: مرجع ملف، أو سجل أخطاء تم تنقيته، أو لقطة شاشة، أو وثيقة متطلبات. استخدم الرمز @ متبوعًا بمسار الملف لتضمين محتويات ذلك الملف.

اختر أصغر مجموعة مفيدة من المصادر. فقد يؤدي تضمين سجل أو دليل كامل إلى إضافة مواد غير ذات صلة واستهلاك السياق. قم بإزالة بيانات الاعتماد والبيانات الحساسة قبل مشاركة السجلات، وتأكد من أن Claude يمتلك الأدوات اللازمة لاسترداد أي عناوين URL للوثائق التي تقدمها.

على سبيل المثال، الأمر cat error.log | claude -p "Explain this error" يرسل سجلاً مع طلب غير تفاعلي. استخدمه فقط بعد التحقق من محتويات الملف. هذه هي القيمة العملية للذكاء الاصطناعي السياقي: تزويد النموذج بالمعلومات ذات الصلة بالمهمة.

عند إضافة ميزة، حدد مكونًا أو وظيفة مشابهة في المستودع. أخبر «كلود» بالمعايير التي يجب اتباعها، مثل عميل واجهة برمجة التطبيقات (API)، ومنطق التحقق من الصحة، ومعالجة الأخطاء، أو بنية الاختبار.

تمنح عبارة «تتبع كيفية قيام @src/widgets/Weather.tsx بجلب البيانات وتخزينها مؤقتًا» كلود مرجعًا ملموسًا. كما يجب تحديد أي اختلافات تتطلبها الميزة الجديدة حتى لا يتم نسخ سلوك لم يعد مناسبًا. يجب أن تعكس هذه القواعد سير عمل فريقك في تطوير البرمجيات.

بالنسبة لتغييرات الكود، حدد الأمر ذي الصلة للاختبار أو البناء أو lint والسلوك الذي يجب التحقق منه. بالنسبة للأبحاث، اطلب مراجع الملفات أو معرّفات الالتزامات. بالنسبة لأعمال واجهة المستخدم، قدم صورة مرجعية وطريقة مكونة لالتقاط التنفيذ في نفس نافذة العرض.

اطلب من «كلود» تقديم تقرير عما قام بفحصه فعليًّا، بما في ذلك حالات الفشل وعمليات الفحص التي تم تخطيها. تحقق مما إذا كانت الأدلة تغطي المتطلبات؛ فنجاح عملية البناء لا يثبت أن كل سلوك مطلوب يعمل بشكل صحيح.

بالنسبة للمهام الأطول، يوفر Claude Code أيضًا شرط /goal و«Stop hooks». يقوم مُقيّم الهدف بتقييم الأدلة التي تظهر في المحادثة بدلاً من فحص الملفات أو إجراء الاختبارات بشكل مستقل. يمكن لـ«Stop hook» المُهيأ أن يمنع إتمام المهمة، ولكنه يخضع لقيود على الحجب المتكرر. ولا يحل أي منهما محل الاختبارات المناسبة والمراجعة البشرية.

إذا لم تؤدِ التصحيحات المتكررة إلى حل المشكلة، فتوقف وحدد ما الذي لم يتضح في الطلب الأصلي. احفظ النتائج المفيدة، وحالة Git الحالية، والعمل المتبقي قبل مسح المحادثة.

يوصي دليل أفضل الممارسات الصادر عن Anthropic بالبدء من جديد بعد محاولتين فاشلتين لتصحيح نفس المشكلة. استخدم الأمر /clear، ثم أدخل موجهًا منقحًا يتضمن ما تعلمته. لا يؤدي مسح المحادثة إلى التراجع عن التغييرات التي أُجريت على الملفات.

اضغط على مفتاح Esc لمقاطعة استجابة قيد التشغيل. عندما يكون حقل الإدخال فارغًا، اضغط على مفتاح Esc مرتين لفتح قائمة «الرجوع» واختيار ما تريد استعادته. لا تلغي ميزة «الرجوع» كل التأثيرات الخارجية، لذا استخدم نقاط فحص Git وإجراءات استعادة منفصلة للتغييرات التي تطرأ على قواعد البيانات أو الخدمات البعيدة.

احفظ الإرشادات الخاصة بالمشروع بأكمله في ملف CLAUDE.md، والإجراءات القابلة للتكرار في «المهارات»، والتعليمات الخاصة بملفات معينة في القواعد ذات نطاق المسار. استخدم «الخطافات» (hooks) للإجراءات المرتبطة بأحداث محددة، مثل تشغيل أداة التنسيق بعد إجراء تعديل.

اختر بناءً على الوقت الذي يجب أن تُطبق فيه التعليمات:

عادةً ما تنتمي متطلبات ميزة ما إلى موجه المهمة أو المواصفات الخاصة بها، وليس إلى ملف CLAUDE.md. وإضافة تعليمات مؤقتة إلى ملف يشمل المشروع بأكمله يجعل من الصعب تمييزها عن القواعد التي ينبغي تطبيقها في جميع أنحاء المستودع.

على سبيل المثال، احتفظ بأمر اختبار المشروع في ملف CLAUDE.md، وضع القواعد الخاصة بالمكونات في قاعدة ذات نطاق مسار، واحفظ إجراء المراجعة المتكرر كمهارة. راجع هذه الملفات عند تغيير الأوامر أو القواعد، تمامًا كما تفعل مع وثائق المشروع الأخرى.

تعمل المطالبات وملف CLAUDE.md ودليل المهارات على توجيه سلوك Claude؛ إلا أنها لا تضمن اتباع أي تعليمات. يمكن أن تقوم «الخطافات» (hooks) بإجراء فحوصات عند وقوع أحداث محددة، لكن موثوقيتها تعتمد على نوع الخطاف وطريقة تنفيذه.

يعمل «خطاف الأوامر» (command hook) على تشغيل برنامج نصي. أما «خطاف المطالبة» (prompt hook) أو «خطاف الوكيل» (agent hook) فيعتمد على تقدير النموذج. وكما يوضح دليل أفضل الممارسات الصادر عن شركة Anthropic: «يطلب خطاف المطالبة أو خطاف الوكيل من نموذج آخر اتخاذ القرار، لذا فهو ليس حتميًا أيضًا». بالنسبة للقاعدة التي يجب تطبيقها، استخدم ضوابط الأذونات المناسبة واختبر الأمر ذي الصلة أو خطاف HTTP، بما في ذلك كيفية تعامله مع حالات الفشل.

تعد الوكلاء الفرعيون المخصصون طريقة أخرى لتنظيم الأعمال المتكررة. قم بتعريف متخصص في مجلد claude/agents/ عندما تحتاج إلى دور مراجعة متميز أو نطاق أداة محدد، بدلاً من إضافة كل تعليمات المتخصص إلى الجلسة الرئيسية. توفر هذه الأدلة الخاصة بأفضل نموذج Claude للعمل وأنواع وكلاء الذكاء الاصطناعي سياقًا إضافيًا.

إذا كان فريقك يدير المطالبات عبر عدة منتجات للذكاء الاصطناعي، فاطلع على أدوات هندسة المطالبات هذه لإدارة المكتبات خارج نطاق Claude Code.

عندما تسفر جلسة العمل عن نتيجة غير مكتملة أو غير مناسبة، تحقق مما إذا كان الطلب قد ترك قرارات مهمة دون حل. فهذه الأخطاء الخمسة قد تجعل تشخيص المشكلة ومراجعتها أكثر صعوبة.

تمنح عبارة «تحقق من المستودع» كلود توجيهات قليلة بشأن الملفات المهمة أو متى يتوقف. وقد تتلقى ملخصًا عامًا دون إجابة على المشكلة التي دفعتك إلى إرسال الطلب.

حدد السلوك أو القرار الذي تحتاج إلى فهمه، وحدد نقطة البداية، وحدد الناتج المتوقع. على سبيل المثال: «تتبع كيفية قيام نقطة النهاية هذه بالتحقق من الأذونات واذكر الوظائف ذات الصلة». إذا كنت تستخدم وكلاء فرعيين، فاطرح على كل واحد منهم سؤالًا محددًا بدلاً من تفويضهم بنفس البحث غير المقيد.

التنقل بين ميزة ما، وخطأ غير ذي صلة، وطلب توثيق، يترك المحادثة محملة بسياق قد لا ينطبق على المهمة الحالية. وتصبح الإشارات مثل «ذلك الملف» أو «النهج السابق» غامضة.

استخدم جلسات منفصلة للأعمال غير ذات الصلة. إذا كانت هناك جلسات متعددة ستقوم بتحرير المستودع، فاستخدم أشجار عمل Git منفصلة حتى لا تقوم بتعديل نفس دليل العمل. ولطرح سؤال جانبي موجز، فإن الأمر /btw في Claude Code يبقي التبادل خارج سجل المحادثة الرئيسي.

قد ينجح البناء (build) رغم أن إحدى الميزات تعمل بشكل غير صحيح. وقد تنجح مجموعة الاختبارات لأنها لم تختبر أبدًا المدخلات التي تؤدي إلى الفشل. إن مطالبة «كلود» بـ«تشغيل الاختبارات» لا يحدد المتطلبات التي تتحقق منها تلك الاختبارات.

اربط معايير القبول بفحوصات محددة. عند إصلاح خطأ برمجي، اطلب دليلاً على أن اختبار إعادة إنتاج الخطأ قد فشل قبل التغيير ونجح بعده. اجعل المعايير التي لم يتم اختبارها ظاهرة للعيان بدلاً من اعتبار أمر واحد ناجح بمثابة تحقق من التغيير بأكمله.

قد يحتوي ملف CLAUDE.md المتوسع على أوامر قديمة وقواعد مكررة وتعليمات تتعارض مع المتطلبات الخاصة بالمهمة. ولا تؤدي إضافة صياغة أكثر صرامة إلى حل هذه التعارضات.

قم بمراجعة الملف مقارنةً بالمستودع الحالي. قم بإزالة الإرشادات التي عفا عليها الزمن، وتوضيح القواعد المتعارضة، ونقل التعليمات ذات التطبيق المحدود إلى قواعد أو مهارات محددة النطاق. إذا كان هناك متطلب يحتاج إلى فرض، فقم بتكوين واختبار الضوابط المناسبة بدلاً من الاعتماد على التذكيرات المتكررة.

يمكن أن تكشف المراجعة عن عيوب حقيقية ومخاوف غير مؤكدة واقتراحات اختيارية لإعادة هيكلة الكود في آن واحد. وقد يؤدي تطبيق كل اقتراح إلى توسيع نطاق التغيير دون تحسين السلوك المطلوب.

اطلب الأدلة والتأثيرات الكامنة وراء كل نتيجة. أعط الأولوية لمشكلات الدقة والمتطلبات غير المستوفاة، وتحقق من الادعاءات غير المؤكدة، واستبعد التحسينات غير ذات الصلة من الفروق الحالية. يجب أن يكون المراجع قادرًا على الإبلاغ بعدم وجود نتائج قابلة للتنفيذ عندما تدعم الأدلة هذا الاستنتاج.