مهارات Figma Make المخصصة: حزمة من 3 مهارات لأنظمة التصميم

النسخة التي خرجت عن هوية العلامة

بدت نسخة المراجعة صحيحة تقريبًا، وهذا تحديدًا ما جعلها خطرة. كان نصف قطر الأزرار 12px، مع أن النظام مستقر على 8px منذ إعادة بناء الهوية. وظهر اللون الأساسي قريبًا من #18C5DA؛ درجة مجاورة بصريًا للون العميل #06B6D4، لكن لصقها في منتقي الألوان داخل Figma كشف الفرق فورًا. وبعد ثلاثة إطارات، أصبح حجم خط المتن 18px بدل 16px المحدد في النظام.

لم تكن المشكلة في المطالبة التي كتبتها ذلك الصباح، بل في المطالبة التي سبقتها بست مطالبات. يحتفظ Figma Make بسياق الجلسة، لكن قواعد نظام التصميم تتلاشى كلما ابتعدت المحادثة عن الموضع الذي أُدخلت فيه. وحين تصل إلى تنقيح النسخة الثالثة من قسم الواجهة الرئيسي، يبدأ النموذج بابتكار قيم تبدو معقولة للرموز. تصف ملاحظات إصدار مايو 2026 هذه الفجوة تحديدًا بأنها ما جاءت المهارات المخصصة لسدّه: تعليمات مجمّعة قابلة للاستدعاء، تُضاف إلى كل مطالبة من دون لصقها من جديد. (ملخص ملاحظات إصدار Figma، مايو 2026)

أعدت تشغيل موجز العمل نفسه في Make بعد إعداد حزمة المهارات أدناه. نصف قطر الزر: 8px. اللون المميّز: #06B6D4. المتن: 16px. لم تجعل المهارة Make أذكى؛ بل جعلت القواعد عصيّة على النسيان.

موجز العمل: ما الذي يفرضه نظام تصميم العميل فعلًا؟

يعتمد هذا المقال على نظام عميل حقيقي، مع تنقية الرموز التي قد تكشف هويته:

• اللون: الخلفية #0A0E14، والمقدمة #E6EDF3، ولون مميّز واحد #06B6D4. لا لون مميّزًا ثانويًا ولا تدرجات لونية.
• التباعد: أساسه 8px. القيم المسموحة هي 8 / 16 / 24 / 40، ولا تُقبل أي قيمة بينها أو خارجها.
• تدرج الخطوط: 14 / 16 / 20 / 32 / 48. المتن بحجم 16، ولا يُستخدم 18.
• نصف القطر: 8px لكل سطح تفاعلي، و0 للبطاقات، بلا استثناءات.
• الزر: مكوّن واحد بثلاث حالات؛ افتراضي، وتمرير المؤشر، ومعطّل. يملأ اللون المميّز الحالة الافتراضية، بينما تستخدم الحالة المعطّلة لون المقدمة بتعتيم 30%.

تفشل مطالبة عامة مثل «التزم بهويتنا» في تطبيق كل هذه القواعد، لأن الصفات تترك مساحة للتأويل. فعبارة «بارد، بسيط، بلون مميّز واحد» قد تصف ألف نظام. لا يحتاج النموذج إلى لوحة مزاجية؛ بل يحتاج إلى الجدول. والمطلوب أن تُراجع كل نسخة ينشئها Make لهذا العميل وفق ذلك الجدول، من دون أن أعيد كتابته في كل جلسة.

حزمة من 3 مهارات Figma Make: ملفات .md الفعلية

المهارات المخصصة في Figma Make هي ملفات Markdown منفردة تتبع مواصفات Agent Skills. تتحول قيمة name في البيانات الوصفية الأمامية إلى أمر بشرطة مائلة. وتُثبَّت المهارات لكل حساب على حدة، وتبقى متاحة في كل ملفات Make التي تملكها. وهناك شرط مهم: يجب أن يكون الملف مكتفيًا بذاته؛ فلا مجلدات scripts/ أو references/ أو assets/. كل ما تريد أن يستخدمه النموذج يجب أن يوجد داخل التعليمات نفسها. (المهارات المخصصة في Figma Make، مركز مساعدة Figma)

ثلاث مهارات تغطي 90% مما كنت أعيد كتابته.

/follow-ds-guidelines

جدول الرموز الحرفي، ملصقًا داخل التعليمات. بلا تفسير وبلا صفات.

---
name: follow-ds-guidelines
description: Enforce the client design system on every generated frame.
---

