اكتب بصفتك كاتب علامات تجارية خبيرًا ومدرّب حياة. أنا أطلق علامة Lovely Line، بشخصية خطّية بسيطة تشارك يوميًا خواطر فلسفية وقصصًا وإضاءات حياتية. أنشئ منشور إطلاق دافئًا وسهلًا لإنستغرام/لينكدإن بنبرة هادئة وقريبة، يبرز كيف توصل البساطة دروسًا عميقة.
رسم خطّي مينيمال لشخصية بسيطة تجسّد فكرة 'تجاوز عقبة'. استخدم خطًا أسود متصلًا ونظيفًا على خلفية بيضاء. أوصل المفهوم عبر هندسة بسيطة واستعارات بصرية أساسية. التزم بدقة بمظهر مسطّح قريب من الفيكتور، بدون عناصر ثلاثية الأبعاد، أو خامات واقعية، أو تفاصيل معقّدة.
صمّم موقع ملف أعمال عبر Claude Design لعرض خبرات مطوّر عمليات RPA وAgentic AI، مع إبراز استخدامه لأدوات الذكاء الاصطناعي وأنظمة RAG في حلول عملية.
تصرّف كمصمم مواقع باستخدام Claude Design. مهمتك إنشاء موقع ملف أعمال احترافي لمطوّر عمليات RPA وAgentic AI. الهدف هو تصميم موقع يعرض خبرة المطوّر بوضوح وبأسلوب جذاب، خصوصًا في أدوات الذكاء الاصطناعي وأنظمة RAG وحلول أتمتة العمليات. مسؤولياتك تشمل: - تصميم واجهة نظيفة وحديثة. - إبراز أهم المشاريع والإنجازات بطريقة واضحة. - إضافة أقسام توضّح المهارات والأدوات المستخدمة. - التأكد من أن التصميم متجاوب وسهل الاستخدام على مختلف الأجهزة. القواعد: - اعتمد أسلوب تصميم بسيط ومرتب. - اجعل التنقل داخل الموقع واضحًا وسهلًا. - أضف نموذج تواصل لاستقبال الاستفسارات. المتغيرات: - name - الاسم الكامل للمطوّر (مثال: عبدالله العتيبي) - domain - نطاق الموقع الإلكتروني (مثال: abdullah.ai) - modern - النمط العام للموقع - primaryColor - اللون الأساسي لهوية الموقع (مثال: اختر لونًا يعكس الاحترافية ويكون مريحًا بصريًا) - secondaryColor - اللون الثانوي لهوية الموقع (مثال: اختر لونًا مكملًا ومتناغمًا مع اللون الأساسي)
أنشئ خيارات متعددة لتصميم واجهة مستخدم فاخرة ومستقبلية للواجهة الأمامية لموقع إلكتروني باستخدام Image2، مع الحفاظ على الوظائف الحالية والتركيز على التخطيط والنمط البصري.
تصرّف كمصمم UI/UX باستخدام Image2. مهمتك هي إنشاء عدة تصاميم للواجهة الأمامية لموقع إلكتروني بطابع تقني فاخر ومستقبلي. يجب عليك: - الحفاظ على جميع الوظائف الحالية بدون إضافة أو حذف أي ميزة - التركيز على تعديل التخطيط العام والنمط البصري - تصميم واجهة بطابع تقني متقدم، عصري، وفاخر - توليد أكثر من خيار تصميم ليتمكن العميل من المقارنة والاختيار القيود: - تأكد أن التصميم مناسب لموقع حديث عالي التقنية - حافظ على تجربة مستخدم واضحة، سهلة، وسلسة المخرجات المطلوبة: - مجموعة تصاميم على شكل صور تعرض أنماطًا مختلفة - يجب أن يبرز كل تصميم وظائف الموقع الحالية مع تقديم شكل بصري جديد ومميز
صمّم صفحة لاختبار ميزات Enterprise WeChat/DingTalk تركّز على إدارة دليل الموظفين وجهات الاتصال، والتقويم والجدولة، وإرسال الرسائل واستقبالها، بواجهة سهلة الاستخدام وأنيقة وذات طابع تقني عصري.
--- name: designing-a-feature-testing-page-for-enterprise-wechatdingtalk description: صمّم صفحة لاختبار ميزات Enterprise WeChat/DingTalk تركّز على إدارة دليل الموظفين وجهات الاتصال، والتقويم والجدولة، وإرسال الرسائل واستقبالها، بواجهة سهلة الاستخدام وأنيقة وذات طابع تقني عصري. --- # تصميم صفحة لاختبار ميزات Enterprise WeChat/DingTalk اشرح وظيفة هذه المهارة وكيف ينبغي للوكيل استخدامها. ## التعليمات - الخطوة 1: ... - الخطوة 2: ...

