الواجهة قد تكون ممتازة وظيفيًا، لكن التفاصيل الصغيرة في الحركة هي التي تجعلها تبدو إما مصقولة أو «مولّدة بسرعة». المشكلة عند استخدام AI Coding Agents أن طلبًا مثل «حسّن حركات الواجهة» قد ينتج عشرات الحركات غير المتسقة، ومددًا مختلفة، واستخدامًا غير ضروري لـ transition: all.
الحل هنا ليس أن تطلب من الوكيل اختراع Animation جديدة لكل عنصر، بل أن تعطيه مرجع Motion واضحًا وتجعله يبدأ بالمراجعة قبل التعديل. وهذا هو الاستخدام الذي نعرضه اليوم مع Transitions.dev Skill.
أولًا: ثبّت المهارة
npx skills add Jakubantalik/transitions.devوفق التوثيق الرسمي، تعلّم المهارة Coding Agent أنماط الحركة الموجودة في Transitions.dev، وتعمل مع Claude Code وCursor وGitHub Copilot وCodex وGemini CLI. وتوفر المكتبة عشرات الانتقالات الجاهزة، مع نظام Motion Tokens للحركة.
البرومبت
هذا البرومبت من إعداد Let’sDoAI بناءً على فكرة المهارة الرسمية؛ ليس نصًا رسميًا صادرًا عن Transitions.dev أو صاحبها.
راجع حركة واجهة هذا المشروع بالكامل قبل أن تعدّل أي كود.
استخدم Transitions.dev Skill كمرجع للحركة.
ابدأ بـ Motion Audit فقط.
افحص خصوصًا:
- Modals
- Dropdowns
- Menus
- Tabs
- Tooltips
- Toasts
- Buttons
- Hover states
- Loading states
- Skeletons
- Success / Error states
- Panels
- Page transitions
- Icon swaps
- Counters
ابحث عن:
1. عناصر تظهر أو تختفي فجأة بلا Transition.
2. حركات لا تتوافق مع وظيفة العنصر.
3. مدد Animation غير متسقة.
4. Hardcoded durations يمكن توحيدها.
5. استخدام transition: all دون حاجة.
6. Keyframes مخصصة بينما يوجد Pattern مناسب في Transitions.dev.
7. اختلاف غير مبرر بين حركة الفتح والإغلاق.
8. Hover animation مبالغ فيها.
9. حركة قد تسبب Layout أو Paint غير ضروري.
10. أي حركة لا تراعي prefers-reduced-motion.
لكل مشكلة أعطني:
- الملف.
- العنصر.
- المشكلة الحالية.
- لماذا تبدو الحركة غير مصقولة.
- Transition المناسب من Transitions.dev.
- حجم التغيير المطلوب.
- هل التعديل ضروري أم تحسين اختياري.
رتب النتائج حسب:
Critical
Recommended
Polish
لا تعدّل أي ملف في هذه المرحلة.
بعد المراجعة، أعطني Motion Plan بأقل عدد ممكن من التغييرات التي تحقق أكبر تحسن بصري.
انتظر اعتمادي قبل تطبيق أي تغيير.شاهد الفكرة قبل تطبيقها
يوفر الموقع الرسمي Demo يوضح الفرق بين مخرجات AI العامة وواجهة تستخدم Transitions.dev Skill، ويمكن مشاهدة التجربة من داخل هذه المقالة:
إذا لم يظهر المشغل بسبب قيود التضمين في المتصفح أو WordPress، يمكن فتح الـDemo الأصلي من Transitions.dev.
لماذا يعمل هذا الأسلوب؟
لأنه يفصل بين مرحلتين مختلفتين: Motion Audit → Motion Implementation. بدل أن تطلب من الوكيل «حسّن الحركة» فيبدأ فورًا بتغيير CSS، تجبره أولًا على اكتشاف المشاكل وتصنيفها وربطها بنمط حركة مناسب.
أمر transitions review الرسمي يفحص المشروع بحثًا عن الانتقالات المصممة يدويًا، والمدد المكتوبة يدويًا، وKeyframes المخصصة، ثم يوضح أين يمكن أن يناسب المشروع Transition من المكتبة، دون تعديل الملفات.
بعد مراجعة التقرير
طبّق فقط التغييرات التالية من Motion Audit:
[الصق العناصر المعتمدة]
لكل عنصر:
- استخدم أقرب Recipe مناسب من Transitions.dev.
- حافظ على Design System الحالي.
- لا تغيّر Layout أو Business Logic.
- لا تضف Animation لمجرد وجود إمكانية لذلك.
- حافظ على prefers-reduced-motion.
- استخدم Motion Tokens متسقة بدل القيم العشوائية.
- اعرض Diff قبل تطبيق أي تغيير واسع.
بعد التنفيذ راجع جميع الحالات:
open / close
hover / leave
loading / loaded
success / error
ثم أخبرني بما تغير.وإذا أردت أن يختار الوكيل الحركة المناسبة؟
transitions applyبحسب التوثيق الرسمي، يستطيع هذا الأمر اكتشاف Transition مناسب للسياق الحالي، عرض سبب الاختيار، ثم تثبيته بعد تأكيدك. ويمكن أيضًا تحديد Recipe مباشرة، مثل:
transitions apply menu-dropdownمراجعة المشروع كاملًا
transitions reviewثم استخدم هذا الطلب حتى لا يتحول التدقيق إلى تعديل عشوائي:
راجع نتائج Transitions.dev.
لا تطبق كل الاقتراحات تلقائيًا.
اختر فقط التغييرات التي:
1. تحل مشكلة UX فعلية.
2. تزيد اتساق Motion System.
3. لا تضيف تشتيتًا بصريًا.
4. لا تزيد التعقيد دون قيمة.
5. تحافظ على Accessibility.
رتبها حسب أعلى أثر بصري مقابل أقل تعديل برمجي.
اعرض الخطة قبل التنفيذ.مثال عملي: Modal بلا حركة
.modal {
opacity: 1;
}بدل أن تكتب للوكيل «Animate this modal»، اطلب منه تحليل الحركة أولًا:
راجع هذا Modal باستخدام Transitions.dev Skill.
حدد أولًا:
- أفضل Pattern للفتح.
- أفضل Pattern للإغلاق.
- Duration المناسبة.
- Easing.
- Transform المناسب.
- reduced-motion behavior.
لا تغير الكود حتى تعرض الاقتراح.ما الذي يمكن تطبيقه؟
- Modal وPanel
- Dropdown وMenu
- Tabs
- Tooltip
- Toast
- Skeleton وLoading states
- Icon swaps
- Hover interactions
- Success وError states
- Page transitions
المكتبة الرسمية تعرض أمثلة حية لهذه الأنماط وغيرها، مع CSS وReact، وتؤكد أن الانتقالات مصممة مع مراعاة prefers-reduced-motion واستخدام خصائص مناسبة للحركة مثل transform وopacity وfilter.
خطأ شائع: اجعل الهدف أقل Animation، لا أكثر
Add animations everywhere.هذه ليست استراتيجية Motion جيدة. الهدف هو أن تساعد الحركة المستخدم على فهم ماذا حدث، ومن أين جاء العنصر، وإلى أين ذهب، وما الذي تغير. وفي بعض الحالات يكون أفضل Motion هو عدم إضافة حركة أصلًا.
النسخة السريعة
استخدم Transitions.dev Skill لمراجعة Motion في المشروع.
لا تعدّل الكود الآن.
ابحث عن:
- Missing transitions
- inconsistent durations
- transition: all
- unnecessary keyframes
- poor open/close behavior
- missing reduced-motion support
- animations that do not help UX
اربط كل مشكلة بأقرب Transitions.dev Recipe.
رتب النتائج حسب:
Critical / Recommended / Polish.
ثم أعطني أصغر Motion Plan يحقق أكبر تحسن بصري.
انتظر الاعتماد قبل التنفيذ.المصدر والأدوات المناسبة
المصدر: الفكرة الأصلية جاءت من منشور Jakub Antalik على X حول Transitions.dev Skill، ثم تم التحقق منها عبر الموقع الرسمي والتوثيق الرسمي. هذه المقالة والبرومبت العربي من إعداد Let’sDoAI، وليسا إرشادًا رسميًا من الشركة.
الأدوات/النماذج: المهارة الرسمية موجهة إلى Claude Code وCursor وGitHub Copilot وCodex وGemini CLI. ويمكن استخدامها مع مشاريع Frontend التي تعتمد CSS أو React، بينما توفر Transitions.dev أيضًا أدوات Agent مستقلة للتدقيق والإصلاح.
الروابط الأصلية: صفحة Transitions Skill · Transitions.dev · GitHub · منشور X الأصلي
الخلاصة العملية
لا تطلب من Coding Agent أن يخترع الحركة. أعطه Motion Library وAudit Workflow، ثم اجعله يبرر كل حركة قبل إضافتها.
Scan → Audit → Match Recipe → Approve → Apply → Verify
بهذا تتحول الحركة من «زخرفة يضيفها الذكاء الاصطناعي» إلى جزء من نظام تصميم يمكن مراجعته وتوحيده واختباره.