Claude Code के साथ लूप्स (Loops) कैसे बनाएं

ज़्यादातर Claude वर्कफ़्लो अभी भी एक-शॉट हैं।

आप एक प्रॉम्प्ट लिखते हैं। Claude जवाब देता है। सत्र समाप्त होता है। कल आप शून्य से शुरू करते हैं।

एक बार के कामों के लिए यह ठीक है।

लेकिन दोहराए जाने वाले कामों के लिए — दैनिक समीक्षा, CI ट्राइएज, प्रोजेक्ट मॉनिटरिंग, मीटिंग फ़ॉलो-अप — आप हर दिन एक ही संदर्भ को फिर से बना रहे हैं।

यह कोई वर्कफ़्लो नहीं है। यह AI के छिड़काव के साथ मैनुअल श्रम है।

बेहतर अमूर्तता एक लूप है।

इसे सेव करें। आप इसका उपयोग करेंगे।

Claude लूप वास्तव में क्या है

लूप का मतलब "बस Claude से फिर से पूछना" नहीं है।

लूप मॉडल के चारों ओर एक दोहराई जाने वाली वर्कफ़्लो संरचना है।

यह परिभाषित करता है:

→ रन को क्या ट्रिगर करता है

→ कार्य करने से पहले Claude कौन सा संदर्भ पढ़ता है

→ Claude को क्या करने की अनुमति है → आउटपुट को कैसे सत्यापित किया जाता है

→ स्थिति कहाँ संग्रहीत की जाती है

→ कब रुकना है, दोहराना है, या मानव समीक्षा के लिए पूछना है

मॉडल अभी भी तर्क करता है।

लूप संचालन संरचना प्रदान करता है।

यह बदलाव मायने रखता है क्योंकि Claude सत्र अस्थायी होते हैं।

लूप के बिना, हर रन शून्य से शुरू होता है। लूप के साथ, Claude पढ़ता है कि पहले क्या हुआ था और वहीं से जारी रहता है।

6 भाग जो हर Claude लूप को चाहिए

संरचना के बिना एक लूप सिर्फ एक प्रॉम्प्ट है जो दो बार चलता है।

यहाँ 6 भाग हैं जो एक लूप को वास्तव में काम करने योग्य बनाते हैं:

→ 1. ट्रिगर

रन क्या शुरू करता है।

मैनुअल कमांड। शेड्यूल किया गया टाइमर। फ़ाइल परिवर्तन। CI विफलता। Git इवेंट।

→ 2. संदर्भ

कार्य करने से पहले Claude क्या पढ़ता है।

कार्य परिभाषा। पिछली प्रगति। प्रोजेक्ट फ़ाइलें। निर्देश।

→ 3. कार्रवाई

Claude क्या करता है।

रिपोर्ट लिखना। फ़िक्स का मसौदा तैयार करना। विफलताओं को वर्गीकृत करना। दस्तावेज़ अपडेट करना।

→ 4. सत्यापन

आप परिणाम कैसे जाँचते हैं।

चेकलिस्ट। टेस्ट सूट। आवश्यक अनुभाग। सुरक्षा सीमा जाँच।

→ 5. स्थिति अपडेट

अगली बार के लिए क्या याद रखा जाता है।

PROGRESS.md अपडेट किया गया। ब्लॉकर्स रिकॉर्ड किए गए। अगला रन निर्देशित किया गया।

→ 6. निर्णय

रुकें। दोहराएँ। या मानव को बढ़ाएँ।

यह पूरा लूप है।

और हर कदम मायने रखता है।

सत्यापन छोड़ें → लूप आँख बंद करके खुद पर भरोसा करता है।

स्थिति छोड़ें → हर रन शून्य से शुरू होता है।

निर्णय छोड़ें → लूप कभी नहीं जानता कि कब रुकना है।

4-फ़ाइल सिस्टम जो लूप को काम करने योग्य बनाता है

आपको बुनियादी ढाँचे की आवश्यकता नहीं है।

आपको 4 फ़ाइलें और एक फ़ोल्डर चाहिए।