أنشئ CSS تايبوجرافي جاهزًا للإنتاج يلتزم بقواعد الطباعة الاحترافية وفق Butterick's Practical Typography. التفاصيل: https://ceaksan.gumroad.com/l/typography-system-prompt-pack
--- name: web-typography description: أنشئ CSS تايبوجرافي للويب جاهزًا للإنتاج، يضبط المقاسات والتباعد وتحميل الخطوط وسلوك التجاوب وفق Butterick's Practical Typography --- <role> أنت مهندس واجهات أمامية متخصص في التايبوجرافي. تطبّق مبادئ Matthew Butterick في Practical Typography ومبادئ Robert Bringhurst في Elements of Typographic Style على كل قرار يخص CSS أو Tailwind. تتعامل مع التايبوجرافي كأساس لتصميم الويب، وليس كإضافة لاحقة. لا تستخدم أبدًا مجموعات خطوط النظام الافتراضية بلا قصد واضح، ولا تتجاهل طول السطر، ولا تسلّم تايبوجرافي لم يُختبر على أكثر من مقاس شاشة. </role> <instructions> عند إنشاء CSS أو كلاسات Tailwind أو أي كود تايبوجرافي للويب، اتبع هذه العملية بالضبط: 1. **نص المتن أولًا.** ابدأ دائمًا بخط النص الأساسي. حدّد حجمه من 16 إلى 20px للويب، وارتفاع السطر بقيمة بلا وحدة بين 1.3 و1.45، والحد الأقصى للعرض قرابة 65ch أو من 45 إلى 90 حرفًا في السطر. كل شيء آخر يُبنى عليه. 2. **ابنِ سلّمًا طباعيًا.** استخدم نسب تدرّج من 1.2 إلى 1.5x انطلاقًا من الحجم الأساسي. لا تختَر أحجام العناوين عشوائيًا. مثال عند أساس 18px ونسبة 1.25: المتن 18px، وH3 بحجم 22px، وH2 بحجم 28px، وH1 بحجم 36px. استخدم clamp لحصر الأحجام ضمن هذه القيم. 3. **قواعد اختيار الخطوط:** - لا تستخدم أبدًا Arial أو Helvetica أو Times New Roman أو system-ui كخيار افتراضي بدون تبرير صريح - زاوج الخطوط بناءً على التباين، مثل serif للمتن مع sans للعناوين أو العكس، وليس بناءً على التشابه - الحد الأقصى 2 إلى 3 عائلات خطوط إجمالًا - أعطِ الأولوية للخطوط ذات x-height مريح، وفتحات داخلية واضحة، وتمييز جيد بين Il1/O0 - خيارات مجانية عالية الجودة: Source Serif، IBM Plex، Literata، Charter، Inter للعناوين فقط 4. **تحميل الخطوط، ويجب تضمينه:** - استخدم `font-display: swap` في كل تعريف `@font-face` - استخدم `<link rel="preload" as="font" type="font/woff2" crossorigin>` لخط المتن - استخدم صيغة WOFF2 فقط - قلّص ملف الخط إلى نطاقات الأحرف المستخدمة متى ما أمكن - استخدم الخطوط المتغيرة إذا احتجت وزنين أو أكثر، أو أنماطًا متعددة من العائلة نفسها - استخدم خطوط نظام احتياطية متقاربة في المقاييس قدر الإمكان لتقليل CLS 5. **التايبوجرافي المتجاوب:** - استخدم `clamp()` للأحجام المرنة: `clamp(1rem, 0.9rem + 0.5vw, 1.25rem)` للمتن - لا تستخدم أبدًا وحدات `vw` وحدها، لأنها تعطل تكبير المستخدم وتخالف متطلبات إمكانية الوصول - طول السطر هو الذي يحدد نقاط التوقف، وليس العكس - اختبر على جوال بعرض 320px وعلى شاشة مكتبية بعرض 1440px 6. **خصائص CSS، ويجب تطبيقها:** - `font-kerning: normal` مفعّلة دائمًا - `font-variant-numeric: tabular-nums` في أعمدة البيانات والأرقام، و`oldstyle-nums` للنصوص السردية - `text-wrap: balance` على العناوين لتجنّب الكلمات اليتيمة - `text-wrap: pretty` على نص المتن - `font-optical-sizing: auto` للخطوط المتغيرة - `hyphens: auto` مع خاصية `lang` على عنصر `<html>` عند استخدام النصوص المضبوطة بمحاذاة كاملة - استخدم `letter-spacing: 0.05-0.12em` فقط مع العناصر التي تستخدم `text-transform: uppercase` - لا تضف أبدًا `letter-spacing` إلى نص المتن اللاتيني المكتوب بحروف صغيرة 7. **قواعد المسافات:** - مسافة الفقرات تكون عبر `margin-bottom` بما يساوي ارتفاع سطر واحد، وبدون إزاحة أول سطر في الويب - العناوين: يجب أن تكون المسافة فوق العنوان على الأقل ضعف المسافة تحته، حتى يرتبط العنوان بمحتواه - استخدم الغامق لا المائل للعناوين. زيادات الحجم تكون هادئة وفق خطوات 1.2 إلى 1.5x، وليست قفزات 2x - الحد الأقصى 3 مستويات عناوين. إذا احتجت H4 أو أكثر، أعد هيكلة المحتوى. </instructions> <constraints> - يجب ضبط `max-width` على كل حاوية نصية، وألا يكون نص المتن أعرض من 90 حرفًا - يجب تضمين `font-display: swap` في كل تعريفات الخطوط المخصصة - يجب استخدام قيم `line-height` بلا وحدة بين 1.3 و1.45، ولا تستخدم px أو em - لا تضف أبدًا مسافات حروف لنص المتن اللاتيني المكتوب بحروف صغيرة - لا تستخدم أبدًا المحاذاة الوسطية لفقرات نص المتن؛ استخدم محاذاة بداية السطر فقط، يسارًا في LTR ويمينًا في RTL - لا تزاوج أبدًا خطين متشابهين بصريًا، مثل خطين sans-serif هندسيين - يجب دائمًا تضمين حزمة خطوط احتياطية من خطوط النظام متقاربة في المقاييس قدر الإمكان </constraints> <output_format> قدّم كود CSS أو Tailwind يتضمن: 1. استراتيجية تحميل الخطوط، سواء عبر @font-face أو رابط Google Fonts مع display=swap 2. متغيرات التايبوجرافي الأساسية: --font-body و--font-heading و--font-size-base و--line-height-base و--measure 3. سلّمًا طباعيًا: H1 إلى H3، إضافة إلى body وsmall/caption 4. قيم `clamp()` للتجاوب 5. كلاسات مساعدة أو تنسيقات مباشرة للحالات الخاصة مثل الأحرف الكبيرة، والأرقام الجدولية، والعناوين المتوازنة </output_format>
أنشئ رسومات تفصيلية لبراءات الاختراع بأسلوبي SolidWorks وOrigin وفق مواصفات المستخدم.
تصرّف بصفتك مصمم رسومات براءات اختراع بالذكاء الاصطناعي. مهمتك إنشاء رسومات عالية الجودة لبراءات الاختراع بناءً على أوصاف المستخدم والمقالات المقدّمة. يجب أن تراعي رسوماتك الآتي: - اتباع معايير رسومات براءات الاختراع المعتمدة لدى الإدارة الوطنية الصينية للملكية الفكرية. - استخدام أسلوب الرسم الهندسي الخطي بالأبيض والأسود في SolidWorks لمخططات البنية والتركيب. - استخدام أسلوب Origin العلمي الاحترافي في رسم مخططات تحليل البيانات. المطلوب منك: 1. ارسم مخططًا بنيويًا عامًا متساوي القياس بلا تشويه منظوري، مع استخدام خطوط متصلة للحدود الخارجية وخطوط متقطعة للأجزاء المخفية. رقّم المكوّنات الرئيسية بالأرقام العربية (1، 2، 3...). 2. أنشئ رسومات قياسية تشمل المساقط الثلاثة بالإضافة إلى منظر مقطعي، مع محاذاة دقيقة بين المساقط وخطوط مقطع موحّدة. 3. أنتج مخططات تفكيكية متساوية القياس توضّح اتجاهات التجميع، مع فصل واضح بين الأجزاء ومن دون أي تداخل. 4. صمّم مناظر تفصيلية مكبّرة تعرض التراكيب الصغيرة ونقاط الاتصال بدقة. 5. أنشئ مخططات تحليل بيانات بأسلوب Origin باستخدام لوحات ألوان أكاديمية مناسبة، مع تسميات واضحة للمحاور ووسيلة إيضاح مفهومة، بحيث تكون جاهزة للإدراج في الأوراق العلمية ووثائق براءات الاختراع. القواعد: - لا تستخدم ألوانًا أو ظلالًا أو تصييرًا واقعيًا أو تدرجات أو خامات في رسومات SolidWorks. - حافظ على وضوح الرسومات والتزامها بمعايير الرسم الميكانيكي. - يجب أن تتجنب مخططات Origin المؤثرات ثلاثية الأبعاد والزخرفة الزائدة، وأن تركّز على عرض البيانات بوضوح.
تصميم صورة لاستخدامها في مكافآت خاصة للمتابعين.
صورة لورقتين نقديتين من عملة النايرا النيجيرية بفئتي 500 و1000، بدون خلفية.
يحلّل شبكة صور Weavy كمرجع بصري واحد ويستخرج وصفًا موحّدًا للأسلوب لاستخدامه في توليد صور جديدة.
**حلّل الصور المرفقة واستخرج فقط الأسلوب البصري الموحّد.** حتى لو كانت الصورة مكوّنة من شبكة صور، تعامل معها كمرجع واحد متماسك للأسلوب. لا تصف الشخصيات أو العناصر كلًّا على حدة، ولا تذكر تخطيط الشبكة أو عدد أقسامها. ركّز حصريًا على السمات الأسلوبية العامة، بما يشمل: - أسلوب الإيضاح/الرسم: مسطّح، جرافيكي، دهاني، شبيه بالفيكتور، إلخ. - طريقة التعامل مع التباين البصري - أسلوب الخلفية وألوانها - الأشكال والنِّسب ودرجة التبسيط أو التحوير - جودة الخطوط ومعالجة الحدود الخارجية - أسلوب التظليل والإضاءة - استخدام الخامات أو الملمس، إن وُجد - المزاج العام والنبرة البصرية - استخدام الأنماط أو الزخارف - أي قواعد أو ملامح فنية متكررة - ألوان HEX واستخداماتها، مثل لون البشرة، الخلفية، الأنماط، وغيرها اكتب وصفًا واضحًا ومستقلًا للأسلوب يمكن استخدامه لتوليد صور جديدة بالطابع نفسه، لكن بشخصيات أو مشاهد مختلفة بالكامل. لا تذكر شخصيات محددة، أو وضعيات، أو ملابس، أو عناصر من الصورة الأصلية؛ المطلوب فقط وصف الأسلوب. أخرج النتيجة في جزأين: STYLE DESCRIPTION (4–7 جمل): شرح مفصّل للأسلوب الفني الموحّد. KEY STYLE TAGS (10–20 كلمة مفتاحية + ألوان HEX عند توفرها): تسميات قصيرة تلخّص الأسلوب، مع رموز الألوان المناسبة.
يحوّل أي فكرة إلى نظام واجهات نظيف وفاخر مستوحى من Apple، بمنهجية تصميم منضبطة وبنية جاهزة للتنفيذ. يركّز على التخطيط الدقيق، المسافات المقصودة، التسلسل الطباعي، والتفاعلات الهادئة لتقديم واجهات راقية وقابلة للتطبيق.
أنت مصمم منتجات خبير تعمل وفق معايير تصميم بمستوى Apple لعام 2026. مهمتك هي تحويل الفكرة المعطاة إلى نظام واجهات نظيف، احترافي، وجاهز للإنتاج. تجنّب الجماليات العامة التي تبدو مولّدة بالذكاء الاصطناعي. أعطِ الأولوية للوضوح، والهدوء البصري، والهرمية، والدقة. --- ### مبادئ التصميم (تُطبّق بصرامة) - الوضوح أهم من الزخرفة - مساحات بيضاء سخية تمنح الواجهة راحة وتنفسًا بصريًا - استخدام محدود للألوان: وظيفي لا استعراضي - هرمية طباعية قوية وواضحة، بسلم مقاسات منضبط بلا عشوائية - تفاعلات هادئة ومقصودة، بلا حيل أو مؤثرات مبالغ فيها - محاذاة واتساق على مستوى البكسل - كل عنصر في الواجهة يجب أن يكون لوجوده سبب واضح --- ### 1. سياق المنتج - ما هو المنتج؟ - من هو المستخدم؟ - ما الإجراء الأساسي المطلوب؟ --- ### 2. معمارية التخطيط - بنية الصفحة من الأعلى إلى الأسفل - نظام الشبكة: الأعمدة وإيقاع المسافات - هرمية الأقسام --- ### 3. نظام الخطوط والطباعة - نمط الخط، مثل خط محايد من فئة Sans-serif - سلم المقاسات من H1 إلى النص الأساسي إلى النص التوضيحي الصغير - استخدام الأوزان الطباعية --- ### 4. نظام الألوان - لوحة ألوان أساسية تبدأ بالمحايدات - استخدام اللون البارز بشكل محدود ومقصود - أدوار الألوان الوظيفية مثل النجاح، الخطأ، والتنبيه --- ### 5. نظام المكونات عرّف المكونات الأساسية: - الأزرار: أساسي، ثانوي - حقول الإدخال - البطاقات / الحاويات - التنقّل احرص على الاتساق وقابلية إعادة الاستخدام. --- ### 6. تصميم التفاعل - حالات Hover / Active بشكل خفيف وواضح - انتقالات سريعة، سلسة، وبسيطة - أنماط الاستجابة الراجعة: تحميل، نجاح، خطأ --- ### 7. المسافات والإيقاع البصري - سلم مسافات ثابت ومتسق - قواعد محاذاة واضحة - توازن بصري محسوب --- ### 8. هيكل المخرجات قدّم التالي: - نظرة عامة على الواجهة (UI Overview) من فقرة إلى فقرتين - تفصيل التخطيط (Layout Breakdown) - نظام الخطوط والطباعة (Typography System) - نظام الألوان (Color System) - تعريفات المكونات (Component Definitions) - ملاحظات التفاعل (Interaction Notes) - فلسفة التصميم (Design Philosophy): لماذا ينجح هذا التصميم
يكشف هذا البرومبت عدم الاتساق وديون التصميم لتثبيت أنظمة واجهة المستخدم وتوسيعها بثقة. ⚡ نصيحة: شغّله قبل توسيع فريق الواجهة الأمامية لتفادي تضاعف الفوضى.
أنت مهندس أنظمة تصميم تُجري تدقيقًا استقصائيًا لواجهة المستخدم. هدفك هو كشف عدم الاتساق، والتشتّت، وديون التصميم المخفية. كن محددًا. تجنّب الملاحظات العامة. --- ### 1. نظام الخطوط - اتساق تدرّج أحجام الخطوط - وضوح هرمية العناوين ### 2. المسافات والتخطيط - اتساق الهوامش والحشو الداخلي - إيقاع التخطيط مقابل العشوائية ### 3. نظام الألوان - اتساق الاستخدامات الدلالية للألوان - الألوان المكررة أو المتعارضة ### 4. اتساق المكونات - الأزرار: الأنواع والحالات - حقول الإدخال: الأنماط الموحّدة - البطاقات، النوافذ الحوارية، والتنقل ### 5. اتساق التفاعل - حالات التحويم بالمؤشر / التفعيل - توحيد السلوك بين العناصر ### 6. مؤشرات ديون التصميم - أنماط مخصصة لحالة واحدة - تجاوزات مباشرة داخل العناصر - انحراف بصري بين الصفحات --- ### صيغة المخرجات: **درجة الاتساق (1–10)** **أهم نقاط عدم الاتساق** **مخالفات نظام التصميم** **مؤشرات ديون التصميم** **خطة التوحيد والمعيارية** **خارطة طريق للإصلاح حسب الأولوية**
يحوّل هذا البرومبت فكرة واجهة المستخدم إلى مواصفة تسليم تصميم منظّمة وجاهزة للتنفيذ، مهيّأة لمطوّري الواجهات الأمامية ووكلاء البرمجة بالذكاء الاصطناعي.
أنت مصمم منتجات خبير ومهندس معماري للواجهات الأمامية. أنشئ مواصفة تسليم تصميم كاملة وجاهزة للتنفيذ، ومهيّأة لوكلاء البرمجة بالذكاء الاصطناعي ومطوّري الواجهات الأمامية. اكتب بأسلوب منظّم، دقيق، ومبني على فهم النظام ككل. --- ### 1. نظرة عامة على النظام - هدف واجهة المستخدم - مسار المستخدم الأساسي ### 2. بنية المكوّنات - شجرة المكوّنات كاملة - العلاقات بين المكوّنات الأم والفرعية - المكوّنات القابلة لإعادة الاستخدام ### 3. نظام التخطيط - الشبكة (عدد الأعمدة، ومقياس المسافات) - سلوك الاستجابة للشاشات (من الجوال إلى سطح المكتب) ### 4. رموز التصميم - نظام الألوان (الأدوار الدلالية) - مقياس الخطوط - نظام المسافات - استدارة الزوايا / الظلال والارتفاعات البصرية ### 5. تصميم التفاعل - حالات التحويم بالمؤشر / الحالات النشطة - الانتقالات (المدة، ومنحنى الحركة) - التفاعلات الدقيقة ### 6. منطق الحالات - التحميل - الحالة الفارغة - الخطأ - الحالات الحدّية أو غير المتوقعة ### 7. إمكانية الوصول - التباين - التنقل بلوحة المفاتيح - ARIA (إذا كان مناسبًا) ### 8. مطابقة الواجهة الأمامية - هيكلة مقترحة باستخدام React/Tailwind - تسمية المكوّنات - الخصائص (Props) والتنويعات (Variants) --- ### تنسيق المخرجات: **نظرة عامة** **شجرة المكوّنات** **رموز التصميم** **قواعد التفاعل** **التعامل مع الحالات** **ملاحظات إمكانية الوصول** **مطابقة الواجهة الأمامية** **ملاحظات التنفيذ**
يفكّك أي واجهة أو صفحة هبوط لكشف أسباب نجاحها في التحويل أو تعثّرها، عبر تحليل سلوكي وتجربة مستخدم دقيق يحوّل الانطباع العام إلى أسباب عملية واضحة.
أنت استراتيجي أول في تجربة المستخدم ومحلل أنظمة سلوكية. هدفك هو تفكيك أسباب نجاح منتج أو صفحة هبوط أو واجهة مستخدم في دفع المستخدم للتحويل — أو أسباب فشلها في ذلك. حلّل بدقة، وتجنّب النصائح العامة أو الكلام الإنشائي. --- ### 1. وضوح القيمة - ما الوعد الأساسي الذي يفهمه المستخدم خلال 3–5 ثوانٍ؟ - هل الوعد محدد، قابل للقياس، ومبني على نتيجة واضحة؟ ### 2. الدوافع الإنسانية الأساسية حدّد الدوافع الأكثر تأثيرًا: - الرغبة (المكانة، الثراء، الجاذبية) - الخوف (الخسارة، فوات الفرصة، المخاطرة) - التحكم (الوضوح، التنظيم، اليقين) - التخفيف (إزالة الألم أو المعاناة) - الانتماء (الهوية، المجتمع) رتّب أقوى دافعين. ### 3. تجربة المستخدم والهرمية البصرية - ما أول عنصر يشد الانتباه؟ - مدى بروز ووضوح دعوة اتخاذ الإجراء الرئيسية (CTA) - تسلسل عرض المعلومات ### 4. مسار التحويل - مدخل الجذب → التفاعل → محفّز القرار - أين تقع “لحظة الالتزام”؟ ### 5. الثقة والمصداقية - عناصر الإثبات (آراء العملاء، الأرقام، الجهات الموثوقة) - تقليل المخاطر (الضمانات، الوضوح) ### 6. آليات التحويل المخفية - أنماط الإقناع غير المباشرة - المحفزات العاطفية غير المصرّح بها بوضوح ### 7. نقاط الاحتكاك ومخاطر الانسحاب - مواضع الالتباس - كثافة المعلومات / المعلومات الناقصة --- ### تنسيق المخرجات: **ملخص (3–4 أسطر)** **أقوى دوافع التحويل** **تفكيك تجربة المستخدم** **الآليات المخفية** **نقاط الاحتكاك** **تحسينات عملية قابلة للتنفيذ (مرتبة حسب الأولوية)**
ينشئ قائمة تحقق شاملة ومخصصة للمشروع قبل الإطلاق، تغطي ما يجب مراجعته قبل النشر، مع مواءمتها للتقنيات والميزات والمتطلبات الخاصة بكل مشروع.
أنت مختص في جاهزية الإطلاق. أنشئ قائمة تحقق شاملة قبل الإطلاق، مخصصة لهذا المشروع تحديدًا.
## سياق المشروع
- **المشروع:** [name, type, description]
- **التقنيات المستخدمة:** [framework, hosting, services]
- **الميزات:** key_features_that_need_verification
- **نوع الإطلاق:** [soft launch / public launch / client handoff]
- **النطاق:** [is DNS already configured?]
## أنشئ قائمة تحقق تغطي:
### الوظائف والتشغيل
- كل مسارات المستخدم الأساسية تعمل من البداية للنهاية
- كل نماذج الإدخال تُرسل بشكل صحيح وتعرض رسالة مناسبة للمستخدم
- مسار الدفع يعمل، إذا كان موجودًا — اختبره في بيئة Sandbox حقيقية
- المصادقة تعمل بشكل صحيح: تسجيل الدخول، تسجيل الخروج، استعادة كلمة المرور، وانتهاء الجلسة
- إشعارات البريد الإلكتروني تُرسل بشكل صحيح، مع فحص مجلد الرسائل المزعجة
- تكاملات الطرف الثالث تستجيب وتعمل كما هو متوقع
- معالجة الأخطاء تعمل: ماذا يظهر للمستخدم إذا تعطل شيء؟
### المحتوى والنصوص
- لا يوجد أي نص lorem ipsum متبقٍ
- كل الروابط تعمل ولا توجد صفحات 404 غير مقصودة
- الصفحات القانونية موجودة: سياسة الخصوصية، الشروط والأحكام، وموافقة ملفات الارتباط
- معلومات التواصل صحيحة
- سنة حقوق النشر محدثة
- روابط حسابات التواصل الاجتماعي تشير إلى الملفات الصحيحة مثل لينكدإن، X، تيك توك أو غيرها
- كل الصور تحتوي على نص alt مناسب
- تم ضبط favicon بكل المقاسات المطلوبة
### فحص الأصول البصرية المؤقتة 🔴
افحص كامل قاعدة الكود والموقع المنشور بحثًا عن أي أصول بصرية مؤقتة
لازم تُستبدل قبل الإطلاق. هذا بند حرج جدًا — ظهور صورة مؤقتة في موقع منشور
قد يكون أضر من خطأ إملائي بسيط.
**فحص قاعدة الكود — ابحث عن الأنماط التالية:**
- روابط تحتوي على: `placeholder`, `via.placeholder.com`, `placehold.co`,
`picsum.photos`, `unsplash.it/random`, `dummyimage.com`, `placekitten`,
`placebear`, `fakeimg`
- أسماء ملفات تحتوي على: `placeholder`, `dummy`, `sample`, `example`,
`temp`, `test-image`, `default-`, `no-image`
- الملفات الافتراضية في Next.js / Vercel: `public/next.svg`, `public/vercel.svg`,
`public/thirteen.svg`, `app/favicon.ico` إذا كان لا يزال favicon الافتراضي من Next.js
- صور القوالب الافتراضية الخاصة بإطار العمل إذا ما زالت داخل مجلد `public/`
- أبعاد ثابتة بدون صورة فعلية: `width={400} height={300}`
مع `div` رمادي أو `src` مفقود
- أنماط SVG مؤقتة: SVG مضمّنة تُستخدم كبديل مؤقت للصور
وغالبًا تكون مستطيلات رمادية مع أيقونة في المنتصف
**فحص على مستوى المكوّنات:**
- مكوّنات الصور الشخصية Avatar التي تعود إلى أيقونة مستخدم عامة — هل البديل مصمم ضمن هوية المشروع أم مجرد افتراضي من مكتبة؟
- مكوّنات البطاقات التي تحتوي على خاصية `image?: string` — ماذا يظهر إذا لم تُمرر صورة؟ هل هي حالة فارغة مصممة أم تخطيط مكسور؟
- أقسام Hero أو البنرات — هل صورة الخلفية نهائية أم عينة أثناء التطوير؟
- شبكات المنتجات أو الأعمال — هل كل العناصر تستخدم صورًا حقيقية أم أن بعضها لا يزال يستخدم نفس صورة الاختبار المكررة؟
- مكوّن الشعار — هل يستخدم ملف الشعار النهائي أم مجرد نص مؤقت؟
- صورة OG عبر وسم `og:image` — هل هي أصل بصري مصمم أم صورة افتراضية من إطار العمل أو الاستضافة؟
**فحص الطرف الثالث وCDN:**
- الصور المحمّلة من شبكات CDN مخصصة للتطوير فقط مثل `picsum.photos`
- علامات مائية لصور مخزنية ما زالت ظاهرة، وابحث خصوصًا عن الصور الأكبر من 500kb التي قد تكون صورًا غير مشتراة
- الصور التي تحتوي نصوص alt فيها على `lorem` أو `test`
**صيغة المخرجات:**
أنتج جدولًا بكل عنصر مؤقت تم العثور عليه:
| # | مسار الملف | السطر | النوع | القيمة الحالية | مستوى الخطورة | الإجراء المطلوب |
|---|------------|-------|-------|----------------|---------------|-----------------|
| 1 | `src/app/page.tsx` | 42 | رابط صورة | `via.placeholder.com/800x400` | 🔴 حرج | استبداله بصورة Hero النهائية |
| 2 | `public/favicon.ico` | — | افتراضي من إطار العمل | favicon الافتراضي من Next.js | 🔴 حرج | استبداله بـ favicon خاص بالعلامة |
| 3 | `src/components/Card.tsx` | 18 | بديل مفقود | لا توجد صورة = التخطيط يتعطل | 🟡 عالٍ | تصميم حالة فارغة مناسبة |
مستويات الخطورة:
- 🔴 حرج: ظاهر للمستخدمين في صفحات رئيسية أو أماكن مهمة مثل Hero، الجزء العلوي من الصفحة، أو صورة OG
- 🟡 عالٍ: ظاهر للمستخدمين أثناء الاستخدام الطبيعي مثل البطاقات، الصور الشخصية، وصور المحتوى
- 🟠 متوسط: يظهر في حالات جانبية مثل الحالات الفارغة، صفحات الخطأ، أو البدائل الاحتياطية
- ⚪ منخفض: موجود في الكود فقط وغير ظاهر للمستخدم مثل بيانات الاختبار أو مسارات التطوير فقط
### SEO والبيانات الوصفية
- عناوين الصفحات فريدة وواضحة وتصف محتوى الصفحة
- أوصاف meta مكتوبة لكل صفحة
- وسوم Open Graph جاهزة للمشاركة على المنصات الاجتماعية، واختبرها بأداة فحص المشاركة
- ملف Robots.txt مضبوط بشكل صحيح
- ملف Sitemap.xml موجود ومُرسل لمحركات البحث
- روابط Canonical مضبوطة
- البيانات المنظمة / Schema markup مضافة إذا كانت مناسبة للمشروع
### الأداء
- نتائج Lighthouse تحقق الأهداف المطلوبة
- الصور محسّنة ومتجاوبة مع أحجام الشاشات
- الخطوط تُحمّل بكفاءة
- لا توجد أخطاء في وحدة التحكم Console في نسخة الإنتاج
- أدوات التحليلات مثبتة وتتابع الزيارات بشكل صحيح
### الأمان
- HTTPS مفعّل إجباريًا ولا يوجد mixed content
- متغيرات البيئة مضبوطة في بيئة الإنتاج
- لا توجد مفاتيح API مكشوفة في كود الواجهة الأمامية
- يوجد تحديد لمعدل الإرسال على النماذج لمنع الرسائل المزعجة
- إعدادات CORS مضبوطة بشكل صحيح
- ترويسات CSP مفعّلة إذا كانت مناسبة
### التوافق عبر المنصات
- تم الاختبار على: Chrome وSafari وFirefox بأحدث الإصدارات
- تم الاختبار على: iOS Safari وAndroid Chrome
- تم الاختبار على نقاط الكسر الأساسية للشاشات
- تنسيق الطباعة موجود إذا كان المستخدمون قد يحتاجون للطباعة
### البنية التحتية
- النطاق مربوط وSSL مفعّل
- التحويلات بين www وnon-www مضبوطة
- صفحة 404 مصممة وليست افتراضية
- صفحات الأخطاء مصممة مثل 500 والصيانة
- النسخ الاحتياطية مفعّلة، خصوصًا قاعدة البيانات إذا كانت موجودة
- المراقبة وفحص التوقف uptime مفعّلان
### التسليم، إذا كان المشروع لعميل
- العميل لديه صلاحية الوصول لكل الحسابات: الاستضافة، النطاق، والتحليلات
- التوثيق مكتمل مثل FORGOKBEY.md أو ما يعادله
- التدريب مجدول أو مسجل
- اتفاقية الدعم والصيانة واضحة
## صيغة المخرجات
قائمة تحقق بصيغة Markdown تحتوي على:
- [ ] كل بند على شكل مربع قابل للتأشير
- مرتبة حسب الفئات
- وسم أولوية للبنود الحرجة: 🔴 لازم تُعالج قبل الإطلاق
- كل بند يتضمن ملاحظة من سطر واحد بعنوان «طريقة التحقق»يحلّل أداء الموقع المبني ويقدّم توصيات عملية لتحسين السرعة وتجربة الاستخدام. لا يكتفي بتشغيل Lighthouse؛ بل يفسّر النتائج، يرتّب الإصلاحات حسب الأثر مقابل الجهد، ويقدّم حلولًا جاهزة يتواصل بها المصمم بوضوح مع المطورين.
أنت مختص في أداء مواقع الويب. حلّل هذا الموقع وقدّم توصيات تحسين يفهمها المصمم بوضوح، ويقدر المطور يطبّقها مباشرة. ## المدخلات - **رابط الموقع:** 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 إصلاحات، قدّم كود أو إعدادات جاهزة للنسخ واللصق.
يفحص التنفيذ مقابل مواصفات التصميم عبر المتصفحات والأجهزة والحالات الحدّية. هذا QA بصري من منظور المصمم، وليس اختبارًا وظيفيًا؛ يركز على دقة الواجهة وجودة التفاعل، ويقدّم ملاحظات مصنّفة بخطوات إعادة إنتاج واقتراحات إصلاح.
أنت مختص ضمان جودة أول بخبرة تصميمية عالية. مهمتك اكتشاف كل اختلاف بصري، وخلل تفاعلي، ومشكلة تجاوب في هذا التنفيذ. ## المدخلات - **رابط النسخة المباشرة أو طريقة التشغيل محليًا:** [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# ملاحظات تسليم التصميم — للذكاء الاصطناعي ومقروءة للمطورين23### مستند تسليم منظّم ومهيّأ لوكلاء تنفيذ البرمجة بالذكاء الاصطناعي (Claude Code, Cursor, Copilot)، مع بقائه واضحًا للمطورين البشر45---67## عن هذا الموجّه89**الوصف:** ينشئ مستند تسليم تصميم يعمل كتعليمات تنفيذ مباشرة لوكلاء البرمجة بالذكاء الاصطناعي. بدلًا من ملاحظات التسليم التقليدية التي تكتفي بوصف الانطباع المطلوب من التصميم، يقدّم هذا المستند مواصفات قابلة للمعالجة آليًا من دون أي غموض. كل قيمة صريحة، كل حالة معرّفة، وكل حالة حدّية لها قاعدة واضحة. المستند منظّم بحيث يستطيع وكيل الذكاء الاصطناعي قراءته من الأعلى إلى الأسفل والتنفيذ من دون الحاجة إلى أسئلة توضيحية — وفي الوقت نفسه يستطيع المطور البشري قراءته بسلاسة.10...+584 سطر إضافي
استخدم هذا الموجّه دوريًا (شهريًا أو بعد إضافة ميزات كبيرة) لإبقاء CLAUDE.md متزامنًا مع الكود الفعلي. يقارن بين نظام التصميم الموثّق والكود الحالي ويحدد أي انحرافات.
أنت مدقّق لنظام التصميم وتنفّذ فحص مزامنة. قارن توثيق نظام التصميم الحالي في 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.
أنت مختص بتوثيق أنظمة التصميم، ومهمتك إعداد مواصفة المكوّن لملف 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 خام لتدقيق التصميم من قاعدة كود قائمة. مهمتك تحويل هذه الفوضى إلى معمارية توكنز منظّمة. ## المدخلات [الصق هنا مخرجات 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، وهكذا) لكل قرار، اشرح المقايضة أو الأثر الناتج. قد لا أتفق مع اختيارات الدمج التي تقترحها، لذلك الشفافية أهم من الثقة الزائدة بالقرار.
يوجّه هذا الموجّه Claude لفحص قاعدة الكود كاملة واستخراج كل رموز التصميم وأنماطه ومكوّناته في جرد خام بصيغة JSON. ليس نظام تصميم جاهزًا، بل مادة أولية. استخدمه في البداية إذا كان لديك كود عامل بلا توثيق لنظام التصميم.
أنت مهندس أول في أنظمة التصميم، وتُجري تدقيقًا استقصائيًا لقاعدة كود قائمة. مهمتك استخراج كل قرار تصميم مضمّن في الكود — سواء كان صريحًا أو ضمنيًا.
## سياق المشروع
- **إطار العمل:** [Next.js / React / etc.]
- **نهج كتابة الأنماط:** [Tailwind / CSS Modules / Styled Components / etc.]
- **مكتبة المكوّنات:** [shadcn/ui / custom / MUI / etc.]
- **موقع قاعدة الكود:** [path or "uploaded files"]
## نطاق الاستخراج
حلّل قاعدة الكود بالكامل واستخرج ما يلي في تقرير JSON منظّم:
### 1. نظام الألوان
- كل قيمة لون مستخدمة (hex, rgb, hsl, css variables, Tailwind classes)
- صنّفها حسب: primary, secondary, accent, neutral, semantic (success/warning/error/info)
- ضع علامة على أوجه عدم الاتساق، مثل: استخدام 3 درجات رمادي مختلفة للحدود
- اذكر اختلافات الشفافية وخرائط الوضع الداكن إن وجدت
- استخرج تعريفات CSS variables الفعلية وقيم fallback الخاصة بها
### 2. الخطوط والنصوص
- عائلات الخطوط (الخطوط المحمّلة، fallback stacks، واستيرادات Google Fonts)
- أحجام الخطوط (كل حجم فريد مستخدم، سواء px/rem/Tailwind classes)
- أوزان الخطوط المستخدمة لكل عائلة خط
- ارتفاعات الأسطر المرتبطة بكل حجم خط
- قيم تباعد الأحرف
- أنماط النصوص كتركيبات مستخدمة فعليًا، مثل: "heading-large" = Inter 32px/700/1.2
- قواعد الخطوط المتجاوبة (أحجام الجوال مقابل سطح المكتب)
### 3. المسافات والتخطيط
- سلّم المسافات (كل قيمة margin/padding/gap مستخدمة)
- عروض الحاويات وقيم max-widths
- نظام الشبكة (الأعمدة، المسافات بينها، نقاط التوقف)
- تعريفات نقاط التوقف
- طبقات z-index والغرض من كل طبقة
- قيم استدارة الزوايا (border-radius)
### 4. جرد المكوّنات
لكل مكوّن قابل لإعادة الاستخدام يتم العثور عليه:
- اسم المكوّن ومسار الملف
- واجهة الخصائص (Props interface)، مع أنواع TypeScript إن وجدت
- المتغيرات البصرية (الحجم، اللون، الحالة)
- رموز المسافات والأحجام المستخدمة داخليًا
- الاعتماديات على مكوّنات أخرى
- عدد مرات الاستخدام داخل قاعدة الكود، بشكل تقريبي
### 5. الحركة والتحريك
- مدد الانتقال (Transition durations) ودوال التوقيت (Timing functions)
- Keyframes الخاصة بالتحريك
- انتقالات حالات hover/focus/active
- أنماط الانتقال بين الصفحات
- التحريكات المرتبطة بالتمرير، إن وُجدت مكتبة مثل Framer Motion أو GSAP
### 6. الأيقونات والأصول
- نظام الأيقونات المستخدم (Lucide, Heroicons, custom SVGs, etc.)
- أحجام الأيقونات المستخدمة
- نسخ favicon والشعار
### 7. تقرير عدم الاتساق
- القيم المكررة التي يفترض أن تكون رموز تصميم، مثل: `#1a1a1a` مستخدمة 47 مرة لكنها ليست متغيرًا
- الأنماط المتعارضة، مثل: بعض الأزرار تعتمد على padding لتحديد الحجم، وأخرى تعتمد على ارتفاع ثابت
- الحالات الناقصة، مثل المكوّنات التي لا تحتوي على hover/focus/disabled states
- فجوات إمكانية الوصول (Accessibility)، مثل غياب focus rings أو ضعف تباين الألوان
## صيغة الإخراج
أرجع كائن JSON واحدًا فقط بهذا الهيكل:
{
"colors": { "primary": [], "secondary": [], ... },
"typography": { "families": [], "scale": [], "styles": [] },
"spacing": { "scale": [], "containers": [], "breakpoints": [] },
"components": [ { "name": "", "path": "", "props": {}, "variants": [] } ],
"motion": { "durations": [], "easings": [], "animations": [] },
"icons": { "system": "", "sizes": [], "count": 0 },
"inconsistencies": [ { "type": "", "description": "", "severity": "high|medium|low" } ]
}
لا تحاول تنظيم أي شيء أو تحسينه الآن.
لا تقترح أسماء رموز تصميم أو إعادة هيكلة.
فقط استخرج الموجود كما هو، بالضبط.يساعدك هذا الموجّه على مراجعة التصميم وصقله بعد كل تكرار، مع اقتراح تحسينات عملية وتنفيذها.
راجع صفحة page الحالية وفق المعايير التالية: - هل يخلق القسم الافتتاحي (Hero) انطباعًا عاطفيًا واضحًا خلال أقل من 3 ثوانٍ؟ - هل التسلسل الهرمي للخطوط والعناوين واضح عبر جميع أحجام الشاشات؟ - هل التفاعلات مقصودة وتدعم تجربة المستخدم، أم مجرد عناصر زخرفية؟ - هل يرتقي التصميم لمستوى جودة reference_site_x مع حفاظه على هوية مميزة ومختلفة؟ اقترح 3 تحسينات محددة مع توضيح المبررات، ثم نفّذها.
يساعدك هذا البرومبت على بناء موقعك صفحةً صفحة بعد برومبت الانطلاقة الأولية.
بناءً على التصوّر المعتمد، ابنِ صفحة [Homepage/About/etc.]. المتطلبات والقيود: - مكوّن React واحد في ملف واحد باستخدام Tailwind - تصميم يبدأ من الجوال أولاً، ومتجاوب مع مختلف الشاشات - ميزانية الأداء: لا تعتمد على أي مكتبة يتجاوز حجمها 50kb إلا إذا كان ذلك مبررًا بوضوح - يجب أن تكون [Specific interaction from Phase 1] هي اللحظة الأبرز في قسم الهيرو - استخدم مهارة frontend-design لضمان جودة التصميم اعرض لي المكوّن. سأراجعه قبل الانتقال إلى الصفحة التالية.
برومبت يضع أساس مشروع تصميم موقع ويب، ويوجّه النقاش الأولي حول الفكرة، التخطيط، الهوية البصرية، والتقنيات قبل كتابة أي كود.
أنت مدير إبداعي خبير في استوديو تصميم معروف بتجارب ويب جريئة وذات موقف تصميمي واضح. أقدّم لك موجزًا لمشروع جديد. **العميل:** company_name **القطاع:** industry **الموقع الحالي:** if_there_is_one_or_delete_this_line **التموضع السوقي:** [مثال: "أفخم استوديو تصميم داخلي في الرياض، ولا يتعامل إلا مع 5 عملاء سنويًا"] **الجمهور المستهدف:** [من هم؟ ما الذي يبحثون عنه؟ وما دوافعهم؟] **النبرة:** [3-5 صفات، مثل: "واثقة، بسيطة، هادئة الإيقاع، تحريرية"] **مراجع يجب تجنّبها:** [مثال: "لا نريد قوالب SaaS عامة، ولا إحساس الصور الجاهزة، ولا تصميمًا استعراضيًا هدفه لفت الانتباه على Dribbble فقط"] **المراجع:** [2-3 روابط مواقع أو توجهات أسلوبية] **الصفحات الأساسية:** [الرئيسية، من نحن، الخدمات، تواصل معنا — أو غيرها] قبل كتابة أي كود، اقترح: 1. مفهومًا تصميميًا في 2-3 جمل؛ يكون هو "الفكرة الكبيرة" للموقع 2. استراتيجية تخطيط لكل صفحة: سلوك التمرير، وطريقة بناء الشبكة 3. توجه الخطوط والألوان 4. تفاعلًا مميزًا واحدًا يعرّف شخصية الموقع 5. قرارات الحزمة التقنية: الحركة، المكتبات، مع توضيح السبب لا تكتب أي كود الآن. اعرض المفهوم أولًا للمراجعة.