सात AI एजेंट हमारी रातें चलाते हैं: कोडिंग से आगे शेड्यूल किए गए एजेंट, प्रॉम्प्ट के साथ

23 सितंबर को, Rob नाम के एक यूज़र ने हमारे सार्वजनिक बैकलॉग पर लिखा: "would love to get examples of how you guys are doing stuff beyond coding"। सवाल जायज़ है। इस साइट पर सब कुछ कोडिंग एजेंट के बारे में है, और जो हम असल में हर शाम चलाते हैं वह ज़्यादातर कोडिंग नहीं है।

28 अगस्त से, सात एजेंट 20:00 बजे एक Mac mini पर शुरू होते हैं। वे दिन के कमिट, Search Console, एडमिन डैशबोर्ड, बैकलॉग, लोगों का भेजा फ़ीडबैक और पिछली रात की रिपोर्टें पढ़ते हैं। वे बग ठीक करते हैं, वेबसाइट सुधारते हैं, हर तीन दिन में एक ब्लॉग लेख लिखते और अनुवाद करते हैं, तीन सोशल नेटवर्क पर पोस्ट करते हैं, एक प्रोडक्ट नॉलेज बेस अपडेट करते हैं, और 22:00 बजे सातवाँ एजेंट पढ़ता है कि बाकी छह ने क्या छोड़ा है और 25 पंक्तियों का एक ईमेल भेजता है। कोई देख नहीं रहा होता। संस्थापक अगली सुबह अपने फ़ोन पर ईमेल पढ़ता है।

यह लेख Rob को जवाब है। क्या चलता है, कैसे जुड़ा है, एजेंट बिना कभी बात किए एक-दूसरे को काम कैसे सौंपते हैं, कौन-सा मॉडल कौन-सा काम करता है और क्यों, वे चार नियम जो उनके प्रॉम्प्ट को ठोकर खाकर सीखने पड़े, और खुद प्रॉम्प्ट, ऐसे ब्लॉक में समेटे हुए जिन्हें आप कॉपी कर सकते हैं। नीचे का हर आँकड़ा रिपॉज़िटरी से आता है: रिपोर्टें वहीं कमिट होती हैं, रात दर रात।

33 रातों ने क्या बनाया

रिपॉज़िटरी के रिपोर्ट फ़ोल्डर में 33 तारीख वाली डायरेक्टरी हैं, 28 अगस्त से 30 सितंबर तक। उन्हें पढ़ने पर यह मिलता है:

• रिपोर्टर के भेजे सुबह के 31 ईमेल।
• फ़िक्सर के ठीक किए 51 बग, हर एक की रिपोर्ट पंक्ति में कमिट लिंक के साथ। इनमें से कई यूज़र्स ने सार्वजनिक बैकलॉग पर रिपोर्ट किए थे और उन्हें अगली रिलीज़ के साथ जवाब मिला।
• 10 सितंबर से SEO टीम के लिखे 7 ब्लॉग लेख, हर तीन दिन में एक, हर एक पहले अंग्रेज़ी और फ़्रेंच में, फिर उसी रात 18 और भाषाओं में।
• सोशल मीडिया जर्नल के 29 दिन: हर शाम तीन नेटवर्क और पाँच Facebook ग्रुप, साथ में हर उस पोस्ट के नीचे धन्यवाद की टिप्पणी जहाँ किसी यूज़र ने AgentsRoom शेयर किया।
• लगभग सौ फ़ैक्ट शीट वाला एक प्रोडक्ट नॉलेज बेस, जो दिन के कमिट के साथ अपडेट रहता है, जिसे ऐप के भीतर का असिस्टेंट पढ़ता है और साइट llms-full.txt के रूप में परोसती है।

इसमें से किसी के लिए भी 20:00 के बाद इंसान की ज़रूरत नहीं पड़ी। इसके कुछ हिस्से के लिए 08:00 बजे इंसान की ज़रूरत पड़ी, और आख़िरी एजेंट का मक़सद यही है।

टीम: 20:00 बजे कौन चलता है

हर एजेंट AgentsRoom में एक Scheduled Task है: एक प्रॉम्प्ट, एक एजेंट (रोल, CLI, मॉडल), एक मशीन और एक समय। सातों Claude Code चलाते हैं। इनमें से दो अकेले एजेंट नहीं बल्कि दो चरणों वाली टीमें हैं, और हम इसकी वजह पर लौटेंगे।

आख़िरी कॉलम की सारी .md फ़ाइलें reports/night/<date>/ में रहती हैं, कमिट और पुश की हुई। यही फ़ोल्डर पूरा तालमेल सिस्टम है, और अगला सेक्शन बताता है क्यों।

वे कैसे जुड़े हैं

सातों में से हर एक एक ही ढाँचे वाला Scheduled Task है:

