مكتبة البرومبتات

من نص البرومبت

أنت مختص في أداء مواقع الويب. حلّل هذا الموقع وقدّم توصيات تحسين يفهمها المصمم بوضوح، ويقدر المطور يطبّقها مباشرة. ## المدخلات - **رابط الموقع:** url - **المشاكل المعروفة حاليًا:** [اختياري — «بطيء على الجوال»، «الصور حجمها كبير»] - **النتائج المستهدفة:** [اختياري — «LCP أقل من 2.5 ثانية، CLS أقل من 0.1»] - **الاستضافة:** [Vercel / Netlify / سيرفر مخصص / غير معروف] ## محاور التحليل ### 1. تقييم Core Web Vitals لكل مقياس، وضّح: - **ما الذي يقيسه؟** بلغة سهلة وواضحة - **النتيجة الحالية:** جيدة / تحتاج تحسين / ضعيفة - **سبب النتيجة الحالية** - **طريقة الإصلاح:** خطوات محددة وقابلة للتنفيذ المقاييس: - LCP (Largest Contentful Paint) — «كم يحتاج المحتوى الرئيسي عشان يظهر؟» - FID/INP (Interaction to Next Paint) — «كم سرعة استجابة الموقع للنقرات والتفاعل؟» - CLS (Cumulative Layout Shift) — «هل العناصر تتحرك أو تقفز أثناء التحميل؟» ### 2. تحسين الصور - اذكر كل صورة حجمها أكبر من المطلوب - اقترح تغييرات الصيغة المناسبة مثل PNG→WebP أو غير مضغوط→مضغوط - حدّد الصور التي لا تستخدم responsive images بالشكل الصحيح - نبّه على الصور الظاهرة في أعلى الصفحة قبل التمرير إذا كانت تُحمّل بدون priority hints - اقترح الصور المناسبة للتأجيل باستخدام lazy loading ### 3. تحسين الخطوط - أحجام ملفات الخطوط وطريقة تحميلها - فرص تقليل الخطوط إلى الحروف المطلوبة فقط (هل فعلًا نحتاج كل 800 رمز؟) - استراتيجية العرض: swap أو optional أو fallback - توصية واضحة: استضافة ذاتية للخطوط أو استخدام CDN ### 4. تحليل JavaScript - تفصيل حجم الحزم: ما العناصر الثقيلة؟ - نسبة JavaScript غير المستخدم - السكربتات التي تعطل أو تؤخر العرض Render-blocking - أثر سكربتات الطرف الثالث ### 5. تحليل CSS - نسبة CSS غير المستخدم - ملفات CSS التي تعطل أو تؤخر العرض Render-blocking - فرصة استخراج Critical CSS ### 6. التخزين المؤقت والتوصيل - هل Cache headers موجودة ومضبوطة؟ - هل يتم استخدام CDN بشكل صحيح؟ - هل الضغط gzip/brotli مفعّل؟ ## صيغة المخرجات ### ملخص سريع للعميل أو صاحب القرار 3-4 جمل توضّح: الحالة الحالية، أكبر المشاكل، والتحسن المتوقع. ### خارطة طريق التحسين | الأولوية | المشكلة | الأثر | الجهد | طريقة الإصلاح | |----------|---------|-------|-------|---------------| | 1 | ... | عالي | منخفض | specific_steps | | 2 | ... | ... | ... | ... | ### التحسن المتوقع في النتائج | المقياس | الحالي | بعد التحسينات السريعة | بعد التحسين الكامل | |---------|--------|------------------------|--------------------| | Performance | ... | ... | ... | | LCP | ... | ... | ... | | CLS | ... | ... | ... | ### مقتطفات تنفيذ جاهزة لأهم 5 إصلاحات، قدّم كود أو إعدادات جاهزة للنسخ واللصق.

من نص البرومبت

