किसी भी CLI कमांड को एक विश्वसनीय, दोहराने योग्य वर्कफ़्लो में बदलें

दैनिक स्टैंडअप तैयारी वर्कफ़्लो बनाने के लिए Dagu स्किल का उपयोग करें। सही सिंटैक्स के लिए स्कीमा, कोडिंग एजेंट और pitfalls संदर्भ देखें। उपयोगकर्ता से पूछें: - रिपोर्ट कितने दिन पीछे तक कवर करे? (डिफ़ॉल्ट: 1) - कार्यदिवसों पर किस समय चलना चाहिए? (डिफ़ॉल्ट: सुबह 8:00 बजे) - उनके पास कौन सा AI कोडिंग एजेंट CLI इंस्टॉल है? (claude, codex, gemini, opencode, aider इसी क्रम में जांचें — पहला मिलने वाला उपयोग करें, या अगर कोई नहीं मिले तो पूछें) पूर्वापेक्षाएं: gh CLI प्रमाणित (gh auth login), कम से कम एक AI कोडिंग एजेंट CLI इंस्टॉल। वर्कफ़्लो को: 1. gh api graphql के साथ --jq का उपयोग करके सर्वर-साइड JSON फ़ॉर्मेटिंग के लिए उपयोगकर्ता की GitHub गतिविधि प्राप्त करें (jq CLI का उपयोग न करें)। प्रति रेपो कमिट्स (REST के माध्यम से संदेशों के साथ), मर्ज किए गए PR (बॉडी के साथ), अवधि में अपडेट किए गए ओपन/ड्राफ्ट PR (हाल के कमिट्स और टाइमस्टैम्प के साथ, रेपो द्वारा ग्रुप), और रिव्यूज़ प्राप्त करें। 2. गतिविधि से सभी संगठनों को स्वचालित रूप से खोजें और सब कुछ संगठन के अनुसार ग्रुप करें। 3. गतिविधि वाले प्रत्येक संगठन के लिए, उपयोगकर्ता के AI एजेंट CLI का उपयोग करके बोला जाने वाला स्टैंडअप ड्राफ्ट तैयार करने के लिए इनलाइन sub-DAG (--- सेपरेटर) का उपयोग करें। उस एजेंट के लिए उपलब्ध सबसे सस्ते/तेज़ मॉडल का उपयोग करें क्योंकि यह एक सरल टेक्स्ट सारांश कार्य है। टोकन बर्बाद न करने के लिए बिना गतिविधि वाले संगठनों के लिए कॉल पूरी तरह छोड़ दें। 4. एजेंट कमांड, मॉडल और ड्राफ्ट प्रॉम्प्ट सभी को टॉप-लेवल env वेरिएबल के रूप में परिभाषित किया जाना चाहिए (प्रॉम्प्ट के लिए YAML मल्टीलाइन | उपयोग करें) ताकि उपयोगकर्ता स्टेप लॉजिक में बदलाव किए बिना आसानी से एजेंट बदल सकें या आउटपुट कस्टमाइज़ कर सकें। 5. प्रत्येक संगठन सेक्शन को markdown के रूप में असेंबल करें: बोला जाने वाला ड्राफ्ट, मर्ज किए गए PR, रेपो द्वारा ग्रुप किए गए ओपन PR जिनमें कमिट इतिहास और टाइमस्टैम्प हों, और रिव्यूज़। 6. सभी संगठन सेक्शन को एक रिपोर्ट में मिलाकर DAG_DOCS_DIR में सहेजें। 7. catchup, retry defaults और एजेंट स्टेप्स पर timeouts के साथ कार्यदिवसों पर शेड्यूल करें। महत्वपूर्ण: ज्ञात वर्कअराउंड के लिए pitfalls संदर्भ की समीक्षा करें। प्रत्येक एजेंट CLI के लिए सही नॉन-इंटरैक्टिव कमांड और मॉडल फ़्लैग के लिए कोडिंग एजेंट संदर्भ का पालन करें।