• रोज़ 20:00 बजे सक्रिय होता है (रिपोर्टर के लिए 22:00)। कोई cron एक्सप्रेशन नहीं; आवृत्ति एडिटर में चुनी जाती है।
• एक मशीन पर पिन किया हुआ। प्रोजेक्ट कई कंप्यूटरों पर खुला है, और जब तक आप उसे सीमित न करें, ट्रिगर हर उस मशीन पर सक्रिय होता है जिस पर वह है। हमारे ट्रिगर Mac mini तक सीमित हैं, इसलिए 20:05 पर खोला गया लैपटॉप दूसरा CEO शुरू नहीं करता।
• मशीन को जगाता है। Mac mini सोता है। टास्क में “मशीन जगाएँ” विकल्प है, जो रन से कुछ सेकंड पहले ऑपरेटिंग सिस्टम के अपने टूल से वेक शेड्यूल करता है (macOS पर pmset, Windows पर wake-to-run के साथ Task Scheduler, Linux पर rtcwake)। इसके बिना, सोती मशीन बस रन चूक जाती है।
• कैच-अप चालू या बंद, हर टास्क के लिए अलग। अगर 20:00 बजे मशीन बंद थी, तो कैच-अप चालू वाला टास्क अगली बार ऐप खुलने पर सक्रिय होता है। CEO, PM और रिपोर्टर में यह चालू है। SEO, फ़िक्सर, सोशल और डॉक्यूमेंटेशन टास्क में बंद है: अगली सुबह 11:00 बजे शुरू होने वाला रन उसी checkout में दिन के काम से टकराएगा।
• परमिशन मोड टास्क पर सेट है, प्रोवाइडर पर नहीं। बिना निगरानी वाला रन रात 3 बजे किसी मंज़ूरी के अनुरोध पर रुक नहीं सकता, इसलिए टास्क उनके बिना चलता है, जबकि संस्थापक उसी CLI पर जिन एजेंट को हाथ से चलाता है वे अब भी पहले पूछते हैं।
• 60 मिनट निष्क्रिय रहने पर कंसोल बंद हो जाता है। काम पूरा कर चुका एजेंट साइडबार में तब तक पड़ा नहीं रहता जब तक कोई उसे बंद न करे।
• प्रॉम्प्ट ही पहला संदेश है। हर प्रॉम्प्ट का टेक्स्ट प्रॉम्प्ट लाइब्रेरी में रखा है और वही टेक्स्ट ट्रिगर के प्रॉम्प्ट फ़ील्ड में है, इसलिए एक को बदलने का मतलब दोनों को बदलना है। प्रॉम्प्ट फ़्रेंच में हैं, क्योंकि संस्थापक रिपोर्टें फ़्रेंच में पढ़ता है। बाकी सब, कमिट संदेशों से लेकर नॉलेज बेस तक, अंग्रेज़ी में है।

एक और हिस्सा सातों साझा करते हैं: “रात के एजेंट, साझा नियम” नाम की एक स्किल। हर प्रॉम्प्ट “यह स्किल लोड करें और लागू करें” से शुरू होता है, और स्किल में वह सब है जो सब पर लागू होता है: किसका ज़िम्मा क्या है, “एक रात, एक रन” वाला पहरा, git के अधिकार, रिपोर्ट का फ़ॉर्मेट, बैकलॉग के नियम, और रिपोर्टर के लिए ईमेल का फ़ॉर्मेट। जब कोई नियम बदलता है, तो वह एक ही जगह बदलता है।

वे बिना बात किए एक-दूसरे को काम कैसे सौंपते हैं

सातों एजेंट कभी एक-दूसरे को संदेश नहीं भेजते। भेज सकते थे, AgentsRoom में एजेंट मैसेजिंग है, लेकिन संदेश अगली सुबह दिखाई नहीं देता और उस पर grep नहीं चलाया जा सकता। सब कुछ उन तीन चीज़ों से होकर जाता है जो रात के बाद भी बची रहती हैं:

रिपॉज़िटरी। हर एजेंट reports/night/<date>/<agent>.md लिखता है, उसे अपने रन के पहले मिनट में खोलता है, हर पूरे हुए काम के बाद उसे दोबारा लिखता है, कमिट और पुश करता है। रिपोर्ट के चार तय सेक्शन हैं: “दो शब्दों में” (एक बुलेट सूची, हर किए गए काम के लिए एक बुलेट), “तय करना है” (सिर्फ़ वह जो प्रॉम्प्ट इंसान के लिए रखता है), “जाँचना है” (एक लोकल URL या खोलने के लिए एक स्क्रीन), “विवरण” (जितना लंबा ज़रूरी हो)। यह एक रन मार्कर पर ख़त्म होती है: आख़िरी कमिट जो एजेंट ने देखा।

बैकलॉग। जो एजेंट किसी दूसरे के लिए काम ढूँढता है, वह वह काम खुद नहीं करता। वह एक टैग के साथ टिकट खोलता है: छोटे, जाँचे हुए बग के लिए ceo-fix, जिसे फ़िक्सर लेगा; लक्षित क्वेरी वाले कंटेंट के काम के लिए ceo-seo; जिस चीज़ में इंसान की ज़रूरत हो उसके लिए ceo-decision (डेटाबेस, बिलिंग, ऑथ, एन्क्रिप्शन, कीमतें, इंडेक्स हुआ URL, डिफ़ॉल्ट व्यवहार)। डॉक्यूमेंटेशन प्रभारी कमिट पढ़ते हुए साइट पर बिना पेज वाला एक फ़ीचर पाता है: वह ceo-seo टिकट दर्ज करता है, और SEO उसे अगली रात ले लेता है। CEO एरर लॉग पढ़ते हुए कोड में कारण समेत एक बग पाता है: ceo-fix, और फ़िक्सर उसे अगली रात ले लेता है।

कल की रिपोर्ट। कोई भी काम खोलने से पहले, हर एजेंट पिछली रात की अपनी रिपोर्ट पढ़ता है, साथ में दिन के दौरान बंद हुए टिकटों की सूची। कल उसने जो बताया था, वह अक्सर दिन में ठीक हो चुका होता है। पहले से निपटाया गया विषय दोबारा नहीं उठाया जाता; पहले से खुला टिकट दोबारा नहीं बनाया जाता।