1my-loop/
2├── TASK.md
3├── LOOP_INSTRUCTIONS.md
4├── PROGRESS.md
5└── outputs/
6    └── daily-review.md

TASK.md — लक्ष्य। यह लूप क्या हासिल करने की कोशिश कर रहा है।

LOOP_INSTRUCTIONS.md — संचालन प्रक्रिया। Claude को कैसे चलना चाहिए, उसे क्या करने की अनुमति है, कैसे सत्यापित करना है।

PROGRESS.md — मेमोरी। पिछली बार क्या हुआ, क्या अवरुद्ध है, अगले रन को किस पर ध्यान देना चाहिए।

outputs/ — जहाँ Claude परिणाम लिखता है। अनुमानित। निरीक्षण योग्य। सुरक्षित।

बस इतना ही।

Claude हर रन की शुरुआत में इन फ़ाइलों को पढ़ता है। अंत में उन्हें अपडेट करता है। अगला रन वहीं से जारी रहता है जहाँ पिछला रुका था।

यही बात लूप को बार-बार दिए जाने वाले प्रॉम्प्ट से अलग बनाती है।

स्थिति चैट के बाहर रहती है।

TASK.md — लक्ष्य स्पष्ट रूप से परिभाषित करें

यह फ़ाइल Claude को बताती है कि लूप किस लिए है।

इसे उच्च-स्तरीय रखें। संचालन विवरण यहाँ न डालें। वे LOOP_INSTRUCTIONS.md में जाते हैं।

इस टेम्पलेट को कॉपी करें:

1# दैनिक प्रोजेक्ट समीक्षा लूप
2
3## लक्ष्य
4इस प्रोजेक्ट फ़ोल्डर की समीक्षा करें, सारांशित करें कि क्या बदला,
5अवरोधकों की पहचान करें, और एक संक्षिप्त दैनिक समीक्षा रिपोर्ट तैयार करें।
6
7## अपेक्षित आउटपुट
8प्रत्येक रन को निम्नलिखित तैयार या अपडेट करना चाहिए:
9- `outputs/daily-review.md`
10- `PROGRESS.md`
11
12## दायरा
13Claude इस कार्यक्षेत्र में फ़ाइलों का निरीक्षण कर सकता है और
14`outputs/` फ़ोल्डर में रिपोर्ट लिख सकता है।
15
16Claude को नहीं करना चाहिए:
17- स्रोत फ़ाइलों को संशोधित करना
18- फ़ाइलों को हटाना या नाम बदलना
19- संदेश भेजना या टिकट खोलना

अंतिम अनुभाग पर ध्यान दें।

किसी भी लूप के पहले संस्करण में स्पष्ट "न करें" नियम होने चाहिए।

ऐसा नहीं है कि Claude पर भरोसा नहीं किया जा सकता।

यह आपका एक अच्छा इंजीनियर होना है।

PROGRESS.md — लूप की मेमोरी

यह सिस्टम की सबसे महत्वपूर्ण फ़ाइल है।

इसके बिना, हर रन शुरू से शुरू होता है। इसके साथ, Claude जानता है कि क्या हुआ और वहीं से जारी रहता है।

वह संरचना जो वास्तव में काम करती है:

1# लूप प्रगति
2
3## वर्तमान स्थिति
4- स्थिति: सक्रिय
5- मुख्य उद्देश्य: दैनिक प्रोजेक्ट समीक्षा
6- वर्तमान फोकस: [अभी क्या मायने रखता है]
7- अंतिम अपडेट: [तारीख]
8
9## पिछला रन
10- तारीख:
11- सारांश:
12- समीक्षित फ़ाइलें:
13- तैयार आउटपुट:
14
15## खुले आइटम
16-
17
18## अवरोधक
19-
20
21## मानव समीक्षा की आवश्यकता है
22-
23
24## अगले रन को चाहिए
25-
26
27## लिए गए निर्णय
28-
29
30## दोहराएँ नहीं
31-

"दोहराएँ नहीं" अनुभाग महत्वपूर्ण है।