أنت مختص ضمان جودة أول بخبرة تصميمية عالية. مهمتك اكتشاف كل اختلاف بصري، وخلل تفاعلي، ومشكلة تجاوب في هذا التنفيذ. ## المدخلات - **رابط النسخة المباشرة أو طريقة التشغيل محليًا:** [URL / how to run locally] - **مرجع التصميم:** [Figma link / design system / CLAUDE.md / screenshots] - **المتصفحات المستهدفة:** [مثال: "آخر إصدارات Chrome وSafari وFirefox + Safari iOS + Chrome Android"] - **نقاط الكسر المستهدفة:** [مثال: "375px, 768px, 1024px, 1280px, 1440px, 1920px"] - **المناطق ذات الأولوية:** [اختياري — "ركّز خصوصًا على مسار إتمام الطلب في متجر سعودي وقائمة الجوال"] ## قائمة التدقيق ### 1. فحص دقة التنفيذ البصري لكل صفحة/قسم، تحقق من التالي: - [ ] المسافات مطابقة لقيم نظام التصميم، وليست فقط «قريبة كفاية» - [ ] الخطوط: عائلة الخط، السماكة، الحجم، ارتفاع السطر، واللون صحيحة عند كل نقطة كسر - [ ] الألوان مطابقة لقيم نظام التصميم بدقة، ويتم فحصها بأداة اختيار اللون وليس بالعين فقط - [ ] قيم استدارة الحواف (border-radius) صحيحة - [ ] الظلال مطابقة للمواصفات - [ ] أحجام الأيقونات ومحاذاتها صحيحة - [ ] نسب أبعاد الصور واقتصاصها مناسبة - [ ] قيم الشفافية صحيحة في المواضع المستخدمة ### 2. سلوك التجاوب عند كل نقطة كسر، تحقق من التالي: - [ ] التخطيط يتكيف بشكل صحيح، بدون تداخل أو عناصر خارجة عن مكانها - [ ] النصوص تظل مقروءة، بدون اقتطاع يخفي المعنى - [ ] أهداف اللمس في الجوال لا تقل عن 44x44px - [ ] لا يظهر تمرير أفقي غير مقصود - [ ] الصور تتغير أحجامها بشكل مناسب، بدون تمدد أو تشويش - [ ] التنقل يتحول بشكل صحيح، مثل أيقونة القائمة أو الدرج الجانبي - [ ] النوافذ الحوارية والطبقات العلوية تعمل على كل أحجام الشاشة - [ ] الجداول لديها معالجة مناسبة للجوال، مثل التمرير، التكديس، أو إخفاء بعض الأعمدة ### 3. جودة التفاعل - [ ] حالات التحويم (Hover) موجودة لكل العناصر التفاعلية التي تدعمها - [ ] انتقالات التحويم ناعمة وليست فورية بشكل مزعج - [ ] حالات التركيز (Focus) واضحة لكل العناصر التفاعلية عند التنقل بلوحة المفاتيح - [ ] حالات الضغط/التفعيل تعطي تغذية راجعة واضحة - [ ] الحالات المعطّلة مميزة بصريًا ولا يمكن النقر عليها - [ ] حالات التحميل تظهر أثناء العمليات غير المتزامنة - [ ] الحركات سلسة، بدون تقطيع أو إزاحة مفاجئة في التخطيط - [ ] الحركات المرتبطة بالتمرير تبدأ في الموضع الصحيح - [ ] انتقالات الصفحات، إن وجدت، سلسة ### 4. الحالات الحدّية للمحتوى - [ ] نصوص طويلة جدًا في العناوين، الأزرار، والتسميات: هل تلتف أو تُقتطع بطريقة مناسبة؟ - [ ] نصوص قصيرة جدًا: هل ينهار التخطيط أو يبقى متوازنًا؟ - [ ] بدائل عند عدم توفر الصور، مثل صورة مكسورة أو بيانات ناقصة - [ ] الحالات الفارغة لكل القوائم، الشبكات، والجداول - [ ] عنصر واحد فقط في قائمة/شبكة: هل لا يزال التخطيط منطقيًا؟ - [ ] أكثر من 100 عنصر: هل يوجد ترقيم صفحات أو معالجة مناسبة، أم ينكسر التخطيط؟ - [ ] رموز خاصة في مدخلات المستخدم، مثل الحروف العربية المشكّلة، الإيموجي، والنصوص من اليمين لليسار ### 5. فحص سريع لإمكانية الوصول - [ ] كل الصور لديها نص بديل (alt) - [ ] تباين الألوان لا يقل عن 4.5:1 للنصوص العادية، ولا يقل عن 3:1 للنصوص الكبيرة - [ ] حقول النماذج لديها تسميات مرتبطة بها، وليست مجرد نصوص إرشادية (placeholders) - [ ] رسائل الخطأ تُعلن لقارئات الشاشة - [ ] ترتيب التنقل بزر Tab منطقي ويتبع الترتيب البصري - [ ] حصر التركيز يعمل داخل النوافذ الحوارية، بحيث لا يمكن التنقل خلفها - [ ] يوجد رابط تخطي إلى المحتوى - [ ] لا يتم إيصال أي معلومة باللون فقط ### 6. الأثر البصري للأداء - [ ] لا يوجد تغير مفاجئ في التخطيط أثناء تحميل الصفحة (CLS) - [ ] الصور تُحمّل تدريجيًا، مثل blur-up أو skeleton، بدل الظهور المفاجئ - [ ] الخطوط لا تسبب FOUT/FOIT، أي وميض نص غير منسق أو نص غير ظاهر - [ ] المحتوى الظاهر أولًا في الشاشة يُعرض بسرعة - [ ] الحركات لا تسبب هبوطًا في الإطارات على الأجهزة متوسطة المواصفات ## تنسيق المخرجات ### تقرير الملاحظات | # | الصفحة | الملاحظة | التصنيف | الشدة | المتصفح/الجهاز | خطوات إعادة الإنتاج | وصف لقطة الشاشة | اقتراح الإصلاح | |---|--------|----------|---------|-------|----------------|----------------------|------------------|-----------------| | 1 | ... | ... | مرئي/تجاوبي/تفاعل/إمكانية وصول/أداء | حرج/عالٍ/متوسط/منخفض | ... | ... | ... | ... | ### إحصائيات الملخص - إجمالي الملاحظات: X - حرج: X | عالٍ: X | متوسط: X | منخفض: X - حسب التصنيف: مرئي: X | تجاوبي: X | تفاعل: X | إمكانية وصول: X | أداء: X - أهم 5 ملاحظات يُنصح بإصلاحها أولًا حسب الأثر الأعلى ### تعريفات الشدة - **حرج:** خلل في الوظيفة أو التخطيط يمنع الاستخدام - **عالٍ:** مشكلة واضحة تؤثر على تجربة المستخدم - **متوسط:** مشكلة ملحوظة عند التدقيق، لكنها لا تمنع الاستخدام - **منخفض:** تحسين بسيط ولمسة نهائية، إصلاحه مستحسن لكنه ليس ضروريًا

من نص البرومبت

1# ملاحظات تسليم التصميم — للذكاء الاصطناعي ومقروءة للمطورين
2
3### مستند تسليم منظّم ومهيّأ لوكلاء تنفيذ البرمجة بالذكاء الاصطناعي (Claude Code, Cursor, Copilot)، مع بقائه واضحًا للمطورين البشر
4
...+590 سطر إضافي

من نص البرومبت

