ما هو Ponytail؟ مهارة تجعل وكيل البرمجة يكتب كودًا أقل

ما هو Ponytail

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

المستودع هو DietrichGebert/ponytail. أُنشئ في 12 يونيو 2026 وتجاوز 90,000 نجمة بحلول 1 أغسطس 2026. أحدث إصدار موسوم حتى تاريخ 1 أغسطس 2026 هو v4.8.4، الذي نُشر في 29 يونيو 2026، وتُدرِج صفحة الإصدارات عشرة وسوم بين 14 و29 يونيو وحدها. مشروع يتحرك بهذه الوتيرة سيكون قد تغيّر بحلول وقت قراءتك لهذا النص، لذا ثبّت وسمًا محددًا قبل أن تبني أي شيء فوقه.

الفكرة قبل الأداة: التوقف عند أول درجة تصمد

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

1. هل يحتاج هذا الشيء إلى الوجود من الأساس؟ هذا هو مبدأ YAGNI (لن تحتاج إليه). إذا كانت الإجابة بالنفي، تجاهله.
2. هل هو موجود بالفعل في قاعدة الكود هذه؟ أعد استخدام الدالة المساعدة أو النمط الموجود مسبقًا.
3. هل تقوم المكتبة القياسية بهذه المهمة؟ استخدمها.
4. هل تغطيها ميزة أصلية في المنصة؟ استخدمها.
5. هل تحلّها تبعية مثبَّتة بالفعل؟ استخدمها.
6. هل يمكن أن تكون سطرًا واحدًا؟ اجعلها سطرًا واحدًا.
7. فقط بعد ذلك، اكتب الحد الأدنى من الكود الذي يعمل.

الترتيب هو ما يقوم بالعمل، لا درجة واحدة بمفردها. الوكيل المطلوب منه أداة اختيار تاريخ سيكتب أداة اختيار تاريخ، لأن كتابتها هي ما طُلب منه فعله. السلّم يجعله يتحقق من الدرجة 4 أولًا، وتقول الدرجة 4 إن المتصفح يملك بالفعل <input type="date">. يسجّل معيار الأداء الخاص بالمشروع هذه الحالة بالضبط: أداة اختيار تاريخ خرجت في 404 سطر بدون هذه القاعدة، وخرجت في 23 سطرًا معها، لأن الوكيل استخدم حقل الإدخال الأصلي عوضًا عن بناء مكوّن. وانتقلت أداة اختيار الألوان من 287 سطرًا إلى 23 سطرًا للسبب نفسه.

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

ما يقدّمه المستودع فعليًا

• AGENTS.md، مجموعة القواعد الدائمة التفعيل، وهي الفكرة كاملة في ملف واحد يمكنك قراءته خلال خمس دقائق.
• skills/ponytail/SKILL.md، تعريف المهارة (skill)، مع تلميح للوسيطة يكون lite أو full أو ultra.
• ملفات قواعد ضمن أدلة خاصة بكل محرر مثل .cursor/rules/ و.windsurf/rules/، مخصّصة للمضيفات (hosts) التي تقرأ القواعد لكنها لا تحمّل المهارات.
• hooks/، وbenchmarks/، وexamples/، وscripts/.

تُغيّر وسيطة الشدة مدى صرامة القاعدة في الدفع نحو الالتزام. lite يبني ما طلبته ويذكر خيارًا أكسل في سطر واحد. full هو الإعداد الافتراضي، وهو الذي يفرض السلّم. ultra هو إعداد المتطرفين في مبدأ YAGNI: فهو يفضّل الحذف على الإضافة، بل قد يجادل في المتطلب نفسه.

تحصل المضيفات القادرة على تشغيل المهارات أيضًا على أوامر الشرطة المائلة. /ponytail يضبط المستوى، و/ponytail-review يفحص الفرق (diff) بحثًا عن الإفراط في الهندسة، و/ponytail-audit يفحص مستودعًا كاملًا، و/ponytail-debt يجمع الاختصارات التي أجّلتها، و/ponytail-gain يطبع بطاقة نتائج القياس المرجعي. أما المضيفات التي تقرأ ملفات القواعد فقط فتحصل على مجموعة القواعد دون أي أوامر.

لقراءة المصدر قبل أن تثق به، استنسخ الوسم (tag) بدلًا من الفرع (branch):

git clone --depth 1 --branch v4.8.4 https://github.com/DietrichGebert/ponytail.git

في Claude Code، يوثّق المشروع بدلًا من ذلك تثبيت إضافة (plugin)، وهذان السطران كما وردا في التوثيق بتاريخ 1 أغسطس 2026:

/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail

يتبع مسار الإضافة الفرع الافتراضي بدلًا من وسم، لذا يمكن أن تتغيّر التعليمات التي توجّه وكيلك (agent) من تحتك بين الجلسات. هذه هي المقايضة التي تقبلها مقابل راحة وجود أمر تحديث.

