سبعة وكلاء ذكاء اصطناعي يديرون ليالينا: وكلاء مجدولون أبعد من البرمجة، مع البرومبتات

في 23 سبتمبر، كتب مستخدم اسمه Rob على قائمة المهام العامة لدينا: "would love to get examples of how you guys are doing stuff beyond coding". سؤال في محلّه. كل ما في هذا الموقع يتحدث عن وكلاء البرمجة، وما نشغّله فعلًا كل مساء ليس برمجة في معظمه.

منذ 28 أغسطس، ينطلق سبعة وكلاء على Mac mini في الساعة 20:00. يقرؤون commits اليوم، و Search Console، ولوحات الإدارة، وقائمة المهام، والملاحظات التي أرسلها الناس، وتقارير الليلة الماضية. يصلحون أخطاء، ويصحّحون الموقع، ويكتبون مقالة مدونة ويترجمونها كل ثلاثة أيام، وينشرون على ثلاث شبكات اجتماعية، ويحدّثون قاعدة معرفة للمنتج، وفي الساعة 22:00 يقرأ السابع ما تركه الستة الآخرون ويرسل بريدًا إلكترونيًا من 25 سطرًا. لا أحد يراقب. يقرأ المؤسس البريد على هاتفه صباح اليوم التالي.

هذه المقالة هي الجواب لـ Rob. ما الذي يعمل، وكيف رُبط، وكيف يتبادل الوكلاء العمل دون أن يتحدثوا أبدًا، وأي نموذج يؤدي أي مهنة ولماذا، والقواعد الأربع التي اضطرت البرومبتات إلى تعلّمها بالطريقة الصعبة، والبرومبتات نفسها، مختصرة في كتل يمكنك نسخها. كل رقم أدناه يأتي من المستودع: التقارير محفوظة فيه بـ commit، ليلة بعد ليلة.

ما أنتجته 33 ليلة

يضم مجلد التقارير في المستودع 33 مجلدًا مؤرَّخًا، من 28 أغسطس إلى 30 سبتمبر. قراءتها تعطي ما يلي:

• 31 بريدًا صباحيًا أرسلها مُعِدّ التقرير.
• 51 خطأ أصلحها مُصلِح الأخطاء، كل منها مع رابط الـ commit في سطره من التقرير. عدد منها أبلغ عنه مستخدمون على قائمة المهام العامة وتلقّوا ردًا مع الإصدار التالي.
• 7 مقالات مدونة كتبها فريق SEO منذ 10 سبتمبر، مقالة كل ثلاثة أيام، كل منها بالإنجليزية والفرنسية أولًا، ثم بـ 18 لغة أخرى في الليلة نفسها.
• 29 يومًا من سجلّ الشبكات الاجتماعية: ثلاث شبكات وخمس مجموعات Facebook كل مساء، إضافة إلى تعليق شكر تحت كل منشور شارك فيه مستخدم AgentsRoom.
• قاعدة معرفة للمنتج من نحو مئة بطاقة، تُحدَّث وفق commits اليوم، يقرؤها المساعد المدمج في التطبيق ويقدّمها الموقع بصيغة llms-full.txt.

لم يتطلب أي من ذلك إنسانًا بعد الساعة 20:00. بعضه تطلّب إنسانًا في الساعة 08:00، وهذا هو الغرض من الوكيل الأخير.

التشكيلة: من يعمل في الساعة 20:00

كل وكيل هو مهمة مجدولة في AgentsRoom: برومبت، ووكيل (دور، CLI، نموذج)، وجهاز، ووقت. السبعة كلهم يعملون على Claude Code. اثنان منهم ليسا وكيلين منفردين بل فريقان من خطوتين، وسنعود إلى السبب.

ملفات .md في العمود الأخير كلها تعيش في reports/night/<date>/، محفوظة بـ commit ومدفوعة بـ push. هذا المجلد هو نظام التنسيق كله، والقسم التالي يشرح السبب.

كيف رُبطوا

كل واحد من السبعة مهمة مجدولة بالشكل نفسه:

• تنطلق يوميًا في الساعة 20:00 (22:00 لمُعِدّ التقرير). لا تعبير cron؛ يُختار التكرار في المحرر.
• مثبّتة على جهاز واحد. المشروع مفتوح على عدة حواسيب، والمُشغِّل ينطلق على كل جهاز يملكه ما لم تقيّده. مُشغِّلاتنا مقيّدة بالـ Mac mini، فلا يبدأ حاسوب محمول فُتح في 20:05 CEO ثانيًا.
• توقظ الجهاز. الـ Mac mini ينام. للمهمة خيار «إيقاظ الجهاز»، يبرمج إيقاظًا بأداة نظام التشغيل نفسه (pmset على macOS، و Task Scheduler مع الإيقاظ للتشغيل على Windows، و rtcwake على Linux) قبل التشغيل ببضع ثوانٍ. من دونه، يفوّت الجهاز النائم التشغيل ببساطة.
• التعويض مفعّل أو معطّل، لكل مهمة. إذا كان الجهاز مطفأً في الساعة 20:00، تنطلق المهمة التي فُعّل فيها التعويض عند الإقلاع التالي. الـ CEO ومدير المنتج ومُعِدّ التقرير فعّلوه. مهام SEO ومُصلِح الأخطاء والشبكات الاجتماعية والتوثيق عطّلته: تشغيل يبدأ في الساعة 11:00 صباح اليوم التالي سيصطدم بعمل النهار في نسخة العمل نفسها.
• وضع الأذونات مضبوط على المهمة، لا على المزوّد. تشغيل بلا إشراف لا يمكنه أن يتوقف عند طلب موافقة في الثالثة فجرًا، لذلك تعمل المهمة من دونها، بينما الوكلاء الذين يقودهم المؤسس يدويًا على الـ CLI نفسه ما زالوا يسألون أولًا.
• تُغلق الطرفية بعد 60 دقيقة من الخمول. الوكيل الذي أنهى عمله لا يبقى في الشريط الجانبي حتى يغلقه أحد.
• البرومبت هو الرسالة الأولى. نص كل برومبت محفوظ في مكتبة البرومبتات وهو النص نفسه الموجود في حقل البرومبت الخاص بالمُشغِّل، فتعديل أحدهما يعني تعديل الاثنين. البرومبتات مكتوبة بالفرنسية، لأن المؤسس يقرأ التقارير بالفرنسية. كل ما عدا ذلك، من رسائل الـ commit إلى قاعدة المعرفة، بالإنجليزية.

قطعة أخرى يتشاركها السبعة: مهارة اسمها «وكلاء الليل، قواعد مشتركة». يبدأ كل برومبت بعبارة «حمّل هذه المهارة وطبّقها»، والمهارة تحوي كل ما يصحّ عليهم جميعًا: من يتولّى ماذا، وحارس «ليلة واحدة، تشغيل واحد»، وصلاحيات git، وصيغة التقرير، وقواعد قائمة المهام، وصيغة البريد لمُعِدّ التقرير. حين تتغير قاعدة، تتغير في مكان واحد.

كيف يتبادلون العمل دون أن يتحدثوا

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

المستودع. يكتب كل وكيل reports/night/<date>/<agent>.md، ويفتحه في الدقيقة الأولى من تشغيله، ويعيد كتابته بعد كل عمل منتهٍ، ويحفظه بـ commit ويدفعه بـ push. للتقرير أربعة أقسام ثابتة: «في كلمتين» (قائمة نقطية، نقطة لكل شيء أُنجز)، و«للقرار» (فقط ما يخصّصه البرومبت للإنسان)، و«للتحقق» (رابط محلي أو شاشة تُفتح)، و«التفاصيل» (بالطول اللازم). وينتهي بعلامة تشغيل: آخر commit رآه الوكيل.

قائمة المهام. الوكيل الذي يجد عملًا لوكيل آخر لا يؤدي ذلك العمل. يفتح تذكرة بوسم: ceo-fix لخطأ صغير تم التحقق منه سيتولاه مُصلِح الأخطاء؛ و ceo-seo لعمل محتوى مع استعلامه المستهدف؛ و ceo-decision لكل ما يحتاج إلى الإنسان (قاعدة البيانات، والفوترة، والمصادقة، والتشفير، والأسعار، ورابط مفهرس، وسلوك افتراضي). أمين التوثيق، وهو يقرأ الـ commits، يجد ميزة بلا صفحة على الموقع: فيفتح تذكرة ceo-seo، ويتولاها SEO في الليلة التالية. الـ CEO، وهو يقرأ سجلات الأخطاء، يجد خطأ وسببه في الكود: ceo-fix، ويتولاه مُصلِح الأخطاء في الليلة التالية.

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

تُغلق الحلقة عند الإنسان. ينتهي بريد مُعِدّ التقرير بسطر واحد: للرد على مدير المنتج، أضف قسم «## القرارات» في نهاية rapport.md (P1 موافق / P2 لا: السبب / P3 لاحقًا)، ثم commit، ثم push. يقرأ مدير المنتج النسخة المدفوعة في المساء التالي وينفّذ ما وُوفق عليه: ينشئ التذكرة، ويدمج المكرّرات، ويركن الباقي مع السبب. القرار الذي لا يلقى ردًا ثلاث ليالٍ هو قرار في حد ذاته: يخرج الاقتراح من البريد ويبقى تذكرة.

أي نموذج يؤدي أي مهنة، ولماذا

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

Fable حيث تكون المهنة حُكمًا. يقرر الـ CEO ما إذا كان التقييم السلبي على أحد المراجع خطأً حقيقيًا أم تفضيلًا. يقرر مُصلِح الأخطاء ما إذا كان بلاغ الخطأ خطأً فعلًا أم إعدادًا خاصًا بجهاز واحد، ثم يجد السبب في الكود. تقرر الخطوة 1 من SEO أي جملة في الموقع أصبحت خاطئة مع commit اليوم، وأي مقالة تُكتب، وأي صفحة تُترك وشأنها. تختار الخطوة 1 من الشبكات الاجتماعية موضوع المساء وتكتب لجمهور يكتشف النص المولَّد في ثلاثة أسطر. هذه البرومبتات طويلة (برومبت SEO نحو 4,000 كلمة) ومليئة بقواعد «أنت تقرر، لا تسأل» مع قوائم قصيرة من الاستثناءات. هناك يستحق أقوى نموذج تكلفته.

