دليل واضح إلى مهارات Matt Pocock الهندسية للوكلاء البرمجيين

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

الهدف ليس زيادة الأتمتة لمجرد الأتمتة. بل فرض تحكم أدق في الطريقة التي يصل بها الوكيل إلى قرار هندسي.

المتطلبات المسبقة وخيارات التثبيت

قبل تثبيت أي شيء، تأكد من توفر المتطلبات التالية:

• مستودع موجود أو مستودع جديد تمت تهيئته
• Claude Code أو Cursor أو Codex أو GitHub Copilot أو Amp
• صلاحية لإضافة ملفات تعليمات الوكلاء
• شجرة عمل Git نظيفة، أو حفظ التغييرات بأمان عبر commit أو stash
• اختيار نظام لتتبع المشكلات، مثل GitHub Issues أو ملفات Markdown محلية

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

1. ثبّت المهارات عبر مسار واحد

يمكن لمستخدمي Claude Code الذين يريدون مهارات مُدارة ومخصصة للقراءة فقط تثبيت الإضافة الرسمية:

bashCopy
/plugin install mattpocock-skills

يتلقى هذا المسار التحديثات من خلال نظام الإضافات في Claude Code. وتُدار الملفات بدلاً من تعديلها مباشرة، ما يجعله مناسباً للفرق التي تريد تثبيتاً موحداً ومشتركاً.

تشرح وثائق إضافات Claude Code آلية اكتشاف الإضافات وتثبيتها وإدارتها.

بالنسبة إلى Codex أو Cursor أو GitHub Copilot أو Amp، أو إذا أردت تثبيتاً قابلاً للتعديل في Claude Code، فاستخدم واجهة سطر الأوامر skills.sh:

bashCopy
npx skills@latest add mattpocock/skills

اختر المهارات المطلوبة أثناء التثبيت. واحرص على تضمين setup-matt-pocock-skills، لأنها تربط مجموعة المهارات العامة بالقواعد الفعلية للمستودع.

تثبّت أداة CLI ملفات عادية يستطيع المطورون فحصها، وإدارتها ضمن الإصدارات، وتعديلها. توضح وثائق skills.sh الوكلاء المدعومين وطريقة إدارة الحزم، بينما تشرح وثائق Agent Skills في Cursor كيف يكتشف Cursor ملفات المهارات ويطبقها.

التحديثات هنا صريحة وليست تلقائية:

bashCopy
npx skills update

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

لماذا هذا مهم؟ يمنع استخدام مسار تثبيت واحد تكرار المهارات، مع الحفاظ على سياسة واضحة للتحديث والمراجعة.

إعداد المهارات في مستودع موجود

لا يحتاج المشروع الحالي إلى إعادة بناء معماريته أو قائمة مهامه أو اختباراته أو وثائقه من الصفر. يقرأ الإعداد ما هو موجود بالفعل، ثم يسجّل القرارات الخاصة بالمستودع بناءً عليه.

2. احمِ الحالة الحالية للمستودع

افحص شجرة العمل قبل أن تطلب من الوكيل تغيير تعليمات المشروع:

bashCopy
git status

إذا كانت الشجرة تحتوي على عمل مقصود، فاحفظه عبر commit أو stash:

bashCopy
git add.
git commit -m "Save work before agent skills setup"

أو:

bashCopy
git stash push -m "Before Matt Pocock skills setup"

يوفر ذلك نقطة مقارنة نظيفة. قد يقترح الإعداد تغييرات على CLAUDE.md أو AGENTS.md أو الملفات الموجودة ضمن docs/agents/، لذلك يجعل الفرق النظيف كل إضافة واضحة.

3. شغّل إعداد المستودع مرة واحدة

افتح المستودع في وكيل البرمجة الذي اخترته، ثم شغّل:

bashCopy
/setup-matt-pocock-skills

تقرأ مهارة الإعداد عنوان Git remote، وتفحص ملفات CLAUDE.md وCONTEXT.md الموجودة. بعد ذلك، تقترح تعليمات خاصة بالمستودع بدلاً من افتراض أن المشروع فارغ.

راجع كل تغيير مقترح قبل قبوله. يمكن للإعداد تسجيل القرارات ضمن docs/agents/، وإضافة قسم خاص بمهارات الوكلاء إلى CLAUDE.md أو AGENTS.md.