चक्र इंसान पर पूरा होता है। रिपोर्टर का ईमेल एक पंक्ति पर ख़त्म होता है: प्रोडक्ट मैनेजर को जवाब देने के लिए, rapport.md के अंत में “## फ़ैसले” सेक्शन जोड़ें (P1 ठीक / P2 नहीं: कारण / P3 बाद में), कमिट, पुश। PM अगली शाम पुश किया गया वर्ज़न पढ़ता है और जो मंज़ूर हुआ उसे लागू करता है: टिकट बनाता है, डुप्लिकेट मिलाता है, बाकी को कारण के साथ किनारे रखता है। जिस फ़ैसले का तीन रातों तक जवाब न आए, वह भी एक फ़ैसला है: प्रस्ताव ईमेल से हट जाता है और टिकट बनकर रहता है।

कौन-सा मॉडल कौन-सा काम करता है, और क्यों

ऊपर की तालिका दो मॉडल दिखाती है। यह मौजूदा कॉन्फ़िगरेशन है, कोई बेंचमार्क नहीं, और यह बदलती रहती है। लेकिन बँटवारा सोच-समझकर किया गया है।

जहाँ काम विवेक का है, वहाँ Fable। CEO तय करता है कि किसी ओरेकल पर थम्स-डाउन असली गलती है या पसंद का मामला। फ़िक्सर तय करता है कि बग रिपोर्ट सच में बग है या किसी एक मशीन का खास सेटअप, फिर कोड में कारण ढूँढता है। SEO का चरण 1 तय करता है कि आज के कमिट से साइट का कौन-सा वाक्य गलत हो गया, कौन-सा लेख लिखना है, और किस पेज को छेड़ना नहीं है। सोशल का चरण 1 शाम का विषय चुनता है और ऐसे पाठकों के लिए लिखता है जो तीन पंक्तियों में जनरेट किया गया टेक्स्ट पहचान लेते हैं। ये प्रॉम्प्ट लंबे हैं (SEO वाला लगभग 4,000 शब्दों का है) और “आप तय करते हैं, पूछते नहीं” जैसे नियमों से भरे हैं, अपवादों की छोटी सूचियों के साथ। यहीं सबसे मज़बूत मॉडल अपनी कीमत वसूल करता है।

जहाँ काम मात्रा का है, वहाँ 1M कॉन्टेक्स्ट वाला Opus। सब-एजेंट की मदद से एक लेख का 18 भाषाओं में अनुवाद करना, हर एक के ज़िम्मे तीन लोकेल, फिर फ़्रेंच संदर्भ से मिलान की जाँच करना, यह पढ़ना और लिखना है, बहुत सारा, वही नियम 18 बार लागू करते हुए। डॉक्यूमेंटेशन प्रभारी सौ फ़ैक्ट शीट के सामने एक दिन के diff पढ़ता है। PM एग्ज़िट बातचीत का 8 MB का एक्सपोर्ट पढ़ता है। रिपोर्टर पाँच रिपोर्टें पढ़ता है और कॉपी करता है, सोचता नहीं। वहाँ विवेक से ज़्यादा बड़ा कॉन्टेक्स्ट और प्रति टोकन कम कीमत मायने रखते हैं।

इसलिए सात में से दो दो चरणों वाली एजेंट टीमें हैं, हर चरण अपने मॉडल वाला एक एजेंट। Fable पर चरण 1 साझा रिपोर्ट में “हैंडऑफ़” सेक्शन लिखकर ख़त्म होता है: उन फ़ाइलों और कुंजियों की सटीक सूची जो अनुवादक को देनी हैं, या वे सटीक पोस्ट जो प्रकाशक को प्रकाशित करनी हैं। Opus पर चरण 2 वह सेक्शन पढ़ता है और सिर्फ़ वही करता है जो उसमें लिखा है। टीम का ग्राफ़ सीधा है, एक चक्र, और रिपोर्ट अपनी “रन जारी है” पंक्ति तब तक रखती है जब तक चरण 2 उसे हटा न दे। बाहर से, 22:00 बजे, अब भी “जारी है” वाली रिपोर्ट का मतलब है या तो कटा हुआ रन या अपने दो चरणों के बीच की टीम, और रिपोर्टर बताता है कि कौन-सा।

वे चार नियम जो प्रॉम्प्ट को सीखने पड़े

पहले प्रॉम्प्ट नौकरी के विवरण थे। मौजूदा प्रॉम्प्ट ज़्यादातर नियम हैं, और हर नियम की एक तारीख है, क्योंकि हर एक किसी बिगड़ी हुई रात के बाद लिखा गया।

1. एक रन मार्कर, कल की रिपोर्ट से पढ़ा हुआ। SEO एजेंट का पहला वर्ज़न “पिछले 24 घंटे के कमिट” पढ़ता था। दो समस्याएँ: 20:00 का रन और अगले दिन 20:10 का रन एक जैसे 24 घंटे नहीं देखते, और जिस रात एजेंट नहीं चला वह कमिट का ऐसा दिन है जिसे कोई नहीं देखता। अब हर रिपोर्ट आख़िरी देखा गया कमिट: <sha> पर ख़त्म होती है, और अगला रन उसी कमिट से शुरू होता है, घड़ी चाहे जो कहे। कोई मार्कर नहीं (पहली रात, गायब रिपोर्ट): दो दिन पीछे, और रिपोर्ट यह बताती है।

2. इतिहास डिस्क पर है, इसलिए कुछ भी उठाने से पहले उस पर grep चलाएँ। पहले दो हफ़्तों में सबसे ज़्यादा लौटने वाली शिकायत: “यह आप मुझे पहले बता चुके हैं, मैंने इसे कल ठीक कर दिया”। इलाज एक नियम है जिसमें एक कमांड है: कोई विषय उठाने या कोई काम खोलने से पहले, grep -ril "<विषय>" reports/night/ और git log --since="30 days ago" -- <फ़ाइल>। मेल मिले तो पहले वह रिपोर्ट पढ़ें। तीन स्थितियाँ, और सिर्फ़ तीन, निपटाए गए विषय पर फिर से बात करने देती हैं: फ़िक्स काम नहीं किया और आपने अभी इसकी जाँच की है; फ़िक्स अधूरा है और आप बताते हैं कि क्या बाकी है; विषय का स्वरूप बदल गया है। इसके साथ दो नतीजे आए। एक रात, एक रन: अगर आज रात की रिपोर्ट मौजूद है, उसमें “दो शब्दों में” है और अब “रन जारी है” नहीं लिखा, तो एजेंट रुक जाता है। और जिस प्रस्ताव का तीन रातों तक जवाब न आए, वह रिपोर्ट से हट जाता है; टिकट बना रहता है।