रिलीज़ नोट्स जनरेटर वर्कफ़्लो बनाने के लिए Dagu स्किल का उपयोग करें। सही सिंटैक्स के लिए स्कीमा, कोडिंग एजेंट और pitfalls संदर्भ देखें। उपयोगकर्ता से पूछें: - कौन सा रिपॉजिटरी? (डिफ़ॉल्ट: वर्तमान रेपो, gh repo view --json nameWithOwner के माध्यम से पहचाना गया) - तुलना के लिए कौन से टैग? (डिफ़ॉल्ट: नवीनतम टैग बनाम पिछला टैग, स्वचालित रूप से पहचाने गए) पूर्वापेक्षाएं: gh CLI प्रमाणित (gh auth login), कम से कम एक AI कोडिंग एजेंट CLI इंस्टॉल। वर्कफ़्लो को: 1. तुलना के लिए दो git टैग रिज़ॉल्व करें। यदि निर्दिष्ट नहीं हैं, तो GitHub API का उपयोग करके नवीनतम और पिछले टैग स्वचालित रूप से पहचानें। उन्हें JSON के रूप में आउटपुट करें ताकि डाउनस्ट्रीम स्टेप्स JSON path के माध्यम से अलग-अलग फ़ील्ड संदर्भित कर सकें (जैसे ${TAGS.to})। 2. GitHub compare API के साथ --jq का उपयोग करके दो टैग के बीच कमिट्स से सभी PR नंबर निकालें (jq CLI का उपयोग न करें)। प्रति लाइन एक PR नंबर आउटपुट करें। 3. प्रत्येक PR के लिए, gh api graphql के माध्यम से विवरण प्राप्त करें: नंबर, शीर्षक, लेखक login, बॉडी सारांश (पहले ~300 अक्षर), लेबल और closingIssuesReferences (नंबर, शीर्षक, लेखक login)। परिणामों से एक JSON array बनाएं। - महत्वपूर्ण: पिछले स्टेप के आउटपुट पर इटरेट करते समय "for X in $VAR" का उपयोग न करें — Dagu मल्टीलाइन आउटपुट को एक स्ट्रिंग वेरिएबल में कैप्चर करता है, इसलिए word splitting काम नहीं करती। इसके बजाय, पिछले स्टेप की stdout फ़ाइल को लाइन दर लाइन पढ़ें: `while IFS= read -r line; do ... done < "${prev_step.stdout}"`. GraphQL क्वेरी में पास करने से पहले प्रत्येक लाइन से `tr -dc '0-9'` के साथ गैर-संख्यात्मक अक्षर हटाएं। - gh GraphQL क्वेरी स्ट्रिंग $-प्रीफ़िक्स्ड वेरिएबल नाम ($owner, $name, $num) का उपयोग करती है। ये Dagu स्क्रिप्ट में सुरक्षित हैं क्योंकि Dagu केवल ${braced} वेरिएबल और bare $varname पैटर्न जो परिभाषित Dagu वेरिएबल से मेल खाते हैं उन्हें विस्तारित करता है — अपरिभाषित bare $names शेल के लिए यथावत संरक्षित रहते हैं। हालांकि, इंटीजर वेरिएबल को -F में बिना कोट्स के पास करें (जैसे -F num=$NUM न कि -F num="$NUM") ताकि gh उन्हें स्ट्रिंग नहीं बल्कि इंटीजर के रूप में भेजे। 4. प्रत्येक PR को वर्गीकृत करने और अंतिम रिलीज़ नोट्स फ़ॉर्मेट करने दोनों के लिए एक ही AI एजेंट स्टेप का उपयोग करें (स्वचालित रूप से पहचानें कि कौन सा CLI उपलब्ध है, सबसे सस्ते मॉडल का उपयोग करें)। इसे PR विवरण JSON, changelog टेम्पलेट और संदर्भ (रेपो, टैग, तिथि, योगदानकर्ताओं से बाहर रखने के लिए रेपो स्वामी) प्रदान करें। 5. आउटपुट को DAG_DOCS_DIR में सहेजें। 6. AI एजेंट स्टेप पर defaults.retry_policy और timeout_sec: 300 का उपयोग करें। changelog फ़ॉर्मेट टेम्पलेट को अनिवार्य रूप से टॉप-लेवल env वेरिएबल के रूप में YAML मल्टीलाइन (|) का उपयोग करके परिभाषित किया जाना चाहिए ताकि उपयोगकर्ता स्टेप लॉजिक में बदलाव किए बिना आउटपुट कस्टमाइज़ कर सकें।