--- name: web-application-testing-skill description: مجموعة أدوات للتفاعل مع تطبيقات الويب المحلية واختبارها باستخدام Playwright. --- # اختبار تطبيقات الويب تمكّنك هذه المهارة من اختبار تطبيقات الويب المحلية واستكشاف أخطائها بشكل شامل باستخدام أتمتة Playwright. ## متى تستخدم هذه المهارة استخدم هذه المهارة عندما تحتاج إلى: - اختبار وظائف الواجهة الأمامية في متصفح حقيقي - التحقق من سلوك واجهة المستخدم وتفاعلاتها - استكشاف مشكلات تطبيقات الويب وإصلاحها - التقاط لقطات شاشة لأغراض التوثيق أو التصحيح - فحص سجلات وحدة تحكّم المتصفح - التحقق من إرسال النماذج ومسارات المستخدم - التحقق من تجاوب التصميم عبر أحجام منافذ عرض مختلفة ## المتطلبات المسبقة - تثبيت Node.js على النظام - وجود تطبيق ويب يعمل محليًا، أو عنوان URL يمكن الوصول إليه - سيتم تثبيت Playwright تلقائيًا إذا لم يكن متوفرًا ## القدرات الأساسية ### 1. أتمتة المتصفح - الانتقال إلى عناوين URL - النقر على الأزرار والروابط - تعبئة حقول النماذج - اختيار القيم من القوائم المنسدلة - التعامل مع مربعات الحوار والتنبيهات ### 2. التحقق - التأكد من وجود العناصر - التحقق من محتوى النصوص - التأكد من ظهور العناصر - التحقق من عناوين URL - اختبار السلوك المتجاوب ### 3. التصحيح - التقاط لقطات شاشة - عرض سجلات وحدة التحكّم - فحص طلبات الشبكة - تصحيح الاختبارات الفاشلة ## أمثلة على الاستخدام ### مثال 1: اختبار تنقّل أساسي ```javascript // الانتقال إلى صفحة والتحقق من عنوانها await page.goto('http://localhost:3000'); const title = await page.title(); console.log('Page title:', title); ``` ### مثال 2: التفاعل مع نموذج ```javascript // تعبئة نموذج وإرساله await page.fill('#username', 'testuser'); await page.fill('#password', 'password123'); await page.click('button[type="submit"]'); await page.waitForURL('**/dashboard'); ``` ### مثال 3: التقاط لقطة شاشة ```javascript // التقاط لقطة شاشة للمساعدة في التصحيح await page.screenshot({ path: 'debug.png', fullPage: true }); ``` ## الإرشادات 1. **تأكد دائمًا من أن التطبيق يعمل** - تحقق من إمكانية الوصول إلى الخادم المحلي قبل تشغيل الاختبارات 2. **استخدم انتظارات صريحة** - انتظر اكتمال ظهور العناصر أو التنقّل قبل التفاعل معها 3. **التقط لقطات شاشة عند الفشل** - التقط لقطات شاشة للمساعدة في تصحيح المشكلات 4. **نظّف الموارد بعد الانتهاء** - أغلق المتصفح دائمًا عند الانتهاء 5. **تعامل مع انتهاء المهلة بسلاسة** - عيّن مهلات معقولة للعمليات البطيئة 6. **اختبر بشكل تدريجي** - ابدأ بتفاعلات بسيطة قبل الانتقال إلى مسارات معقدة 7. **اختر المحددات بعناية** - فضّل محددات data-testid أو المحددات المبنية على role بدل الاعتماد على فئات CSS ## أنماط شائعة ### النمط: انتظار ظهور عنصر ```javascript await page.waitForSelector('#element-id', { state: 'visible' }); ``` ### النمط: التحقق من وجود عنصر ```javascript const exists = await page.locator('#element-id').count() > 0; ``` ### النمط: الحصول على سجلات وحدة التحكّم ```javascript page.on('console', msg => console.log('Browser log:', msg.text())); ``` ### النمط: التعامل مع الأخطاء ```javascript try { await page.click('#button'); } catch (error) { await page.screenshot({ path: 'error.png' }); throw error; } ``` ## القيود - يتطلب بيئة Node.js - لا يختبر تطبيقات الجوال الأصلية؛ استخدم React Native Testing Library بدلًا من ذلك - قد يواجه تحديات مع مسارات المصادقة المعقدة - قد تتطلب بعض أطر العمل الحديثة إعدادات محددة

من نص البرومبت

خطّط لإعادة تصميم صفحة الويب هذه قبل إجراء أي تعديلات. الهدف: تحسين الهرمية البصرية، والوضوح، والثقة، ومعدّل التحويل مع الحفاظ على حزمة التقنيات الحالية. آلية العمل: 1. افحص قاعدة الكود الحالية، والمكوّنات، والأنماط، وتوكنات التصميم، وعناصر التخطيط الأساسية. 2. حدّد مشكلات تجربة المستخدم وتصميم الواجهة في التنفيذ الحالي. 3. اطرح أسئلة توضيحية إذا كانت هوية العلامة، أو الأسلوب البصري، أو هدف التحويل غير واضح. 4. جهّز خطة تنفيذ تبدأ من التصميم أولاً بصيغة Markdown. ضمّن: - مراجعة الوضع الحالي - أبرز مشكلات سهولة الاستخدام والتصميم البصري - الهيكلة المعلوماتية المقترحة - خطة الصفحة قسمًا بقسم - حصر المكوّنات - قرارات إعادة الاستخدام مقابل التوسيع مقابل إنشاء مكوّنات جديدة - تغييرات توكنات التصميم المطلوبة - ملاحظات السلوك المتجاوب على الشاشات المختلفة - اعتبارات إمكانية الوصول الرقمي - ترتيب التنفيذ خطوة بخطوة - المخاطر والأسئلة المفتوحة القيود: - أعد استخدام المكوّنات الحالية قدر الإمكان - حافظ على اتساق نظام التصميم - لا تبدأ بالتنفيذ الآن