لماذا يكون الوكيل الكسول أرخص على VPS

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

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

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

على الخادم تتغير المخاطر، لأن الوكيل غالبًا ما يعمل دون أن يراقبه أحد. الوكيل الذي يعمل في جلسة tmux أو وفق مؤقت تكون أمامه ساعات ليبني على قرار خاطئ قبل أن تراه. هذه هي المخاطرة العملية في تشغيل وكيل برمجة على VPS، ولهذا يولي من يمارسون هندسة الحلقات عناية كبيرة بالتعليمات الدائمة بدل الاهتمام بالمطالبات الفردية. القاعدة الموجودة في الملف الدائم التفعيل تنطبق على الجولة 200. أما القاعدة التي تكتبها في المحادثة فتنطبق على الجولة 3.

التبعيات الجديدة هي التكلفة الخفية الأخرى. تقول الدرجة 5 استخدم ما هو مثبَّت بالفعل. كل حزمة يضيفها الوكيل من تلقاء نفسه هي شيء ستُصلحه لاحقًا وشيء سينتهي به المطاف في كل صورة حاوية (container image) تبنيها من ذلك المستودع.

ما تقوله أرقام قياس الأداء الخاصة بـ Ponytail

ينشر المشروع مجموعتين من النتائج، وهما تختلفان عن بعضهما بفارق كبير. وكلتا المجموعتين من الأرقام المنشورة من قبل المشروع نفسه. وليست أي منهما اختباراً مستقلاً.

[
  {
    "label": "Lines of code",
    "single_shot_pct": 93,
    "agentic_pct": 54
  },
  {
    "label": "Cost per run",
    "single_shot_pct": 63,
    "agentic_pct": 20
  },
  {
    "label": "Wall clock time",
    "single_shot_pct": 74,
    "agentic_pct": 27
  }
]

يأتي عمود الطلقة الواحدة من نموذج مجرد يُجيب عن مجموعة صغيرة من الطلبات، بوجود القاعدة وبدونها، وتُؤخذ القيم كوسيط إحصائي لعدة عمليات تشغيل متكررة، بتاريخ 13 و17 يونيو 2026. أما عمود العمل الوكيلي فيأتي من جلسة Claude Code تعمل من دون واجهة رسومية، تُحرِّر full-stack-fastapi-template الخاص بـ tiangolo، وهو مستودع حقيقي قائم على FastAPI و React. شملت الاختبارات اثنتي عشرة تذكرة ميزة، بأربع عمليات تشغيل لكل تذكرة على Haiku 4.5، وقُيِّم الأداء استناداً إلى الفرق الناتج في git diff.

انظر إلى العمود الثاني. نتيجة العمل الوكيلي هي أسطر كود أقل بنسبة 54 في المئة، وتكلفة أقل بنسبة 20 في المئة، ووقت تنفيذ فعلي أقل بنسبة 27 في المئة، مقابل 93 في المئة و74 في المئة لنفس المقاييس في إعداد الطلقة الواحدة. وملف README صريح بشأن السبب: خط الأساس في إعداد الطلقة الواحدة هو نموذج مجرد "يجيب بعدة خيارات مع تعليق"، وهذا أمر يسهل التفوق عليه. أما عند القياس مقابل وكيل حقيقي يقوم بعمل حقيقي، فإن هذا الفارق يتقلص. لكنه يبقى فارقاً حقيقياً، وهذه هي الحقيقة الأكثر فائدة.

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

النمط الذي يمكنك نسخه اليوم دون تثبيت أي شيء

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

## Before you write code

Climb this list in order. Stop at the first line that applies.

1. Does this need to exist? If not, say so and stop.
2. Does this repo already have it? Reuse the helper.
3. Does the standard library do it? Use it.
4. Does the platform do it natively? Use it.
5. Does an installed dependency do it? Use it.
6. Can it be one line? Write one line.
7. Otherwise write the minimum that works.

Never take the shortcut on: reading the code before changing it, validating
input that crosses a trust boundary, error handling that would otherwise lose
data, security, accessibility, or anything I asked for by name.

Do not add an abstraction I did not ask for. Do not add a dependency without
saying why in one line. Prefer deleting code to adding it.

Mark a deliberate simplification with a comment naming its ceiling and the
upgrade path.

تلك القاعدة الأخيرة تستحق تناولها بمفردها. تقضي اتفاقية Ponytail بأن يكون التعليق معلَّمًا باسم الأداة:

# ponytail: global lock, per-account locks if throughput matters

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