3. काम शुरू होने से पहले रिपोर्ट खोली जाती है। पहले 21:30 पर कटा रन कुछ भी नहीं छोड़ता था। अब स्किल लोड करने के बाद एजेंट सबसे पहले mkdir -p reports/night/$(date +%F) करता है और रिपोर्ट का ढाँचा लिखता है, उसके चार सेक्शन शीर्षकों और रन जारी है, 20:01 पर शुरू हुआ पंक्ति के साथ। हर पूरे हुए काम के बाद वह पूरी फ़ाइल दोबारा लिखता है। कटा हुआ रन एक अधूरी रिपोर्ट छोड़ता है जिसे रिपोर्टर कॉपी कर सकता है, जो उस एजेंट से कहीं बेहतर है जो “चला ही नहीं”।

4. साथ-साथ कमिट करें, अंत में कभी नहीं। 9 सितंबर को मापा गया: दो एजेंट एक ही मिनट में रोके गए। जो हर काम के बाद कमिट कर रहा था, उसने कुछ नहीं खोया। दूसरे ने 45 बदली हुई, बिना पुश की, किसी के नाम न की जा सकने वाली फ़ाइलें छोड़ीं, जिन्हें संस्थापक ने अगली सुबह हाथ से समेटा, और उसकी रिपोर्ट मौजूद ही नहीं थी। तब से नियम है: हर पूरे हुए काम के लिए एक कमिट, फ़ाइलों के नाम एक-एक करके, रिपोर्ट के लिए एक आख़िरी कमिट, और रन के दौरान कम से कम एक पुश। कमिट एक तारीख वाला निशान भी है, और नियम 2 इसी पर grep चलाता है।

पाँचवाँ नियम याददाश्त के बारे में नहीं बल्कि हिम्मत के बारे में है, और इसी ने नतीजों को सबसे ज़्यादा बदला। SEO प्रॉम्प्ट कहता है: “आप कोई ऑडिटर नहीं हैं जो निष्कर्ष रिपोर्ट करे: रात में साइट आपकी है। जो रन मंज़ूरी के लिए छह सुझावों पर ख़त्म होता है, वह नाकाम रन है।” फिर यह वे छह स्थितियाँ गिनाता है, और सिर्फ़ छह, जिनमें एजेंट को काम करने के बजाय पूछना चाहिए: कोई URL हटाना या उसका नाम बदलना, रैंक करने वाले पेज का शीर्षक बदलना, कानूनी टेक्स्ट, कोई कीमत या कोटा, प्राइवेसी या एन्क्रिप्शन के बारे में कोई दावा, पाँच से ज़्यादा पेजों को छूने वाला बदलाव। बाकी सब वह करता है, और संस्थापक अगली सुबह जो पसंद न आए उसे हटा देता है। फ़िक्सर के पास यही नियम तीन स्थितियों के साथ है। इस नियम से पहले, रिपोर्टें सुझावों की सूचियाँ थीं। इसके बाद, वे कमिट की सूचियाँ हैं।

प्रॉम्प्ट

मूल प्रॉम्प्ट फ़्रेंच में और लंबे हैं। आगे वह हिस्सा है जो कहीं भी काम आ सकता है, हमारे प्रोजेक्ट के खास पाथ और नाम हटाकर। तीन ब्लॉक: हर एजेंट के लोड किए जाने वाले साझा नियम, रिपोर्टर, और “तय करें, पूछें नहीं” वाले दो सेक्शन।

ब्लॉक 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 न करें, अपनी रिपोर्ट में सबसे ऊपर यह बताएँ।
आपका रन मार्कर: कल की रिपोर्ट के अंत में “आख़िरी देखा गया कमिट: <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 को उठाया गया”)।
चौथी से: वह “तय करना है” से हट जाती है। टिकट बना रहता है; “विवरण” में ज़्यादा से ज़्यादा एक पंक्ति।
अगर फ़ैसला आपके दायरे में है, तो तीसरी रात तय करें और यह बताएँ।

## साथ-साथ कमिट और पुश करें
पहला काम पूरा और जाँचा जाते ही पहला कमिट। फिर हर काम के लिए एक।
आख़िरी कमिट आपकी रिपोर्ट के लिए। रन के दौरान कम से कम एक बार और अंत में एक बार पुश करें।
पुश ठुकराया गया (रिमोट आगे बढ़ गया): git pull --ff-only, फिर push। फिर भी ठुकराया गया: फ़ोर्स न करें,
rebase न करें, रिपोर्ट में लिखें।