هنا يظهر التحكم البشري بأوضح صورة. تستطيع المهارة اكتشاف السياق واقتراح القواعد، لكن المطور هو من يحدد ما سيصبح سياسة معتمدة في المستودع.

4. اختر نموذجاً واحداً لتتبع المشكلات

في GitHub، يستخدم مسار العمل أداة gh عبر سطر الأوامر. ويستخدم GitLab أداة glab، بينما يعمل الوضع المحلي من دون مستودع بعيد. يمكن أيضاً استخدام Linear وJira وAzure DevOps وBeads وGitea وغيرها من أنظمة التتبع. لكن يجب وصف آلية العمل البرمجية لكل منها في docs/agents/issue-tracker.md، حتى يعرف الوكيل كيف ينشئ عناصر العمل ويقرأها ويربطها ويحدّثها.

يمثل GitHub Issues وملفات Markdown المحلية خيارين بديلين، وليسا طبقتين تعملان معاً. يؤدي اختيار كليهما إلى إنشاء مصدرين محتملين للحقيقة، ويجعل حالة الإنجاز غير موثوقة.

يحدد الإعداد أيضاً:

• مكان حفظ المشكلات
• تصنيفات الفرز التي يستخدمها المستودع
• مكان حفظ وثائق المجال
• واجهة سطر الأوامر التي تتحكم في نظام التتبع
• طريقة تسجيل علاقات الاعتماد بين المهام

هذا الحد الفاصل مفيد. فالمستودع يملك قواعده الهندسية، بينما توفر المهارات المثبتة إجراءات قابلة للتكرار.

لماذا هذا مهم؟ تحصل المستودعات الحالية على مسار عمل مضبوط للوكلاء من دون التخلي عن معماريتها أو نظام التسليم المستخدم فيها.

إعداد المهارات في مشروع جديد

مسار المشروع الجديد أقصر، لأن عدد القواعد الحالية التي يجب التوفيق بينها أقل. ومع ذلك، من المفيد تحديد لغة المجال وقواعد تتبع المشكلات بوضوح قبل بدء أول ميزة كبيرة.

5. ضع تعليمات المستودع مبكراً

أنشئ المستودع وأول ملف لتعليمات الوكلاء:

bashCopy
git init
touch AGENTS.md

ثبّت المهارات عبر المسار الذي اخترته، ثم شغّل:

bashCopy
/setup-matt-pocock-skills

اختر نظام تتبع المشكلات، وحدد مصطلحات المجال قبل التخطيط لميزة كبيرة. تمنح مصطلحات المجال الوكلاء أسماء ثابتة للكيانات والحدود والحالات والعمليات التجارية.

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

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

للفرق التي تتابع التغييرات الأوسع في مجال وكلاء البرمجة، يقدم مقال اتجاهات مطوري AI: الوكلاء والنماذج المحلية وسلامة الكود سياقاً مرتبطاً بالتحكم في الوكلاء وسلامة الكود.

لماذا هذا مهم؟ تقلل القرارات المبكرة بشأن المصطلحات ونظام التتبع الغموض قبل أن تبدأ جلسات متعددة للوكلاء في إنتاج الكود.

فهم المهارات الـ25 حسب وقت استخدامها

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

6. اربط كل مهارة بالمرحلة الهندسية المناسبة

عندما لا تكون نقطة البداية الصحيحة واضحة، استخدم:

bashCopy
/ask-matt

يمنعك هذا من البدء بالتنفيذ عندما تكون المشكلة الحقيقية متطلباً غير محسوم، أو بحثاً ناقصاً، أو قاعدة غير محددة في المستودع.

7. اتبع التسلسل المعتاد لتسليم العناصر

ابدأ باختبار الفكرة من خلال أسئلة منظمة:

bashCopy
/grill-with-docs

ستحصل على مجموعة موثقة من القرارات. وبعد استقرار هذه القرارات، حوّلها إلى مواصفات:

bashCopy
/to-spec

تصبح المواصفات مدخلاً لتصميم التذاكر:

bashCopy
/to-tickets

بعد ذلك، يمكن إدخال كل تذكرة معتمدة في سياق تنفيذ جديد:

bashCopy
/implement

وبعد التنفيذ، راجع النتيجة مقارنة بالمواصفات ومعايير المستودع:

bashCopy
/code-review

