حوّل أي أمر CLI إلى سير عمل موثوق وقابل للتكرار

استخدم مهارة Dagu لإنشاء سير عمل تحضير الاجتماع اليومي. ارجع إلى مراجع المخطط ووكيل البرمجة والمشاكل المعروفة للحصول على الصياغة الصحيحة. اسأل المستخدم: - كم يوماً للخلف يجب أن يغطي التقرير؟ (الافتراضي: 1) - في أي وقت يجب تشغيله في أيام العمل؟ (الافتراضي: 8:00 صباحاً) - أي واجهة سطر أوامر لوكيل البرمجة بالذكاء الاصطناعي مثبتة لديهم؟ (تحقق من claude، codex، gemini، opencode، aider بهذا الترتيب — استخدم أول واحد يتم العثور عليه، أو اسأل إذا لم يتم اكتشاف أي منها) المتطلبات الأساسية: gh CLI مصادق عليه (gh auth login)، وجود واجهة سطر أوامر واحدة على الأقل لوكيل البرمجة بالذكاء الاصطناعي مثبتة. يجب أن يقوم سير العمل بما يلي: 1. جلب نشاط المستخدم على GitHub باستخدام gh api graphql مع --jq لتنسيق JSON من جانب الخادم (لا تستخدم jq CLI). جلب الالتزامات لكل مستودع (مع الرسائل عبر REST)، وطلبات السحب المدمجة (مع النص)، وطلبات السحب المفتوحة/المسودة المحدثة في الفترة (مع الالتزامات الأخيرة والطوابع الزمنية، مجمعة حسب المستودع)، والمراجعات. 2. اكتشاف جميع المؤسسات تلقائياً من النشاط وتجميع كل شيء حسب المؤسسة. 3. لكل مؤسسة بها نشاط، استخدم DAG فرعي مضمن (فاصل ---) لإنشاء مسودة اجتماع منطوقة باستخدام واجهة سطر أوامر وكيل الذكاء الاصطناعي للمستخدم. استخدم أرخص/أسرع نموذج متاح لذلك الوكيل لأن هذه مهمة تلخيص نصي بسيطة. تخطَّ الاستدعاء بالكامل للمؤسسات التي لا يوجد بها نشاط لتجنب إهدار الرموز. 4. يجب تعريف أمر الوكيل والنموذج وموجه المسودة جميعها كمتغيرات بيئة على المستوى الأعلى (استخدم YAML متعدد الأسطر | للموجه) حتى يتمكن المستخدمون من تبديل الوكلاء أو تخصيص المخرجات بسهولة دون تعديل منطق الخطوة. 5. تجميع كل قسم مؤسسة كـ markdown: مسودة منطوقة، طلبات سحب مدمجة، طلبات سحب مفتوحة مجمعة حسب المستودع مع سجل الالتزامات والطوابع الزمنية، والمراجعات. 6. دمج جميع أقسام المؤسسات في تقرير واحد محفوظ في DAG_DOCS_DIR. 7. جدولة في أيام العمل مع catchup وإعدادات إعادة المحاولة الافتراضية والمهلات الزمنية على خطوات الوكيل. مهم: راجع مرجع المشاكل المعروفة للحلول البديلة المعروفة. اتبع مرجع وكيل البرمجة للأمر غير التفاعلي الصحيح وعلامات النموذج لكل واجهة سطر أوامر وكيل.