## आपकी रिपोर्ट: शुरू में खोली जाती है, सिर्फ़ अंत में कभी नहीं लिखी जाती
reports/night/<YYYY-MM-DD>/<आप>.md, काम से पहले बनाई गई, इसके साथ:
  # <एजेंट> - <तारीख>
  _रन जारी है - <HH:MM> पर शुरू हुआ_   (अंत में हटाई जाती है)
  ## दो शब्दों में      (3 से 5 पंक्तियाँ, या एक बुलेट सूची: हर किए गए काम के लिए एक बुलेट)
  ## तय करना है         (सिर्फ़ वह जो आपका प्रॉम्प्ट इंसान के लिए रखता है; वरना “कुछ नहीं”)
  ## जाँचना है          (- [ ] क्या : कहाँ : क्या दिखना चाहिए; वरना “कुछ नहीं”)
  ## विवरण              (जितना लंबा ज़रूरी हो: सबूत, फ़ाइलें, कमांड)
  ## रन मार्कर
  आख़िरी देखा गया कमिट: <आपके आख़िरी कमिट के बाद git rev-parse HEAD>
हर पूरे हुए काम के बाद पूरी फ़ाइल दोबारा लिखें।
पाठक फ़ोन पर है, दो मिनट के लिए: छोटे वाक्य, कोई फ़ाइल पाथ नहीं,
पहले सेक्शन में कोई SHA नहीं, किसी फ़ंक्शन का नाम नहीं। कोई आँकड़ा तभी जब वह किसी फ़ैसले को बदले।

ब्लॉक 2: रिपोर्टर (22:00)

आप रिपोर्टर हैं। आप बाकी सब के दो घंटे बाद चलते हैं।
आपका एकमात्र काम: उन्होंने जो छोड़ा उसे पढ़ना और सिर्फ़ एक ईमेल भेजना जिसे संस्थापक
फ़ोन पर एक मिनट में पढ़े, और बिना कुछ और खोले समझ जाए।
आप कुछ भी विश्लेषण नहीं करते, कुछ ठीक नहीं करते, कुछ प्रस्तावित नहीं करते। आप इकट्ठा करते हैं और साफ़ करते हैं।

जिस रात की आप रिपोर्ट करते हैं, वह डिस्क से पढ़ी जाती है, घड़ी से नहीं:
DAY=$(ls -1 reports/night | sort | tail -1)

1. git fetch; वर्किंग ट्री साफ़ हो तो git pull --ff-only: रिपोर्टें कमिट की हुई हैं।
2. ls reports/night/$DAY: पाँच फ़ाइलों (ceo, seo, pm, fixer, social) का इंतज़ार करें।
   कुछ गायब: sleep 9 मिनट और दोबारा गिनें, ज़्यादा से ज़्यादा 6 बार। फिर भी भेज दें, यह बताते हुए कि कौन गायब है।
3. जो रिपोर्ट अब भी “रन जारी है” कहती है, वह कटा हुआ रन है, गैरहाज़िर नहीं।
   उसमें जो है उसे कॉपी करें और “जो काम नहीं किया” में लिखें कि यह एजेंट कट गया था।
4. हर रिपोर्ट से सिर्फ़ तीन सेक्शन लें: “दो शब्दों में”, “तय करना है”, “जाँचना है”।
   “विवरण” को कभी उद्धृत न करें।
5. फ़िक्सर के ठीक किए बग तीन हिस्सों वाले बुलेट हैं, जिन्हें “ > ” अलग करता है:
   यूज़र ने क्या झेला > एक वाक्य में कारण > कमिट URL।
   उन्हें अक्षरशः, लिंक समेत, “ठीक किए गए बग” में कॉपी करें।
6. git status -sb और git log --oneline --since="4 hours ago": ऐसी रिपोर्ट जो बिना कमिट के काम का दावा करे,
   बदली हुई फ़ाइलें जिन पर कोई दावा न करे, या बिना पुश के कमिट: ईमेल की पहली पंक्ति।

reports/night/$DAY/rapport.md लिखें। ज़्यादा से ज़्यादा 25 पंक्तियाँ टेक्स्ट
(सेक्शन शीर्षक और “ठीक किए गए बग” की पंक्तियाँ नहीं गिनी जातीं)।
छह नियम, पंक्ति दर पंक्ति लागू:
1. एक बुलेट = एक पूरा वाक्य जो अपने आप में समझ आए। कभी “जैसा कल बताया गया” नहीं।
2. कोई विषय सिर्फ़ एक सेक्शन में आता है।
3. शून्य तकनीकी शब्दजाल: कोई पाथ नहीं, कोई SHA नहीं, किसी कुंजी का नाम नहीं, कोई आंतरिक संक्षिप्त रूप नहीं।
   एक अपवाद: कमिट का पूरा GitHub URL, “ठीक किए गए बग” की हर पंक्ति पर ज़रूरी।
4. कोई आँकड़ा तभी जब वह किसी फ़ैसले को बदले, और वह बदलाव हो, कुल संख्या कभी नहीं।
5. हर बुलेट में ज़्यादा से ज़्यादा दो पंक्तियाँ। विवरण एजेंट की रिपोर्ट में है।
6. अच्छी ख़बर से पहले बुरी ख़बर, और पहली पंक्ति बताती है कि कुछ टूटा है या नहीं।

सेक्शन, इसी क्रम में: तय करना है / जाँचना है / ठीक किए गए बग / क्या किया गया /
सोशल नेटवर्क (ज़्यादा से ज़्यादा 3 पंक्तियाँ, लिंक समेत) / CLI और मॉडल (1 पंक्ति) /
जो काम नहीं किया। खाली सेक्शन एक शब्द है: “कुछ नहीं”।
कभी न काटें: “तय करना है”, लिंक समेत “ठीक किए गए बग”, पोस्ट के लिंक, SEO लेख।
भेजें। HTTP कोड जाँचें। सबसे नीचे “... को भेजा गया - HTTP <code>” जोड़ें।
rapport.md को कमिट और पुश करें। कभी दो बार न भेजें: अगर आज की rapport.md में पहले से
“को भेजा गया” वाली पंक्ति है, तो रुक जाएँ।

ब्लॉक 3: “तय करें, पूछें नहीं” वाले सेक्शन