You are building inside a locked design system. Use these exact values.
Do not improvise alternates, do not interpolate, do not soften.

## Color
- background: #0A0E14
- foreground: #E6EDF3
- accent: #06B6D4 (single accent, no secondary)

## Spacing (8px base)
- allowed: 8, 16, 24, 40
- forbidden: any value not in the allowed list

## Type ramp
- 14 / 16 / 20 / 32 / 48
- body is 16. never 18.

## Radius
- interactive surfaces: 8
- cards: 0

## Button (one component, three states)
- default: fill #06B6D4, foreground #0A0E14
- hover: fill #06B6D4 at 90% opacity
- disabled: foreground #E6EDF3 at 30% opacity

If a request would produce a value outside this table, return the closest
allowed value and flag the substitution in a comment.

/design-crit

هذه مهارة للمراجعة. يفحص Make الإطار الحالي وفق جدول الرموز، ثم يعيد قائمة نجاح أو فشل تحدد القيم المخالفة بصيغة hex والبكسل.

---
name: design-crit
description: Audit the current frame against the client design system.
---

Walk the current frame top to bottom. For every visual element, check:
- color hex against the allowed palette
- spacing values against the 8 / 16 / 24 / 40 scale
- type size against the 14 / 16 / 20 / 32 / 48 ramp
- radius against 8 (interactive) or 0 (cards)

Return a table:
| Element | Property | Found | Expected | Pass/Fail |

End with a one-line verdict: PASS if all rows pass, FAIL otherwise.
Do not auto-fix. The human decides which deviations are intentional.

/insert-sample-data

تضيف مهارة البيانات النموذجية نصوصًا بديلة اعتمدها العميل، فلا تصل نسخ المراجعة وفيها lorem ipsum أو أسماء شركات اخترعها النموذج ثم يعترض عليها الفريق القانوني لاحقًا. (ملخص ملاحظات إصدار مايو 2026)

---
name: insert-sample-data
description: Replace placeholder text with approved sample data.
---

When asked for sample content, use only this set:

## Names
Sarah Chen, Marcus Okafor, Priya Raman, Diego Alvarez

## Company names (fictional, cleared)
Northwind Labs, Apex & Vine, Halcyon Group, Stratus Co

## Numbers
Use round numbers in product UI: 1,240 / 3,500 / 12,800.
Avoid revenue-shaped numbers unless asked.

Never use lorem ipsum. Never invent a real-sounding brand name not on this list.

ثلاثة ملفات، وكل واحد منها يلغي جزءًا كنت ألصقه مرارًا.

ربط موصل Notion كي تقرأ المهارة نظام التصميم المباشر

يناسب نهج الرموز الثابتة في /follow-ds-guidelines الأنظمة المستقرة. لكن ما إن يغيّر العميل أحد الرموز — وسيحدث ذلك — حتى يصبح الجدول المضمّن قديمًا. والحل هو إقران المهارة بموصل يجعل Make يجلب المصدر المباشر. (الموصلات في Figma Make، مركز مساعدة Figma)

في ملف هذا العميل، يوجد نظام التصميم في صفحة Notion واحدة بعناوين تطابق عناوين المهارة: اللون، والتباعد، وتدرج الخطوط، ونصف القطر، والزر. أستدعي المهارة والموصل في مطالبة واحدة.

Use the /follow-ds-guidelines skill, but pull the current token values
from @Notion "Halcyon – Design System v3" and override the inline table
where they differ. Then build the pricing section per the attached spec.

يمكن للمطالبة نفسها جلب وثيقة متطلبات المنتج من Drive بالصيغة ذاتها — @Drive "Halcyon pricing PRD" — ليجمع Make سياق نظام التصميم والمواصفات دفعة واحدة. (ملخص ملاحظات إصدار مايو 2026)

أختار النهج بحسب كل عميل: رموز مضمّنة للأنظمة التي لم تتغير منذ ثلاثة أشهر، وموصل يمد المهارة بالبيانات للأنظمة التي ما زالت تتطور. لا يتغير ملف المهارة .md بين الحالتين؛ الذي يتغير هو المطالبة. وهذا مقصود، لأنني لا أريد تضخمًا بمهارة منفصلة لكل عميل، بل مهارة واحدة تعرف كيف تقبل التجاوز.

وللتوضيح، تعمل مهارة /prototype-to-figma في خادم Figma MCP على سطح مختلف؛ فهي مثبّتة مسبقًا لنقل العمل بين الكود ولوحة التصميم، ولا تكتبها بنفسك. أما مهارات Make المخصصة فهي العكس: تكتبها أنت، وتعيش داخل Make، ولا تمس طبقة MCP.