Opus بسياق 1M حيث تكون المهنة حجمًا. ترجمة مقالة إلى 18 لغة بوكلاء فرعيين، ثلاث لغات لكل منهم، ثم مراجعة الدمج مقابل المرجع الفرنسي، هي قراءة وكتابة، وبكثرة، مع القواعد نفسها مطبّقة 18 مرة. يقرأ أمين التوثيق يومًا من الفروقات مقابل مئة بطاقة. يقرأ مدير المنتج ملفًا مُصدَّرًا حجمه 8 ميغابايت من محادثات المغادرة. يقرأ مُعِدّ التقرير خمسة تقارير وينسخ، ولا يفكّر. هناك، السياق الكبير والتكلفة الأقل لكل توكن أهم من الحُكم.

اثنان من السبعة إذن فرق وكلاء من خطوتين، كل خطوة وكيل بنموذجه الخاص. الخطوة 1 على Fable تنتهي بكتابة قسم «التسليم» في التقرير المشترك: القائمة الدقيقة للملفات والمفاتيح التي على المترجم تسليمها، أو المنشورات الدقيقة التي على الناشر نشرها. الخطوة 2 على Opus تقرأ ذلك القسم ولا تفعل إلا ما يسرده. مخطط الفريق خطي، دورة واحدة، ويحتفظ التقرير بسطر «تشغيل جارٍ» حتى تحذفه الخطوة 2. من الخارج، في الساعة 22:00، التقرير الذي ما زال موسومًا «جارٍ» يعني إما تشغيلًا مقطوعًا وإما فريقًا بين خطوتيه، ومُعِدّ التقرير يقول أيهما.

القواعد الأربع التي اضطرت البرومبتات إلى تعلّمها

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

1. علامة تشغيل، تُقرأ من تقرير الأمس. كانت النسخة الأولى من وكيل SEO تقرأ «commits آخر 24 ساعة». مشكلتان: تشغيل في 20:00 وتشغيل في 20:10 في اليوم التالي لا يريان الـ 24 ساعة نفسها، والليلة التي لم يعمل فيها الوكيل هي يوم من الـ commits لا ينظر إليه أحد. الآن ينتهي كل تقرير بـ آخر commit تمت رؤيته: <sha>، ويبدأ التشغيل التالي من ذلك الـ commit، أيًّا كان ما تقوله الساعة. لا علامة (ليلة أولى، تقرير مفقود): يومان إلى الوراء، والتقرير يذكر ذلك.

2. السجلّ موجود على القرص، فابحث فيه بـ grep قبل رفع أي شيء. الشكوى التي تكررت أكثر من غيرها في الأسبوعين الأولين: «قلت لي هذا من قبل، أصلحته أمس». الحل قاعدة فيها أمر: قبل الإشارة إلى موضوع أو فتح عمل، grep -ril "<الموضوع>" reports/night/ و git log --since="30 days ago" -- <الملف>. وجود تطابق يعني قراءة ذلك التقرير أولًا. ثلاث حالات، وثلاث فقط، تسمح بالعودة إلى موضوع عولج: الإصلاح لم ينجح وقد تحققت منه للتو؛ الإصلاح جزئي وأنت تسمّي ما تبقّى؛ الموضوع تغيّرت طبيعته. وجاءت معها نتيجتان. ليلة واحدة، تشغيل واحد: إذا كان تقرير الليلة موجودًا، ويحتوي «في كلمتين» ولم يعد يقول «تشغيل جارٍ»، يتوقف الوكيل. والاقتراح الذي لا يلقى ردًا ثلاث ليالٍ يخرج من التقرير؛ وتبقى التذكرة.

3. يُفتح التقرير قبل أن يبدأ العمل. كان التشغيل الذي يُقطع في 21:30 لا يترك شيئًا. الآن، أول ما يفعله الوكيل بعد تحميل المهارة هو mkdir -p reports/night/$(date +%F) وكتابة هيكل التقرير بعناوين أقسامه الأربعة وسطر تشغيل جارٍ، بدأ في 20:01. يعيد كتابة الملف كاملًا بعد كل عمل منتهٍ. التشغيل المقطوع يترك تقريرًا جزئيًا يستطيع مُعِدّ التقرير نسخه، وهذا أفضل بكثير من وكيل «لم يعمل».