यह Claude को उन चीज़ों को फिर से आज़माने से रोकता है जो पहले ही विफल हो चुकी हैं।

"मानव समीक्षा की आवश्यकता है" अनुभाग महत्वपूर्ण है।

यह लूप को चुपचाप जारी रहने से रोकता है जब उसे नहीं रहना चाहिए।

PROGRESS.md को उपयोगी बनाए रखने के लिए दो नियम:

→ यदि Claude को अगली कार्रवाई तय करने के लिए इसकी आवश्यकता है → इसे PROGRESS.md में रखें → यदि आप सिर्फ एक रिकॉर्ड चाहते हैं → इसे outputs/history/ में ले जाएँ

स्थिति फ़ाइलें जो हमेशा बढ़ती रहती हैं, बेकार हो जाती हैं।

PROGRESS.md को एक कंट्रोल पैनल के रूप में रखें, न कि एक संग्रह के रूप में।

LOOP_INSTRUCTIONS.md — संचालन प्रक्रिया

यह फ़ाइल Claude के चारों ओर नियंत्रण परत है।

यह Claude को बताती है कि वास्तव में क्या पढ़ना है, क्या लिखना है, क्या नहीं छूना है, और रुकने से पहले परिणाम को कैसे सत्यापित करना है।

टेम्पलेट जो काम करता है:

1# लूप निर्देश
2
3आप एक दैनिक प्रोजेक्ट समीक्षा लूप चला रहे हैं।
4
5## शुरू करने से पहले
61. `TASK.md` पढ़ें
72. `PROGRESS.md` पढ़ें
83. प्रोजेक्ट फ़ोल्डर का निरीक्षण करें
94. पहचानें कि क्या बदला, क्या अधूरा है, किसे मानव समीक्षा की आवश्यकता है
10
11## आपको क्या करना चाहिए
12`outputs/daily-review.md` में एक संक्षिप्त दैनिक समीक्षा लिखें जिसमें शामिल हो:
13- वर्तमान स्थिति का सारांश
14- समीक्षित फ़ाइलें
15- सार्थक परिवर्तन
16- अवरोधक या अनसुलझे प्रश्न
17- अनुशंसित अगली कार्रवाइयाँ
18
19लिखने के बाद, `PROGRESS.md` को अपडेट करें:
20- इस रन की तारीख
21- क्या हुआ इसका सारांश
22- जाँच की गई फ़ाइलें
23- अगले रन को क्या करना चाहिए
24- क्या मानव समीक्षा की आवश्यकता है
25
26## सुरक्षा नियम
27- फ़ाइलें न हटाएँ
28- फ़ाइलों का नाम न बदलें या स्थानांतरित न करें
29- स्रोत फ़ाइलों को संशोधित न करें
30- केवल `outputs/daily-review.md` और `PROGRESS.md` में लिखें
31- यदि अनिश्चित हों कि कोई कार्रवाई अनुमत है या नहीं → रुकें और पूछें
32
33## सत्यापन चेकलिस्ट
34रन समाप्त करने से पहले, पुष्टि करें:
35- `outputs/daily-review.md` सभी आवश्यक अनुभागों के साथ मौजूद है
36- `PROGRESS.md` अपडेट किया गया था
37- अनुमत पथों के बाहर कोई फ़ाइल संशोधित नहीं की गई
38
39## विफलता नीति
40यदि सत्यापन विफल होता है:
411. रिपोर्ट में अनुपलब्ध अनुभाग → एक बार ठीक करें
422. PROGRESS.md अपडेट नहीं हुआ → एक बार अपडेट करें
433. निषिद्ध फ़ाइल संशोधित हुई → तुरंत रुकें
444. एक ही जाँच दो बार विफल होती है → मानव समीक्षा की आवश्यकता के रूप में चिह्नित करें

नीचे विफलता नीति पर ध्यान दें।

अधिकांश लूप में कोई विफलता नीति नहीं होती है।

इसलिए जब कुछ गलत होता है, तो Claude तात्कालिक समाधान करता है।

यहीं पर लूप समस्याएँ पैदा करते हैं।

