Impeccable: 62 قاعدة حتمية تطارد رتابة الذكاء الاصطناعي

للصفحات التي يبنيها نموذج لغوي مظهر يمكن تمييزه من أول نظرة. لقد رأيته: خط Inter في كل مكان، وتدرّج من البنفسجي إلى الأزرق أعلى الصفحة، وبطاقات داخل بطاقات، ونص رمادي على خلفية ملوّنة، ومربّع أيقونة مستدير الحواف يطفو فوق كل عنوان. أعطى Paul Bakaus هذا المظهر اسمًا، ثم كتب linter لتعقّبه.

Impeccable مهارة تصميم لوكائل البرمجة. حصدت نحو 6,700 نجمة هذا الأسبوع، ويقف مجموعها عند 91,500 تقريبًا. العبارة الترويجية — «المعجم التصميمي لوكيل البرمجة الخاص بك» — تُقلّل من شأن الجزء غير المألوف فعلًا: 62 من فحوصها تعمل كقواعد حتمية دون أي نموذج.

ما هي، على وجه التحديد

مهارة واحدة، و24 أمرًا، وكاشف. بدأت كامتداد لمهارة frontend-design من Anthropic، ثم نمت إلى شيء له آراؤه الخاصة.

التثبيت أمر واحد في جذر المشروع:

npx impeccable install
/impeccable init

الخطوة الثانية هي التي يتجاوزها الناس. يُجري init مقابلة معك عن المنتج — الجمهور، والغرض، والقيود، والنبرة — ثم يكتب الأجوبة في PRODUCT.md. أما أمر document المنفصل فيولّد DESIGN.md من الشيفرة الموجودة لديك. هذا الفصل مهم: حقائق المنتج والنظام البصري أثران مختلفان يتغيّران بإيقاعين مختلفين، ودمجهما في ملف واحد هو أقصر طريق إلى وثيقة تصميم عتيقة.

ثم تأتي الأوامر الـ24. وهي أقرب إلى معجم منها إلى سير عمل:

craft ينفّذ التسلسل الكامل، تشكيل ثم بناء، مع تكرار بصري. critique يراجع التسلسل الهرمي والوضوح والنبرة العاطفية. audit يفحص إمكانية الوصول والأداء والاستجابة. polish يوائم مع نظام التصميم قبل الإطلاق. bolder وquieter تعديلان اتجاهيان: تضخيم أو كبح. harden يتولى حالات الخطأ، والتعريب i18n، وتجاوز النص، والحالات الحدّية. typeset وlayout يصلحان الأمرين اللذين تخطئ فيهما واجهات الوكلاء أكثر من غيرهما. live يفتح متصفحًا ويولّد نسخًا من عنصر محدّد في مكانه.

ويمكنك تثبيت أي منها كاختصار مستقل:

/impeccable pin audit

فيُنشئ /audit كأمر في المستوى الأعلى. ميزة صغيرة، لكن الفرق كبير في ما إذا كان هذا المعجم سيُستخدم فعلًا.

الكاشف هو الهندسة المثيرة للاهتمام

هنا يفترق Impeccable عن كومة المستودعات التي ليست إلا مجموعات من الـprompts: القواعد الـ62 لا تحتاج نموذجًا، ولا مفتاح API، ولا وكيلًا.

npx impeccable detect src/
npx impeccable detect index.html
npx impeccable detect --json .
npx impeccable detect --list-rules

أي أنها تعمل داخل CI. طلب سحب يعيد إدخال حركة ارتداد، أو يُسرّب تدرّجًا بنفسجيًا، أو يترك نصًا رماديًا بحجم 14px على خلفية فيروزية، يمكن أن يفشل في الفحص من دون أن يدفع أحد ثمن tokens. وهناك علم --github يُصدر تعليقات GitHub Actions، وهو التفصيل التكاملي الوحيد المهم لمعظم الفرق.

مجموعة القواعد ذات رأي، إلى حدّ يزعج بعض الناس، والوثائق لا تخفي ذلك. قائمة الأنماط المضادة تحظر Arial وInter والخطوط الافتراضية للنظام؛ وتحظر الأسود الخالص والرمادي الخالص (يجب أن يكونا مشوبين بلون)؛ وتحظر تغليف كل شيء ببطاقات والبطاقات داخل البطاقات؛ وتحظر حركات الارتداد والمرونة بوصفها قديمة؛ وتحظر النص الرمادي على خلفيات ملوّنة.

بعض ذلك حجج حرفية يمكن الدفاع عنها. نص فقرة بتباين غير كافٍ على خلفية مشبعة خلل في إمكانية الوصول، ويبدو رخيصًا في الوقت نفسه. أما حظر Inter فحكم ذوق، وأحكام الذوق تشيخ سريعًا — الوثيقة نفسها التي تحظر Inter ستبدو بعد ثلاث سنوات قطعة من زمن مضى. لكن linter بلا آراء ليس إلا منسّقًا، وقيمة هذا أنه يمتلك موقفًا.

ولأنه حتمي، فهو قابل للالتفاف. أي فريق يريد تمرير التدرّج البنفسجي يمكنه إضافة استثناء سطري:

<!-- impeccable-disable overused-font: exported brand doc -->

