Claude Code शेड्यूल: Cloud, Desktop या /loop

पहले तय करें कि डेटा कहाँ है और कंप्यूटर बंद होने पर भी काम चलना चाहिए या नहीं। स्थानीय फ़ाइल के लिए अपनी मशीन की पहुँच चाहिए। लैपटॉप के बिना रिपॉज़िटरी जाँचने के लिए अलग क्लाउड वातावरण चाहिए। मौजूदा काम के दौरान थोड़ी देर निगरानी के लिए /loop पर्याप्त हो सकता है।

शेड्यूल सहेजना इस बात का प्रमाण नहीं कि फ़ाइलें उपलब्ध हैं, काम चला या जाँचने योग्य परिणाम मिला।

कहाँ चलाना है

शर्त	Cloud routine	Desktop Local task	session का /loop
वातावरण	क्लाउड	आपका कंप्यूटर	सक्रिय Claude Code session
कंप्यूटर बंद हो सकता है	हाँ	नहीं	नहीं
स्थानीय फ़ाइलें	क्लाउड में उपलब्ध करानी होंगी	उपयुक्त	उपयुक्त
दोबारा शुरू करने पर	शेड्यूल रहता है	शेड्यूल रहता है	योग्य अधूरे और न समाप्त हुए काम resume पर लौटते हैं

सामान्य Cloud रन चुनी गई रिपॉज़िटरी का clone इस्तेमाल करता है, आपकी मौजूदा स्थानीय directory नहीं। Desktop स्थानीय फ़ाइलें पढ़ता है, लेकिन ऐप खुला और कंप्यूटर जागा होना चाहिए। शर्तें और directory चयन Desktop दस्तावेज़ में हैं।

पहले एक मैनुअल रन जाँचें

छोटे टेस्ट प्रोजेक्ट में secrets रहित README.md रखें और पहले उसकी प्रति सहेजें। Cloud के लिए फ़ाइल चुनी गई टेस्ट रिपॉज़िटरी में commit करें। एक ही prompt इस्तेमाल करें:

चुने गए प्रोजेक्ट में केवल README.md खोलें।
पहली गैर-खाली पंक्ति और "## " से शुरू होने वाले दूसरे स्तर के शीर्षकों की संख्या लौटाएँ।
फ़ाइल नहीं है तो बताएँ।
फ़ाइलें न बदलें, shell commands न चलाएँ और संदेश न भेजें।
जवाब SCHEDULE_CHECK से शुरू करें।

पंक्ति और संख्या खुद जाँचें तथा सुनिश्चित करें कि फ़ाइलें नहीं बदलीं। इससे इनपुट पहुँच और निर्देश की स्पष्टता जाँची जाती है। Prompt की सीमाएँ इरादा बताती हैं; वास्तविक क्षमता वातावरण और टूल अनुमतियों से तय होती है।

फ़ाइल न पढ़ सके तो शेड्यूल समस्या नहीं सुधारेगा। पहले प्रोजेक्ट, पहुँच और path जाँचें।

छोटी निगरानी के लिए स्पष्ट /loop

मौजूदा CLI session में अंतराल और पूरा prompt दें:

/loop 5m केवल README.md पढ़ें। SCHEDULE_CHECK और पहली गैर-खाली पंक्ति लौटाएँ। फ़ाइलें न बदलें, commands न चलाएँ और संदेश न भेजें।

पुष्ट अंतराल और task ID लिखें। एक स्वचालित जवाब की प्रतीक्षा करें, फिर Claude से सूची माँगें और उसी ID को रद्द कराएँ। दोबारा सूची लेकर पुष्टि करें।

यह सटीक टाइमर नहीं है: समय में थोड़ा बदलाव होता है और व्यस्त session देर से चलता है। दोहराए जाने वाले काम सात दिन में समाप्त होते हैं। नई बातचीत इन्हें नहीं लेती; --resume या --continue केवल योग्य, न समाप्त हुए काम बहाल करते हैं। विवरण /loop गाइड में है।

हमेशा टेस्ट prompt दें। खाली /loop README प्रयोग के बजाय मौजूदा काम की अंतर्निहित रखरखाव प्रक्रिया शुरू कर सकता है।

स्थानीय फ़ाइलों के लिए Desktop

Routines में Local task बनाएँ, टेस्ट directory चुनें और वही prompt डालें। पहले Run now से परिणाम और अनुमति अनुरोध देखें। फिर शेड्यूल चालू करके history में अलग स्वचालित रन जाँचें।

स्लीप से जागने पर Desktop एक छूटा रन पूरा कर सकता है: पिछले सात दिनों में अंतिम छूटा समय गिना जाता है, हर छूटी बार नहीं। देर से चलने वाले काम के लिए डेटा सीमा स्पष्ट करें। दैनिक जाँच एक निश्चित तारीख के बदलाव पढ़ सकती है, वास्तविक रन समय को नए रिपोर्ट-दिन की शुरुआत मानने के बजाय।

प्रयोग के बाद Paused करें। History में मैनुअल, स्वचालित, छूटे और अनुमति की प्रतीक्षा वाले रन अलग पहचानें। Run now अकेले शेड्यूल का प्रमाण नहीं है।

लैपटॉप के बिना Cloud

खाते में Cloud routine उपलब्ध हो तो Routines से बनाएँ, टेस्ट रिपॉज़िटरी और वातावरण चुनें, केवल आवश्यक connectors जोड़ें और prompt व शेड्यूल सेट करें। Run now के बाद अलग निर्धारित session जाँचें।

Cloud routine स्वायत्त चलती है; रन के बीच सामान्य अनुमति अनुरोध नहीं होते। रिपॉज़िटरी, नेटवर्क, वातावरण के variables और connectors पहुँच तय करते हैं। पहली README जाँच को काम के ईमेल या प्रकाशन की पहुँच नहीं चाहिए। Routines गाइड देखें।

जाँच के बाद दोहराव बंद करें। ID, अपेक्षित और वास्तविक समय, परिणाम लिंक और छूटने का कारण रखें। फिर असली काम का prompt लगाकर इनपुट, अनुमतियाँ और परिणाम दोबारा जाँचें। Cloud या Desktop जगह चुनता है; काम की गुणवत्ता अलग जाँचनी होती है।