SEO एजेंट, उसके प्रॉम्प्ट का सेक्शन 0:

# 0. आप तय करते हैं, पूछते नहीं
यह इस प्रॉम्प्ट का सबसे अहम नियम है और यह आपकी सावधानी की आदत से ऊपर है।
आप कोई ऑडिटर नहीं हैं जो निष्कर्ष रिपोर्ट करे: रात में साइट आपकी है।
जो रन “ये रहे 6 सुझाव, मंज़ूरी के लिए” पर ख़त्म होता है, वह नाकाम रन है।
जब आप हिचकिचाएँ, खुद को संस्थापक की जगह रखें और चार संदर्भों से तय करें:
- प्रोडक्ट असल में क्या करता है, रिपॉज़िटरी और प्रकाशित वर्ज़न में पढ़कर, मौजूदा कॉपी में कभी नहीं;
- साइट पहले से क्या कहती है: उसका नज़रिया, उसका लहजा, उसके वादे। आप आगे बढ़ाते हैं, नए सिरे से नहीं गढ़ते;
- Search Console क्या कहता है: कौन-से पेज ज़िंदा हैं, कौन-से इरादे सच में मौजूद हैं;
- पाठक: Google पर खोजने वाले डेवलपर, और टूल सुझाने वाले AI असिस्टेंट।
  उनके लिए क्या मायने रखता है: जाँचा जा सकने वाला, तारीख वाला दावा; ऐसा पेज जो एक सटीक सवाल का जवाब दे;
  पेजों से मेल खाता अप-टू-डेट llms.txt; ईमानदार तुलनाएँ।
संस्थापक अगली सुबह आपकी रिपोर्ट पढ़ता है और जो उसे पसंद न आए उसे हटाने को कहेगा।
एक ज़्यादा सुधार की कीमत पाँच मिनट है; बिना नतीजे की रात हमेशा के लिए गई।

आप उसकी राय सिर्फ़ इन छह स्थितियों में पूछते हैं:
1. किसी मौजूदा URL को हटाना या उसका नाम बदलना;
2. रैंक करने वाले पेज का शीर्षक या मेटा डिस्क्रिप्शन बदलना, जब वह गलत न हो;
3. कानूनी टेक्स्ट (शर्तें, प्राइवेसी, लाइसेंस);
4. कोई कीमत, कोई व्यावसायिक कोटा, कोई ऑफ़र;
5. प्राइवेसी, एन्क्रिप्शन या डेटा कहाँ चलता है, इसके बारे में कोई दावा;
6. ऐसा बदलाव जो एक साथ पाँच से ज़्यादा पेजों को छुए।
इन छह स्थितियों में: फ़ैसले के लिए टैग किया गया टिकट, “तय करना है” में एक पंक्ति, और आप आगे बढ़ते हैं।
बाकी सब आप आज रात करते हैं। अगर “तय करना है” में कुछ और है,
तो आपने वह फ़ैसला किसी और पर डाल दिया जो आपका था।

फ़िक्सर, उसके प्रॉम्प्ट का सेक्शन 0:

# 0. आप ठीक करते हैं, वर्गीकरण नहीं करते
यूज़र का रिपोर्ट किया गया बग एक वादा है। किसी ने लिखने का समय निकाला, वह इंतज़ार कर रहा है,
और आज रात कोई और इसे नहीं संभालेगा। जो रन “5 बग का विश्लेषण, 1 ठीक,
4 दर्ज” लौटाता है, वह नाकाम रन है। आपका लक्ष्य खाली कतार है: पहले यूज़र्स के बग,
सबसे पुराने पहले, फिर बाकी, जब तक कोई न बचे।
जब किसी फ़िक्स पर हिचकिचाएँ, तीन संदर्भों से तय करें:
- कोड आज क्या करता है, पढ़कर, अंदाज़े से नहीं;
- रिपोर्ट लिखते समय यूज़र ने ज़ाहिर तौर पर क्या उम्मीद की थी;
- सबसे कम जोखिम: सबसे संकरा फ़िक्स जो कारण को सुलझाए, सबसे सुंदर नहीं।
विवाद वाला फ़िक्स पलटने में पाँच मिनट लगते हैं; एक महीना और छोड़ा गया बग एक यूज़र की कीमत लेता है।

आप किसी रिपोर्ट किए गए बग को बिना फ़िक्स के सिर्फ़ तीन स्थितियों में छोड़ सकते हैं, टिकट में साबित करके:
1. असली जाँच के बाद भी आपको कारण नहीं मिला: लिखें कि आपने क्या-क्या खारिज किया,
   सिर्फ़ “दोहराया नहीं जा सका” नहीं;
2. यह बग नहीं, फ़ैसला है: डेटाबेस, बिलिंग, ऑथ, एन्क्रिप्शन, प्राइवेसी,
   इंडेक्स हुआ URL, डिफ़ॉल्ट व्यवहार। फ़ैसले के लिए टिकट, आपकी सिफ़ारिश के साथ;
3. कोई गेट आपका फ़िक्स ठुकराता है और आप उसे ठीक नहीं कर पाते।
“यह बड़ा है”, “यह कई फ़ाइलों को छूता है”, “मैं पूछना पसंद करूँगा” कारण नहीं हैं।
एक बग = एक कमिट। फिर टिकट पूर्ण में जाता है, और अगर किसी यूज़र ने उसे रिपोर्ट किया था,
तो अगली रिलीज़ के लिए दो वाक्यों का संदेश कतार में लगता है। कभी “रुका हुआ” नहीं: वह कॉलम
इंसानों का है।
हर ठीक किए गए बग के लिए आपकी रिपोर्ट पंक्ति, सुबह के ईमेल में जस की तस कॉपी की जाती है:
- <यूज़र ने क्या झेला> > <कारण, एक सरल वाक्य> > <कमिट URL>