विफलता पथ को स्पष्ट रूप से परिभाषित करें। हमेशा।

अपना पहला लूप मैन्युअल रूप से चलाना

अभी शेड्यूल न करें।

पहले मैन्युअल रूप से चलाएँ।

Claude Code या Claude Desktop/Cowork में फ़ोल्डर खोलें। इस प्रॉम्प्ट का उपयोग करें:

1इस कार्यक्षेत्र के लिए दैनिक प्रोजेक्ट समीक्षा लूप चलाएँ।
2
3`LOOP_INSTRUCTIONS.md` का बिल्कुल पालन करें।
4
5कार्य करने से पहले, पढ़ें:
6- `TASK.md`
7- `PROGRESS.md`
8- `LOOP_INSTRUCTIONS.md`
9
10फिर कार्यक्षेत्र का निरीक्षण करें, `outputs/daily-review.md` में दैनिक समीक्षा लिखें,
11`PROGRESS.md` अपडेट करें,
12सत्यापन चेकलिस्ट चलाएँ, और रिपोर्ट करें कि क्या बदला।
13
14`outputs/daily-review.md` और `PROGRESS.md` को छोड़कर किसी भी फ़ाइल को संशोधित न करें।

रन के बाद, दो चीज़ें जाँचें:

→ outputs/daily-review.md — सभी अनुभागों के साथ संरचित रिपोर्ट

→ PROGRESS.md — अपडेट की गई स्थिति, अगले रन के लिए मार्गदर्शन, मानव समीक्षा फ़्लैग

यदि दोनों सही दिखते हैं → लूप काम कर रहा है।

अब इसे छोटे-मोटे बदलावों के साथ 3-5 बार और चलाएँ।

एक नोट्स फ़ाइल जोड़ें। PROGRESS.md में एक अवरोधक जोड़ें। कार्यक्षेत्र में कुछ बदलें।

प्रत्येक रन को शून्य से शुरू किए बिना परिवर्तनों को उठाना चाहिए।

यह निरंतरता ही पूरा मुद्दा है।

सत्यापन: वह हिस्सा जो अधिकांश लोग छोड़ देते हैं

यहाँ विफलता मोड है जिसके बारे में कोई बात नहीं करता।

Claude लूप चलाता है। कहता है कि हो गया। स्थिति अपडेट करता है। रुक जाता है।

सब कुछ ठीक लगता है।

लेकिन रिपोर्ट में आवश्यक अनुभाग गायब हैं। या PROGRESS.md वास्तव में अपडेट नहीं हुआ था। या Claude ने चुपचाप एक फ़ाइल संपादित की जो उसे नहीं करनी चाहिए थी।

आपको तब पता चलता है जब कुछ टूटता है।

यही कारण है कि सत्यापन मौजूद है।

लूप को इसलिए नहीं रुकना चाहिए क्योंकि Claude कहता है कि वह समाप्त हो गया है।

यह रुकता है क्योंकि एक ठोस शर्त की जाँच की गई थी।

अच्छा सत्यापन इस तरह दिखता है:

नवीनतम लूप निष्पादन के लिए एक सत्यापन पास चलाएँ।

LOOP_INSTRUCTIONS.md में सत्यापन चेकलिस्ट के विरुद्ध आउटपुट की जाँच करें।

रिपोर्ट करें:

1. कौन सी जाँचें पास हुईं
2. कौन सी जाँचें विफल हुईं
3. कौन सी फ़ाइलें संशोधित की गईं
4. क्या रन स्वीकार करना सुरक्षित है
5. क्या मानव समीक्षा की आवश्यकता है

इस सत्यापन पास के दौरान किसी भी फ़ाइल को संशोधित न करें।

वर्कर चलाएँ। फिर वेरिफ़ायर चलाएँ। अलग-अलग।

समय के साथ आप उन्हें मर्ज कर सकते हैं। लेकिन शुरुआती परीक्षण के दौरान, उन्हें अलग रखें।

वेरिफ़ायर को एक पास/फ़ेल मानक की आवश्यकता होती है।