4. commit أولًا بأول، لا في النهاية أبدًا. ما قيس في 9 سبتمبر: أُوقف وكيلان في الدقيقة نفسها. الذي كان ينفّذ commit بعد كل عمل لم يخسر شيئًا. الآخر ترك 45 ملفًا معدّلًا، غير مدفوعة ولا يمكن نسبتها، التقطها المؤسس يدويًا صباح اليوم التالي، ولم يكن تقريره موجودًا. منذ ذلك الحين القاعدة هي commit واحد لكل عمل منتهٍ، والملفات مسمّاة واحدًا واحدًا، و commit أخير للتقرير، و push واحد على الأقل أثناء التشغيل. والـ commit أيضًا أثر مؤرَّخ، وهو ما تبحث فيه القاعدة 2 بـ grep.

قاعدة خامسة لا تتعلق بالذاكرة بل بالجرأة، وهي التي غيّرت الإنتاج أكثر من غيرها. يقول برومبت SEO: «لست مدقّقًا يرفع ملاحظات: في الليل، الموقع لك. التشغيل الذي ينتهي بست أفكار تنتظر الموافقة تشغيل فاشل.» ثم يسرد الحالات الست، وست فقط، التي يجب فيها على الوكيل أن يسأل بدل أن يتصرف: حذف رابط أو تغيير اسمه، وتغيير عنوان صفحة تحتل ترتيبًا في البحث، ونص قانوني، وسعر أو حصة، وادعاء يخص الخصوصية أو التشفير، وتغيير يمسّ أكثر من خمس صفحات. كل ما عدا ذلك يفعله، ويحذف المؤسس ما لا يعجبه صباح اليوم التالي. لمُصلِح الأخطاء القاعدة نفسها بثلاث حالات. قبل هذه القاعدة، كانت التقارير قوائم اقتراحات. بعدها، صارت قوائم commits.

البرومبتات

الأصول مكتوبة بالفرنسية وطويلة. ما يلي هو الجزء القابل للنقل، مع حذف المسارات والأسماء الخاصة بمشروعنا. ثلاث كتل: القواعد المشتركة التي يحمّلها كل وكيل، ومُعِدّ التقرير، والقسمان «أنت تقرر، لا تسأل».

الكتلة 1: القواعد المشتركة (يحمّلها السبعة كمهارة)

# وكلاء الليل: قواعد مشتركة
تتقدّم على البرومبت الخاص بك إذا تعارض الاثنان.

## ليلة واحدة، تشغيل واحد
DAY=$(date +%F); F=reports/night/$DAY/<اسمك>.md
إذا كان F موجودًا، ويحتوي «في كلمتين» ولم يعد يحتوي «تشغيل جارٍ»:
توقّف. لا تكتب شيئًا، لا ترسل شيئًا، واختم برسالة من سطر واحد.
إذا كان لا يزال يقول «تشغيل جارٍ»: فهو تشغيلك أنت، قُطع قبل دقائق.
استأنف من حيث توقّف، ولا تبدأ من الصفر.

## ما يحق لك فعله
- Git: add <ملفات مسمّاة>، commit، push لعملك أنت، أولًا بأول.
  أبدًا: add -A، commit -a، push --force، stash، reset، checkout، clean، فرع جديد.
- البناء: typecheck، lint، سكربتات الفحص، بناء محلي للتحقق.
  أبدًا: أي سكربت ينشر أو يُصدر.
- قائمة المهام: إنشاء تذكرة، الإضافة إلى تذكرة، إغلاق تذكرة أصلحتها.
  أبدًا: الرد على مستخدم (فهذا يرسل بريدًا)، حذف تذكرة، الكتابة فوق وصف.
- لا رقم مختلَقًا أبدًا. المصدر غير متاح: قل ذلك وامضِ.
- قبل أي كتابة في git: git status --short. شجرة العمل مشتركة مع وكلاء آخرين.

## اللحاق بالمستجدات، ومعرفة ما أُنجز مسبقًا
git fetch && git status -sb
متأخر ونظيف: git pull --ff-only. متأخر وفيه تعديلات: لا تنفّذ pull، وقل ذلك في رأس تقريرك.
علامة تشغيلك: السطر «آخر commit تمت رؤيته: <sha>» في نهاية تقرير الأمس.
لا علامة: --since="2 days ago"، وقل ذلك.
ثلاث قراءات إلزامية قبل أي تحليل:
1. git log --no-merges --format='%h %s' <sha>..HEAD و git diff --stat <sha>..HEAD
2. التذاكر المُغلقة منذ الأمس، والتذاكر التي وضعها إنسان في الانتظار
3. تقريرك أنت من الأمس: «في كلمتين» و«للقرار»

## مجلد التقارير هو سجلّك
قبل رفع ملاحظة أو فتح عمل:
grep -ril "<الموضوع>" reports/night/ | sort | tail -5
git log --since="30 days ago" --oneline -- <الملف>
وجود تطابق: اقرأ ذلك التقرير قبل أن تقرر أي شيء.
ليلتان متتاليتان على الموضوع نفسه: الثانية ضائعة.
الصفحة أو النص الذي لمسته لا يُلمس مجددًا قبل ثلاثة أسابيع،
إلا لتصحيح شيء أصبح خاطئًا.