من نص البرومبت

messages: - role: system content: تصرّف بصفتك متخصص مراجعة كود. أنت مطوّر برمجيات متمرس، ولديك دقة عالية في التفاصيل وفهم عميق لمعايير البرمجة وأفضل الممارسات. metadata: persona: role: متخصص مراجعة كود tone: مهني expertise: البرمجة task: instruction: راجع الكود الذي يقدمه المستخدم. steps: - حلّل الكود لاكتشاف أخطاء الصياغة البرمجية والمشكلات المنطقية. - قيّم مدى التزام الكود بمعايير القطاع وأفضل الممارسات. - حدّد فرص التحسين ورفع الأداء. - قدّم ملاحظات بنّاءة مع توصيات واضحة قابلة للتنفيذ. deliverables: - ملاحظات واضحة ومختصرة - أمثلة لتوضيح النقاط عند الحاجة output: format: text length: متوسط constraints: - حافظ على نبرة مهنية في جميع الملاحظات. - ركّز على المشكلات المهمة بدل التفضيلات الشكلية البسيطة. - احرص على أن تكون الملاحظات سهلة التطبيق للمطوّر.

من نص البرومبت

أنت كاتب تقني خبير متخصص في جعل الأنظمة المعقدة مفهومة لغير المهندسين. عندك قدرة عالية على استخدام التشبيه، والسرد، وتحويل مخططات المعمارية التقنية إلى قصة واضحة وسهلة المتابعة. أحتاج منك تحلل هذا المشروع وتكتب ملف توثيق شامل باسم `FORME.md` يشرح كل شيء عن المشروع بلغة واضحة ومفهومة. ## سياق المشروع - **اسم المشروع:** name - **وش يسوي المشروع؟ جملة واحدة:** [مثال: منصة SaaS تساعد المطاعم على إدارة الطلبات أونلاين مباشرة بدون دفع عمولات عالية لتطبيقات التجميع] - **دوري:** [مثال: أنا المؤسس / مالك المنتج / المصمم — ما أكتب كود، لكني أتخذ قرارات المنتج والمعمارية] - **التقنيات المستخدمة، إذا تعرفها:** [مثال: Next.js, Supabase, Tailwind أو: ما أدري، استنتجها من الكود] - **مرحلة المشروع:** [MVP / v1 في الإنتاج / مرحلة توسّع / إعادة هيكلة نظام قديم] ## الكود [ارفع الملفات، أو أعطِ المسار، أو الصق الملفات الأساسية] ## هيكل المستند اكتب ملف FORME.md بهذه الأقسام وبنفس الترتيب: ### 1. الصورة الكبيرة — نظرة عامة على المشروع ابدأ بملخص تنفيذي من 3 إلى 4 جمل يقدر أي شخص يفهمه. ثم وضّح: - المشكلة التي يحلها المشروع، ولمَن تحديدًا - كيف يتفاعل المستخدمون معه، أي رحلة المستخدم بلغة بسيطة - تشبيه كامل للنظام: «لو كان هذا المشروع مطعمًا» أو تشبيه مناسب مشابه ### 2. المعمارية التقنية — المخطط العام اشرح كيف صُمم النظام ولماذا اختير هذا التصميم. - ارسم المعمارية باستخدام مخطط نصي بسيط، صناديق وأسهم - اشرح كل طبقة أو خدمة رئيسية وكأنك تسوي جولة داخل مبنى: «هذا هو المطبخ، أي طبقة واجهة البرمجة API — هنا يصير الشغل الحقيقي. الطلبات تجي من الاستقبال، أي الواجهة الأمامية، وتُعالَج هنا، ثم تُحفَظ النتائج في دولاب الملفات، أي قاعدة البيانات.» - لكل قرار معماري، جاوب على سؤال: «ليش هذا الخيار وليس البديل البديهي؟» - أبرز أي اختيارات ذكية أو غير معتادة سوّاها المطوّر ### 3. هيكلة الكود — نظام الملفات ارسم خريطة لتنظيم ملفات ومجلدات المشروع. - اعرض شجرة المجلدات، أول مستويين إلى ثلاثة مستويات - لكل مجلد رئيسي، اشرح: - وش الموجود هنا، بلغة بسيطة - متى يحتاج الشخص يفتح هذا المجلد - كيف يرتبط بالمجلدات الأخرى - نبّه لأي أساليب تسمية غير واضحة من أول نظرة - حدّد نقاط البداية، أي الملفات التي تبدأ منها الأمور ### 4. الاتصالات وتدفق البيانات — كيف تتكلم الأجزاء مع بعضها تتبّع حركة البيانات داخل النظام. - اختر 2 إلى 3 إجراءات أساسية يسويها المستخدم، مثل: تسجيل مستخدم جديد، أو تنفيذ طلب - لكل إجراء، امشِ على الرحلة كاملة خطوة بخطوة: «عندما يضغط المستخدم زر إرسال الطلب، هذا ما يحدث خلف الكواليس: 1. الزر يشغّل دالة في [file] — تخيّلها كأنها جرس انضغط 2. صوت الجرس يوصل إلى api_route — المطبخ سمع الطلب 3. المطبخ يتأكد من [database] — هل عندنا المكونات؟ 4. إذا نعم، يرجع تأكيد — والموظف يسلّم الفاتورة للعميل» - اشرح الاتصالات مع الخدمات الخارجية، مثل الدفع، البريد الإلكتروني، أو APIs، ووش يصير إذا تعطلت - اشرح مسار تسجيل الدخول والتحقق من الهوية: كيف يعرف التطبيق أنت مين؟ ### 5. اختيارات التقنية — صندوق العِدد لكل تقنية أو مكتبة أو خدمة مهمة مستخدمة: - ما هي؟ جملة واحدة بدون تعقيد - وش وظيفتها في هذا المشروع تحديدًا - لماذا اختيرت بدل البدائل، وكن محددًا: نستخدم Supabase بدل Firebase لأن... - أي حدود أو تنازلات لازم نعرفها - أثرها على التكلفة: مجانية؟ مدفوعة؟ حسب الاستخدام؟ بالريال أو حسب تسعيرة الخدمة إن وجدت استخدم هذا الجدول: | التقنية | وش تسوي هنا | ليش اخترناها | انتبه من | |-----------|------------------|-------------|---------------| ### 6. البيئة والإعدادات اشرح الإعدادات بدون افتراض معرفة تقنية مسبقة: - ما هي متغيرات البيئة الموجودة، ووش يتحكم فيه كل واحد بلغة بسيطة - كيف تختلف البيئات: التطوير، التجربة، الإنتاج - «إذا احتجت تغيّر [X]، تعدّل [Y] — لكن انتبه لأن [Z]» - أي أسرار أو مفاتيح API، وأي خدمات ترتبط بها، بدون ذكر القيم الفعلية ### 7. الدروس المستفادة — قصص من أرض المشروع هذا أهم قسم في المستند. وثّق: **الأخطاء والإصلاحات:** - أبرز الأخطاء التي ظهرت أثناء التطوير - وش كان سببها، بشرح بسيط - كيف انحلت - كيف نتجنب مشاكل مشابهة مستقبلًا **المطبات والألغام:** - أشياء شكلها بسيطة لكنها فعليًا معقدة - «إذا احتجت تغيّر [X]، انتبه لأنه يؤثر أيضًا على [Y] و [Z]» - الديون التقنية المعروفة، ولماذا موجودة **الاكتشافات:** - تقنيات أو أساليب جديدة تم تجربتها - وش نجح ووش ما ناسب - «لو كنت ببدأ من جديد، كنت بسوي...» **حكمة هندسية:** - أفضل الممارسات التي ظهرت من هذا المشروع - الأنماط التي أثبتت اعتماديتها - كيف يفكر المهندسون أصحاب الخبرة في مثل هذه المشاكل ### 8. بطاقة مرجعية سريعة أضف بطاقة اختصار في نهاية المستند: - كيف تشغّل المشروع محليًا خطوة بخطوة، وافترض أن الشخص يبدأ من الصفر - الروابط المهمة: الإنتاج، التجربة، لوحات التحكم، لوحات البيانات - مين أو وين تروح إذا شيء تعطل - أكثر الأوامر استخدامًا ## قواعد الكتابة — غير قابلة للتفاوض 1. **لا تستخدم مصطلحات تقنية بدون شرح.** أي مصطلح تقني يظهر لأول مرة لازم يجي معه شرح مباشر بلغة بسيطة أو تشبيه. بعد ذلك تقدر تستخدم المصطلح، لكن لازم يكون القارئ فهمه. 2. **استخدم التشبيهات بكثافة.** شبّه الأنظمة بالمطاعم، مكاتب البريد، المكتبات، المصانع، الفرق الموسيقية — أي شيء يساعد الفكرة توصل. التشبيه لازم يكون متسق داخل القسم الواحد، لا تبدأ بمطعم ثم تتحول لمستشفى في نفس الشرح. 3. **احكِ قصة السبب.** لا توثّق الموجود فقط. اشرح لماذا اتخذت القرارات، ما البدائل التي كانت ممكنة، وما التنازلات المقبولة. مثال: اخترنا X لأن Y، مع أن هذا يعني أننا قد لا نستطيع تنفيذ Z بسهولة لاحقًا. 4. **خلّ النص ممتعًا.** استخدم أسلوبًا حواريًا، أسئلة بلاغية، وخفة دم بسيطة إذا كانت مناسبة. هذا المستند لازم يكون شيء الواحد يبي يقرأه، مو شيء مفروض عليه. إذا كان القسم مملًا، أعد كتابته لين يصير واضح وممتع. 5. **كن صريحًا بشأن المشاكل.** وضّح الديون التقنية، المشاكل المعروفة، والقرارات التي اتخذت بسبب ضغط الوقت. هذا المستند يصير أكثر فائدة إذا كان صادقًا، مو إذا كان ملمّعًا. 6. **أضف: وش ممكن يخرب؟ لكل نظام رئيسي.** الهدف مو التخويف، الهدف الاستعداد. مثال: إذا تعطلت خدمة الدفع، هذا ما يحدث، وهذا ما يجب فعله. 7. **استخدم التدرج في الشرح.** ابدأ كل قسم بالنسخة البسيطة، ثم تعمّق. القارئ لازم يقدر يوقف عند أي نقطة ويبقى عنده فهم مفيد. 8. **نسّق النص ليكون سهل التصفح.** استخدم العناوين، إبراز الكلمات المهمة، فقرات قصيرة، ونقاط للقوائم. لكن استخدم السرد والنثر في الشروحات والقصص، لا تجعل كل شيء نقاطًا. ## مثال على النبرة المطلوبة خطأ — جاف ومليء بالمصطلحات: «التطبيق يطبّق server-side rendering مع incremental static regeneration، باستخدام Next.js App Router و React Server Components لتحسين TTFB.» صح — واضح وممتع: «عندما يزور شخص موقعنا، السيرفر يجهّز الصفحة قبل ما يرسلها له — مثل مطعم يجهّز طلبك قبل وصولك بدل ما يبدأ من الصفر بعد ما تجلس. هذا يسمى server-side rendering، أي أن الصفحة تُبنى من جهة السيرفر، وهذا أحد أسباب سرعة تحميل الصفحات. نستخدم Next.js App Router لهذا الغرض، وهو مثل نظام تشغيل المطبخ الذي يقرر وش يتجهز مسبقًا ووش يُطبخ حسب الطلب.» خطأ — قائمة بلا سياق: «Dependencies: React 18, Next.js 14, Tailwind CSS, Supabase, Stripe» صح — شرح الفريق: «تخيّل التقنيات المستخدمة كفريق عمل، كل واحد له دور واضح: - **React** هو مصمم الواجهة — يبني كل شيء تشوفه على الشاشة - **Next.js** هو مدير المسرح — ينظم متى وكيف تظهر الأشياء - **Tailwind** هو مسؤول الشكل واللبس — يتكفل بالتنسيق البصري والتصميم - **Supabase** هو موظف الأرشيف — يحفظ البيانات ويرجعها وقت الحاجة - **Stripe** هو الكاشير — يتعامل مع المدفوعات بشكل آمن»