هذا التسلسل ليس إجراءً إلزامياً لكل تغيير. إذا كان التغيير الكامل يناسب نافذة سياق واحدة، وكانت معايير قبوله واضحة، فيمكن لـ/implement تنفيذه مباشرة من دون إنشاء تذاكر.

أما في التغييرات الكبيرة، فتحمي هذه العناصر المعلومات بين جلسات الوكلاء. يتحول النقاش إلى مواصفات، وتتحول المواصفات إلى تذاكر، ثم تتحول كل تذكرة إلى تنفيذ قابل للمراجعة.

لماذا هذا مهم؟ يمنع التسليم الصريح للعناصر اختفاء القرارات عندما يتغير سياق الوكيل.

صمّم تذاكر تستطيع الوكلاء الجديدة إنجازها

التذكرة هي وحدة عمل مستقلة تستطيع جلسة وكيل جديدة فهمها وإنجازها. يجب أن تحتوي على معايير قبول قابلة للملاحظة، وعوائق واضحة، وسلوك واحد محدود يمكن عرضه عملياً.

8. أنشئ شرائح رأسية بدلاً من طبقات تقنية

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

وثّق مؤلف المهارات حالة تضم 26 تذكرة، منظّمة في طبقات corpus وproducer وaggregator وselector. وتطلب إغلاق كل تذكرة نحو 20 جلسة وكيل، خُصص نحو ثلاثة أرباعها لإعادة العمل.

الدرس ليس أن 26 تذكرة عدد كبير بطبيعته. بل إن التقسيم المرتب من الناحية التقنية قد يخلق تكلفة تنسيق مرتفعة، إذا لم تنتج التذاكر الفردية سلوكاً مستقلاً يمكن عرضه.

بعد مراجعة أي تذكرة مقترحة، اسأل: ما الذي يمكن عرضه عند إغلاقها؟ إذا كانت الإجابة تعتمد على عدة تذاكر غير مكتملة، فمن المرجح أن التقسيم أفقي أكثر من اللازم.

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

9. راجع مخطط الاعتماديات قبل النشر

تعامل مع الاعتماد باعتباره رابط حظر موجهاً. إذا ذكرت التذكرة B أنها Blocked by A، فلا يمكن بدء B قبل إغلاق A.

تشكل التذاكر التي لا توجد أمامها عوائق مفتوحة جبهة العمل الحالية. ويمكن لجلسات الوكلاء المستقلة بدء هذه التذاكر بأمان.

تنشر /to-tickets التذاكر التي تحظر غيرها أولاً. وقبل النشر، تعرض تقسيماً مرقماً وتطلب من المستخدم دمج التذاكر أو تقسيمها أو تصحيحها.

الإنسان هو من يعتمد هذا المخطط. تقترح المهارة ترتيب التنفيذ، لكنها لا تملك صلاحية تحديد النطاق أو المعمارية.

10. خزّن التذاكر في GitHub أو في ملفات محلية

في GitHub، أنشئ مشكلة مع عوائق أصلية:

bashCopy
gh issue create --blocked-by 12,15

أنشئ مشكلة فرعية ضمن مشكلة رئيسية:

bashCopy
gh issue create --parent <number>

أو أرفق مشكلة موجودة كمشكلة فرعية:

bashCopy
gh issue edit <parent> --add-sub-issue <number>

تُفضل العلاقات الأصلية على النص العادي في الوصف، لأن GitHub يستطيع إظهار العوائق والمشكلات الفرعية في صورة بيانات منظمة. تشرح وثائق اعتماديات المشكلات في GitHub العلاقات المدعومة.

قد تستمر المهارة في كتابة Blocked by داخل وصف المشكلة، أو قد تتجاهل رابط المشكلة الفرعية بالمشكلة الرئيسية. افحص المشكلات المنشورة وأصلح العلاقات الأصلية عند الحاجة.

في الوضع المحلي، تُحفظ كل تذكرة في ملف منفصل:

.scratch/<feature-slug>/issues/<NN>-<slug>.md

نفّذ تذكرة محلية مرقمة باستخدام:

bashCopy
/implement 03

تلغي الملفات المحلية الحاجة إلى إعداد نظام تتبع، وتناسب الأعمال المنفصلة داخل المستودع. أما GitHub وLinear فهما أنسب لعرض جبهة الاعتماديات عبر عدة جلسات جديدة للوكلاء.

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