مكان وضع هذه الكتلة لا يقل أهمية عن مضمونها. الملف الذي يحمّله الوكيل في كل تشغيل يوجّه كل تشغيل، بما في ذلك التشغيلات التي لا تراقبها. هذا الفرق هو موضوع كتابة ملف AGENTS.md يتّبعه وكيلك فعليًا، وهو السبب في أن هذا النمط ينتمي إلى ملف مُودَع في نظام التحكم بالإصدار لا إلى سجل أوامر الـ shell لديك.

أين تتوقف القاعدة عن الصواب

هذا السلّم مُعايَر لعمل الميزات في قاعدة شيفرة موجودة بالفعل، حيث يكون إعادة الاستخدام متاحًا عادةً وصحيحًا عادةً. وهو لا يناسب مشروعًا يُبنى من الصفر، لأن الدرجة 2 لا تجد فيها شيئًا يُعاد استخدامه، والدرجة 5 لا تجد فيها شيئًا مُثبَّتًا، فينزلق الوكيل إلى الدرجة 7 في كل مرة. كما أنه لا يناسب اللحظة التي تريد فيها التجريد فعلًا. فإذا كنت على وشك إضافة المستدعي الرابع لنفس الكتلة المنسوخة، فإن «أقصر diff» يمنحك نسخة خامسة.

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

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

الخلاصة الصادقة هي أن Ponytail هو موجّه (prompt) مكتوب بعناية، مُوزَّع بشكل جيد، ومصحوب بأرقام. لا شيء فيه يستلزم الإضافة (plugin). ما يقدمه المشروع هو أن شخصًا ما كتب القائمة بالشكل الصحيح، واختبرها على مستودع حقيقي، ونشر الطريقة إلى جانب النتيجة.

FAQ

هل يعمل Ponytail مع وكلاء غير Claude Code؟

نعم. يصدر Ponytail كمهارة (skill) للمضيفات التي تحمّل المهارات، وهي قائمة تضم Claude Code وCodex وOpenCode وGemini وعدة أدوات أخرى مذكورة في README. أما المحررات التي تقرأ ملفات القواعد لكنها لا تحمّل المهارات، مثل Cursor وWindsurf وCline وCopilot، فتأخذ مجموعة القواعد الدائمة التفعيل من دليل القواعد المطابق ولا تحصل على أوامر الشرطة المائلة. النص نفسه في الحالتين، لذا يكمن الفرق الحقيقي في ما إذا كان المضيف يبقي هذا النص ضمن السياق في كل دورة (turn) أو فقط عند تفعيل مهارة.

هل يتخطى الوكيل الكسول الاختبارات أو التحقق من الصحة أو الأمان؟

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

هل أرقام السرعة والتكلفة المنشورة موثوقة؟

هذه قياسات المشروع نفسه، نُشرت مع منهجيتها، وينبغي قراءتها على هذا الأساس. أرقام "اللقطة الواحدة" (single shot) تقارن بنموذج مجرّد يجيب بخيارات وتعليقات، وهو ما يصفه README نفسه بأنه خط أساس ضعيف. أما أرقام الوضع الوكيلي فتأتي من جلسة Claude Code بلا واجهة (headless) على مستودع واحد يجمع FastAPI وReact، شملت 12 تذكرة (ticket)، بواقع 4 عمليات تشغيل لكل تذكرة، باستخدام Haiku 4.5. هذه أرقام صادقة لذلك الإعداد. لكنها ليست تنبؤًا لقاعدة الشيفرة (codebase) الخاصة بك، لأن المشروع يذكر أيضًا أن نسبة التوفير تقترب من الصفر في الشيفرة التي كانت أصلاً عند حدها الأدنى.

هل أحتاج إلى تثبيت أي شيء للحصول على الفائدة؟

لا. السلّم (ladder) نص فقط، ولصق كتلة مكافئة في ملف التعليمات الذي يقرؤه وكيلك بالفعل يمنحك معظم الأثر. أما الإضافة (plugin) فتمنحك الصياغة المُحدَّثة، ومستويات الشدة، وأوامر المراجعة، ومسار تحديث. تجربة الكتلة المنسوخة أولًا هي إجابة الدرجة 1 عن سؤال ما إذا كان التثبيت ضروريًا أصلًا.

كيف أمنع وكيلاً غير مراقَب من الإفراط في البناء طوال الليل؟

ضع القاعدة في ملف التعليمات الدائم التفعيل بدلًا من رسالة محادثة، بحيث تُطبَّق في الدورة رقم 200 من تشغيل طويل، لا في الدورة 3 فقط. بعد ذلك، احصر الضرر بشكل منفصل: امنح الوكيل نسخة عمل يُسمح له بإفسادها بدلًا من نسختك الوحيدة، واشترط مراجعة بشرية للفروقات (diff) قبل أي دمج (merge). قاعدة الحد الأدنى من التغييرات (minimal diff) تقلل كمية ما يجب أن تقرأه. لكنها لا تقرر ما يُدمَج، ولا ينبغي لها ذلك.