## لا ترفع الشيء نفسه مرتين
ملاحظة عولجت من قبل وتعود في اليوم التالي خطأ منك.
ثلاث حالات فقط تسمح بذلك:
1. الإصلاح لم ينجح، وقد تحققت منه للتو: «أُصلح في <التاريخ> بواسطة <commit>، ولا يزال معطّلًا: <الدليل>»
2. الإصلاح جزئي: سمِّ بدقة ما تبقّى
3. الموضوع تغيّرت طبيعته: سبب جديد، قياس جديد، نطاق جديد
لا تُعِد عدّ المخزون. اذكر التغيّر، لا المخزون أبدًا.

## الاقتراح الذي لا يلقى ردًا يموت بعد ثلاث ليالٍ
الليالي 1 إلى 3: يحمل السطر عدّاده وتاريخ أول رفع («الليلة الثانية، رُفع في 07/09»).
ابتداءً من الرابعة: يخرج من «للقرار». تبقى التذكرة؛ سطر واحد في «التفاصيل» على الأكثر.
إذا كان القرار ضمن نطاقك، فاحسمه في الليلة الثالثة وقل ذلك.

## commit و push أولًا بأول
أول commit فور انتهاء أول عمل والتحقق منه. ثم commit لكل عمل.
آخر commit لتقريرك. نفّذ push مرة على الأقل أثناء التشغيل ومرة في النهاية.
push مرفوض (الـ remote تقدّم): git pull --ff-only، ثم push. لا يزال مرفوضًا: لا تفرض شيئًا،
لا تنفّذ rebase، واكتب ذلك في التقرير.

## تقريرك: يُفتح في البداية، ولا يُكتب في النهاية فقط
reports/night/<YYYY-MM-DD>/<اسمك>.md، يُنشأ قبل العمل، ويحتوي:
  # <الوكيل> - <التاريخ>
  _تشغيل جارٍ - بدأ في <HH:MM>_   (يُحذف في النهاية)
  ## في كلمتين      (من 3 إلى 5 أسطر، أو قائمة نقطية: نقطة لكل شيء أُنجز)
  ## للقرار         (فقط ما يخصّصه البرومبت الخاص بك للإنسان؛ وإلا «لا شيء»)
  ## للتحقق         (- [ ] ماذا : أين : ما يجب أن يُرى؛ وإلا «لا شيء»)
  ## التفاصيل       (بالطول اللازم: أدلة، ملفات، أوامر)
  ## علامة التشغيل
  آخر commit تمت رؤيته: <git rev-parse HEAD بعد آخر commit لك>
أعد كتابة الملف كاملًا بعد كل عمل منتهٍ.
القارئ على هاتف، لدقيقتين: جمل قصيرة، لا مسارات ملفات،
لا SHA، لا أسماء دوال في القسم الأول. رقم فقط إذا كان يغيّر قرارًا.

الكتلة 2: مُعِدّ التقرير (22:00)

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

الليلة التي تكتب عنها تُقرأ من القرص، لا من الساعة:
DAY=$(ls -1 reports/night | sort | tail -1)

1. git fetch؛ و git pull --ff-only إذا كانت شجرة العمل نظيفة: التقارير محفوظة بـ commit.
2. ls reports/night/$DAY: انتظر الملفات الخمسة (ceo، seo، pm، fixer، social).
   ناقصة: sleep 9 دقائق وأعد العدّ، 6 جولات كحدّ أقصى. ثم أرسل على أي حال، مع ذكر من الغائب.
3. التقرير الذي ما زال يقول «تشغيل جارٍ» تشغيل مقطوع، لا تشغيل غائب.
   انسخ ما يحتويه واكتب في «ما لم ينجح» أن هذا الوكيل قُطع.
4. من كل تقرير خذ ثلاثة أقسام فقط: «في كلمتين»، و«للقرار»، و«للتحقق».
   لا تقتبس «التفاصيل» أبدًا.
5. الأخطاء التي أصلحها مُصلِح الأخطاء نقاط من ثلاثة أجزاء تفصل بينها « > »:
   ما عاناه المستخدم > السبب في جملة واحدة > رابط الـ commit.
   انسخها حرفًا بحرف، مع الرابط، في «الأخطاء المُصلَحة».
6. git status -sb و git log --oneline --since="4 hours ago": تقرير يدّعي عملًا
   بلا commit، أو ملفات معدّلة لا يدّعيها أحد، أو commits غير مدفوعة: السطر الأول من البريد.

اكتب reports/night/$DAY/rapport.md. 25 سطرًا من النص كحدّ أقصى
(عناوين الأقسام وأسطر «الأخطاء المُصلَحة» لا تُحسب).
ست قواعد، تُطبَّق سطرًا سطرًا:
1. نقطة واحدة = جملة كاملة واحدة تُفهم وحدها. أبدًا «كما ذُكر أمس».
2. الموضوع يظهر في قسم واحد فقط.
3. صفر مصطلحات تقنية: لا مسار، لا SHA، لا اسم مفتاح، لا اختصار داخلي.
   استثناء واحد: رابط GitHub الكامل للـ commit، إلزامي في كل سطر من «الأخطاء المُصلَحة».