أين تعطلت التجربة؟ عدم الحتمية وكلفة المشاركة

هناك ثلاث نقاط لم يتناولها الإعلان.

دعم النماذج أضيق مما توحي به الوثائق. تعمل المهارات المخصصة حاليًا مع نموذج Figma Make الافتراضي وClaude Opus 4.7 فقط. وإذا وحّد فريقك عمله على نموذج آخر داخل Make، فلن تُطبّق المهارة ولن يظهر فشل واضح؛ بل تتوقف عن فرض القواعد بصمت. (المهارات المخصصة في Figma Make، مركز مساعدة Figma) في أي نسخة جماعية، هذه أول نقطة أفحصها قبل البحث في سبب عودة نصف القطر الخاطئ.

النتائج متسقة «غالبًا جدًا»، وليست متطابقة. هذا ما تقوله وثائق Figma نفسها. ولأن النموذج غير حتمي، قد تغفل /design-crit أحيانًا مخالفة في إطار معقد، أو تعتبر خيارًا مقصودًا مخالفة. (المهارات المخصصة في Figma Make، مركز مساعدة Figma) لذلك أتعامل مع مهارة المراجعة بوصفها فحصًا أوليًا سريعًا، لا اعتمادًا نهائيًا.

كلفة المشاركة هي المشكلة التشغيلية. المهارات المخصصة مرتبطة حاليًا بالحساب الفردي. لنقل الحزمة إلى زميل، تصدّر ملفات .md ثم يرفعها هو إلى حسابه. ولا يتوفر نشر على مستوى المؤسسة. (المهارات المخصصة في Figma Make، مركز مساعدة Figma) وهذه عقبة حقيقية لاستوديو يدير عدة أنظمة لعملاء مختلفين: كل زميل جديد يحتاج إلى تثبيت يدوي لكل مهارة نشطة، وكل تحديث للمهارة يتطلب تصديرًا جديدًا. الحل بسيط لكنه فعّال: ضع ملفات .md تحت إدارة الإصدارات في مستودع العميل — نضع ملفاتنا بجوار رموز التصميم داخل المستودع الأحادي نفسه — ووسّم الإصدارات. عندها تصبح لخطوة الرفع حقيقة مرجعية واحدة بدل رسالة في Slack.

ومن زاوية تشغيل الاستوديوهات التي تبني على منصات تفرض أعباء مماثلة لكل مقعد، كتبت عن حساب تكلفة خطة Webflow المميزة للسبب نفسه: الأدوات تسعّر سطح الاستخدام، بينما تدفع أنت كلفة تعقيدات الدمج الكامنة تحته.

الخلاصة: ما الذي يدخل في المهارة، وما الذي يبقى قرارًا بشريًا؟

بعد بضعة أسابيع من استخدام هذه الآلية في DVNC.studio، استقررت على قاعدة بسيطة: كل ما أعدت كتابته أكثر من مرتين يدخل في مهارة. جداول الرموز، وقوائم التحقق النقدي، وقواعد البيانات النموذجية، والنصوص المتكررة لتعليقات إمكانية الوصول؛ لا شيء منها إبداعي، لكنها كلها كانت عبئًا تشغيليًا.

أما ما يبقى للبشر فهو القرار. تشير /design-crit إلى قيمة خارج النظام، لكنها لا تقرر هل هي خطأ أم استثناء متعمد لواجهة تسويقية منفردة. تجيد المهارة قول: «نصف القطر هنا 12، والمطلوب 8». لكنها لا تعرف أن «نصف القطر هنا 12 لأن فكرة الحملة احتاجت إلى بطاقة أكثر نعومة، وقد اتفقنا على ذلك يوم الثلاثاء». هذا الحكم هو جوهر العمل.

ما ينبغي فعله الثلاثاء المقبل: اختر نظام العميل الأكثر استخدامًا لديك. افتح ملف .md. الصق جدول الرموز كما لصقت جدول Halcyon أعلاه. احفظه باسم follow-ds-guidelines.md، وارفعه كمهارة مخصصة، ثم نفّذ به نسخة حقيقية واحدة، وبعدها شغّل /design-crit على الناتج وقارنه يدويًا بجدول الرموز. إذا التقطت المهارة ما كنت ستلتقطه بنفسك، فقد وفّرت ساعة من إعادة كتابة المطالبات لكل عميل كل أسبوع. وإذا أغفلت شيئًا واضحًا، فموضع الإصلاح هو ملف .md لا سجل مطالباتك.