AI लेखन सफ़ाई वर्कफ़्लो बनाने के लिए Dagu स्किल का उपयोग करें। सही सिंटैक्स के लिए स्कीमा, कोडिंग एजेंट और pitfalls संदर्भ देखें। उपयोगकर्ता से पूछें: - क्या वे फ़ाइल प्रोसेस करना चाहते हैं या इनलाइन टेक्स्ट पेस्ट करना? (input_file और input_text दोनों पैरामीटर सपोर्ट करें) - कितने रीराइट राउंड? (डिफ़ॉल्ट: 2) - कठोरता स्तर? (low/medium/high, डिफ़ॉल्ट: medium) पूर्वापेक्षाएं: कम से कम एक AI कोडिंग एजेंट CLI इंस्टॉल (claude या gemini)। विकिपीडिया संदर्भ प्राप्त करने के लिए curl। वर्कफ़्लो में 4 स्टेप्स हैं: detect_agent, setup, review_loop, finalize। स्टेप 1 — detect_agent: पूर्ण बाइनरी पथ आउटपुट करें (केवल नाम नहीं) क्योंकि Dagu स्क्रिप्ट में उपयोगकर्ता का पूरा PATH उपलब्ध नहीं हो सकता। फ़ॉलबैक के रूप में ~/.local/bin/ जैसे सामान्य स्थानों की जांच करें। टॉप-लेवल env में PATH: "${HOME}/.local/bin:${PATH}" जोड़ें। स्टेप 2 — setup: - curl के माध्यम से नवीनतम विकिपीडिया "Signs of AI Writing" पेज (raw wikitext) प्राप्त करें। URL एक टॉप-लेवल env वेरिएबल होना चाहिए ताकि उपयोगकर्ता इसे बदल सकें। - इनपुट टेक्स्ट तैयार करें। input_file के लिए, cp करें। input_text के लिए, फ़ाइल में सुरक्षित रूप से लिखने के लिए `printenv input_text` का उपयोग करें — स्क्रिप्ट में सीधे ${input_text} का उपयोग न करें क्योंकि Dagu शेल चलने से पहले वेरिएबल विस्तारित करता है। printenv pitfall देखें। - सभी मल्टीलाइन/उपयोगकर्ता-नियंत्रित env वेरिएबल (WRITING_STYLE, ADDITIONAL_RULES, CHECK_STRICTNESS) को DAG_DOCS_DIR में एक सामान्य प्रीफ़िक्स के साथ हेल्पर फ़ाइलों में लिखें। इन फ़ाइलों को लूप स्टेप द्वारा पढ़ा जाता है और finalize में साफ़ किया जाता है। स्टेप 3 — review_loop: बैश for लूप के साथ एक सिंगल स्क्रिप्ट स्टेप (repeat_policy नहीं, sub-DAG नहीं)। लूप max_rounds इटरेशन तक चलता है: a. wiki संदर्भ, स्टाइल (फ़ाइल से), कठोरता (फ़ाइल से) और वर्तमान टेक्स्ट के साथ एक प्रॉम्प्ट बनाएं। सिस्टम निर्देशों के लिए सिंगल-कोटेड heredoc डिलीमिटर (<<'INSTR') का उपयोग करें ताकि शेल उन्हें विस्तारित न करे। b. टेक्स्ट जांचने के लिए AI एजेंट (CHECK_MODEL, जैसे sonnet) को कॉल करें। आउटपुट की पहली लाइन: इश्यू काउंट। शेष लाइनें: प्रति-इश्यू फ़ीडबैक फ़ॉर्मेट: ISSUE: "<quote>" | SIGN: <category> | FIX: <rewrite>। c. फ़ीडबैक को प्रति-राउंड फ़ाइल (जैसे ${P}_feedback_round${ROUND}.txt) में सहेजें ताकि finalize इसे रिपोर्ट में शामिल कर सके। d. काउंट निकालें। यदि 0 है, तो तुरंत ब्रेक करें (रीराइट की आवश्यकता नहीं)। e. रीराइट के लिए AI एजेंट (REWRITE_MODEL, जैसे opus) को कॉल करें। आउटपुट को सीधे टेक्स्ट फ़ाइल में लिखें, इन-प्लेस ओवरराइट करें। महत्वपूर्ण: WRITING_STYLE या ADDITIONAL_RULES जैसे मल्टीलाइन env वेरिएबल को सीधे स्क्रिप्ट में संदर्भित न करें — Dagu शेल चलने से पहले उन्हें विस्तारित करता है, जो पार्सिंग तोड़ सकता है। इसके बजाय setup द्वारा लिखी गई हेल्पर फ़ाइलों से cat के माध्यम से पढ़ें। केवल सरल env वेरिएबल (पथ, मॉडल नाम, संख्याएं) सीधे उपयोग करने के लिए सुरक्षित हैं। स्टेप 4 — finalize: पूरी रिपोर्ट बनाएं जिसमें: मेटाडेटा हेडर (तिथि, शब्द गणना, कठोरता, प्रति-राउंड इश्यू काउंट), फिर "पाए गए और ठीक किए गए इश्यू" सेक्शन जिसमें सभी प्रति-राउंड फ़ीडबैक सूचीबद्ध हों, फिर रीराइट किए गए टेक्स्ट के साथ "अंतिम टेक्स्ट" सेक्शन। सभी हेल्पर फ़ाइलें और प्रति-राउंड फ़ीडबैक फ़ाइलें साफ़ करें। Env वेरिएबल नॉब्स (सभी टॉप-लेवल, आसानी से कस्टमाइज़ करने योग्य): - WRITING_STYLE: मल्टीलाइन (|) लक्ष्य लेखन शैली निर्देश - CHECK_STRICTNESS: low/medium/high - CHECK_MODEL: जांच के लिए मॉडल (सस्ता, जैसे sonnet) - REWRITE_MODEL: रीराइटिंग के लिए मॉडल (गुणवत्ता, जैसे opus) - ADDITIONAL_RULES: विकिपीडिया संदर्भ के अलावा अतिरिक्त नियम - WIKI_URL: विकिपीडिया raw URL (बदलने योग्य) - WIKI_EXCERPT_LINES: AI को फ़ीड करने के लिए wiki की कितनी लाइनें स्ट्रॉन्गली टाइप्ड params (name, type, description, default, minimum, maximum) का उपयोग करें। महत्वपूर्ण: ज्ञात वर्कअराउंड के लिए pitfalls संदर्भ की समीक्षा करें। सही नॉन-इंटरैक्टिव कमांड और मॉडल फ़्लैग के लिए कोडिंग एजेंट संदर्भ का पालन करें।