استخدم مهارة Dagu لإنشاء سير عمل مولّد ملاحظات الإصدار. ارجع إلى مراجع المخطط ووكيل البرمجة والمشاكل المعروفة للحصول على الصياغة الصحيحة. اسأل المستخدم: - أي مستودع؟ (الافتراضي: المستودع الحالي، يتم اكتشافه عبر gh repo view --json nameWithOwner) - أي علامات للمقارنة؟ (الافتراضي: أحدث علامة مقابل العلامة السابقة، يتم اكتشافها تلقائياً) المتطلبات الأساسية: gh CLI مصادق عليه (gh auth login)، وجود واجهة سطر أوامر واحدة على الأقل لوكيل البرمجة بالذكاء الاصطناعي مثبتة. يجب أن يقوم سير العمل بما يلي: 1. حل علامتي git للمقارنة. إذا لم يتم تحديدها، اكتشف تلقائياً أحدث علامة والعلامة السابقة باستخدام GitHub API. أخرجها كـ JSON حتى تتمكن الخطوات اللاحقة من الرجوع إلى الحقول الفردية عبر مسار JSON (مثل ${TAGS.to}). 2. استخراج جميع أرقام طلبات السحب من الالتزامات بين العلامتين باستخدام GitHub compare API مع --jq (لا تستخدم jq CLI). أخرج رقم طلب سحب واحد لكل سطر. 3. لكل طلب سحب، جلب التفاصيل عبر gh api graphql: الرقم، العنوان، اسم المؤلف، ملخص النص (أول ~300 حرف تقريباً)، التصنيفات، و closingIssuesReferences (الرقم، العنوان، اسم المؤلف). بناء مصفوفة JSON من النتائج. - حرج: عند التكرار على مخرجات خطوة سابقة، لا تستخدم "for X in $VAR" — يلتقط Dagu المخرجات متعددة الأسطر في متغير نصي واحد، لذا لا يعمل تقسيم الكلمات. بدلاً من ذلك، اقرأ ملف stdout للخطوة السابقة سطراً بسطر: `while IFS= read -r line; do ... done < "${prev_step.stdout}"`. أزل الأحرف غير الرقمية من كل سطر باستخدام `tr -dc '0-9'` قبل تمريره إلى استعلام GraphQL. - يستخدم نص استعلام gh GraphQL أسماء متغيرات بادئة $ ($owner، $name، $num). هذه آمنة في سكريبتات Dagu لأن Dagu يوسع فقط المتغيرات ${بين أقواس} وأنماط $varname العارية التي تطابق متغيرات Dagu المعرفة — الأسماء العارية $ غير المعرفة تُحفظ كما هي للصدفة. ومع ذلك، مرر متغيرات الأعداد الصحيحة إلى -F بدون علامات اقتباس (مثل -F num=$NUM وليس -F num="$NUM") حتى يرسلها gh كأعداد صحيحة وليس نصوصاً. 4. استخدم خطوة وكيل ذكاء اصطناعي واحدة (اكتشف تلقائياً أي واجهة سطر أوامر متاحة، استخدم أرخص نموذج) لتصنيف كل طلب سحب وتنسيق ملاحظات الإصدار النهائية. زوّده بتفاصيل طلبات السحب JSON وقالب سجل التغييرات والسياق (المستودع، العلامات، التاريخ، مالك المستودع لاستبعاده من المساهمين). 5. حفظ المخرجات في DAG_DOCS_DIR. 6. استخدم defaults.retry_policy و timeout_sec: 300 على خطوة وكيل الذكاء الاصطناعي. يجب تعريف قالب تنسيق سجل التغييرات كمتغير بيئة على المستوى الأعلى باستخدام YAML متعدد الأسطر (|) حتى يتمكن المستخدمون من تخصيص المخرجات دون تعديل منطق الخطوة.