बाकी चार प्रॉम्प्ट (CEO, PM, डॉक्यूमेंटेशन प्रभारी, SEO चरण 2) इसी ढाँचे पर चलते हैं: स्किल लोड करें, वे फ़ाइलें बताएँ जो आप लिख सकते हैं, रीडिंग क्रम से गिनाएँ, बताएँ कि टिकट में क्या जाता है और रिपोर्ट में क्या, रन मार्कर पर ख़त्म करें।

जो काम नहीं किया, और अब भी नहीं करता

कुछ रातें ईमेल के “जो काम नहीं किया” सेक्शन में हैं, और उन्हें गिनाना फ़ायदेमंद है क्योंकि आप भी इन्हीं से टकराएँगे।

• पाँच एजेंट एक ही मिनट में एक ही ब्रांच पर पुश करते हुए। रिमोट आगे बढ़ जाने से पुश ठुकरा दिया जाता है। नियम है git pull --ff-only फिर पुश, फ़ोर्स कभी नहीं, और अगर यह दो बार नाकाम हो तो रिपोर्ट यह बताती है और इंसान सुबह पुश करता है। ऐसा लगभग हफ़्ते में एक बार होता है।
• एक कमिट जो दूसरे एजेंट की staged फ़ाइल बहा ले गया। 29 सितंबर को SEO के पहले कमिट में एक डिलीशन चला गया जिसे डॉक्यूमेंटेशन प्रभारी ने साझा checkout में stage किया था। कुछ नहीं खोया (डिलीशन जानबूझकर था), लेकिन कमिट गलत एजेंट के नाम है। तब से हर कमिट साफ़ pathspec इस्तेमाल करता है, और “फ़ाइलों के नाम एक-एक करके” वाला नियम शैली की पसंद नहीं है।
• एक डिस्क जिसमें 20:10 पर ख़ाली जगह शून्य बाइट रह गई, लगातार दो शाम। एजेंट से बाहर की वजह, 20:25 पर अपने आप ठीक, कोई फ़ाइल नहीं खोई। लेकिन रिपोर्टें यह बताती हैं, क्योंकि भरी डिस्क वाली रात ठीक वैसी ही दिखती है जैसी वह रात जिसमें किसी एजेंट ने कुछ नहीं किया।
• रिपोर्टर का ऐसी रिपोर्ट के लिए 54 मिनट इंतज़ार जो आने वाली नहीं। नौ मिनट के छह चक्कर ऊपरी सीमा है। 22:00 बजे अपने दो चरणों के बीच की टीम कटे हुए रन जैसी दिखती है, और ईमेल कहता है “पूरा नहीं हुआ था”, जो ईमानदार है और पढ़ने में थोड़ा घबराहट वाला।
• दोहराए गए निष्कर्षों वाले शुरुआती हफ़्ते। ऊपर का नियम 2 तब तक मौजूद नहीं था जब तक संस्थापक ने चौथी बार “यह आप मुझे तीन दिन पहले बता चुके हैं” नहीं लिखा।

इसे खुद कैसे सेट करें

आपको सात एजेंट की ज़रूरत नहीं है। आपको एक ऐसे एजेंट की ज़रूरत है जो ऐसी रिपोर्ट लिखे जिसे आप पढ़ेंगे, और रिपोर्टर तीसरे एजेंट से ही काम का होता है। AgentsRoom में:

1. प्रॉम्प्ट लाइब्रेरी में प्रॉम्प्ट लिखें। ऊपर के ब्लॉक 1 से स्किल के रूप में शुरुआत करें, और एक छोटा प्रॉम्प्ट जो बताए कि इस एजेंट का ज़िम्मा क्या है और वह कौन-सी फ़ाइलें लिख सकता है।
2. प्रोजेक्ट पर एक Scheduled Task बनाएँ: आपके चाहे समय पर रोज़, एजेंट का रोल, CLI और मॉडल, प्रॉम्प्ट, और एडवांस्ड ब्लॉक में बिना निगरानी वाले रन के लिए परमिशन मोड। इसे उस मशीन पर पिन करें जो इसे चलाएगी, और अगर वह मशीन सोती है तो “मशीन जगाएँ” चालू करें।
3. रिपॉज़िटरी में reports/night/ फ़ोल्डर बनाएँ और उसे कमिट करें। पूरी तालमेल परत बस यही है।
4. दूसरा एजेंट उस दिन जोड़ें जिस दिन पहला किसी और के लिए टिकट बनाने लगे: ceo-fix टैग का मतलब तभी है जब अगली रात कोई फ़िक्सर उसे पढ़े।
5. जब एक काम विवेक और मात्रा में बँट जाए, तो उसे दो मॉडलों वाली दो चरणों की टीम बनाएँ, और चरण 1 से एक हैंडऑफ़ सेक्शन लिखवाएँ जिसे चरण 2 पढ़े।

Scheduled Tasks पेज फ़ील्ड बताता है, और कोडिंग एजेंट को नाइट शिफ्ट पर लगाने वाला लेख वह सोच है जो इस टीम से पहले आई। अगर आपके एजेंट एक मशीन साझा करते हैं, तो पहले पढ़ें जब उनमें से दस एक ही कमांड चलाते हैं तो क्या होता है: यह यहाँ, रात में, हुआ था, और इलाज एक छोटा साझा लॉक है।

Rob, कोडिंग से आगे हम यही करते हैं। प्रॉम्प्ट ही प्रोडक्ट हैं।

अक्सर पूछे जाने वाले सवाल

क्या इस तरह शेड्यूल पर एजेंट चलाने के लिए AgentsRoom ज़रूरी है?