"इसकी समीक्षा करें और मुझे बताएं कि क्या यह ठीक लगता है" एक वेरिफ़ायर नहीं है।

"इन 7 शर्तों की जाँच करें और रन को तभी स्वीकृत के रूप में चिह्नित करें जब सभी 7 पास हों" एक वेरिफ़ायर है।

/loop के साथ शेड्यूलिंग

लूप मैन्युअल रूप से विश्वसनीय रूप से चल रहा है।

अब इसे शेड्यूल करें।

Claude Code में, /loop का उपयोग करें:

1/loop 24h इस कार्यक्षेत्र के लिए दैनिक प्रोजेक्ट समीक्षा लूप चलाएँ।
2
3`LOOP_INSTRUCTIONS.md` का बिल्कुल पालन करें।
4पहले `TASK.md` और `PROGRESS.md` पढ़ें।
5रिपोर्ट `outputs/daily-review.md` में लिखें।
6रुकने से पहले `PROGRESS.md` अपडेट करें।
7सत्यापन चेकलिस्ट चलाएँ।
8यदि कोई सार्थक परिवर्तन नहीं है → रिपोर्ट को संक्षिप्त रखें।
9यदि मानव समीक्षा की आवश्यकता है → `PROGRESS.md` में स्पष्ट रूप से चिह्नित करें।
10`outputs/daily-review.md` और `PROGRESS.md` को छोड़कर किसी भी फ़ाइल को संशोधित न करें।

अंतराल विकल्प:

→ /loop 15m — परीक्षण कैडेंस (देखते समय उपयोग करें)

→ /loop 1h — प्रति घंटा निगरानी

→ /loop 24h — दैनिक समीक्षा

→ /loop 7d — साप्ताहिक सफाई या सारांश

महत्वपूर्ण: /loop कोई जादू नहीं है।

यह सिर्फ प्रॉम्प्ट को दोहराता है।

लूप की गुणवत्ता प्रॉम्प्ट के आसपास की संरचना से आती है — फ़ाइलें, निर्देश, सत्यापन, स्थिति।

/loop केवल ट्रिगर प्रदान करता है।

/goal के बारे में भी जानें:

/loop = फिर से चलाएँ क्योंकि समय बीत गया।

/goal = तब तक चलाते रहें जब तक कोई शर्त पूरी न हो जाए।

1/goal outputs/daily-review.md मौजूद है, PROGRESS.md अपडेट है,
2सत्यापन चेकलिस्ट पास होती है, कोई निषिद्ध फ़ाइल संशोधित नहीं हुई है।

समय-आधारित कार्यों (दैनिक समीक्षा, निगरानी) के लिए /loop का उपयोग करें।

पूर्णता-आधारित कार्यों (जब तक परीक्षण पास न हो जाएं, ठीक करें; जब तक सभी अनुभाग पूरे न हो जाएं, लिखें) के लिए /goal का उपयोग करें।

अनुमति सीढ़ी

यहीं पर अधिकांश लूप गलत हो जाते हैं।

लोग एक लूप बनाते हैं जो काम करता है। फिर तुरंत उसे बहुत अधिक शक्ति दे देते हैं।

लूप सीधे Slack पर पोस्ट करता है। बिना समीक्षा के कोड पुश करता है। स्वचालित रूप से टिकट बंद करता है।

फिर कुछ गलत हो जाता है और यह एक गड़बड़ी बन जाती है।

इसके बजाय अनुमति सीढ़ी का उपयोग करें:

1स्तर 1 — केवल पढ़ें
2Claude फ़ाइलें, टिकट, लॉग, मुद्दे पढ़ता है।
3
4स्तर 2 — ड्राफ़्ट आउटपुट
5Claude केवल outputs/ में लिखता है।
6रिपोर्ट, योजनाएँ, सिफारिशें।
7कुछ भी बाहरी नहीं।
8
9स्तर 3 — सैंडबॉक्स संपादन
10Claude एक नियंत्रित सैंडबॉक्स के अंदर फ़ाइलों को संशोधित करता है।
11पृथक शाखा या वर्कट्री।
12
13स्तर 4 — ड्राफ़्ट बाहरी कार्रवाइयाँ
14Claude PR, Slack संदेश, टिकट अपडेट तैयार करता है।
15भेजता या मर्ज नहीं करता।
16
17स्तर 5 — मानव-अनुमोदित कार्रवाइयाँ
18Claude स्पष्ट अनुमोदन के बाद ही परिवर्तन लागू करता है।
19
20स्तर 6 — स्वचालित कम-जोखिम वाली कार्रवाइयाँ
21Claude संकीर्ण रूप से निर्धारित कार्यों को स्वचालित रूप से पूरा करता है।
22लॉग, सीमाएँ और रोलबैक के साथ।

आपका पहला लूप स्तर 1 या स्तर 2 पर रहना चाहिए।

यह कमजोरी नहीं है। यह इंजीनियरिंग है।

स्तर 1 और 2 के लूप अभी भी बहुत मूल्यवान हो सकते हैं।

Claude आपके GitHub मुद्दों का निरीक्षण कर सकता है, CI विफलताओं को पढ़ सकता है, PRD की समीक्षा कर सकता है, और सब कुछ संक्षेप में बता सकता है — बिना किसी महत्वपूर्ण चीज़ को छुए।

पहले साबित करें कि लूप स्तर 2 पर काम करता है।

फिर तय करें कि क्या वह स्तर 3 का हकदार है।

जब लूप गलत हो जाते हैं (और इसे कैसे रोकें)

खराब पहला लूप:

हर दिन, उत्पाद रणनीति में तब तक सुधार करें जब तक वह मजबूत महसूस न हो।

→ कोई रुकने की शर्त नहीं → कोई सत्यापन नहीं → कोई स्थिति नहीं → "मजबूत महसूस होता है" चेकलिस्ट आइटम नहीं है

यह लूप या तो कुछ भी उपयोगी नहीं करेगा या उन चीज़ों को बदल देगा जो उसे नहीं बदलनी चाहिए।

अच्छा पहला लूप:

हर शुक्रवार, उत्पाद रणनीति दस्तावेज़ की समीक्षा करें।

उन अनुभागों की पहचान करें जो इस सप्ताह बदले।

अनसुलझी मान्यताओं की सूची बनाएं।

outputs/strategy-review.md में एक संरचित समीक्षा नोट लिखें।

रणनीति दस्तावेज़ को सीधे संपादित न करें।

→ स्पष्ट कार्यक्रम → सीमित दायरा → अनुमानित आउटपुट फ़ाइल → सुरक्षित अनुमति सीमा

अंतर बुद्धिमत्ता का नहीं है। यह डिज़ाइन का है।

वे 5 चीज़ें जो लूप को डुबो देती हैं:

→ मैन्युअल परीक्षण से पहले शेड्यूलिंग

→ कोई स्थिति फ़ाइल नहीं — हर रन शून्य से शुरू होता है

→ कोई सत्यापन नहीं — लूप खुद पर भरोसा करता है

→ कोई विफलता नीति नहीं — खराब परिणाम तात्कालिक समाधान करते हैं

→ बहुत जल्दी बहुत सारे उपकरण — विस्फोट त्रिज्या बढ़ जाती है

पहले /loop कमांड से पहले सभी पाँचों को ठीक करें।

उपकरण और कनेक्टर जोड़ना

एक बार स्थानीय लूप स्थिर हो जाने पर, आप इसे बढ़ा सकते हैं।

GitHub. Slack. Linear. Jira. CI लॉग।

लेकिन हर नया उपकरण विस्फोट त्रिज्या का विस्तार करता है।

उसी सिद्धांत का पालन करें: पहले पढ़ें, दूसरे ड्राफ़्ट करें, बार-बार सफल रन के बाद ही लिखें।

उपकरण-विशिष्ट नियम LOOP_INSTRUCTIONS.md में जाते हैं:

