يُعطي معظم الناس prompts لـ Claude Code بنفس الطريقة التي يُعطون بها prompts لـ ChatGPT. هنا الخلل.

ChatGPT محرّك أسئلة وأجوبة. Claude Code وكيل. شكل السؤال الجيّد ليس شكل الهدف الجيّد.

بعد سنة من تشغيل Claude Code على قواعد كود إنتاجية، اختصرته إلى أربعة أقسام يجب أن تكون دائمًا في الـ prompt:

• الهدف — كيف يبدو النجاح.
• القيود — ما لا يجب أن يتغيّر.
• تعريف الإنجاز — كيف يعرف الوكيل أنّه انتهى.
• السياق — مؤشّرات على الملفات / التذاكر / الأخطاء ذات الصلة.

اترك أحدها وستحصل على انحراف. ضمّن الأربعة، وسيشتغل الوكيل بهدوء لمدّة 5 دقائق ويعود بـ diff نظيف.

الـ prompt السيّئ

> أعد هيكلة خدمة المستخدم للأداء.

لماذا يفشل:

• "الأداء" غير معرّف. زمن الاستجابة؟ الذاكرة؟ الإنتاجية؟
• لا قيود — قد يعيد كتابة مخطّط قاعدة البيانات.
• لا تعريف للإنجاز — يتوقّف حين يملّ.
• لا سياق — عليه أن يُخمّن أيّ ملفّ هو "خدمة المستخدم".

ستحصل على شيء يبدو كأنّه عمل لكنّه ليس كذلك.

الـ prompt الجيّد

> الهدف: تخفيض زمن الاستجابة p95 لـ GET /api/users/:id من 240 ms إلى أقلّ من 80 ms.
>
> القيود:
> - لا تغيّر شكل الـ API العام.
> - لا تُضف اعتماديات جديدة.
> - أبقِ الكود في app/api/users — لا طبقات جديدة.
>
> تعريف الإنجاز:
> - الاختبارات الحالية تنجح.
> - أضف load test (50 استدعاءً متزامنًا × 100 تكرار).
> - p95 < 80 ms محليًا على Node 20.
> - أضف وصف PR من فقرة واحدة.
>
> السياق:
> - app/api/users/route.ts هو نقطة الدخول.
> - lib/db/users.ts يحوي استعلام N+1 البطيء.
> - نستعمل Postgres 15 و drizzle ORM.

نفس المهمّة. نتيجة مختلفة. سيقوم الوكيل بـ:

1. قراءة الملفّين.
2. تحديد N+1.
3. كتابة الإصلاح بطلب مُجمَّع واحد.
4. إضافة الـ load test.
5. تشغيل الاختبار وتأكيد الرقم.
6. تسليم diff مع وصف PR.

هذا تفويض، ليس إكمالاً تلقائيًا.

لماذا يهمّ كلّ قسم

الهدف

اكتبه كنتيجة، لا كفعل. "تخفيض p95 إلى 80 ms" نتيجة. "إعادة هيكلة استدعاءات قاعدة البيانات" فعل — وسيقوم وكيل ضعيف بالفعل دون بلوغ النتيجة.

القيود

القيود هي ما قد يفاجئك. إن كان مهندس مبتدئ يعيد كتابة الملفّ ويفاجئك بتغيير شكل الـ API، اكتب ذلك. إن كان قد يفاجئك بإضافة Redis، اكتب ذلك.

أغلب قصص "Claude Code فعل شيئًا غريبًا" هي قيود ناقصة، لا ذكاء ناقص.

تعريف الإنجاز

الجزء الأكثر إهمالًا في أيّ prompt. بدونه، يتوقّف الوكيل حين يظنّ المهمة منتهية — عادة بعد كتابة الكود، قبل تشغيل الاختبارات.

تعريفات الإنجاز الجيّدة قابلة للاختبار:

• "الاختبارات الحالية تنجح."
• "نقطة النهاية الجديدة ترجع 201 وheader Location صالحًا."
• "lighthouse-ci لا يُظهر أيّ تراجع على الصفحة الرئيسية."

إن لم تستطع كتابة DoD، فالمهمّة ليست جاهزة للتفويض.

السياق

لست مضطرًا للصق الملفات. تكفي المؤشّرات:

• app/api/users/route.ts — نقطة الدخول.
• tests/api/users.test.ts — اختبارات قائمة.
• "رأينا التراجع في PR #842."

يستطيع Claude Code القراءة والبحث. يحتاج فقط أن تشير إلى الحيّ الصحيح.

قالب 80/20 الذي أحتفظ به في .claude/commands/

# /goal — الصق هذا القالب، املأ الفراغات

الهدف: <نتيجة برقم إن أمكن>

القيود:
- <شيء لا يجب أن يتغيّر>
- <قاعدة اعتماديّة>
- <قاعدة أسلوب أو هندسة>

تعريف الإنجاز:
- <أمر اختبار ينجح>
- <فحص أداء أو صحّة>
- <وصف PR في فقرة>

السياق:
- <ملفّ أو مجلّد>
- <تذكرة / خطأ / log ذو صلة>

اختصاره كـ slash command يجعل كتابة prompt ميزة جديدة تستغرق 90 ثانية. سنغطّي الـ slash commands جيدًا في المقال 4.

أنماط مضادّة يجب التخلّي عنها اليوم

• "اجعله أنظف." أنظف وفق أيّ مقياس؟ اختر: عدد الأسطر، التعقيد الدوري، أو قاعدة lint محدّدة.
• "أصلح الخلل." أيّ خلل؟ ما السلوك المتوقّع؟ والفعلي؟
• "أعد الهيكلة من أجل القراءة." القراءة ذوق. اختر نمطًا ملموسًا: "استخرج إلى دوال نقيّة"، "استبدل الـ ifs المتداخلة بـ early returns".

prompts غامضة تنتج كودًا غامضًا. الوكيل مرآة.

حيلة أخيرة: "المثال السلبي"

أحيانًا الطريقة الأنظف لتقييد الوكيل هي إظهار ما لا يجب فعله.

> لا تضف طبقة تجريد جديدة.
> المحاولة السابقة أضافت كلاسًا UserRepository — أزلناه.
> ينبغي أن يكون الإصلاح ~20 سطرًا في lib/db/users.ts، لا 200 سطر.

فعّال بشكل قاسٍ. تستبق الوضع الأكثر شيوعًا لفشل الوكيل المتحمّس: بناء مملكة حين تكفي دالّة واحدة.

---

المقال التالي: Slash commands — كيف تحوّل قالب الـ prompt أعلاه إلى أمر /feature بضغطة واحدة، وكيف تربط /init و /agents و /compact لبناء هيكل مشروع كامل في جلسة واحدة.