नहीं। एक cron लाइन और claude -p किसी भी मशीन पर 20:00 बजे एक Claude Code सेशन शुरू कर देंगे। इसके बाद बाकी सब आपको खुद लिखना पड़ता है: सोते हुए कंप्यूटर को जगाना, मशीन से छूटा हुआ रन बाद में पूरा करना, प्रोजेक्ट दो कंप्यूटरों पर खुला हो तब भी हर रात एक ही रन रखना, एक एजेंट की रिपोर्ट दूसरे मॉडल पर चल रहे दूसरे एजेंट तक पहुँचाना, और अपने फ़ोन पर देखना कि रन किसी सवाल पर अटका है। AgentsRoom के Scheduled Tasks ये सारे हिस्से संभालते हैं, और इस लेख के सातों एजेंट इनमें से हर एक का इस्तेमाल करते हैं। प्रॉम्प्ट और नियम जैसे हैं वैसे ही काम आते हैं, सेशन चाहे कोई भी शुरू करे।

सात एजेंट की एक रात का खर्च कितना है?

वे Claude सदस्यता पर Claude Code सेशन के रूप में चलते हैं, AgentsRoom में शुरू किए गए किसी भी एजेंट की तरह, इसलिए उनके लिए प्रति-टोकन का कोई बिल नहीं आता, और हमने प्रति रात का कोई खर्च प्रकाशित नहीं किया है। जो नियम इसे सीमा में रखता है वह “एक रात, एक रन” वाला पहरा है: दो बार सक्रिय होने वाला ट्रिगर, या बीच में कटकर दोबारा शुरू हुआ रन, काम को दोहराता नहीं, क्योंकि हर एजेंट सबसे पहले यही जाँचता है कि आज रात की रिपोर्ट पहले से मौजूद और बंद है या नहीं।

क्या एजेंट को बिना किसी की निगरानी के कमिट और पुश करने देना सुरक्षित है?

यह सुरक्षित है उन चीज़ों की वजह से जिनकी उन्हें इजाज़त नहीं है, न कि उन चीज़ों की वजह से जिन्हें चाहने के लिए उनसे कहा गया है। साझा नियम git add -A, commit -a, फ़ोर्स पुश, stash, reset, checkout, clean, नई ब्रांच बनाना और डिप्लॉय करने वाली कोई भी स्क्रिप्ट मना करते हैं। हर कमिट अपनी फ़ाइलों के नाम एक-एक करके लेता है, हर लिखने से पहले git status से वर्किंग ट्री जाँचा जाता है, और रिमोट आगे बढ़ जाने की वजह से ठुकराया गया पुश fast-forward pull से सुलझाया जाता है या इंसान पर छोड़ दिया जाता है। सुबह की समीक्षा रात के कमिट की सूची है, और कुछ भी गलत हो तो पाँच मिनट का revert है।

एजेंट डैशबोर्ड के बजाय रिपॉज़िटरी में Markdown रिपोर्ट क्यों लिखते हैं?

क्योंकि रिपोर्ट ही याददाश्त भी है। हर एजेंट पिछली रात की अपनी रिपोर्ट पढ़कर शुरू करता है, वहाँ अपना रन मार्कर (आख़िरी कमिट जो उसने देखा) पाता है, और कुछ भी उठाने से पहले पूरे रिपोर्ट फ़ोल्डर पर grep चलाता है, ताकि पिछले हफ़्ते निपटाया गया विषय फिर से न उठे। डैशबोर्ड वही आँकड़े दिखाता और कुछ भी याद नहीं रखता। रिपोर्ट को कमिट करने से उस पर तारीख भी लग जाती है, और इसी से अगली रात ठीक-ठीक जान पाती है कि पिछली रात ने क्या छुआ।

सात में से दो एजेंट दो अलग मॉडलों पर दो चरणों वाली टीमें क्यों हैं?

क्योंकि काम के दोनों आधे हिस्से एक जैसे काम नहीं हैं। SEO का वह चरण जो Search Console पढ़ता है, तय करता है कि साइट पर क्या गलत है और लेख अंग्रेज़ी और फ़्रेंच में लिखता है, उसे विवेक चाहिए, और वह Fable पर चलता है। उस लेख का 18 और भाषाओं में अनुवाद करना, i18n गेट और बिल्ड चलाना मात्रा का काम है, और वह 1M कॉन्टेक्स्ट वाले Opus पर चलता है। पहला चरण साझा रिपोर्ट में एक साफ़ हैंडऑफ़ सेक्शन लिखता है, दूसरा चरण सिर्फ़ वही करता है जो उस सेक्शन में लिखा है। सोशल टीम का बँटवारा भी यही है: लिखना और विज़ुअल Fable पर, Chrome में प्रकाशित करना और लोगों को धन्यवाद देना Opus पर।

जब कोई रन बीच में कट जाए तो क्या होता है?

रिपोर्ट रन के पहले मिनट से मौजूद रहती है, “रन जारी है” कहने वाली एक पंक्ति के साथ, और हर पूरा हुआ काम उसी समय कमिट हो जाता है। इसलिए 21:40 पर कटा रन एक अधूरी रिपोर्ट, अपने कमिट, और शून्य untracked फ़ाइलें छोड़ता है। रिपोर्टर अधूरी रिपोर्ट कॉपी करता है और लिखता है कि एजेंट कट गया था। हमने यह 9 सितंबर को मुश्किल से सीखा: दो एजेंट एक ही मिनट में रुक गए, जो साथ-साथ कमिट करता जा रहा था उसने कुछ नहीं खोया, दूसरे ने 45 बदली हुई फ़ाइलें छोड़ीं जिन्हें कोई किसी के नाम नहीं कर सका।