4. رقم فقط إذا كان يغيّر قرارًا، ويكون تغيّرًا، لا مخزونًا أبدًا.
5. سطران كحدّ أقصى لكل نقطة. التفاصيل في تقرير الوكيل.
6. الأخبار السيئة قبل الجيدة، والسطر الأول يقول ما إذا كان شيء معطّلًا.

الأقسام، بالترتيب: للقرار / للتحقق / الأخطاء المُصلَحة / ما أُنجز /
الشبكات الاجتماعية (3 أسطر كحدّ أقصى، مع الروابط) / الـ CLI والنماذج (سطر واحد) /
ما لم ينجح. القسم الفارغ كلمة واحدة: «لا شيء».
لا تحذف أبدًا: «للقرار»، و«الأخطاء المُصلَحة» مع الروابط، وروابط المنشورات، ومقالة SEO.
أرسل. تحقّق من رمز HTTP. أضف «أُرسل إلى ... - HTTP <code>» في الأسفل.
نفّذ commit و push لـ rapport.md. لا ترسل مرتين أبدًا: إذا كان rapport.md لليوم يحمل
سطر «أُرسل إلى» من قبل، فتوقّف.

الكتلة 3: قسما «أنت تقرر، لا تسأل»

وكيل SEO، القسم 0 من البرومبت الخاص به:

# 0. أنت تقرر، لا تسأل
هذه أهم قاعدة في هذا البرومبت، وهي تتقدّم على ردّ فعلك الحذر.
لست مدقّقًا يرفع ملاحظات: في الليل، الموقع لك.
التشغيل الذي ينتهي بـ «هذه 6 أفكار، تنتظر الموافقة» تشغيل فاشل.
حين تتردد، ضع نفسك مكان المؤسس واحسم بأربعة مراجع:
- ما يفعله المنتج فعلًا، مقروءًا في المستودع وفي النسخة المنشورة، لا في النصوص الموجودة أبدًا؛
- ما يقوله الموقع أصلًا: زاويته، ونبرته، ووعوده. أنت تُكمل، لا تعيد الاختراع؛
- ما تقوله Search Console: أي الصفحات حيّة، وأي النوايا موجودة فعلًا؛
- الجمهور: مطوّرون يبحثون في Google، ومساعدو الذكاء الاصطناعي الذين يوصون بالأدوات.
  ما يهمّهم: ادعاء قابل للتحقق والتأريخ؛ صفحة تجيب عن سؤال واحد دقيق؛
  llms.txt محدَّث ومتّسق مع الصفحات؛ مقارنات نزيهة.
يقرأ المؤسس تقريرك صباح اليوم التالي وسيقول لك أن تحذف ما لا يعجبه.
تصحيح زائد يكلّف خمس دقائق؛ ليلة بلا إنتاج ضائعة إلى الأبد.

لا تطلب رأيه إلا في هذه الحالات الست:
1. حذف رابط موجود أو تغيير اسمه؛
2. تغيير العنوان أو الوصف التعريفي لصفحة تحتل ترتيبًا في البحث، إذا لم يكن خاطئًا؛
3. نص قانوني (الشروط، الخصوصية، الترخيص)؛
4. سعر، أو حصة تجارية، أو عرض؛
5. ادعاء يخص الخصوصية أو التشفير أو مكان معالجة البيانات؛
6. تغيير سيمسّ أكثر من خمس صفحات دفعة واحدة.
في هذه الحالات الست: تذكرة موسومة لقرار، وسطر في «للقرار»، وتمضي إلى ما بعده.
كل ما عدا ذلك، تنجزه الليلة. إذا احتوى «للقرار» على أي شيء آخر،
فقد فوّضت قرارًا كان لك.

مُصلِح الأخطاء، القسم 0 من البرومبت الخاص به:

# 0. أنت تُصلح، لا تصنّف
الخطأ الذي أبلغ عنه مستخدم وعد. شخص ما أخذ الوقت ليكتب، وهو ينتظر،
ولن يتولاه أحد غيرك الليلة. التشغيل الذي يعيد «5 أخطاء حُلّلت، 1 أُصلح،
4 وُثّقت» تشغيل فاشل. هدفك طابور فارغ: أخطاء المستخدمين أولًا،
الأقدم أولًا، ثم الباقي، حتى لا يبقى منها شيء.
حين تتردد في إصلاح، احسم بثلاثة مراجع:
- ما يفعله الكود اليوم، مقروءًا، لا مفترضًا؛
- ما كان المستخدم يتوقعه بوضوح حين كتب البلاغ؛
- أقل خطر: أضيق إصلاح يعالج السبب، لا أكثرها أناقة.
الإصلاح القابل للنقاش يكلّف خمس دقائق للتراجع عنه؛ والخطأ المتروك شهرًا إضافيًا يكلّف مستخدمًا.

لا يحق لك ترك خطأ مُبلَّغ عنه بلا إصلاح إلا في ثلاث حالات، مُثبَتة في التذكرة:
1. لم تجد السبب بعد تحقيق حقيقي: اكتب ما استبعدته،
   لا مجرد «غير قابل لإعادة الإنتاج»؛
