أداة unslop مهارة (skill) تعمل مع Claude Code وCodex وGoogle Antigravity. تبدأ بتدقيق الواجهة لتحديد علامات المظهر المولّد، مثل التدرجات البنفسجية والتوهجات وتباين المسافات، ثم تقترح اتجاهًا تصميميًا مستمدًا من المنتج قبل أي تعديل. بعد ذلك تعدّل الواجهة على مراحل بترتيب ثابت. وننصح الفريق بمراجعة كل مرحلة قبل قبولها، وهي ممارسة يحددها الفريق لا خطوة يفرضها المستودع.
يحدث هذا كثيرًا: يطلب مطوّر من أداة ذكاء اصطناعي بناء لوحة تحكم، فتظهر الواجهة خلال دقائق. تبدو مقبولة في البداية، ثم يعرضها مدير العمليات أو فريق المبيعات فتبدو غريبة عن الشركة. المشكلة ليست في السرعة، بل في أن الفريق لم يتفق بعد على الشكل ولا على الحاجة التي تخدمها الواجهة.
يشرح هذا الدليل أداة لتحسين واجهات الذكاء الاصطناعي Claude، وهي unslop، التي طوّرها Damir Sokolovsky (@heydamir). نبدأ بعلامات الواجهة المولّدة، ثم نشرح خطوات التثبيت والتشغيل، وما تغيّره المهارة وما يبقى قرارًا لفريقك، وكيف تتحقق من النتيجة وتنظّم التعديل داخل نظام تصميم موثّق.
ما الذي يجعل الواجهة تبدو مولّدة بالذكاء الاصطناعي؟
في سيناريو توضيحي، طلب مدير تقنية في شركة متوسطة من فريقه نموذجًا أوليًا لبوابة العملاء. خلال يوم واحد وصلت شاشات كاملة مولّدة بأداة ذكاء اصطناعي. وعند عرضها على فريق المبيعات، لاحظ الفريق أن الشكل لا يشبه هوية الشركة، ولم يتفقوا على سبب ذلك.
قبل البحث عن حل، يحتاج الفريق إلى اتفاق واضح على الظاهرة نفسها: ما المقصود بالواجهة المولّدة، وما العلامات البصرية التي يمكن ملاحظتها بسرعة.
اقرأ أيضاً: متى يصبح موقع الشركة أداة عمل لا مجرد واجهة؟.
ما المقصود بـ vibe coding؟
يُستخدم تعبير vibe coding لوصف بناء البرمجيات بوصف الفكرة بلغة طبيعية لأداة ذكاء اصطناعي، ثم قبول النتيجة بعد مراجعة قد تكون محدودة. نستعمل التعبير في هذا المقال بهذا المعنى.
المستودع الخاص بمهارة unslop يصف هذه الواجهات بأنها vibecoded، وتهدف المهارة إلى تحويلها إلى واجهة مصممة لها طابعها الخاص. وعندما تُترك القرارات البصرية للأداة، قد تتشابه الشاشات في علاماتها، ولا يرتبط شكلها بمنتج الشركة أو جمهورها. لذلك يبدأ تحويل واجهة vibe coding إلى تصميم احترافي بمراجعة هذه القرارات، لا بتغيير لون واحد.
علامات الواجهة المولّدة: التدرجات والتوهجات والنصوص الصاخبة
يذكر المستودع أن المهارة تبحث أولًا عن العلامات الواضحة، ومنها التدرجات البنفسجية والتوهجات والرموز التعبيرية والنصوص الصاخبة والمسافات غير المنتظمة. وتتضح بعض هذه العلامات بالنظر المباشر إلى الشاشة:
- تدرجات بنفسجية في الخلفيات والأزرار.
- توهجات حول البطاقات والأزرار.
- رموز تعبيرية في العناوين والتسميات.
- نصوص صاخبة تستعمل عبارات مبالغًا فيها.
المسافات غير المتسقة وأثرها على الثقة
يذكر المستودع المسافات غير المنتظمة ضمن العلامات التي تبحث عنها المهارة، ويأتي تعديل المسافات أولًا في ترتيب المراحل قبل الألوان. أما أثرها على الثقة، فهو ملاحظة من السيناريو لا حكم عام. فقد تفاوتت الحواف بين البطاقات، وتباينت الفراغات داخل الشاشة الواحدة، فبدا الفريق أقل ثقة بالبيانات المعروضة، رغم أنها صحيحة.
هذه العلامات لا تعني أن الشيفرة سيئة، بل تعني أن الشكل لم يُحدَّد بعد بحسب منتج الشركة وجمهورها. وإذا سألت كيف أجعل واجهة الذكاء الاصطناعي تبدو احترافية، فابدأ بهذه القائمة قبل أي تعديل. فالتعديل دون تشخيص يغيّر الشكل، ولا يضمن أن الشاشة صارت أفضل.
ما هي أداة unslop ولماذا تُسمّى مهارة Claude؟
unslop مهارة طوّرها Damir Sokolovsky (@heydamir)، وهدفها تحويل واجهة تبدو مولّدة بالذكاء الاصطناعي إلى تصميم له طابعه الخاص. يصفها المستودع بأنها مهارة تعمل مع Claude Code وCodex وGoogle Antigravity، فهي مهارة Claude لتحسين تصميم الواجهات، ويُضاف مجلدها إلى بيئة عمل المطوّر.
لماذا تُسمّى مهارة؟ في Claude Code يصبح اسم المجلد هو الأمر الذي يكتبه المستخدم، فمجلد unslop يُستدعى بالأمر /unslop. ويذكر المستودع أنه يمكن أيضًا طلب الشيء بعبارة عادية، فيلتقط الوكيل المهارة بنفسه.
حدود تستحق الانتباه: توليد الصور يتطلب ربط خدمة صور، وتسأل المهارة قبل كل توليد مدفوع. وفيديو القصة القصير يتطلب Playwright وffmpeg.
ما الذي تفعله المهارة على الشاشة؟
تبدأ المهارة بالتدقيق، فتسرد علامات التوليد ومكانها، مثل التدرجات البنفسجية والتوهجات والتسميات بالرموز التعبيرية والنصوص المبالغ فيها والمسافات غير المنتظمة. ثم تقترح اتجاهًا مستمدًا من المنتج وتعرضه قبل أي تعديل. وإذا كانت الشاشة جيدة، تقترح تحسينات صغيرة بدل إعادة التصميم.
التعديل يجري على مراحل بهذا الترتيب:
- المسافات
- الألوان
- الأيقونات
- النصوص
- الخطوط
- التخطيط
- التفاصيل
- المرئيات
- الحركة
البيئات التي يذكرها المستودع: Claude Code وCodex وGoogle Antigravity
يذكر المستودع مسار تثبيت لكل بيئة. في Claude Code تُنسخ المهارة إلى مجلد المهارات الشخصي أو إلى مجلد داخل المشروع. وفي Codex يذكر المستودع طلب التثبيت من رابط المستودع، أو النسخ إلى مجلد خاص بـ Codex، ويكون الاستدعاء بالأمر $unslop. أما Google Antigravity فيذكر المستودع النسخ إلى مجلد المهارات الخاص بها، ولا يذكر أمر استدعاء خاصًا بها.
هذه المسارات مكتوبة في المستودع، ولم نتحقق منها في وثائق كل أداة. راجع وثائق البيئة التي تستخدمها قبل التثبيت، وتفاصيل الأوامر في القسم الرابع.
ما أنواع المشاريع المناسبة لها؟
يذكر المستودع أنها تعمل مع Next.js وReact وVue وSvelte وTailwind وHTML وCSS العادي، وعلى لوحات التحكم والتطبيقات وصفحات الهبوط، وحتى موقع منشور إذا توفّر رابطه فقط.
مثال توضيحي: فريق في شركة متوسطة بالرياض بنى لوحة متابعة للطلبات بمساعدة الذكاء الاصطناعي، ويريد تحسين مظهرها قبل عرضها على عميل. الشاشة موجودة ومشكلتها في طابعها البصري، وهذه حالة مناسبة. أما الهوية البصرية الجديدة فقرار يحتاج مراجعة مع من يملك الهوية. ولفهم الفرق بين الأداة المساعدة والوكيل الذي يتخذ خطوات متعددة، راجع ما هو الوكيل الذكي المستقل وحدود التجربة.
كيف تفصل مشكلات الواجهة المولّدة عن مشكلات التجربة الحقيقية؟
ليست كل ملاحظة على شاشة مولّدة بالذكاء الاصطناعي تحتاج إلى الحل نفسه. بعضها يتعلق بالمظهر، مثل المسافات والألوان والخطوط. وبعضها يتعلق بالطريقة التي يتحرك بها المستخدم داخل المنتج.
الخلط بين النوعين يهدر وقت الفريق. قد يقضي المطور ساعات في ضبط الألوان، بينما يبقى السبب الحقيقي لتعثر المستخدم دون معالجة. لذلك نفصل الملاحظات قبل أي تعديل، فهذه هي البداية الصحيحة لتحسين تصميم واجهة المستخدم المولدة بالذكاء الاصطناعي.
مشكلات الواجهة: المسافات والألوان والخطوط والمكونات المتكررة
هذه المشكلات تظهر أمام العين مباشرة. مسافات غير متساوية بين البطاقات، وتدرجات لونية لا تتبع هوية الشركة، وخطوط بأوزان متعددة دون قاعدة واضحة.
المكونات المتكررة مثال آخر. قد يجد الفريق ثلاثة أزرار لإجراء واحد بتصاميم مختلفة، أو جداول تعرض التاريخ بثلاث صيغ. هذه الملاحظات محددة، ويمكن تعديلها دون تغيير ما يفعله المنتج.
يصف المستودع أن المهارة تبحث أولًا عن التدرجات البنفسجية والتوهجات والإيموجي في العناوين والنصوص الصاخبة والمسافات غير المنتظمة، ثم تراجع المسافات والألوان والأيقونات والنصوص والخطوط والتخطيط بالترتيب.
مشكلات التجربة: خطوات زائدة وأسئلة لا يعرف المستخدم الإجابة عنها
مشكلات التجربة تظهر حين يتعثر المستخدم رغم أن الشاشة تبدو جيدة. مثال افتراضي للتوضيح: موظف في شركة توزيع في جدة يريد تقديم طلب إجازة، فيمر بخمس شاشات قبل الإرسال، ويسأل نفسه عن معنى حقل لم يُشرح.
هذه الملاحظات لا تُحل بتغيير الألوان. تحتاج إلى فهم من يستخدم الشاشة، وما الذي يريد إنجازه، وأين يتوقف. قد يتطلب ذلك مقابلة مستخدمين أو مراجعة طلبات الدعم، وهذا عمل بحث لا يصفه المستودع.
قبل أن تبني قرارات المنتج على تعديل شكلي، راجع أولوياتك التقنية والتشغيلية، كما نوضح في التحول الرقمي يبدأ من خطوة عمل واحدة.
كيف تكتب الفرق بين النوعين في تذكرة العمل؟
اكتب كل ملاحظة في تذكرة منفصلة، وضع نوعها في العنوان: مظهر أو تجربة. تذكرة المظهر تصف العنصر والمكان والمعيار المطلوب. تذكرة التجربة تصف الهدف والخطوة التي تعثّر فيها المستخدم.
هكذا تعرف أي الملاحظات تسلّمها للمهارة، وأيها تحتاج إلى نقاش مع الفريق المنتج قبل أي تعديل.
صياغة التذكرة حسب نوع المشكلة
تذكرة غامضة
- تحسين شكل صفحة الطلبات
- الواجهة تبدو مولّدة وتحتاج إلى تعديل
تذكرة واضحة
- مظهر: توحيد مسافات بطاقات الطلبات وفق نظام التصميم المعتمد
- تجربة: تقليل عدد الشاشات قبل الإرسال، وتحديد الحقل الذي يسبب السؤال
كيف تثبّت المهارة وتشغّلها على مشروع موجود؟
تدعم unslop في مستودعها ثلاث بيئات هي Claude Code وCodex وGoogle Antigravity، ولكل بيئة مسار تثبيت خاص بها. يقتصر هذا القسم على Claude Code، وهو المسار المناسب لفريق يريد تحسين واجهة تطبيق مولد بالذكاء الاصطناعي دون إعادة بنائه من الصفر.
تنبيه قبل أي تنفيذ: الأوامر التالية منقولة من ملف README في المستودع كما وردت عند إعداد هذا المقال. قبل تشغيل أي أمر على مشروع عميل، افتح المستودع على GitHub وقارن الأوامر بما هو منشور هناك الآن، فقد تتغير بين الإصدارات.
ما الذي تحتاجه قبل التثبيت؟
المهارة تعمل داخل Claude Code، ولا تحتاج إلى Playwright أو ffmpeg للتدقيق والتعديل الأساسي. هاتان الأداتان مطلوبتان فقط لميزتين محددتين: التقاط لقطة لموقع منشور، وإنشاء فيديو قصير لعرض التعديل.
- Claude Code مثبّت على جهاز المطوّر، ومفتوح على مجلد المشروع.
- فرع منفصل أو نسخة احتياطية قبل أي تعديل. هذه توصية عملية، وليست شرطًا من المستودع.
- Playwright وChromium للالتقاط، وffmpeg في PATH لإنشاء الفيديو فقط.
التثبيت على مستوى المستخدم أو على مستوى مشروع واحد
يعتمد هذا الدليل على مسارين من مسارات المهارات في Claude Code: مجلد شخصي في ~/.claude/skills/، ومجلد داخل المشروع في .claude/skills/. ويذكر توثيق Claude Code مسارات أخرى أيضًا.
قبل أن تختار أحدهما، راجع صفحة التوثيق لتعرف نطاق كل مسار، ثم اكتب المسار الذي يعتمده فريقك في دليل العمل الداخلي.
تشغيل المهارة بالأمر أو بوصف الطلب بلغتك
اكتب /unslop مع وصف الشاشة، أو صف طلبك بكلماتك ويتعرّف الوكيل على المهارة من تلقاء نفسه. أمثلة من README:
- /unslop this dashboard
- /unslop the hero of https://example.com
- /unslop my landing page and make the story video so I can post it
خطوات التثبيت في Claude Code
تحقّق من المستودع ثم استنسخه
قارن الأوامر بملف README في المستودع. ثم نفّذ أمر git clone الوارد هناك، وتأكد من وجود المجلد skills/unslop داخل المستودع المستنسخ.
قائمة مراجعة مكتوبة يدويًا إلى جانب العمل على الحاسوب. انسخ المهارة إلى المسار المختار
انسخ مجلد skills/unslop إلى ~/.claude/skills/ للمسار الشخصي، أو إلى .claude/skills/ داخل المشروع. بعد النسخ، تأكد من أن مجلد unslop وصل فعلًا إلى المسار الذي اخترته قبل المتابعة.
ثبّت أدوات الالتقاط عند الحاجة
من مجلد المشروع، ثبّت Playwright وChromium، وأضف ffmpeg إلى PATH إذا أردت إنشاء فيديو. يذكر توثيق Playwright أن الأمر npm init playwright@latest يضيفه إلى مشروع قائم أو ينشئ مشروعًا جديدًا، فاختر ما يوافق سياسة فريقك.
تحقّق من ظهور المهارة
افتح Claude Code واكتب /skills، وتأكد من ظهور unslop في القائمة قبل تشغيلها على مشروع حقيقي. إذا لم تظهر، فراجع المسار الذي نسخت إليه المجلد.
كيف تعمل المهارة خطوة بخطوة من التدقيق إلى التعديل؟
تعمل unslop، وهي مهارة Claude Skills للواجهات، وفق تسلسل واضح. تبدأ بالتدقيق، ثم تقترح اتجاهًا قبل أي تعديل، ثم تمر على جوانب الشاشة بترتيب محدد. بهذا يعرف الفريق ما يتوقعه قبل تشغيلها، وأين يستطيع أن يوجّهها.
وتنص وثائق المستودع على أن المهارة تقترح الاتجاه قبل أن تعدّل أي شيء، فيستطيع المستخدم توجيهها مبكرًا. وإذا كانت الشاشة جيدة أصلًا، تخبر المهارة الفريق بذلك وتقترح تحسينات صغيرة بدل إعادة التصميم. هذه النقطة مفيدة للفرق التي تريد تغييرًا محدودًا قبل عرض العمل على العملاء.
مرحلة التدقيق: قائمة بعلامات الواجهة المولّدة ومواقعها
تفحص المهارة الشاشة أولًا، وتسجّل كل علامة تدل على الطابع المولّد مع مكانها فيها. تذكر الوثائق من هذه العلامات التدرجات البنفسجية والتوهجات، والملصقات بالإيموجي، والنصوص الصاخبة، والمسافات غير المنتظمة. وبهذا تتحول الملاحظة العامة مثل «الشاشة لا تعجبني» إلى بنود محددة يستطيع الفريق مناقشتها واحدًا تلو الآخر.
مثال افتراضي للتوضيح: في شاشة متابعة طلبات، قد تظهر البطاقة الرئيسية بتدرج لوني وتوهج خلف الرقم، وقد تختلف هوامش البطاقات من قسم إلى آخر. يكتب الفريق هذه البنود قبل أي تعديل، فيعرف ما الذي سيتغير ولماذا.
مرحلة تحديد الاتجاه قبل التعديل
بعد التدقيق تقترح المهارة اتجاهًا مستمدًا من منتجك نفسه. يشمل الاتجاه شخصية الواجهة وعالمها، واللحظة أو اللحظتين اللتين تحملان اللون، إضافة إلى تفصيلة مميزة تميّز الشاشة.
لأن المهارة لا تعدّل قبل عرض هذا الاتجاه، يستطيع الفريق تصحيحه إذا لم يناسب هوية الشركة أو طريقة عملها. ويستحق هذا الوقت مراجعة مشتركة بين مدير التقنية ومصمم الواجهة، لأن الاتجاه هو ما سيحكم كل تعديل لاحق.
المرور على الجوانب: المسافات ثم الألوان ثم الأيقونات ثم النصوص
بعد اعتماد الاتجاه تمر المهارة على جوانب الشاشة بالترتيب التالي: المسافات، ثم الألوان، ثم الأيقونات، ثم النصوص، ثم الخطوط والتخطيط والتفاصيل والعناصر المرئية والحركة. وتذكر الوثائق هذا الترتيب دون أن تشرح سبب اختياره، لذلك يحسن أن يتابع الفريق كل مرحلة قبل الانتقال إلى التالية.
وعند الحاجة إلى مشهد أو كائن في الواجهة، قد تولّد المهارة صورة عبر خدمة صور متصلة. تذكر الوثائق من هذه الخدمات fal وReplicate وOpenAI images وHiggsfield، وتنص على أنها تعرض الطلب وتسأل قبل كل توليد مدفوع. وتضيف أن لوحات المتابعة والتطبيقات نادرًا ما تحتاج إلى ذلك. وإذا لم تكن خدمة متصلة، تعرض المهارة ربطها كخادم MCP قبل أي توليد.
ولا تصف الوثائق مرحلة مراجعة نهائية مستقلة، لذلك يتولى الفريق المراجعة بنفسه قبل قبول أي تعديل، كما يوضح القسم السابع.
دورة عمل المهارة
- التدقيققائمة بعلامات الواجهة المولّدة ومواقعها
- تحديد الاتجاهشخصية وعالم ولحظة لونية وتفصيلة مميزة
- المرور على الجوانببالترتيب من المسافات إلى الحركة
- مراجعة الفريقيتحقق الفريق من النتيجة قبل قبول أي تعديل
ترتيب المرور على الجوانب الأولى
المسافات
مراجعة الهوامش والفراغات بين العناصر، وهي من العلامات التي تذكرها الوثائق صراحة لطابع الواجهة المولّدة.
الألوان
مراجعة التدرجات والتوهجات، والإبقاء على الألوان التي يحددها الاتجاه المعتمد.
الأيقونات
مرحلة مستقلة للأيقونات. راجع فيها الملصقات بالإيموجي، لأن الوثائق تعدّها من علامات الواجهة المولّدة.
النصوص
تخفيف العبارات الصاخبة، وجعل العناوين تصف ما تعرضه الشاشة.
ما الذي تغيّره المهارة وما الذي تتركه للمطوّر أو المصمم؟
تركّز مهارة unslop، وهي أداة لتحسين واجهات الذكاء الاصطناعي Claude، على طبقة المظهر والتجربة البصرية. هذه الطبقة تحتاج عادةً إلى عمل بعد أن تولّد الأداة الواجهة. يصف المستودع عملها على التنسيق والنصوص والتخطيط والحركة، حتى عندما يكون المرجع رابطًا لموقع حيّ.
ما تحسّنه المهارة وفق وصف المستودع
تبدأ المهارة بالتدقيق، فتحدد علامات الواجهة المولّدة، مثل التدرجات البنفسجية والتوهجات والوسوم بالرموز التعبيرية والنصوص الصاخبة والمسافات غير المنتظمة. ثم تقترح اتجاهًا بصريًا مستمدًا من المنتج، وتعدّل الشاشة على دفعات مرتبة.
- المسافات والألوان والأيقونات والنصوص والخطوط والتخطيط، بالترتيب الذي يذكره المستودع.
- مشاريع Next.js وReact وVue وSvelte وTailwind وHTML وCSS العادي.
- تحسينات صغيرة إذا كانت الشاشة جيدة أصلًا، بدل إعادة تصميمها.
ما لا تضمنه المهارة
لا يذكر المستودع أن المهارة تتحقق من المنطق البرمجي أو صحة البيانات، لذلك يبقى هذا الفحص على الفريق. مثال توضيحي: في منصة طلبات إجازات لشركة توزيع في جدة، قد تصبح الشاشة أوضح، لكن زر الموافقة ما زال يرسل الطلب إلى مسار قديم. هذه مشكلة في الربط الخلفي، ولا يحلّها تغيير الألوان.
- التحقق من الأرقام والنصوص الديناميكية ومصدرها بعد تعديل القالب.
- مراجعة سلوك الشاشة عند الأخطاء وحالات التحميل الفارغة.
متى تحتاج إلى مصمم بشري؟
تحتاج الشركة إلى مصمم عندما يتجاوز العمل شاشة واحدة، مثل بناء هوية بصرية لعلامة تُعرض على عملاء في السعودية والخليج، أو تحويل إرشادات العلامة إلى نظام تصميم كامل. ويفيد المصمم أيضًا في الشاشات الرئيسية التي يراها العملاء أولًا.
أما الصور المولّدة فتعرض المهارة طلبها وتطلب موافقتك قبل كل توليد مدفوع، فيبقى قرار الإنفاق بيدك. ويبقى القرار البصري النهائي عند من يملك الهوية في الشركة.
قبل أن تطلب تعديلًا من المهارة
كيف تتحقق من أن الواجهة صارت أفضل قبل قبول التعديل؟
لا يكفي أن تبدو الواجهة أفضل بعد التعديل. يحتاج الفريق إلى مقارنة تبيّن ما تغيّر فعلًا، ثم يقرر قبوله أو رفضه على أساس واضح. هنا ينتقل تحسين تصميم واجهة المستخدم المولدة بالذكاء الاصطناعي من الانطباع إلى الفحص.
مقارنة قبل وبعد: الحواف والفراغات والتباين واتساق المكونات
مثال توضيحي: مدير تقنية في شركة متوسطة يراجع لوحة تحكم قبل عرضها على عميل. يفتح الصفحتين الأساسيتين، ويقارن البطاقات والجداول والأزرار بقيم نظام التصميم، لا بالإحساس وحده.
كل قياس يحتاج إلى مرجع: قيم الرموز المعتمدة في المشروع، أو سياسة إمكانية الوصول لدى الشركة. إن لم يكن المرجع مكتوبًا، فوثّقه قبل المراجعة، لأن المقارنة بلا مرجع تبقى انطباعًا.
قائمة مراجعة قبل قبول التعديلات
استخدم القائمة بعد انتهاء التعديل وقبل الموافقة عليه. إذا فشل بند جوهري، يُعاد التعديل إلى الفريق بدل قبوله. ويحدد نظام الصلاحيات في الشركة من يملك قرار القبول.
إذا اقترح unslop اتجاهًا قبل التعديل، فراجعه أولًا. فالأداة تقترح تحسينات صغيرة بدل إعادة التصميم إذا كانت الشاشة جيدة أصلًا، وهذا يحدد حجم المراجعة المطلوبة.
هل تغطي الاختبارات الواجهة الجديدة؟
تصف صفحة التثبيت الرسمية لـ Playwright إطارًا لاختبار تطبيقات الويب الحديثة من طرف إلى طرف، ويتضمن مشغّل اختبارات وتقرير HTML وعرضًا لتتبّع التشغيل. وتذكر الصفحة أنه يدعم Chromium وWebKit وFirefox. هذه الأدوات تفحص السلوك: هل ينتقل الزر إلى الصفحة الصحيحة؟ هل يرسل النموذج البيانات؟
لكن المصدر لا يصف فحوصًا للمسافات أو درجات الألوان، فلا نعتمد عليه وحده في الحكم البصري.
وفي مستودع unslop يطلب الدليل تثبيت Playwright مع متصفح Chromium لأخذ لقطة لموقع حي أو لإنشاء فيديو للشاشة. هذا استخدام منفصل عن اختبارات السلوك في المشروع.
طريقة التحقق من بنود الواجهة قبل وبعد
الفحص بالعين فقط
- مقارنة الشاشتين بالنظر دون مرجع محدد
- الحكم على الحواف والمسافات بأنها متقاربة أو لا
- الحكم على التباين بالإحساس
الفحص بمرجع معلوم
- قياس الحواف والظلال بقيم الرموز المعتمدة
- فحص المسافات بين البطاقات والأزرار بالقيم نفسها في كل شاشة
- فحص التباين وفق سياسة إمكانية الوصول لدى الشركة
- تسجيل الفرق في ملاحظة مكتوبة مع طلب التعديل
قائمة مراجعة قبل قبول التعديلات
كيف تنظّم التعديلات داخل فريق له نظام تصميم وهوية بصرية؟
في الشركة التي لها نظام تصميم موثّق، لا يكفي أن تبدو الواجهة أفضل بصريًا. يجب أن تبقى ضمن الهوية المعتمدة، وأن يعرف الفريق من وافق على كل تغيير ولماذا.
تبدأ الحوكمة قبل تشغيل المهارة، لا بعدها.
من يراجع التعديلات المقترحة؟
تخيّل أن فريق منتجات في شركة لوجستية في جدة أنشأ لوحة تحكم بسرعة، ثم شغّل مهارة Claude لتحسين تصميم الواجهات عليها. الخطوة الأولى التي يراجعها مدير المنتج أو مسؤول التصميم هي الاتجاه المقترح، لأن المهارة تعرضه قبل أن تعدّل أي شيء، فيستطيع المراجع توجيهها مبكرًا.
المراجعة الثانية يقوم بها مطوّر الواجهة، ليتأكد من أن التعديلات لا تكسر المكونات القائمة. وإذا كانت الشاشة جيدة أصلًا، فالمهارة تقترح تحسينات صغيرة بدل إعادة التصميم، وهذا القرار نفسه يحتاج إلى موافقة.
كيف توثّق التغييرات وتربطها بنظام التصميم؟
احفظ كل جولة تعديل في سجل واضح، مع وصف للمرور الذي طُبّق، مثل المسافات أو الألوان، وسبب القبول أو الرفض. هذه ممارسة عامة لإدارة التغيير، وليست ميزة تعد بها المهارة.
اربط كل قرار بعنصر في نظام التصميم: الألوان الرئيسية، أحجام الخطوط، والمكونات المعتمدة. إذا خالفت النتيجة اتجاهًا مكتوبًا في دليل الهوية، يُعاد الاتجاه إلى الدليل قبل الدمج، ولا يُقبل لأن الشاشة تبدو أفضل فقط.
ماذا يعني ترخيص CC BY 4.0 لفريقك؟
يحدد المستودع ترخيص المشروع بأنه CC BY 4.0، أي Attribution 4.0 International كما يظهر في صفحة Creative Commons. يسمح هذا الترخيص باستخدام المهارة وتعديلها ومشاركتها، بما في ذلك الاستخدام التجاري، بشرط ذكر المطوّر Damir Sokolovsky (@heydamir) والرابط إلى المستودع.
عمليًا، إذا أدخل فريقك المهارة أو جزءًا منها في أدوات داخلية أو مستندات، فاحتفظ بسطر النسب والرابط. لا تعتمد على هذا المقال وحده في تفسير الترخيص، بل اقرأ نصه الكامل، وإذا كانت لديك أسئلة قانونية فراجع مستشارك القانوني.
قائمة مراجعة قبل دمج التعديلات
أسئلة شائعة
هل تغيّر مهارة unslop منطق التطبيق أم تقتصر على الواجهة والتنسيق؟
يصف المستودع عمل المهارة على طبقة المظهر والتجربة البصرية، مثل المسافات والألوان والأيقونات والنصوص والخطوط والتخطيط والصور والحركة. ولا يذكر المستودع أنها تعالج منطق البرمجة أو البيانات. لذلك تحقّق من السلوك بعد أي تعديل، ولا تعتبر تحسين الشكل دليلًا على سلامة الوظائف.
كيف أعرف أن الواجهة صارت أفضل بعد التعديل؟
ابدأ بالتدقيق الذي تسرد فيه المهارة مواضع المشكلات قبل أي تعديل. بعد انتهاء المراحل، قارن الحالة الأولى بالنتيجة النهائية، وقرر القبول أو الرفض على أساس ما تغيّر فعلًا. وإذا كانت الواجهة جيدة أصلًا، تذكر المهارة ذلك وتقترح تحسينات صغيرة بدل إعادة التصميم.
هل أحتاج إلى Playwright أو ffmpeg لاستخدام المهارة؟
ليس بالضرورة. يحتاج المستودع إلى Playwright عند أخذ لقطة من موقع حي، وكذلك عند إنشاء فيديو القصة (Story video) القصير للواجهة. أما ffmpeg فيُشترط لفيديو القصة فقط، ويجب أن يكون متاحًا في PATH. ثبّت Playwright من مجلد المشروع الذي تشغّل فيه المهارة.
متى أحتاج إلى مصمم بشري بدل الاعتماد على المهارة؟
لا يحدد المستودع معيارًا لذلك. تعمل المهارة على طبقة المظهر والتجربة البصرية، لكن قرارات الهوية الكاملة وفهم احتياجات المستخدمين وطريقة عمل الفريق تبقى عند فريقك. إذا كانت المشكلة في تدفّق المستخدم داخل المنتج، فراجعها مع مصمم بشري أو مع من يملك تجربة المستخدم في شركتك.
هل يمكن استخدام المهارة مع فريق يعمل بنظام تصميم وهوية بصرية محددة؟
يمكن ذلك مع حذر. تقترح المهارة اتجاهًا قبل التعديل، فتستطيع توجيهها مبكرًا. لكن المستودع لا يذكر أنها تقرأ نظام التصميم الموثّق لديك تلقائيًا. لذلك حدّد قبل التشغيل العناصر الثابتة من الهوية، مثل الألوان والخطوط والمكونات، وراجع كل تغيير مع الجهة التي تعتمد الهوية في الشركة.
خطوة عملية
ابدأ بشاشة واحدة وقِس النتيجة
ابدأ بشاشة واحدة لا بمشروع كامل. ثبّت المهارة من المستودع الأصلي بعد مقارنة أوامر التثبيت مع ملف README، ثم شغّلها بالأمر /unslop على الشاشة المختارة. احفظ التدقيق الأول قبل أي تعديل، وننصح بمراجعة كل مرحلة على حدة، ثم قرر القبول أو الرفض على أساس ما تغيّر. تواصل معنا إذا أردت مساعدة في تبنّي هذه الأداة.
إذا كان هذا التحدي قريباً من واقع عملك، اكتب لنا ما تحتاجه.
تحدث مع الريتاج