استخدم مهارة Dagu لإنشاء سير عمل تنظيف نصوص الذكاء الاصطناعي. ارجع إلى مراجع المخطط ووكيل البرمجة والمشاكل المعروفة للحصول على الصياغة الصحيحة. اسأل المستخدم: - هل يريدون معالجة ملف أم لصق نص مباشرة؟ (دعم كل من معامل input_file و input_text) - كم عدد جولات إعادة الكتابة؟ (الافتراضي: 2) - مستوى الصرامة؟ (low/medium/high، الافتراضي: medium) المتطلبات الأساسية: وجود واجهة سطر أوامر واحدة على الأقل لوكيل البرمجة بالذكاء الاصطناعي مثبتة (claude أو gemini). curl لجلب مرجع ويكيبيديا. يتكون سير العمل من 4 خطوات: detect_agent، setup، review_loop، finalize. الخطوة 1 — detect_agent: أخرج مسار الملف التنفيذي الكامل (وليس الاسم فقط) لأن سكريبتات Dagu قد لا تملك PATH الكامل للمستخدم. تحقق من المواقع الشائعة مثل ~/.local/bin/ كبديل احتياطي. أضف PATH: "${HOME}/.local/bin:${PATH}" إلى env على المستوى الأعلى. الخطوة 2 — setup: - جلب أحدث صفحة "Signs of AI Writing" من ويكيبيديا (نص ويكي خام) عبر curl. يجب أن يكون الرابط متغير بيئة على المستوى الأعلى حتى يتمكن المستخدمون من تبديله. - تحضير نص الإدخال. لـ input_file، انسخه باستخدام cp. لـ input_text، استخدم `printenv input_text` لكتابته بأمان إلى ملف — لا تستخدم ${input_text} مباشرة في السكريبتات لأن Dagu يوسع المتغيرات قبل تشغيل الصدفة. انظر مشكلة printenv. - اكتب جميع متغيرات البيئة متعددة الأسطر/التي يتحكم بها المستخدم (WRITING_STYLE، ADDITIONAL_RULES، CHECK_STRICTNESS) إلى ملفات مساعدة ببادئة مشتركة في DAG_DOCS_DIR. تُقرأ هذه الملفات بواسطة خطوة الحلقة وتُنظف في finalize. الخطوة 3 — review_loop: خطوة سكريبت واحدة مع حلقة bash for (ليس repeat_policy، وليس DAG فرعي). تعمل الحلقة حتى max_rounds تكرار: أ. بناء موجه مع مرجع الويكي والأسلوب (من ملف) والصرامة (من ملف) والنص الحالي. استخدم محدد heredoc بعلامات اقتباس مفردة (<<'INSTR') لتعليمات النظام حتى لا توسعها الصدفة. ب. استدعاء وكيل الذكاء الاصطناعي (CHECK_MODEL، مثل sonnet) لفحص النص. السطر الأول من المخرجات: عدد المشاكل. الأسطر المتبقية: ملاحظات لكل مشكلة بتنسيق: ISSUE: "<اقتباس>" | SIGN: <فئة> | FIX: <إعادة كتابة>. ج. حفظ الملاحظات في ملف لكل جولة (مثل ${P}_feedback_round${ROUND}.txt) حتى تتمكن finalize من تضمينها في التقرير. د. استخراج العدد. إذا كان 0، توقف فوراً (لا حاجة لإعادة الكتابة). هـ. استدعاء وكيل الذكاء الاصطناعي (REWRITE_MODEL، مثل opus) لإعادة الكتابة. اكتب المخرجات مباشرة إلى ملف النص، مع الكتابة فوقه. حرج: لا تشر إلى متغيرات البيئة متعددة الأسطر مثل WRITING_STYLE أو ADDITIONAL_RULES مباشرة في السكريبت — يوسعها Dagu قبل تشغيل الصدفة، مما قد يكسر التحليل. اقرأها من الملفات المساعدة المكتوبة بواسطة setup عبر cat بدلاً من ذلك. فقط متغيرات البيئة البسيطة (المسارات، أسماء النماذج، الأرقام) آمنة للاستخدام المباشر. الخطوة 4 — finalize: بناء تقرير كامل مع: رأس البيانات الوصفية (التاريخ، عدد الكلمات، الصرامة، عدد المشاكل لكل جولة)، ثم قسم "المشاكل المكتشفة والمصلحة" يسرد جميع ملاحظات كل جولة، ثم قسم "النص النهائي" مع النص المعاد كتابته. تنظيف جميع الملفات المساعدة بما في ذلك ملفات ملاحظات كل جولة. مفاتيح متغيرات البيئة (جميعها على المستوى الأعلى، قابلة للتخصيص بسهولة): - WRITING_STYLE: تعليمات أسلوب الكتابة المستهدف متعددة الأسطر (|) - CHECK_STRICTNESS: low/medium/high - CHECK_MODEL: نموذج الفحص (أرخص، مثل sonnet) - REWRITE_MODEL: نموذج إعادة الكتابة (جودة، مثل opus) - ADDITIONAL_RULES: قواعد إضافية بخلاف مرجع ويكيبيديا - WIKI_URL: رابط ويكيبيديا الخام (قابل للتبديل) - WIKI_EXCERPT_LINES: كم سطراً من الويكي يتم تزويد الذكاء الاصطناعي بها استخدم معاملات محددة النوع بقوة (name، type، description، default، minimum، maximum). مهم: راجع مرجع المشاكل المعروفة للحلول البديلة المعروفة. اتبع مرجع وكيل البرمجة للأمر غير التفاعلي الصحيح وعلامات النموذج.