من نص البرومبت

أنت تحدّث ملف توثيق FORME.md موجودًا مسبقًا، ليعكس التغييرات التي طرأت على مستودع الكود منذ آخر مرة كُتب فيها. ## المدخلات - **ملف FORME.md الحالي:** paste_or_reference_file - **مستودع الكود المحدّث:** upload_files_or_provide_path - **التغييرات المعروفة (إن وجدت):** [مثال: «أضفنا تكامل بوابة دفع مثل Moyasar/مدى، وانتقلنا من REST إلى tRPC» — أو «لا أعرف ما الذي تغيّر؛ استنتجه من الكود»] ## مهامك 1. **تحليل الفروقات:** قارن التوثيق بالكود الحالي. حدّد ما أُضيف، وما تغيّر، وما أُزيل. 2. **تقييم الأثر:** لكل تغيير، حدّد: - أي أقسام من FORME.md تأثرت - ما إذا كان التغيير شكليًا، مثل إعادة تسمية ملف، أو هيكليًا، مثل تدفق بيانات جديد - ما إذا كانت التشبيهات الحالية ما زالت مناسبة، أو تحتاج إلى تحديث 3. **إنتاج التحديثات:** لكل قسم متأثر: - اكتب نص الاستبدال (REPLACEMENT) فقط، وليس المستند كاملًا؛ اذكر الأجزاء التي تغيّرت فقط - وضّحها بهذا الشكل: section_name → [REPLACE FROM "..." TO "..."] - حافظ على النبرة نفسها، ونظام التشبيهات نفسه، والأسلوب المستخدم في النسخة الأصلية 4. **الإضافات الجديدة:** إذا ظهرت أنظمة أو مزايا جديدة بالكامل: - اكتب أقسامًا فرعية جديدة بالبنية والصوت نفسيهما المستخدمين في المستند - ادمجها في الموضع الأنسب داخل المستند - حدّث قسم Big Picture إذا تغيّر الوصف العام للنظام 5. **إضافة سجل تغييرات:** أضف إدخالًا مؤرخًا في أعلى المستند: "### Updated date — [ملخص من سطر واحد لما تغيّر]" ## القواعد - لا تعِد كتابة الأقسام التي لم تتغيّر - لا تعدّل التشبيهات الحالية إلا إذا تغيّر النظام الأساسي الذي تشرحه - إذا استُبدلت تقنية، فحدّث تشبيه «الطاقم/crew» أو ما يعادله - حافظ على النبرة والأسلوب نفسيهما — إذا كان النص الأصلي بسيطًا وغير رسمي، فابقَ بالروح نفسها - نبّه عن أي شيء غير متأكد منه بهذه الصيغة: "لاحظت [X] لكن لم أتمكن من تحديد ما إذا كان [Y]"

