ملاحظة الكاتب: يأخذك هذا المقال خطوة بخطوة، ومن دون أي خبرة سابقة، لتجربة المهارتين الأساسيتين في mattpocock/skills. سنبدأ باستخدام /grill-me لتوضيح المتطلبات، ثم نستخدم /tdd لكتابة الشفرة، مع تحديد معايير القبول في كل خطوة.
الخلاصة في جملة واحدة: استخدم /grill-me أولًا ليطرح الوكيل الأسئلة اللازمة لتوضيح المتطلبات، ثم استخدم /tdd لكتابة الشفرة باختبار واحد في كل مرة.
حتى 2026-10-22 بتوقيت بكين، حصد مستودع mattpocock/skills على GitHub نحو 300 ألف نجمة، وهو مرخّص بموجب MIT، وأحدث إصدار له هو v1.3.1. ارتفاع عدد النجوم يدل على كثرة الاهتمام بالمستودع، لكنه لا يعني بالضرورة أنه مناسب لمشروعك. لذلك يركّز هذا المقال على طريقة التثبيت والاستخدام والتحقق من أن المهارتين تعملان كما ينبغي، من دون تهويل النتائج.
هذا دليل عملي يمكنك اتباعه خطوة بخطوة، بالنقر وإدخال النصوص. سنستخدم طلبًا صغيرًا هو «إضافة التحقق من القسائم إلى عملية تقديم الطلب»، ونتابع من التثبيت حتى يتحول أول اختبار إلى اللون الأخضر.
- الهدف: تثبيت المهارتين، وإكمال جولة من أسئلة توضيح المتطلبات باستخدام /grill-me، ثم كتابة أول اختبار بأسلوب «أحمر ← أخضر» باستخدام /tdd
- الوقت المتوقع: لا يستغرق التثبيت سوى بضع دقائق (يذكر الكاتب أنه يكتمل في «30 ثانية»). أما وقت الإجابة عن الأسئلة وكتابة الاختبار فيعتمد أساسًا على سرعة إجاباتك. التقدير التحريري للوقت الإجمالي هو نحو 30 دقيقة إلى ساعة
- المتطلبات المسبقة: أن تستخدم بالفعل وكيلًا برمجيًا، مثل Claude Code أو Codex أو GitHub Copilot أو Gemini CLI أو Cursor، وأن يكون لديك مستودع برمجي يمكنك التجربة فيه بحرية
- مستوى الصعوبة: مبتدئ. تعتمد الخطوات أساسًا على الواجهة الرسومية ومربعات الحوار، مع إدراج أوامر الطرفية كخيارات إضافية
أبرز ما في mattpocock/skills: ما دورا grill-me وtdd؟
mattpocock/skills مجموعة مهارات للوكيل نشرها Matt Pocock، ويصفها المستودع بأنها «مهارات للمهندسين المحترفين». يذكر المؤلف في ملف README أن هذه المهارات صغيرة وقابلة للتركيب، وتعمل مع أي نموذج، وأنها «مبنية على عقود من الخبرة الهندسية».
| النقطة | الوصف | الفائدة |
|---|---|---|
| /grill-me | يطرح الأسئلة تباعًا، ويرفق إجابة مقترحة مع كل سؤال. لا يكتب أي ملفات، ولا يبدأ إلا عندما تشغّله يدويًا | يساعدك على توحيد فهمك للمتطلبات مع الوكيل قبل البدء، ويكشف القرارات التي لم تنتبه إليها |
| /tdd | يحدد أولًا حدود الاختبار (seam) وينتظر موافقتك، ثم يتبع دورة «أحمر ← أخضر»، باختبار واحد في كل مرة | يوفّر تغذية راجعة في كل خطوة، وينتج اختبارات تصمد أمام إعادة الهيكلة |
| /setup-matt-pocock-skills | شغّله مرة واحدة في كل مستودع لإعداد متتبّع المشكلات، ووسوم الفرز، ومكان حفظ المستندات | يساعد المهارات الهندسية على معرفة المكان المناسب لكتابة الملفات |
| خيارات التثبيت | اختر بين الإضافة (تُحدَّث تلقائيًا) وskills.sh (ملفات قابلة للتحرير) | تثبيت الخيارين معًا يجعل كل مهارة تظهر مرتين |
لماذا يُفضّل استخدام grill-me وtdd معًا؟
يسرد ملف README عدة أنماط شائعة للإخفاق، ويرتبط اثنان منها مباشرة بهاتين المهارتين. أولها: «الوكيل لم ينفّذ ما أريده»، ويعود السبب إلى وجود فجوة في التواصل بينك وبينه. والحل هو إجراء جلسة استجواب، يطرح فيها الوكيل عليك أسئلة مفصّلة عمّا تريد إنجازه. أما /grill-me، فلا يتعدى جوهره سطرًا واحدًا: استدعاء مهارة الاستجواب. وترد قواعد طرح الأسئلة الفعلية في مهارة grilling.
أما النمط الآخر فهو: «الكود لا يعمل». فحتى بعد توحيد فهم المتطلبات، يظل الوكيل يعمل كأنه يطير أعمى إن لم يتمكن من رؤية نتائج تشغيل الكود فعليًا. يتبع /tdd نهجًا يبدأ بكتابة اختبار يفشل، ثم يكتب القدر اللازم من الكود لتمريره، وبذلك يحصل الوكيل على تغذية راجعة موثوقة في كل خطوة. وعند استخدام المهارتين معًا، تتولى الأولى الإجابة عن سؤال «ما الذي ينبغي تنفيذه؟»، والثانية عن سؤال «هل نُفّذ على نحو صحيح؟».
كيفية تثبيت mattpocock/skills وتشغيل grill-me وtdd: البدء في 5 خطوات
الخطوة 1: تثبيت mattpocock/skills (يُفضّل استخدام الواجهة الرسومية)
تشرح الوثائق الرسمية طريقة التثبيت في Claude Code وCodex وGitHub Copilot وGemini CLI، أما الوكلاء الآخرين فيمكنهم استخدام skills.sh. ويوضح ملف README أن هذه المهارات متوافقة مع أي نموذج. كما تشير الوثائق الرسمية إلى أن استخدامها مع Auggie وDroid وGoose وغيرها لم يُختبر بعد، لذا يُنصح حاليًا باستخدام skills.sh.
| الوكيل الذي تستخدمه | طريقة التثبيت الموصى بها | هل يُحدَّث تلقائيًا؟ |
|---|---|---|
| GitHub Copilot (VS Code) | افتح لوحة الأوامر، وشغّل Chat: Install Plugin From Source، ثم أدخل https://github.com/mattpocock/skills |
نعم، يُحدَّث يوميًا |
| Claude Code | ثبّت mattpocock-skills من سوق الإضافات الرسمي claude-plugins-official |
نعم، مفعّل افتراضيًا |
| Codex | أضف أولًا سوق إضافات mattpocock/skills، ثم ثبّت الإضافة |
نعم، يُحدَّث عند بدء التشغيل |
| Copilot CLI | ثبّته من سوق إضافات mattpocock |
يُحدَّث تلقائيًا بعد ضبط autoUpdate: true لمرة واحدة |
| Gemini CLI | ثبّت مجلدي engineering وproductivity كلًّا على حدة | لا، يلزم إعادة تشغيل الأوامر |
| Cursor وOpenCode وWindsurf وDevin وAmp وPi وغيرها | skills.sh | لا، يلزم التحديث يدويًا |
التثبيت أسهل ما يكون لمستخدمي VS Code. اضغط Ctrl+Shift+P (أو Cmd+Shift+P على macOS) لفتح لوحة الأوامر، ثم اكتب Chat: Install Plugin From Source واضغط Enter، وبعدها الصق عنوان المستودع. وإذا كنت تفضّل استخدام الطرفية، فإليك أوامر التثبيت الرسمية؛ انسخها كما هي:
- Claude Code: شغّل
claude plugin install mattpocock-skills@claude-plugins-official، وسيُحدَّث تلقائيًا افتراضيًا. - Codex: شغّل أولًا
codex plugin marketplace add mattpocock/skills، ثمcodex plugin add mattpocock-skills@mattpocock؛ وسيُحدَّث عند كل تشغيل. - GitHub Copilot CLI: شغّل أولًا
copilot plugin marketplace add mattpocock/skills، ثمcopilot plugin install mattpocock-skills@mattpocock. - Gemini CLI: شغّل الأمرين التاليين كلًّا على حدة:
gemini skills install https://github.com/mattpocock/skills.git --path skills/engineeringوgemini skills install https://github.com/mattpocock/skills.git --path skills/productivity. لا يجري التحديث تلقائيًا؛ وللتحديث، أعد تشغيل الأمرين. - الوكلاء الآخرون (skills.sh): شغّل
npx skills@latest add mattpocock/skills -a cursor، واستبدل cursor باسم الوكيل الذي تستخدمه، مثل opencode أو devin أو windsurf أو amp أو pi. وإذا لم تكتب-a، فسيُتاح لك اختيار الوكيل بنفسك. للتحديث، شغّلnpx skills@latest update، وعند توفر مهارات جديدة شغّل الأمرaddمجددًا. - تثبيت مهارة واحدة فقط: شغّل
npx skills@latest add mattpocock/skills --skill=<name>، واستبدل<name>باسم المهارة.
يتطلب Copilot CLI أيضًا تعديلًا لمرة واحدة في الملف ~/.copilot/settings.json، وذلك بإضافة هذا المقطع: {"extraKnownMarketplaces": {"mattpocock": {"source": {"source": "github", "repo": "mattpocock/skills"}, "autoUpdate": true}}}. يضيف هذا الإعداد سوق إضافات mattpocock بوصفه سوقًا مصدره مستودع GitHub mattpocock/skills، ويفعّل التحديث التلقائي. وتوضح الوثائق الرسمية أن المقطع مكتوب وفق تنسيق التوثيق، لكن لم يجرّب أحد تشغيله فعليًا بعد.
يمكنك الاختيار بين الإضافة وskills.sh، لكن لا تستخدمهما معًا. الإضافة حزمة للقراءة فقط تُحدَّث تلقائيًا، بينما ينسخ skills.sh ملفات قابلة للتحرير إلى مشروعك. تثبيتهما معًا يؤدي إلى ظهور نسختين من كل مهارة. عند استخدام skills.sh، سيطلب منك المثبّت تحديد المهارات التي تريد تثبيتها؛ تأكد من تحديد setup-matt-pocock-skills.
إذا كنت تريد تثبيت مهارة واحدة فقط، فهناك اعتمادان يجب تثبيتهما معًا. مهارة grill-me لا تفعل سوى استدعاء grilling، لذا يجب تثبيت grilling أيضًا. وتعتمد tdd على codebase-design، الذي تستخدم مفرداته المتعلقة بتصميم الواجهات لمناقشة نقاط الفصل (seam).
تكتمل العملية بنجاح عندما: تكتب / في مربع حوار Agent، فتظهر في قائمة الاقتراحات المهارات grill-me وtdd وsetup-matt-pocock-skills، ويظهر كل منها مرة واحدة فقط.
الخطوة 2: شغّل /setup-matt-pocock-skills في مربع الحوار
عند استخدام هذه المهارات لأول مرة في مستودع، اكتب /setup-matt-pocock-skills في مربع حوار Agent. سيطرح عليك ثلاثة أسئلة، واحدًا تلو الآخر: ما أداة تتبّع المشكلات التي تستخدمها (GitHub أو GitLab أو الملفات المحلية أو خيار آخر تصفه بنفسك)، وما الوسوم التي تريد استخدامها عند فرز التذاكر، وأين تريد حفظ المستندات التي سيُنشئها.
أجب بما يناسبك. إذا لم تكن متأكدًا، فاختر الملفات المحلية؛ ويمكنك تغيير ذلك لاحقًا. من الناحية الدقيقة، لا تعتمد /grill-me على إعداد المستودع، لذا يمكنك تخطي هذه الخطوة. لكن يُستحسن إكمال الإعداد قبل استخدام المهارات الهندسية مثل /tdd. ولا تحتاج إلى تشغيله إلا مرة واحدة لكل مستودع.
تكتمل العملية بنجاح عندما: تُطرح الأسئلة الثلاثة كلها، ويخبرك Agent بأن الإعداد اكتمل، وتعرف أين ستُحفظ المستندات لاحقًا.
الخطوة 3: اختر النموذج المناسب لـ grill-me وtdd
تشير الوثائق الرسمية إلى أن مرحلة طرح الأسئلة تعتمد على النموذج أكثر من معظم المهارات الأخرى. فطرح الأسئلة الاستقصائية يعتمد على معرفة النموذج نفسه بكيفية تعرّض الأنظمة للأعطال، لذا استخدم أفضل نموذج متاح لك. أما كتابة التنفيذ، فتعتمد أساسًا على السياق المتاح، ويمكن أن يؤديها نموذج أقل تكلفة بكفاءة.
| المرحلة | متطلبات النموذج | ما يُنصح به |
|---|---|---|
| طرح الأسئلة عبر /grill-me | يعتمد على الخبرة الهندسية التي يمتلكها النموذج؛ وكلما كان أقوى، كانت أسئلته أدق | استخدم أقوى نموذج متاح لديك، مثل Claude Opus 5.5 |
| كتابة التنفيذ عبر /tdd | يعتمد أساسًا على السياق الذي جرى بناؤه مسبقًا | يمكنك التبديل إلى نموذج أقل تكلفة |
| طريقة الربط | بدّل النماذج حسب المرحلة في Claude Code وCodex | استخدم مفتاحًا واحدًا من APIYI apiyi.com للاتصال بعدة نماذج |
يمكنك إعداد واجهة موحّدة في Claude Code وCodex على النحو التالي:
- Claude Code: اضبط أولًا متغيرَي البيئة
ANTHROPIC_BASE_URLعلىhttps://api.apiyi.com(واجهة APIYI الموحّدة)، وANTHROPIC_AUTH_TOKENعلى مفتاح API الخاص بك. ثم شغّلclaude، واستخدم/modelفي مربع الحوار للتبديل بين النماذج. - Codex: افتح
~/.codex/config.toml، وأضف السطرينmodel = "<模型ID>"وmodel_provider = "apiyi"، ثم أضف مقطعًا جديدًا بعنوان[model_providers.apiyi]، واكتب تحته الأسطر الثلاثةname = "APIYI"وbase_url = "https://api.apiyi.com/v1"وenv_key = "APIYI_API_KEY". راجع معرّف النموذج المعروض في لوحة التحكم.
قد تختلف أسماء الحقول باختلاف إصدار الأداة؛ لذا يُرجى الرجوع إلى الوثائق الرسمية للأداة وإلى docs.apiyi.com.
🎯 نصيحة لاختيار النموذج: استخدم أفضل نموذج لديك في مرحلة طرح الأسئلة، ثم انتقل إلى نموذج أقل تكلفة عند كتابة التنفيذ. ويمكنك التبديل بين النماذج في Claude Code وCodex باستخدام مفتاح واحد من APIYI apiyi.com، ما يجعل الأمر أكثر سهولة. تجدر الإشارة إلى أن APIYI تحلّ مشكلة استدعاء النموذج فقط، ولا تغني عن مهارتي grill-me وtdd نفسيهما.
يُعدّ الإعداد ناجحًا إذا تحققت من النموذج المستخدم حاليًا في مربع الحوار (يمكنك استخدام /model في Claude Code)، وتأكدت من اختيار النموذج القوي الذي تريده لمرحلة طرح الأسئلة.
الخطوة 4: استخدم /grill-me لتوضيح متطلبات «التحقق من القسائم»
ابدأ محادثة جديدة، ولا تتابع في المحادثة التي أعدّ فيها Agent الخطة بالفعل. وأوقف أيضًا وضع التخطيط (plan mode)، لأنه يدفع Agent إلى الإسراع في إعداد خطة، بينما تحتاجه في هذه الخطوة أن يواصل طرح الأسئلة. اكتب في مربع المحادثة /grill-me أريد إضافة التحقق من القسائم إلى عملية إتمام الطلب، ثم اضغط Enter.
لن يستدعي Agent أداة grill-me تلقائيًا؛ فهي لا تعمل إلا عندما تكتبها بنفسك. ستحوّل الأداة المتطلبات إلى «شجرة تصميم»، وتطرح في كل جولة دفعة واحدة جميع الأسئلة التي حُسمت شروطها المسبقة. يُرقّم كل سؤال ويُرفق بإجابة موصى بها، كما تُصاغ الأسئلة عمدًا بحيث تعني إجابتك بـ«نعم» قبول التوصية. قد تبدو جولة الأسئلة والأجوبة على النحو التالي (للتوضيح):
❓ س1 – ما الوقت المعتمد لتحديد انتهاء صلاحية القسيمة؟: وقت تقديم الطلب أم وقت نجاح الدفع؟
➡️ التوصية: وقت تقديم الطلب، لتجنّب انتهاء صلاحية القسيمة فجأة بينما يُكمل المستخدم عملية الدفع.❓ س2 – هل يُحتسب الشحن ضمن الحد الأدنى لقيمة الشراء للحصول على الخصم؟
➡️ التوصية: لا، يُحتسب المجموع الفرعي للمنتجات فقط.❓ س3 – ما الحد الأقصى لعدد القسائم التي يمكن استخدامها في الطلب الواحد؟
➡️ التوصية: قسيمة واحدة.
أكثر ما يؤدي إلى الفشل هنا هو أن توافق على كل شيء. فهذا لا يفعل سوى التصديق على خطة كتبها Agent، من دون أن تتخذ أي قرار بنفسك. الأفضل أن تجيب مع توضيح تفضيلاتك، مثلًا:
س1 نعم. س2 لا أوافق؛ قواعد حملتنا تشمل الشحن. س3 لا أعرف، أحتاج إلى سؤال فريق العمليات. لنبدأ بقسيمة واحدة.
ستُبنى أسئلة الجولة التالية على إجاباتك، مثل: «إذا كان الشحن مشمولًا، فهل يمكن الجمع بين قسيمة الشحن وقسيمة الخصم عند بلوغ حد أدنى للشراء؟». وإذا احتاج السؤال إلى التحقق من حقائق في المستودع، فمن المفترض أن يكلّف Agent وكيلًا فرعيًا بالتحقق منها بنفسه، بدلًا من أن يسألك. وتشير الوثائق الرسمية إلى أن طرح أكثر من أربعين سؤالًا إجمالًا خلال أربع جولات أمر طبيعي.
تُعد هذه الخطوة ناجحة إذا تحققت الأمور التالية:
– تُطرح الأسئلة على جولات، ويكون لكل سؤال رقم وإجابة موصى بها، بحيث يمكنك قبول التوصية بمجرد الرد بـ«نعم».
– تستند الأسئلة في الجولات اللاحقة بوضوح إلى إجاباتك السابقة.
– تكون قد خالفت توصية مرة واحدة على الأقل، أو قلت «لا أعرف» مرة واحدة على الأقل بعد تفكير.
– يطلب منك Agent في النهاية تأكيد ما إذا كنتما قد توصلتما إلى اتفاق، ولا يبدأ العمل أو يكتب أي ملفات قبل تأكيدك.
الخطوة 5: اكتب الشيفرة باستخدام /tdd، اختبارًا واحدًا في كل مرة
واصل العمل في الجلسة نفسها حتى يبقى السياق الذي أنشأته للتو متاحًا. ويمكنك، عند الحاجة، التبديل إلى نموذج أقل تكلفة، ثم إدخال الأمر: /tdd نفّذ التحقق من القسائم وفق القواعد التي اتفقنا عليها للتو.
لن يبدأ بكتابة الاختبارات مباشرة، بل سيعرض أولًا حدود الواجهة (seam) التي يقترح اختبارها، ثم ينتظر موافقتك. مثلًا، الخيار A هو الدالة النقية validateCoupon(coupon, order, now)، وهي تغطي منطق القواعد، لكنها لا تختبر كيفية اتصالها بتدفق إنشاء الطلب. أما الخيار B فهو checkout() في خدمة إنشاء الطلب، ويختبر هذا الاتصال، لكنه أبطأ. إذا اكتفى بذكر أسماء الخيارات، فاسأله عن الجوانب التي يكشفها كل seam وما الذي قد يفوته. في هذا المثال، سنختار الخيار A.
فيما يلي مثال على الاختبار الأول باستخدام TypeScript وVitest. هذا للشرح فقط؛ فالمهارة لا تقتصر على لغة برمجة أو إطار اختبارات بعينه:
- ملف الاختبار:
coupon.test.ts، يستوردitوexpectمنvitest، ويستوردvalidateCouponمن./coupon - اسم الاختبار: لا يمكن للمستخدم استخدام قسيمة منتهية الصلاحية
- القسيمة المُمرّرة:
{ code: "SAVE10", minSubtotal: 100, expiresAt: new Date("2026-10-01") }، أي قسيمة صالحة عند بلوغ المبلغ الفرعي 100، وتنتهي صلاحيتها في 1 أكتوبر - الطلب المُمرّر:
{ subtotal: 120 }، ومبلغه الفرعي 120 - الوقت الحالي المُمرّر:
new Date("2026-10-22"). نمرّر الوقت كوسيط بدلًا من قراءة الوقت الحالي داخل الدالة، حتى لا تتغير النتيجة باختلاف يوم تشغيل الاختبار - النتيجة المتوقعة:
expect(result).toEqual({ ok: false, reason: "expired" })، أي إن التحقق يفشل بسبب انتهاء الصلاحية
شغّل الاختبار أولًا؛ سيفشل لأن validateCoupon غير موجودة بعد. بعد ذلك، يكتب الوكيل أقل قدر من الشيفرة اللازمة لاجتياز الاختبار، مثل التحقق من الشرط now >= coupon.expiresAt وإرجاع نتيجة تفيد بانتهاء الصلاحية. وبعد نجاح الاختبار، يبدأ بكتابة الاختبار التالي، مثل: «ارفض القسيمة إذا لم يبلغ المبلغ الفرعي الحد الأدنى». لاحظ أن القيمة المتوقعة مكتوبة حرفيًا ومستمدة من القاعدة، وأن اسم الاختبار يصف ما يمكن للمستخدم فعله، لا أنه «استدعى دالة داخلية معيّنة».
تتضمن دورة TDD الحالية مرحلتي «الأحمر ← الأخضر» فقط، من دون مرحلة إعادة الهيكلة. أُزيلت هذه المرحلة في يونيو 2026 لأن الوكيل نادرًا ما كان ينفذها، وأصبحت إعادة الهيكلة من مسؤولية /code-review. ما زال وصف المهارة يذكر دورة red-green-refactor، وهذه مشكلة معروفة، لكن هذا التعبير لا يزال قادرًا على تفعيل المهارة. استخدم المحاكاة الوهمية (mock) عند حدود الأنظمة فقط، مثل واجهات API الخارجية والوقت والأرقام العشوائية، ولا تستخدمها لمحاكاة وحداتك الخاصة.
يُعدّ الأمر ناجحًا إذا تحقق ما يلي:
– قبل كتابة أي ملف اختبار، يسرد نقاط الفصل (seams) وينتظر موافقتك.
– يظهر اختبار واحد فقط في كل مرة: يفشل أولًا ثم ينجح، وبعدها فقط يبدأ بكتابة الاختبار التالي. فلا يحدث أن يكتب «مجموعة اختبارات أولًا، ثم مجموعة من الشيفرات».
– تغيير اسم دالة داخلية لا يؤدي إلى فشل الاختبارات.
متى تستخدم مهارات grill-me وtdd وغيرها، وقائمة استكشاف الأخطاء وإصلاحها
يتعثر كثيرون لا لجهلهم بطريقة الاستخدام، بل لاستخدامها في غير موضعها. يمكنك الاحتفاظ بالجدول التالي والرجوع إليه لاختيار المهارة المناسبة لكل حالة.
| حالتك | المهارة المناسبة | التوضيح |
|---|---|---|
| الفكرة لا تزال غامضة، وربما لا تتعلق بالبرمجة | /grill-me | لا تحتاج إلى مستودع ولا تكتب ملفات؛ ويمكن استخدامها في القرارات التجارية والكتابة أيضًا |
| تريد تعديل الشيفرة في مستودع، مع توثيق المصطلحات والقرارات | /grill-with-docs | تتبع عملية الأسئلة نفسها، وتحدّث GLOSSARY.md وسجلات قرارات الهندسة المعمارية (ADR) |
| حجم العمل أكبر مما يمكن إنجازه في جلسة واحدة | /wayfinder | تنشئ خريطة لتذاكر القرارات في متتبع المشكلات، ثم تحلها واحدة تلو الأخرى |
| تريد تنفيذ سلوك له مدخلات ومخرجات واضحة | /tdd | مناسب لمنطق الأعمال، وعقود الطلب والاستجابة، وتحويل البيانات، والتحقق من صحتها |
| لديك مواصفات أو تذكرة جاهزة، وتريد تنفيذها كاملة | /implement | يوجّه العمل عبر /tdd وفق نقاط الفصل المتفق عليها، ثم يشغّل /code-review قبل الإرسال |
إذا لم تعرف أي مهارة تختار، فاكتب /ask-matt، وسيقترح عليك المهارة الأنسب بناءً على حالتك. ويمكن معالجة معظم المشكلات التي تظهر أثناء الاستخدام الفعلي بالرجوع إلى الجدول التالي.
| ما تلاحظه | السبب الشائع | طريقة المعالجة |
|---|---|---|
| كثرة الأسئلة، حتى إنها تتجاوز المئة | النطاق واسع جدًا، أو أن امتلاء السياق يخفض جودة الأسئلة | اطلب من Agent تقسيم العمل إلى مهام أصغر، ثم ناقش كل مهمة على حدة |
| ينتهي بسرعة، ولا تقول طوال الوقت سوى «أوافق» | إجاباتك سلبية أكثر من اللازم | اعترض بوضوح، ونبّه إلى خروج النقاش عن النطاق، وقل «لا أعرف» عندما يكون ذلك صحيحًا |
| تعجز عن الإجابة عن سؤال ما رغم إعادة صياغته مرارًا | السؤال من النوع الذي لا يُحسم بالحوار، مثل الإحساس بتفاعل واجهة المستخدم | أوقف الأسئلة، واستخدم /prototype لإنشاء نموذج أولي مؤقت وتجربته |
| لا تستطيع اختيار حدود الاختبار | لا تذكر قائمة نقاط الفصل سوى أسماءها | اسأل أولًا عن الحالات التي يكشفها كل حد، وما يفوته، ومدى بطئه |
| كُتب التنفيذ أولًا ثم أُضيفت الاختبارات | هذا هو السلوك الافتراضي للنموذج | راقب الشرائح الأساسية أثناء التنفيذ، وإذا لاحظت ذلك فاطلب منه العودة إلى مرحلة «الفشل أولًا» |
| اختبارات المتصفح عالقة في حلقة لا تنتهي | كُتبت اختبارات شاملة من البداية قبل وجود الوظيفة | وضّح في CLAUDE.md أن اختبارات المتصفح تُكتب بعد أن يعمل السلوك المطلوب |
| الاختبارات لا تفعل سوى تكرار التنفيذ | لا توجد إجابة مرجعية مستقلة للتغييرات في الإعدادات أو الشيفرة الرابطة | لا تستخدم TDD لهذه التغييرات؛ ويمكنك توثيق القواعد في CLAUDE.md |
| ظهور نسختين من كل مهارة | ثبّتَّ المهارات عبر كل من الإضافة وskills.sh | أزل التثبيت من إحدى الطريقتين |
الأسئلة الشائعة حول mattpocock/skills
س1: هل يعني حصوله على نحو 300 ألف نجمة أن أداءه ممتاز بالتأكيد؟
لا. يعكس عدد النجوم مدى الاهتمام به، ولا يدل على أدائه الفعلي في مشروعك. يذكر المؤلف أن العمل يستند إلى خبرة هندسية تمتد لعقود، لكن لا توجد حتى الآن تقييمات مستقلة تقدّم بيانات عن مكاسب الكفاءة. وأوثق طريقة للحكم عليه هي تطبيق خطوات المقال واحدةً تلو الأخرى في مستودعك، والتحقق من استيفاء معايير القبول لكل خطوة.
س2: هل يقتصر استخدامه على أدوات مثل Claude Code وCodex؟
لا. الأدوات التي تذكرها الوثائق الرسمية هي فقط الطرق التي جرى التحقق منها. أما الوكلاء غير المذكورين، فيمكنك استخدام skills.sh معهم، عبر تحديد الوكيل باستخدام `-a` أو اختياره تفاعليًا. ويوضح ملف README أيضًا أن هذه المهارات مناسبة لأي نموذج، فهي في الأساس تعليمات للمهارات مكتوبة بصيغة Markdown.
س3: بعد انتهاء الأسئلة في grill-me، هل أبدأ جلسة جديدة لكتابة الشفرة؟
لا. فالسياق الذي تكوّن أثناء طرح الأسئلة هو الجزء الأهم. توصي الوثائق الرسمية بمتابعة العمل في الجلسة نفسها، وطلب إنشاء المواصفات باستخدام /to-spec. أما المثال البسيط في هذا المقال، فيتابع مباشرةً باستخدام /tdd ضمن الجلسة نفسها.
س4: إذا وجدت أن عدد الأسئلة في الجولة الواحدة كبير، فهل يمكنني جعلها سؤالًا واحدًا في كل مرة؟
نعم. يكفي أن تضيف العبارة `When grilling, ask one question at a time.` إلى ملف `CLAUDE.md` العام. لكن طرح الأسئلة على شكل جولات يتيح لك رؤية جميع المسائل التي يمكنك اتخاذ قرار بشأنها دفعةً واحدة. لذا ننصحك بتجربة الأسلوب عدة مرات قبل أن تقرر تغييره.
س5: لماذا يذكر وصف tdd خطوات red-green-refactor، بينما لا تحدث إعادة هيكلة فعليًا؟
أُزيلت مرحلة إعادة الهيكلة عمدًا في يونيو 2026، لكن الوصف لم يُحدَّث بعد. وهذه مشكلة معروفة لم تُغلق حتى الآن. تتبع العملية حاليًا أسلوب «أحمر ← أخضر»، وتُترك إعادة الهيكلة لمهارة /code-review. ويكون الأداء أفضل عند فصل كتابة التنفيذ عن مراجعته، بحيث تجري كل منهما في جلسة مستقلة.
س6: إذا أردت استخدام نموذج مختلف لمرحلة طرح الأسئلة ومرحلة التنفيذ، فما أسهل طريقة؟
يمكنك إعداد واجهة موحّدة في Claude Code أو Codex باتباع طريقة الإعداد في الخطوة الثالثة من هذا المقال. وباستخدام مفتاح واحد من APIYI apiyi.com، يمكنك استخدام Claude Opus 5.5 في مرحلة طرح الأسئلة، ثم الانتقال إلى نموذج أقل تكلفة عند كتابة التنفيذ. تقتصر مهمته على استدعاء النموذج، بينما تظل المهارات مثبتة بالطريقة المعتادة.
س7: ما أنواع التغييرات التي لا تناسبها منهجية tdd؟
من أمثلتها تغييرات الإعدادات، والتوصيلات بين المكونات، والشفرة الرابطة، وتعليقات الأنواع، وعمليات الإضافة والحذف والتعديل والاستعلام التي لا تفعل سوى تمرير الطلبات. فهذه التغييرات لا تملك إجابة مرجعية مستقلة، وقد ينتهي الاختبار إلى مجرد إعادة كتابة التنفيذ. وتقرّ الوثائق الرسمية بأن المهارة لا تساعدك حاليًا على تحديد ما إذا كان استخدام TDD يستحق العناء؛ لذا عليك اتخاذ هذا القرار بنفسك. وإذا لم تكن متأكدًا، يمكنك أولًا استخدام نموذج خفيف عبر APIYI apiyi.com لتطلب من الوكيل تحديد مدخلات التغيير ومخرجاته القابلة للملاحظة. وإذا لم يستطع تحديدها، فلا تستخدم tdd.
أهم النقاط والخلاصة حول mattpocock/skills
أهم النقاط
- اسأل قبل أن تكتب: استخدم
/grill-meأولًا لتوضيح المتطلبات، ثم نفّذها باستخدام/tdd، اختبارًا واحدًا في كل مرة. - اختر طريقة تثبيت واحدة: ثبّت الإضافة أو استخدم skills.sh، لا كليهما؛ وإلا فستظهر نسختان من كل مهارة.
- لا تنسَ التبعيات: عند التثبيت يدويًا، تحتاج مهارة
grill-meإلىgrilling، وتحتاجtddإلىcodebase-design. - أجب بوضوح: اعترض أكثر، وقل «لا أعرف» عندما يلزم. فالموافقة على كل شيء هي أكثر أسباب الفشل شيوعًا.
- أكّد حدود الاختبار أولًا: تعرض
tddحدود الاختبار وتنتظر موافقتك، ثم تنتقل من الأحمر إلى الأخضر من دون إعادة هيكلة. - اختر النموذج المناسب لكل مرحلة: استخدم أقوى نموذج لطرح الأسئلة، ويمكنك اختيار نموذج أقل قدرة للتنفيذ. وباستخدام مفتاح API واحد عبر APIYI، يمكنك التبديل بين النماذج.
الخلاصة
لا تكمن قيمة mattpocock/skills في حصوله على نحو 300 ألف نجمة، بل في تحويل مبدأين هندسيين أساسيين—توضيح المتطلبات أولًا، ثم التحقق منها بخطوات صغيرة—إلى مهارات قابلة للتنفيذ بشكل متكرر. اتبع الخطوات الخمس الواردة في هذا المقال: التثبيت، وتشغيل الإعداد، واختيار النموذج، واستخدام /grill-me لتوضيح المتطلبات، ثم استخدام /tdd لكتابة أول اختبار ينتقل من الأحمر إلى الأخضر. بهذه الطريقة، ستتمكن من تحديد مدى ملاءمة هذا الأسلوب لمشروعك.
إذا كنت تريد استخدام نموذج مختلف في مرحلتي الاستيضاح والتنفيذ، فيمكنك التبديل بين النماذج في Claude Code وCodex باستخدام مفتاح واحد عبر APIYI على apiyi.com. أما ما تبقى، فهو التدرب عدة مرات على متطلبات حقيقية، مع الحرص على تقديم إجابات واضحة.
المراجع
- GitHub – mattpocock/skills: الصفحة الرئيسية للمستودع، وتضم README وجميع ملفات SKILL.md
- الرابط:
github.com/mattpocock/skills -
ملاحظة: المرجع المعتمد لطرق التثبيت وقائمة المهارات وسجل التحديثات
-
AI Hero – توثيق Skills: التوثيق الرسمي لمهارات مثل
grill-meوtdd - الرابط:
aihero.dev/skills -
ملاحظة: يتضمن قائمة التحقق «It’s working if» والأسئلة الشائعة
-
skills.sh – mattpocock/skills: بوابة تثبيت عامة لوكلاء الذكاء الاصطناعي الآخرين
- الرابط:
skills.sh/mattpocock/skills - ملاحظة: مناسب لأدوات مثل Cursor وOpenCode وWindsurf، ويتطلب تحديثًا يدويًا
الكاتب: فريق APIYI التقني
للتواصل التقني: يسعدنا تواصلكم معنا عبر الصفحة الرئيسية لموقع APIYI apiyi.com. ويمكنكم الاطلاع على مزيد من معلومات التكامل في مركز التوثيق docs.apiyi.com.