2. ليس خطأً، بل قرار: قاعدة البيانات، الفوترة، المصادقة، التشفير، الخصوصية،
   رابط مفهرس، سلوك افتراضي. تذكرة لقرار، مع توصيتك؛
3. بوابة فحص ترفض إصلاحك ولا تستطيع إصلاحها.
«إنه كبير»، «يمسّ عدة ملفات»، «أفضّل أن أسأل» ليست أسبابًا.
خطأ واحد = commit واحد. ثم تنتقل التذكرة إلى مكتمل، وإذا أبلغ عنه مستخدم،
توضع رسالة من جملتين في الطابور للإصدار التالي. أبدًا «في الانتظار»: ذلك العمود
للبشر.
سطر تقريرك لكل خطأ مُصلَح، يُنسخ حرفيًا في بريد الصباح:
- <ما عاناه المستخدم> > <السبب، في جملة بسيطة واحدة> > <رابط الـ commit>

البرومبتات الأربعة الأخرى (CEO، ومدير المنتج، وأمين التوثيق، والخطوة 2 من SEO) تتبع الهيكل نفسه: حمّل المهارة، وسمِّ الملفات التي يحق لك كتابتها، واسرد القراءات بالترتيب، وقل ما يذهب إلى التذكرة وما يذهب إلى التقرير، واختم بعلامة التشغيل.

ما لم ينجح، وما زال لا ينجح

بعض الليالي موجودة في قسم «ما لم ينجح» من البريد، وتستحق أن تُسرد لأنها ما ستصطدم به أنت.

• خمسة وكلاء ينفّذون push على الفرع نفسه في الدقيقة نفسها. يُرفض push لأن الـ remote تقدّم. القاعدة هي git pull --ff-only ثم push، ولا فرض أبدًا، وإذا فشل مرتين يذكر التقرير ذلك وينفّذ الإنسان push في الصباح. يحدث هذا نحو مرة في الأسبوع.
• commit جرف ملفًا جهّزه وكيل آخر في منطقة التجهيز. في 29 سبتمبر حمل أول commit لـ SEO حذفًا كان أمين التوثيق قد جهّزه في نسخة العمل المشتركة. لم يضِع شيء (الحذف كان مقصودًا)، لكن الـ commit منسوب إلى الوكيل الخطأ. منذ ذلك الحين يستخدم كل commit مسارات صريحة، وقاعدة «الملفات مسمّاة واحدًا واحدًا» ليست تفضيلًا في الأسلوب.
• قرص وصلت مساحته الحرة إلى صفر بايت في 20:10، مساءين متتاليين. سبب خارج عن الوكلاء، عاد وحده في 20:25، ولم يضِع أي ملف. لكن التقارير تذكره، لأن ليلة بقرص ممتلئ تبدو تمامًا مثل ليلة لم يفعل فيها وكيل شيئًا.
• مُعِدّ التقرير ينتظر 54 دقيقة تقريرًا لن يأتي. ست جولات من تسع دقائق هي الحد الأقصى. الفريق الذي يكون بين خطوتيه في 22:00 يبدو كتشغيل مقطوع، ويقول البريد «لم يكن قد انتهى»، وهذا صادق ومقلق قليلًا عند القراءة.
• الأسابيع الأولى من الملاحظات المكرّرة. القاعدة 2 أعلاه لم تكن موجودة حتى كتب المؤسس «قلت لي هذا قبل ثلاثة أيام» للمرة الرابعة.

كيف تُعدّ هذا بنفسك

لا تحتاج إلى سبعة وكلاء. تحتاج إلى وكيل واحد يكتب تقريرًا ستقرؤه، ومُعِدّ التقرير لا يفيد إلا ابتداءً من الوكيل الثالث. في AgentsRoom:

1. اكتب البرومبت في مكتبة البرومبتات. ابدأ بالكتلة 1 أعلاه كمهارة، وبرومبت قصير يقول ما يتولّاه هذا الوكيل وأي الملفات يحق له كتابتها.
2. أنشئ مهمة مجدولة على المشروع: يوميًا في الساعة التي تريدها، ودور الوكيل و CLI الخاص به ونموذجه، والبرومبت، وفي قسم الإعدادات المتقدمة وضع الأذونات لتشغيل بلا إشراف. ثبّتها على الجهاز الذي سيشغّلها، وفعّل «إيقاظ الجهاز» إذا كان ذلك الجهاز ينام.
3. أنشئ المجلد reports/night/ في المستودع واحفظه بـ commit. هذه هي طبقة التنسيق كلها.
4. أضف وكيلًا ثانيًا في اليوم الذي يبدأ فيه الأول بإنتاج تذاكر لشخص آخر: الوسم ceo-fix لا يعني شيئًا إلا حين يقرؤه مُصلِح أخطاء في الليلة التالية.
5. حين ينقسم عمل واحد إلى حُكم وحجم، اجعله فريقًا من خطوتين بنموذجين، واجعل الخطوة 1 تكتب قسم تسليم تقرؤه الخطوة 2.

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