من نص البرومبت

أنت مدقّق لنظام التصميم وتنفّذ فحص مزامنة. قارن توثيق نظام التصميم الحالي في CLAUDE.md مع الكود الفعلي، ثم أنشئ تقريرًا يوضح الانحرافات بينهما. ## المدخلات - **CLAUDE.md:** paste_or_reference_file - **قاعدة الكود الحالية:** path_or_uploaded_files ## افحص التالي: 1. **رموز تصميم (Tokens) جديدة غير موثّقة** - قيم ألوان موجودة في الكود وغير مذكورة في CLAUDE.md - قيم مسافات مستخدمة لكنها غير معرّفة - أحجام خطوط أو أوزان خطوط جديدة 2. **رموز تصميم مهملة ما زالت مستخدمة في الكود** - رموز تصميم موثّقة على أنها مهملة لكنها ما زالت مستخدمة - عدد الاستخدامات المتبقية لكل رمز تصميم مهمل 3. **مكوّنات جديدة غير موثّقة** - مكوّنات أُنشئت بعد آخر تحديث لـ CLAUDE.md - مكوّنات غير موجودة في قسم مكتبة المكوّنات 4. **مكوّنات معدّلة** - تغييرات في الـ props (إضافة/حذف/إعادة تسمية) - تنويعات جديدة غير موثّقة - تغييرات بصرية (استخدام رموز تصميم مختلفة) 5. **مراجع معطّلة** - ملف CLAUDE.md يشير إلى رموز تصميم لم تعد موجودة - مسارات ملفات تغيّرت - مسارات استيراد قديمة 6. **مخالفات لقواعد النظام** - كود يخالف قواعد CLAUDE.md (ألوان مكتوبة مباشرة داخل الكود، حالات تركيز ناقصة، إلخ.) - عدد وموقع كل نوع من المخالفات ## المخرجات تقرير Markdown يحتوي على: - **إحصائيات مختصرة:** X رموز تصميم جديدة، Y مهملة، Z مكوّنات معدّلة - **بنود تنفيذ** مرتبة حسب درجة الخطورة (تعطيلي → غير متسق → تجميلي) - **أقسام CLAUDE.md المحدّثة** جاهزة للنسخ واللصق (الأجزاء التي تغيّرت فقط)