لماذا هذا مهم؟ تتيح جبهة الاعتماديات الواضحة العمل بالتوازي، من دون افتراض أن إنشاء التذاكر يعني أيضاً إدارة تنفيذها.

الاختبار وحل المشكلات والتشغيل الآمن

غالباً ما تفشل مسارات عمل الوكلاء عند الحدود الفاصلة بين العناصر. لذلك يجب أن يتحقق الاختبار من معايير القبول والتنفيذ وحالة نظام التتبع.

اختبار تنفيذك

قبل التنفيذ، تأكد من أن معايير القبول تفشل. إذا نجح الاختبار في هذه المرحلة، فقد لا يكون في الواقع يختبر السلوك المطلوب.

شغّل أمر الاختبار الحالي في المستودع بدلاً من ابتكار مسار اختبار جديد. ثم استخدم:

bashCopy
/implement <ticket-number>

بعد التنفيذ، تحقق من أربعة أمور:

1. نجاح معايير القبول الجديدة.
2. استمرار نجاح الاختبارات الحالية.
3. إمكانية عرض السلوك المطلوب عملياً.
4. تطابق حالة نظام التتبع مع حالة الإنجاز الفعلية.

اختم باستخدام:

bashCopy
/code-review

يجب أن تقارن المراجعة الكود بالمواصفات، لا أن تكتفي بفحص التنسيق والأسلوب. يساعد ذلك على اكتشاف عمليات تنفيذ صحيحة تقنياً، لكنها تحل مشكلة مختلفة.

مشكلات الإعداد ومسار العمل الشائعة

استخدم سياقاً جديداً لكل تذكرة. يختبر ذلك ما إذا كانت التذكرة مستقلة فعلاً، ويمنع المعرفة المخفية في المحادثات السابقة من التأثير في التنفيذ.

للمزيد حول مخاطر موثوقية الوكلاء، راجع أخبار AI الأسبوعية: النماذج الغامضة ومراقبة الشاشة.

لماذا هذا مهم؟ تثبت الاختبارات صحة السلوك، بينما تحافظ مراجعة نظام التتبع على دقة الحالة التشغيلية بين الجلسات.

خطوات عملية

ابدأ من هنا (خطوتك الأولى)

شغّل git status، ثم احفظ العمل الحالي عبر commit أو stash، وبعدها ثبّت المهارات عبر مسار واحد فقط من المسارات المدعومة.

نتائج سريعة (تأثير فوري)

• شغّل /setup-matt-pocock-skills مرة واحدة، وراجع كل تغيير مقترح على المستودع قبل قبوله.
• شغّل /ask-matt على إحدى المهام الهندسية الحالية، وسجّل نقطة البداية التي يختارها لمسار العمل.

تعمّق أكثر (لمن يريد المزيد)

• مرّر مواصفات مستقرة عبر /to-tickets، ثم تأكد من أن كل تذكرة تحتوي على معايير قبول قابلة للملاحظة وعوائق واضحة.
• نفّذ إحدى تذاكر جبهة العمل في سياق جديد، وشغّل اختبارات المستودع، ثم حدّث نظام التتبع يدوياً بعد الإنجاز.

موارد مفيدة

• وثائق skills.sh - التثبيت والوكلاء المدعومون واكتشاف المهارات وآلية التحديث.
• وثائق إضافات Claude Code - الإرشادات الرسمية لاكتشاف إضافات Claude Code وإدارتها.
• وثائق Agent Skills في Cursor - طريقة تحميل Cursor لمهارات الوكلاء وتطبيقها.
• وثائق اعتماديات المشكلات في GitHub - علاقات الحظر والحظر العكسي والمشكلات الفرعية الأصلية.

أهم الخلاصات

مهارات Matt Pocock الهندسية هي تعليمات للعملية، وليست نظاماً مستقلاً لإدارة الهندسة. فهي تحوّل الأفكار غير الواضحة إلى مواصفات، والمواصفات إلى تذاكر تراعي الاعتماديات، والتذاكر إلى عمليات تنفيذ خضعت للاختبار.

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

يجب أن يبقى البشر مسؤولين عن النطاق، وتقسيم التذاكر، والمعمارية، والعروض العملية، وحالة نظام التتبع.

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