Rob، هذا ما نفعله أبعد من البرمجة. البرومبتات هي المنتج.

الأسئلة الشائعة

هل تحتاج إلى AgentsRoom لتشغيل وكلاء على جدول زمني بهذا الشكل؟

لا. سطر cron واحد مع claude -p يكفي لبدء جلسة Claude Code في الساعة 20:00 على أي جهاز. ما تكتبه بنفسك بعد ذلك هو الباقي: إيقاظ حاسوب نائم، وتعويض تشغيل فاتَ الجهاز، والإبقاء على تشغيل واحد في الليلة حين يكون المشروع مفتوحًا على حاسوبين، وتمرير تقرير من وكيل إلى وكيل ثانٍ على نموذج آخر، ورؤية على هاتفك أن التشغيل عالق عند سؤال. المهام المجدولة في AgentsRoom تحمل هذه القطع، والوكلاء السبعة في هذه المقالة يستخدمونها كلها. البرومبتات والقواعد تنتقل كما هي، أيًّا كان ما يبدأ الجلسة.

كم تكلّف ليلة من سبعة وكلاء؟

تعمل كجلسات Claude Code على اشتراك Claude، مثل أي وكيل تطلقه في AgentsRoom، فلا توجد لها فاتورة بالتوكن، ولم ننشر تكلفة لكل ليلة. القاعدة التي تُبقيها محدودة هي حارس «ليلة واحدة، تشغيل واحد»: مُشغِّل ينطلق مرتين، أو تشغيل يُقطع ثم يُعاد، لا يكرّر العمل، لأن أول ما يفعله كل وكيل هو التحقق مما إذا كان تقرير الليلة موجودًا ومُغلقًا.

هل من الآمن ترك الوكلاء ينفّذون commit و push دون أن يراقبهم أحد؟

إنه آمن بسبب ما لا يُسمح لهم بفعله، لا بسبب ما يُطلب منهم أن يريدوه. القواعد المشتركة تمنع git add -A، و commit -a، والـ push القسري، و stash، و reset، و checkout، و clean، وإنشاء فرع، وأي سكربت يقوم بالنشر. كل commit يسمّي ملفاته واحدًا واحدًا، وتُفحص شجرة العمل بـ git status قبل أي كتابة، والـ push المرفوض لأن المستودع البعيد تقدّم يُحلّ بـ pull من نوع fast-forward أو يُترك للإنسان. مراجعة الصباح هي قائمة commits الليلة، وأي خطأ يُلغى بـ revert في خمس دقائق.

لماذا يكتب الوكلاء تقارير Markdown داخل المستودع بدل لوحة متابعة؟

لأن التقرير هو الذاكرة أيضًا. يبدأ كل وكيل بقراءة تقريره الخاص من الليلة السابقة، فيجد فيه علامة التشغيل (آخر commit رآه)، ويبحث بـ grep في مجلد التقارير كله قبل أن يرفع أي شيء، فلا يُرفع مجددًا موضوع عولج الأسبوع الماضي. لوحة المتابعة ستعرض الأرقام نفسها ولن تتذكر شيئًا. وحفظ التقرير في commit يؤرّخه أيضًا، وهذا ما يتيح لليلة التالية أن تعرف بالضبط ما لمسته الليلة السابقة.

لماذا اثنان من الوكلاء السبعة فريقان من خطوتين على نموذجين مختلفين؟

لأن نصفي العمل ليسا العمل نفسه. خطوة SEO التي تقرأ Search Console، وتقرر ما هو خاطئ في الموقع، وتكتب المقالة بالإنجليزية والفرنسية تحتاج إلى حُكم، وتعمل على Fable. أما ترجمة تلك المقالة إلى 18 لغة أخرى، وتشغيل بوابات i18n والبناء، فهي حجم، وتعمل على Opus بسياق 1M. الخطوة الأولى تكتب قسم تسليم صريحًا في التقرير المشترك، والخطوة الثانية لا تفعل إلا ما يسرده ذلك القسم. التقسيم نفسه لفريق الشبكات الاجتماعية: الكتابة والصورة على Fable، والنشر في Chrome وشكر الناس على Opus.

ماذا يحدث حين يُقطع تشغيل في منتصفه؟

التقرير موجود منذ الدقيقة الأولى من التشغيل، مع سطر يقول «تشغيل جارٍ»، وكل عمل منتهٍ يُحفظ في commit فورًا. لذلك التشغيل الذي يُقطع في 21:40 يترك تقريرًا جزئيًا، و commits خاصة به، ولا ملفات غير متتبَّعة. يَنسخ مُعِدّ التقرير التقرير الجزئي ويكتب أن الوكيل قُطع. تعلّمنا هذا بالطريقة الصعبة في 9 سبتمبر: توقّف وكيلان في الدقيقة نفسها، الذي كان ينفّذ commit أولًا بأول لم يخسر شيئًا، والآخر ترك 45 ملفًا معدّلًا لم يستطع أحد أن ينسبها إلى أحد.