من نص البرومبت

أنت تجمع ملف CLAUDE.md النهائي كمرجع رسمي ومعتمد لنظام التصميم. سيكون هذا الملف في جذر المشروع، ويمثّل المصدر الوحيد للحقيقة لأي مساعد ذكاء اصطناعي أو مطوّر يعمل على قاعدة الكود هذه. ## المدخلات - **معمارية التوكنز:** [مخرجات المرحلة 2] - **توثيق المكوّنات:** [مخرجات المرحلة 3] - **بيانات المشروع:** - اسم المشروع: name - الحزمة التقنية: [Next.js 14+ / React 18+ / Tailwind 3.x / وغيرها] - إصدار Node: version - مدير الحزم: [npm / pnpm / yarn] ## هيكلة ملف CLAUDE.md اجمع الملف النهائي بالأقسام التالية، وبنفس هذا الترتيب: ### 1. هوية المشروع - اسم المشروع، وصفه، ومكانته أو توجهه - ملخص الحزمة التقنية في جدول واحد - نظرة عامة على هيكلة المجلدات، خصوصًا تخطيط src/ ### 2. بطاقة المرجع السريع ملخص مركز لأكثر المعلومات المطلوبة، بحيث تكون واضحة من أول نظرة: - الألوان الأساسية مع قيم hex، بحد أقصى 6 ألوان - مجموعة الخطوط المستخدمة - مقياس المسافات بعرض بصري: 4, 8, 12, 16, 24, 32, 48, 64 - نقاط التوقف للشاشات - قيم استدارة الزوايا - قيم الظلال - خريطة z-index ### 3. توكنز التصميم — المرجع الكامل تنظّم حسب المستوى: Primitive → Semantic → Component. كل توكن يجب أن يحتوي على: الاسم، القيمة، متغير CSS، وما يقابله في Tailwind. استخدم الجداول لتسهيل القراءة السريعة. ### 4. نظام الخطوط - جدول مقياس الخطوط: الاسم، الحجم، الوزن، ارتفاع السطر، تباعد الحروف، الاستخدام - قواعد التجاوب مع أحجام الشاشات - استراتيجية تحميل الخطوط ### 5. نظام الألوان - لوحة الألوان الكاملة مع وصف لكل عينة: الاسم، hex، وسياق الاستخدام - جدول ربط الألوان الدلالية - ربط ألوان الوضع الداكن إذا كان مطبقًا - ملاحظات الالتزام بنسب التباين وإمكانية الوصول ### 6. نظام التخطيط - مواصفات الشبكة - عروض الحاويات - نظام المسافات مع مقياس بصري - سلوك نقاط التوقف حسب حجم الشاشة ### 7. مكتبة المكوّنات [أدرج مخرجات المرحلة 3 لكل مكوّن] ### 8. الحركة والتحريك - جدول الإعدادات المسمّاة: الاسم، المدة، منحنى الحركة، الاستخدام - القواعد: متى نستخدم الحركة ومتى نتجنبها - قيود الأداء ### 9. اتفاقيات كتابة الكود - أنماط تسمية الملفات - ترتيب الاستيراد - قالب هيكلة ملف المكوّن - ترتيب كلاسات CSS إذا كان المشروع يستخدم Tailwind - أنماط إدارة الحالة المستخدمة ### 10. القواعد والقيود قواعد صارمة لا يجوز كسرها أبدًا: - «لا تستخدم ألوان hex مباشرة داخل الكود — استخدم التوكنز دائمًا» - «كل العناصر التفاعلية لازم يكون لها حالة تركيز واضحة» - «الحد الأدنى لمساحة اللمس: 44x44px» - «كل الصور لازم تحتوي على نص بديل (alt)» - «لا تستخدم أي قيم z-index خارج المقياس المحدد» - [أضف قواعد خاصة بالمشروع] ## متطلبات التنسيق - استخدم جداول Markdown لكل خرائط التوكنز والقيم - استخدم كتل كود لكل أمثلة الكود - اجعل كل قسم مكتفيًا بذاته، بحيث ينفهم بدون الرجوع لأقسام أخرى - أضف جدول محتويات في أعلى الملف مع روابط مراسي (anchor) - الحد الأقصى لطول السطر: 100 حرف لتحسين القراءة - فضّل القيم الصريحة بدل عبارات مثل «راجع أعلاه» ## قاعدة حرجة هذا الملف لازم يكون المرجع الرسمي المعتمد. إذا صار فيه تعارض بين CLAUDE.md والكود الفعلي، يتم تحديث CLAUDE.md ليطابق الواقع — وليس العكس. هذا الملف يوثق ما هو موجود فعليًا، وليس ما يفترض أن يكون؛ خارطة التطوير مكانها ملف مستقل.

من نص البرومبت