أو إدارة الاستثناءات عالميًا عبر npx impeccable ignores add-value overused-font Inter --reason "Brand font". وعلم --reason يقوم بعمل اجتماعي هادئ: يجعل الاستثناء مرئيًا في diff.

كيف يتعلّق بالوكيل

مسار التثبيت الذي تختاره يحدّد مقدار التدخّل. مع Claude Code وCopilot وCodex وCursor وGrok Build، يكتب install بيان hooks أصليًا لكل مزوّد. في Claude Code يكون .claude/settings.local.json، وهو مستبعَد بـgit ومحلي على الجهاز. في Copilot يكون .github/hooks/impeccable.json، ويُثبَّت في المستودع ويُشارَك مع وكلاء السحابة. في Cursor يكون .cursor/hooks.json، وينطلق عند postToolUse حين يُكتب ملف.

الأثر أن الكاشف يعمل على تعديلات الوكيل نفسه ويعيد النتائج إلى حلقته. هذه آلية مختلفة جوهريًا عن «تشغيل أمر التدقيق حين تتذكّر». إنه يلتقط الرداءة لحظة التوليد لا لحظة المراجعة.

والمقايضة هي المعتادة: الـhooks التي تكتب في إعدادات المستودع هي hooks تظهر في مراجعة الشيفرة، ومستخدمو Codex عليهم الموافقة صراحة على hooks المشروع عبر /hooks بعد التثبيت. وإذا كان لفريقك رأي حاسم في إعدادات الأدوات المثبّتة، فمسار الـsubmodule موجود لهذا بالضبط: git submodule add مع npx impeccable link --source=.impeccable --providers=claude,cursor يُبقي الأداة تحت التحكم بالإصدارات إلى جانب الشيفرة التي تحكمها.

ما لن يصلحه

ثلاثة حدود تستحق التسمية.

لا يستطيع أن يقول لك إن كانت الصفحة جيدة. القواعد الـ62 تلتقط علامات سطحية. يمكن لصفحة أن تنجح في كلها وتبقى بلا وجهة نظر، وهذه هي الطبقة الأعمق من مشكلة رتابة الذكاء الاصطناعي، والتي لم يحلّها أي linter.

وضع live يعمل فقط على نسخة محلية. لا يحقن نفسه في موقع إنتاج، لا بـHTTPS ولا بغيره. هذا معقول، لكنه يعني أن حلقة التكرار البصري أداة تطوير لا أداة مراجعة.

والمعجم لا ينفع إلا إذا قرأه الوكيل. صياغة Impeccable نفسها صادقة في هذا: سبب إنتاج كل النماذج للتصميم ذاته هو أن كل النماذج دُرّبت على قوالب SaaS نفسها. وملف المهارة دفعة خفيفة ضد توزيع تدريبي، والدفعات تخسر أمام التوزيعات أكثر مما يتمنى أي أحد.

ولماذا لا نكتب قائمة تحقّق فحسب؟

سؤال مشروع. دليل أسلوب في ملف markdown لا يكلّف شيئًا ويؤدي العمل نفسه تقريبًا.

الفرق في الإنفاذ. قائمة التحقق داخل prompt اقتراح: يقرأها النموذج، ويوافق، ثم ينتج تدرّجًا بنفسجيًا لأن ذلك التدرّج ورد في بيانات تدريبه أربعين ألف مرة. أما القاعدة الحتمية فتُفشل البناء. هذه فئة مختلفة من الضغط، وهي الوحيدة التي تصمد أمام موعد تسليم.

والفرق الثاني في درجة التفصيل. القائمة تقول «استخدم طباعة جيدة». أمر typeset في Impeccable يعالج التسلسل الهرمي والسلّم والاقتران بين الخطوط على وجه التحديد، وللكاشف قواعد منفردة لأخطاء منفردة، ما يعني أن التغذية الراجعة تستطيع أن تشير إلى سطر CSS بدل الإشارة باليد نحو الذوق. هذه هي الحجة كلها لصالح الأدوات على حساب التوثيق، وهي تنطبق هنا للسبب نفسه الذي انطبقت به على أدوات linter قبل عشرين عامًا.

والثالث أن المعجم مشترك. bolder وquieter وdistill وharden — كلمات يستطيع المصمم والوكيل أن يتصرفا بناءً عليها. «اجعلها أكثر لمعانًا» ليست كذلك.

لماذا تتصدّر الآن

لأن مشكلة الكمّ وصلت. قبل عام، كان الوكيل يولّد صفحة هبوط من حين لآخر. الآن يستطيع فريق أن يولّد أربعين نسخة قبل الغداء، وقد انتقل عنق الزجاجة من «هل نستطيع بناءه» إلى «هل نستطيع تمييز الجيد منها بالسرعة الكافية».

المدقّق الحتمي للأخطاء الرخيصة هو الجزء الوحيد من هذه المشكلة القابل للتوسّع. الذوق لا يتوسّع. أما القواعد الـ62 الشبيهة بالتعبيرات النمطية عن الخطوط وحركات التخفيف فتتوسّع، وإصدارها كشيء يعمل في CI دون استدعاء نموذج هو أقل قرارات المستودع بريقًا وأكثرها نفعًا.