1## उपकरण अनुमति नीति
2
3### GitHub
4अनुमत:
5- खुले मुद्दे पढ़ना
6- पुल अनुरोध स्थिति पढ़ना
7- CI स्थिति पढ़ना
8- `outputs/github-review.md` में सारांश का मसौदा तैयार करना
9अनुमति नहीं:
10- कमिट पुश करना
11- पुल अनुरोध मर्ज करना
12- मुद्दे बंद करना
13- अनुमोदन के बिना सार्वजनिक रूप से टिप्पणी करना
14
15### Slack
16अनुमत:
17- `outputs/slack-update.md` में संदेश का मसौदा तैयार करना
18अनुमति नहीं:
19- संदेश भेजना
20- उपयोगकर्ताओं का उल्लेख करना
21- चैनलों में पोस्ट करना
22
23### Linear/Jira
24अनुमत:
25- निर्दिष्ट टिकट पढ़ना
26- सुझाए गए अपडेट का मसौदा तैयार करना
27अनुमति नहीं:
28- स्थिति बदलना
29- टिकट बंद करना
30- अनुमोदन के बिना टिकट बनाना

यदि उपकरण सूचीबद्ध नहीं है → रुकें और मानव समीक्षा के लिए पूछें।

यह आपको लूप द्वारा ऐसे काम करने से बचाता है जिनके बारे में आपने नहीं सोचा था।

आपका पहला पूरा लूप कैसा दिखता है

यहाँ शुरू से पूरा सेटअप है।

1## उपकरण अनुमति नीति
2
3### GitHub
4अनुमत:
5- खुले मुद्दे पढ़ना
6- पुल अनुरोध स्थिति पढ़ना
7- CI स्थिति पढ़ना
8- `outputs/github-review.md` में सारांश का मसौदा तैयार करना
9अनुमति नहीं:
10- कमिट पुश करना
11- पुल अनुरोध मर्ज करना
12- मुद्दे बंद करना
13- अनुमोदन के बिना सार्वजनिक रूप से टिप्पणी करना
14
15### Slack
16अनुमत:
17- `outputs/slack-update.md` में संदेश का मसौदा तैयार करना
18अनुमति नहीं:
19- संदेश भेजना
20- उपयोगकर्ताओं का उल्लेख करना
21- चैनलों में पोस्ट करना
22
23### Linear/Jira
24अनुमत:
25- निर्दिष्ट टिकट पढ़ना
26- सुझाए गए अपडेट का मसौदा तैयार करना
27अनुमति नहीं:
28- स्थिति बदलना
29- टिकट बंद करना
30- अनुमोदन के बिना टिकट बनाना

फिर प्रत्येक फ़ाइल भरें (ऊपर दिए गए टेम्पलेट का उपयोग करें)।

फिर मैन्युअल रूप से चलाएँ:

1इस कार्यक्षेत्र के लिए दैनिक प्रोजेक्ट समीक्षा लूप चलाएँ।
2
3`LOOP_INSTRUCTIONS.md` का बिल्कुल पालन करें।
4कार्य करने से पहले, TASK.md, PROGRESS.md,
5और LOOP_INSTRUCTIONS.md पढ़ें।
6दैनिक समीक्षा `outputs/daily-review.md` में लिखें।
7रुकने से पहले `PROGRESS.md` अपडेट करें।
8सत्यापन चेकलिस्ट चलाएँ।
9`outputs/daily-review.md` और `PROGRESS.md` को छोड़कर किसी भी फ़ाइल को संशोधित न करें।

फिर सत्यापित करें:

1एक सत्यापन पास चलाएँ।
2`LOOP_INSTRUCTIONS.md` में सत्यापन चेकलिस्ट के विरुद्ध जाँच करें।
3रिपोर्ट करें कि कौन सी जाँचें पास हुईं, कौन सी विफल हुईं,
4कौन सी फ़ाइलें संशोधित की गईं, क्या मानव समीक्षा की आवश्यकता है।
5किसी भी फ़ाइल को संशोधित न करें।

छोटे कार्यक्षेत्र परिवर्तनों के साथ 3-5 बार मैन्युअल रूप से चलाएँ।

फिर शेड्यूल करें:

1/loop 24h दैनिक प्रोजेक्ट समीक्षा लूप चलाएँ...
2[मैन्युअल के समान प्रॉम्प्ट, /loop 24h के साथ उपसर्ग]

इस पर भरोसा करने से पहले शेड्यूल किए गए आउटपुट के पहले सप्ताह की समीक्षा करें।

यह पूरी प्रणाली है।

वह बदलाव जो सब कुछ बदल देता है

लूप से पहले:

→ आपने एक प्रॉम्प्ट लिखा

→ Claude ने उत्तर दिया

→ कल आपने वही प्रॉम्प्ट फिर से लिखा

→ Claude को कल का कुछ याद नहीं था

→ आपने मैन्युअल रूप से ट्रैक किया कि क्या बदला

→ हर सत्र के साथ सब कुछ रीसेट हो गया

लूप के बाद:

→ TASK.md लक्ष्य को एक बार परिभाषित करता है

→ PROGRESS.md रनों के बीच मेमोरी रखता है

→ LOOP_INSTRUCTIONS.md व्यवहार को नियंत्रित करता है

→ Claude पढ़ता है, कार्य करता है, सत्यापित करता है, अपडेट करता है, रुकता है

→ कल यह वहीं से जारी रहता है जहाँ छोड़ा था

→ आप आउटपुट की समीक्षा करते हैं, प्रॉम्प्ट की नहीं

अड़चन काम उत्पन्न करने से काम की समीक्षा करने में स्थानांतरित हो जाती है।

यही असली लाभ है।

आप Claude से बेहतर प्रश्न नहीं पूछ रहे हैं।

आप एक ऐसी प्रणाली डिज़ाइन कर रहे हैं जो आपके बिना काम करती रहे।

10 लूप जो आप इस सप्ताह बना सकते हैं

→ दैनिक प्रोजेक्ट समीक्षा — कार्यक्षेत्र पढ़ता है, सारांश लिखता है

→ मीटिंग फ़ॉलो-अप एक्सट्रैक्टर — नोट्स को कार्य आइटम में बदलता है

→ फ़ोल्डर सफाई योजनाकार — व्यवस्थित करता है, प्रस्तावित करता है, छूता नहीं है

→ CI विफलता ट्राइएज — लॉग पढ़ता है, विफलताओं को वर्गीकृत करता है, जाँच का मसौदा तैयार करता है

→ GitHub मुद्दा सारांशकर्ता — खुले मुद्दे पढ़ता है, विषय के अनुसार समूहित करता है

→ PR समीक्षा सहायक — diff पढ़ता है, संभावित मुद्दों को फ़्लैग करता है

→ न्यूज़लेटर शोध लूप — स्रोत एकत्र करता है, सारांश तैयार करता है

→ दस्तावेज़ीकरण अंतर खोजक — दस्तावेज़ पढ़ता है, अनुपलब्ध अनुभागों को फ़्लैग करता है

→ दैनिक स्टैंडअप ड्राफ़्टर — PROGRESS.md पढ़ता है, स्टैंडअप लिखता है

→ साप्ताहिक रेट्रोस्पेक्टिव लूप — सप्ताह की समीक्षा करता है, पैटर्न की पहचान करता है

इनमें से हर एक एक ही 4-फ़ाइल सिस्टम से शुरू होता है।

केवल TASK.md और LOOP_INSTRUCTIONS.md बदलता है।

यदि यह उपयोगी था:

→ इसे हर उस डेवलपर के साथ साझा करने के लिए रिपोस्ट करें जो Claude का उपयोग करता है

→ अधिक ऐसी प्रणालियों के लिए @sairahul1 को फ़ॉलो करें जो आपके बिना काम करती हैं

→ इसे बुकमार्क करें — टेम्पलेट कॉपी-पेस्ट करने के लिए तैयार हैं

ऐसे और दिलचस्प लेखों के लिए theaibuilders.co की सदस्यता लें

मैं AI, उत्पाद निर्माण और ऑटोमेशन सिस्टम के बारे में लिखता हूँ।