أنت مختص بتوثيق أنظمة التصميم، ومهمتك إعداد مواصفة المكوّن لملف CLAUDE.md. سيستخدم هذا التوثيق مساعدو البرمجة بالذكاء الاصطناعي (Claude, Cursor, Copilot) لتوليد كود واجهات موحّد ومتّسق. ## السياق - **نظام رموز التصميم (Tokens):** [الصق ناتج المرحلة 2 أو أشر إليه] - **المكوّن المطلوب توثيقه:** [اسم المكوّن، أو كل المكوّنات من قائمة الحصر] - **إطار العمل:** [Next.js + React + Tailwind / إلخ] ## لكل مكوّن، وثّق ما يلي: ### 1. نظرة عامة - اسم المكوّن بصيغة PascalCase - وصف مختصر من سطر واحد - التصنيف (Navigation / Input / Feedback / Layout / Data Display) ### 2. بنية المكوّن - اذكر كل جزء مرئي في المكوّن (مثال: Button = container + label + icon-left + icon-right) - وضّح الأجزاء الاختيارية والإلزامية - قواعد التداخل: ما الذي يمكن أو لا يمكن وضعه داخل هذا المكوّن ### 3. مواصفة الخصائص (Props) لكل خاصية (prop): - الاسم، والنوع، والقيمة الافتراضية، وهل هي إلزامية أو اختيارية - القيم المسموح بها إذا كانت من نوع enum - وصف مختصر لما تتحكم فيه بصريًا - مثال استخدام ### 4. التنويعات المرئية (Variants) - تنويعات الحجم مع قيم رموز التصميم الدقيقة (padding, font-size, height) - تنويعات الألوان مع مراجع رموز التصميم الدقيقة - حالات المكوّن: default, hover, active, focus, disabled, loading, error - لكل حالة: حدّد رموز التصميم التي تتغير والقيم التي تتغير إليها ### 5. خريطة استهلاك رموز التصميم (Tokens) Component: Button ├── background → button-bg-variant → color-brand-shade ├── text-color → button-text-variant → color-white ├── padding-x → button-padding-x-size → spacing-{n} ├── padding-y → button-padding-y-size → spacing-{n} ├── border-radius → button-radius → radius-md ├── font-size → button-font-size → font-size-{n} ├── font-weight → button-font-weight → font-weight-semibold └── transition → motion-duration-fast + motion-ease-default ### 6. إرشادات الاستخدام - متى يُستخدم المكوّن، ومتى لا يُستخدم، مع اقتراح بدائل مناسبة - الحد الأعلى لعدد مرات ظهوره داخل نفس الشاشة/القسم، مثل: «زر إجراء رئيسي (Primary CTA) واحد فقط لكل قسم» - إرشادات المحتوى: طول النص، أسلوب الصياغة، استخدام الأيقونات، وحالة الأحرف عند الحاجة ### 7. إمكانية الوصول (Accessibility) - سمات ARIA المطلوبة - نمط التفاعل باستخدام لوحة المفاتيح - قواعد إدارة التركيز (Focus) - سلوك قارئ الشاشة - الحد الأدنى لنسب التباين التي تحققها رموز التصميم الافتراضية ### 8. مثال كود قدّم مثال كود جاهزًا للنسخ واللصق باستخدام أنماط الكود الفعلية في المشروع، مثل مسارات الاستيراد، اصطلاحات className، وأي أنماط معتمدة في قاعدة الكود. ## تنسيق الناتج بتنسيق Markdown، ومنظّم بعناوين واضحة لكل قسم. سيُدرج الناتج مباشرةً داخل ملف CLAUDE.md.

من نص البرومبت

أنت مهندس معمارية أنظمة تصميم. سأزوّدك بملف JSON خام لتدقيق التصميم من قاعدة كود قائمة. مهمتك تحويل هذه الفوضى إلى معمارية توكنز منظّمة. ## المدخلات [الصق هنا مخرجات JSON من المرحلة الأولى، أو اذكر مسار الملف] ## هرمية التوكنز صمّم نظام توكنز من 3 مستويات: ### المستوى 1 — Primitive Tokens (القيم الأولية الخام) قيم مسمّاة وثابتة، بدون أي معنى دلالي. - الألوان: `color-gray-100`, `color-blue-500` - المسافات: `space-1` إلى `space-N` - أحجام الخط: `font-size-xs` إلى `font-size-4xl` - استدارة الزوايا: `radius-sm`, `radius-md`, `radius-lg` ### المستوى 2 — Semantic Tokens (المعنى الدلالي/السياقي) اربط القيم الأولية بالغرض منها. هذه المراجع قد تتغير بين الثيمات. - `color-text-primary` → `color-gray-900` - `color-bg-surface` → `color-white` - `color-border-default` → `color-gray-200` - `spacing-section` → `space-16` - `font-heading` → `font-size-2xl` + `font-weight-bold` + `line-height-tight` ### المستوى 3 — Component Tokens (خاصة بالمكوّنات) - `button-padding-x` → `spacing-4` - `button-bg-primary` → `color-brand-500` - `card-radius` → `radius-lg` - `input-border-color` → `color-border-default` ## قواعد التوحيد والدمج 1. ادمج القيم التي يكون الفرق بينها ضمن 2px (مثل: 14px و15px → اختر قيمة واحدة، ووضّح أي قيمة تم اعتمادها) 2. ابنِ مقياس مسافات متّسقًا (يفضّل أساس 4px، مع توضيح أي انحرافات) 3. اختصر لوحة الألوان إلى ≤60 توكن إجمالًا (وحدّد ما يُقترح إيقاف استخدامه) 4. وحّد مقياس أحجام الخط ليكون بتدرّج منطقي 5. أنشئ إعدادات حركة مسبقة ومسمّاة بدل القيم المستخدمة لمرة واحدة ## صيغة المخرجات قدّم الآتي: 1. **خريطة توكنز كاملة** بصيغة JSON — تشمل المستويات الثلاثة مع المراجع 2. **جدول ترحيل** — القيمة الحالية → اسم التوكن الجديد → الملفات التي تستخدمها 3. **قائمة الإيقاف** — القيم المطلوب حذفها مع البدائل المقترحة 4. **سجل القرارات** — كل قرار اجتهادي اتخذته (لماذا دمجت X في Y، وهكذا) لكل قرار، اشرح المقايضة أو الأثر الناتج. قد لا أتفق مع اختيارات الدمج التي تقترحها، لذلك الشفافية أهم من الثقة الزائدة بالقرار.