लूप इंजीनियरिंग - प्रॉम्प्टिंग से लूपिंग तक

मैंने यह लेख इस बात पर समर्पित करने का फैसला किया है कि कैसे अपना खुद का प्रोग्राम करने योग्य एजेंट बनाया जाए जो आपके लिए काम करेगा, ताकि आपको हर सुबह अपना कंप्यूटर चालू न करना पड़े और बार-बार उसे कमांड देने न पड़ें।

यह अपने आप जाग जाएगा, अपने आप काम ढूंढेगा, अपने आप समस्याओं की पहचान करेगा, और परिणामों को आपकी मेज पर सहेज कर पेश करेगा ताकि आप उनकी समीक्षा कर सकें।

प्रस्तावना

Loop का विचार कहीं से नहीं आया - जून 2026 के एक ही सप्ताह में, तीन उद्योग विशेषज्ञों ने लगभग एक साथ एक ही विचार व्यक्त किया: इस स्तर को विकसित करना शुरू करने का समय आ गया था।

एक सप्ताह बाद, एंड्रयू एनजी ने इस बातचीत को "बिल्डिंग प्रोडक्ट्स फ्रॉम 0 टू 1" के व्यापक संदर्भ में रखा, जिससे एक अधिक व्यापक तस्वीर सामने आई।

यह लेख उस कहानी से शुरू होता है और फिर आपको स्क्रैच से एक न्यूनतम लेकिन पूर्ण लूप बनाने की प्रक्रिया से गुज़ारता है: 5 चालें, 6 भाग, एक दरवाज़ा जो "नहीं" कहता है, और एक मानव दरवाज़ा - ये सब आपकी अपनी मशीन पर चलता है, और किसी भी सॉफ़्टवेयर प्रोजेक्ट पर पुन: उपयोग करने योग्य है।

स्रोत: हुआशू ऑरेंज बुक, लूप इंजीनियरिंग: स्टॉप आस्किंग मी व्हाट इट इज़ (v260615, जून 2026)

वह सप्ताह जब 3 लोगों ने चिंगारी जलाई

जून 2026: तीन लोग, उनमें से कोई भी समन्वय नहीं कर रहा था, एक-दूसरे के कुछ ही दिनों के भीतर लगभग एक ही बात कही।

पीटर स्टाइनबर्गर, OpenClaw के निर्माता ने X पर दो वाक्य पोस्ट किए जिन्होंने 8.9 मिलियन व्यूज़ हासिल किए:

https://x.com/steipete/status/2063697162748260627

वह पोस्ट वह जगह है जहाँ से यह चर्चा वास्तव में शुरू हुई। यह कोई घोषणापत्र या लंबा निबंध नहीं था, बस दो पंक्तियाँ थीं जिन्होंने उस चीज़ का नाम दिया जो लोग चुपचाप पहले से कर रहे थे।

बोरिस चेर्नी: मैं अब Claude को प्रॉम्प्ट नहीं करता, मेरे पास लूप चल रहे हैं। वे ही हैं जो Claude को प्रॉम्प्ट कर रहे हैं और पता लगा रहे हैं कि क्या करना है।

एडी ओसमानी: लूप इंजीनियरिंग खुद को उस व्यक्ति के रूप में बदल रही है जो एजेंट को प्रॉम्प्ट करता है। आप उस सिस्टम को डिज़ाइन करते हैं जो इसके बजाय ऐसा करता है।

अभ्यास नाम से महीनों पहले आया था, हर कोई पहले से ही लूप लिख रहा था, किसी ने अभी तक इसे कुछ नहीं कहा था।

इसलिए, लूप अब इस बात का एक महत्वपूर्ण हिस्सा हैं कि हम AI एजेंटों को लंबी अवधि में सॉफ़्टवेयर बनाने के लिए पुनरावृत्त रूप से काम करने में कैसे सक्षम बनाते हैं।

एंड्रयू एनजी ने तीन लूपों को उनके समय पैमानों के आधार पर सबसे भीतर से सबसे बाहर तक व्यवस्थित किया: सबसे भीतर का लूप सबसे तेज़ है, और सबसे बाहर का लूप सबसे धीमा है। इसके अलावा, सबसे बाहरी लूप का इनपुट सबसे भीतरी लूप के आउटपुट से आता है:

लूप

इसे कौन चलाता है

चक्र की लंबाई

यह बाहरी परत को क्या आउटपुट देता है

एजेंटिक कोडिंग लूप

एजेंट स्वयं

सेकंड - मिनट

एक संस्करण जो चलता है

डेवलपर फीडबैक लूप

मानव + एजेंट

दसियों मिनट - घंटे

एक स्पष्ट उत्पाद दृष्टि और स्पेक

बाहरी फीडबैक लूप

उपयोगकर्ता + टीम

घंटे - सप्ताह

वास्तविक डेटा जो दृष्टि को विकसित करता है

एंड्रयू एनजी ने हमें समय के अनुसार नक्शा दिया: अलग-अलग गति से चलने वाले तीन लूप। एडी ओसमानी ने अमूर्तता द्वारा दूसरा नक्शा बनाया: प्रॉम्प्ट -> कॉन्टेक्स्ट -> हार्नेस -> लूप।

लूप इंजीनियरिंग सबसे ऊपर बैठती है और तीन क्रियाएँ जोड़ती है जो हार्नेस में नहीं हैं। यह एक टाइमर पर चलता है, सहायकों को जन्म देता है, और खुद को फीड करता है - आज का आउटपुट कल का इनपुट बन जाता है। यह आखिरी वाला है जो इसे एक लूप बनाता है, न कि एक ही कार्य को N बार चलाना।

सबसे महत्वपूर्ण अंतर्ज्ञान: एक ही बग की कीमत प्रत्येक परत पर अलग-अलग होती है:

परत

यह किसकी परवाह करता है

मुख्य प्रश्न

प्रॉम्प्ट इंजीनियरिंग

एक प्रॉम्प्ट लिखें

मॉडल से क्या कहना है

कॉन्टेक्स्ट इंजीनियरिंग

विंडो में क्या लोड है

क्या खींचना, सारांशित करना, साफ़ करना

हार्नेस इंजीनियरिंग

एकल रन को सशस्त्र करना

कौन से उपकरण, कौन सी क्रियाएँ, क्या पूरा माना जाता है

लूप इंजीनियरिंग

हार्नेस के ऊपर शेड्यूलिंग

इसे बार-बार अपने आप कैसे चलाया जाए

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

एक मोड़ के अंदर क्या होता है:

"लूप" को "एक ही जगह घूमना" के रूप में गलत समझा जाता है। ऐसा नहीं है, हर मोड़ में 5 ठोस चालें होती हैं। किसी एक को भी हटा दें और लूप या तो चलेगा नहीं - या चलेगा तो कहीं नहीं पहुँचेगा।

1. सत्यापन वह चाल है जो "नहीं" कहती है।
2. शेड्यूलिंग वह चाल है जो इस मोड़ को अगले मोड़ में फीड करती है।

यह बिल्कुल वही हिस्सा है जो इसे एक लूप बनाता है।

उस प्रोजेक्ट पर मैप किया गया जिसे हम बनाने जा रहे हैं: एक छोटी टीम के लिए एक मॉर्निंग-ट्राएज लूप:

क्रिया

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

ट्राएज लूप में

डिस्कवरी

पता लगाएँ कि इस मोड़ को क्या करना चाहिए

एक स्किल CI / इश्यू / हाल के कमिट पढ़ता है

हैंडऑफ़

कार्य भेजें, और इसे अलग करें

प्रत्येक निष्कर्ष को अपना वर्कट्री मिलता है

सत्यापन

"नहीं" कहने के लिए दूसरा एजेंट लाएँ

समीक्षक के रूप में दूसरा उप-एजेंट, टेस्ट और स्किल की जाँच करता है

परसिस्टेंस

बातचीत के बाहर स्थिति लिखें

PR + Linear टिकट + ./state/triage.md

शेड्यूलिंग

इसे बार-बार चलने दें

GitHub Actions cron 06:00 पर ट्रिगर करता है

नीचे दिए गए 5 पाठों में से प्रत्येक में ठीक एक चाल विकसित होती है।

पाँच पाठ = एक पूर्ण लूप।

और हम पहले वाले से शुरू करते हैं: डिस्कवरी, क्योंकि अगर लूप यह तय नहीं कर सकता कि आज क्या करने लायक है, तो उसके बाद कुछ भी मायने नहीं रखता।

पाठ 1 डिस्कवरी: एक मॉर्निंग-ट्राएज SKILL.md लिखें

स्किल, प्रॉम्प्ट की दीवार नहीं।

कल्पना करें, सोमवार सुबह 6 बजे है, आपका लैपटॉप बंद है और GitHub Action जागता है और claude --skill morning-triage को फायर करता है: यह क्या पढ़ता है, वह क्या निर्णय लेता है जो कार्रवाई योग्य है, वह परिणाम कहाँ लिखता है - यह सब उस SKILL.md के अंदर रहता है जिसे आप लिखने वाले हैं।

ओसमानी की मुख्य पंक्ति: ऑटोमेशन को एक स्किल को ट्रिगर करना चाहिए - लिखित, अद्यतन करने योग्य प्रोजेक्ट ज्ञान, न कि क्रोन जॉब में चिपकाए गए प्रॉम्प्ट की दीवार। चिपकाया गया प्रॉम्प्ट वहीं सड़ता रहता है, क्योंकि कोई भी कभी शेड्यूल के अंदर दबी किसी चीज़ को अपडेट करने के लिए वापस नहीं जाता।

इस पाठ के लिए आपका कार्य: .claude/skills/morning-triage/SKILL.md पर एक स्किल लिखें जो अपने आप तीन स्रोतों (CI / इश्यू / कमिट) को पढ़े, अपने आप तय करे कि क्या करने लायक है, परिणाम ./state/triage.md पर लिखे - और इसमें एक स्पष्ट Stop सेक्शन हो जो बताता हो कि लूप को क्या करने की अनुमति नहीं है।

यह रहा स्टार्टर - तीन चीज़ें बदलें और यह आपका है:

1# .claude/skills/morning-triage/SKILL.md
2---
3name: morning-triage
4trigger: invoked by daily automation
5---
6
7## Read   (डिस्कवरी इनपुट — उन स्रोतों से बदलें जो वास्तव में आपके रेपो में हैं)
8- पिछले रन के बाद से विफल हुए CI रन      # gh run list --status failure
9- पिछले 24 घंटों में खोले गए इश्यू               # gh issue list --search "created:>=…"
10- कल से मर्ज किए गए कमिट              # git log --since=yesterday
11- पिछला ./state/triage.md              # "कल → आज" हैंडऑफ़
12
13## Judge  (सीमा — लूप को चुनने दें, उसे सूची न दें)
14प्रत्येक उम्मीदवार के लिए, तय करें:
15- क्या यह अभी कार्रवाई योग्य है, या शोर?
16- क्या यह किसी रिलीज़ को ब्लॉक करता है? → प्राथमिकता = P0
17- क्या यह पहले से ट्रैक किया जा रहा है? → छोड़ें
18केवल वही रखें जो आज एक वर्कट्री के लायक है।
19
20## Write  (परसिस्टेंस — इसे चैट में नहीं, मार्कडाउन में रखें)
21./state/triage.md में जोड़ें:
22| निष्कर्ष | स्रोत | प्राथमिकता | स्थिति |
23फ़ाइल को कमिट करें ताकि कल इसे पढ़ सके।
24
25## Handoff  (पाठ 2 के लिए तैयारी)
26प्रत्येक रखे गए निष्कर्ष के लिए, एक कार्य पंक्ति आउटपुट करें:
27  worktree=fix/<slug>
28  goal=<stop-condition>
29
30## Stop   (एकमात्र गैर-बॉयलरप्लेट सेक्शन — यहाँ गहराई से सोचें)
31कभी मर्ज न करें। कभी डिलीट न करें।
32जिस भी चीज़ के बारे में आपको कम भरोसा हो → ./inbox/ एक मानव के लिए।
33PR नहीं।

तीन सेक्शन यहाँ असली काम करते हैं:

Read: यह डिस्कवरी का इनपुट है - वास्तविक कमांड तक, ठोस स्रोतों की सूची बनाएं। याद रखें, "कॉन्टेक्स्ट पढ़ें" कोई स्रोत नहीं है, लेकिन gh run list --status failure एक स्रोत है।

Judge: यह आपके पूरे लूप की सीमा है। लूप खुद तय करता है "कार्रवाई योग्य बनाम शोर" - यह आपसे कोई सूची प्राप्त नहीं करता, क्योंकि यदि आप अभी भी इसे हर सुबह एक सूची दे रहे हैं, तो आपने करने को स्वचालित किया है लेकिन चुनने को नहीं। और चुनना आमतौर पर अधिक महंगा कदम होता है। भले ही आपके स्रोत कितने भी अच्छे हों, यदि यह सेक्शन कचरा चुनता है, तो अन्य चार चालें बेकार काम पर घूम रही हैं।

Stop: इस फ़ाइल का एकमात्र हिस्सा जो बॉयलरप्लेट नहीं है। लूप वह सब कुछ करेगा जो स्किल कहती है, और केवल वही जो स्किल कहती है। यदि आप "कभी मर्ज न करें" नहीं लिखते हैं - तो यह एक दिन आपके लिए मर्ज कर देगा।

लाल रेखाएँ स्पष्ट करें: कभी मर्ज न करें, कभी डिलीट न करें, कभी main पर पुश न करें, अनिश्चित कोई भी चीज़ PR में नहीं, ./inbox/ में एक मानव के लिए जाए।

एक और बात जानने लायक: यही स्किल संरचना मॉर्निंग ट्राएज से परे काम करती है: Read सेक्शन को "कल के एक्सेस लॉग + नए इश्यू + वर्तमान डिप्लॉय वर्जन" से बदलें और यह एक शाम का साइट-हेल्थ लूप बन जाता है। Judge में एक पंक्ति जोड़ें - "क्या यह कल से एक रिग्रेशन है?" - और यह क्रॉस-डे तुलना विकसित करता है।

यह पाठ जिस बीमारी को रोकता है - ब्लाइंड लूप:

सबसे आम "लूप जैसा दिखता है लेकिन है नहीं।": लूप चलता है, लेकिन आप अभी भी हर सुबह काम सौंप रहे हैं ("अरे, इन तीन बगों को देखो")। यह निष्पादन का ऑटोमेशन है, डिस्कवरी का नहीं।

लक्षण: लूप आपको कभी आश्चर्यचकित नहीं करता, क्योंकि यह केवल वही करता है जो आप पहले से जानते थे कि करने की आवश्यकता है।

समाधान: Judge को स्किल के अंदर रखें और इसे आज का काम खुद चुनने दें।

आगे बढ़ने से पहले, इन तीनों का उत्तर दें:

1/ आपके Stop सेक्शन में कितनी पंक्तियाँ हैं?

यदि यह सिर्फ "कभी मर्ज न करें" है - तो एक और जोड़ें: इस लूप को आपके लिए और क्या कभी नहीं करना चाहिए? (कभी इश्यू बंद न करें / कभी main पर पुश न करें / एक बार में 3 से अधिक निष्कर्ष न लें..)

2/ Read की पहली पंक्ति को एक कमांड में फिर से लिखें जो वास्तव में आपके प्रोजेक्ट में चलता है

**3/ यदि यह स्किल एक वर्ष तक अपरिवर्तित रहती है - तो क्या होगा?

**अब तुलना करें: एक क्रोन जॉब में चिपकाए गए प्रॉम्प्ट की दीवार का एक वर्ष में क्या होता है?

पाठ 2 हैंडऑफ़: काम बाँटें, और इसे अलग करें

पाठ 1 की स्किल अभी-अभी चलकर समाप्त हुई है। ./state/triage.md में अब 5 कार्रवाई योग्य निष्कर्ष हैं। सबसे स्वाभाविक अगला विचार - एक साथ 5 एजेंट फायर करें, तेज़ी से आगे बढ़ें। यही सटीक कदम है जिससे आप एक उलझा हुआ लूप (Tangled Loop) विकसित करते हैं: कई एजेंट एक ही निर्देशिका में एक ही फ़ाइलों को संपादित कर रहे हैं, और मर्ज का दिन पुरातत्व में बदल जाता है।

मारक एक पंक्ति है: प्रत्येक निष्कर्ष को अपना स्वयं का वर्कट्री मिलता है।

git worktree एक अंतर्निहित git तंत्र है: एक रेपो, कई स्वतंत्र कार्यशील निर्देशिकाएँ, प्रत्येक अपनी शाखा पर चेकआउट की गई है। git worktree add ../fix-auth fix/auth ../fix-auth पर पूरी तरह से पृथक कार्यक्षेत्र खोलता है। बिल्ड, संपादन, परीक्षण - कुछ भी किसी और को स्पर्श नहीं करता है। प्रति निष्कर्ष एक वर्कट्री = एजेंट शारीरिक रूप से अलग हो गए।

इस पाठ के लिए आपका कार्य: एक स्क्रिप्ट लिखें जो ./state/triage.md से प्रत्येक निष्कर्ष को पढ़े, प्रति निष्कर्ष एक पृथक वर्कट्री खोले (जिसका नाम fix/<slug> हो), एक एजेंट को उसके अंदर एक फिक्स का मसौदा तैयार करने के लिए भेजे - और एक समानांतर सीमा निर्धारित करे ताकि यह अनंत रूप से न फैले।

1# state/triage.md पढ़ें, प्रति निष्कर्ष एक वर्कट्री
2# बदलें: MAX_PARALLEL को अपनी मशीन / बिल के अनुसार
3MAX_PARALLEL=3
4
5# बदलें: पार्सिंग को आपके वास्तविक triage.md कॉलम से मिलाएँ
6findings=$(awk -F'|' 'NR>2 && $5 ~ /open/ {print $2}' \
7           state/triage.md | head -n $MAX_PARALLEL)
8
9for finding in $findings; do
10  slug=$(echo "$finding" | tr ' ' '-' | tr -cd '[:alnum:]-')
11
12  # मुख्य पंक्ति: प्रति एजेंट भौतिक अलगाव
13  git worktree add ../wt-$slug -b fix/$slug
14
15  # बदलें: goal पाठ 3 के मूल्यांकनकर्ता द्वारा पढ़ी जाने वाली रुकने की शर्त है
16  claude --worktree ../wt-$slug \
17    --goal "tests/$slug में टेस्ट पास होते हैं और lint साफ है" \
18    "इसके लिए एक फिक्स तैयार करें: $finding" &
19done
20
21wait   # सभी समानांतर एजेंटों के समाप्त होने तक प्रतीक्षा करें
22
23# समापन नियम: एजेंट कभी ऑटो-मर्ज नहीं करते — वर्कट्री
24# पाठ 5 में मानव द्वार की प्रतीक्षा करते हैं
25echo "समीक्षा के लिए सभी वर्कट्री तैयार:"
26git worktree list

यहाँ महत्वपूर्ण नियम: main पर कभी काम न करें।

Main मानव समीक्षा के लिए लैंडिंग स्ट्रिप है - एजेंटों की मेज नहीं। सभी एजेंट fix/* वर्कट्री पर रहते हैं।

समानांतरता को सीमित करें: असीमित स्पॉनिंग टोकन विस्फोट का मुख्य द्वार है (पाठ 5 इस पर वापस आता है)। MAX_PARALLEL को एक ईमानदार प्रश्न के आधार पर चुनें: "मेरी मशीन कितना चला सकती है" नहीं बल्कि "मैं वास्तव में कितने PR की समीक्षा कर सकता हूँ।"

मर्ज एक मानवीय निर्णय है: Stripe इस तरह के लूप के माध्यम से प्रति सप्ताह 1,000+ PR चलाता है, और मनुष्य अभी भी प्रत्येक की समीक्षा करते हैं। मानव प्रक्रिया से बाहर नहीं गया - उन्होंने डेस्क बदल दी: कोड लिखने से कोड की समीक्षा करने तक।

और Stripe केस से एक विवरण चुराने लायक है: उन्होंने प्रतिकूल रूप से उपलब्ध सबसे बड़े मॉडल के बजाय सख्त नियतात्मक द्वार वाले छोटे मॉडल का उपयोग किया।

सबक: लूप के काम के लिए कच्ची मॉडल शक्ति की तुलना में एक तंग सत्यापन द्वार बेहतर है।

यह पाठ जिस बीमारी को रोकता है - उलझा हुआ लूप (Tangled Loop):

एकल-एजेंट लूप पूरी तरह से स्वस्थ दिखता है। समस्या केवल उस दिन दिखाई देती है जब आप समानांतर जाते हैं - पाँच एजेंट चलते हैं, पाँच diffs एक ही फ़ाइल में टकराते हैं, मर्ज अराजकता है।

समाधान: प्रत्येक कार्य को अपनी वर्कट्री मिलती है, एजेंटों के बीच कभी भी कार्यशील निर्देशिका साझा न करें।

आगे बढ़ने से पहले, इन तीनों का उत्तर दें:

**1/ आपने MAX_PARALLEL को किस संख्या पर सेट किया - और क्यों?

**(पैसा? मशीन? या "मैं ईमानदारी से कितने PR की समीक्षा कर सकता हूँ"?)

**2/ यदि कोई वर्कट्री क्रैश हो जाती है - एजेंट बिना छुए बाहर निकल जाता है

**कल की स्थिति फ़ाइल को इसके बारे में क्या रिकॉर्ड करना चाहिए?

**3/ Stripe ने एक छोटा मॉडल + सख्त नियतात्मक द्वार का उपयोग किया

**सबसे बड़े मॉडल के बजाय, वह विकल्प आपके लूप के लिए क्या मायने रखता है?

पाठ 3 सत्यापन: एक दरवाज़ा स्थापित करें जो "नहीं" कहता है (सबसे भारी पाठ)

लूप इंजीनियरिंग में यह सबसे कठिन चाल है, और यह किसी भी अन्य पाठ से अधिक प्रयास की हकदार है।

Anthropic के इंजीनियर पृथ्वी राजशेखरन, लंबे समय तक चलने वाले एजेंटिक ऐप्स पर काम करते हुए, कुछ देखा: एक एजेंट से उसके द्वारा अभी लिखे गए कोड को ग्रेड करने के लिए कहें, और वह लगभग हमेशा अपनी प्रशंसा करेगा - भले ही कोई मानव एक नज़र में देख सके कि यह औसत दर्जे का है।

यह मॉडल के बेवकूफ होने के कारण नहीं है: अपना खुद का होमवर्क ग्रेड करना संरचनात्मक रूप से टूटा हुआ है। जब तक कोड तैयार होता है, एजेंट का कॉन्टेक्स्ट उस आत्म-औचित्य श्रृंखला से भरा होता है कि उसने चीज़ों को इस तरह क्यों लिखा। अपने स्वयं के आउटपुट को देखते हुए, यह परिणाम नहीं देखता - यह परिणाम के लिए तर्क देखता है।

इसे एक लूप के अंदर रखें और यह एक आपदा में बदल जाता है: हर मोड़ का "क्या यह काफी अच्छा है?" उस एजेंट द्वारा उत्तर दिया जाता है जिसने इसे अभी लिखा है। हर मोड़ खुद को सिर हिलाता है। यह जितनी देर चलता है, वास्तविक गुणवत्ता से उतना ही दूर भटकता जाता है। यह नोडिंग लूप (Nodding Loop) है - और यह सूची में सबसे महंगी बीमारी है।

राजशेखरन का समाधान, उनके अपने शब्दों में:

"एक स्वतंत्र मूल्यांकनकर्ता को संदेहास्पद बनाने के लिए ट्यून करना, एक जनरेटर को अपने स्वयं के काम के प्रति आलोचनात्मक बनाने की तुलना में कहीं अधिक साध्य है।"

यह एक संरचनात्मक समस्या है, शब्दों की समस्या नहीं। आप किसी लेखक को अपने सिर से बाहर निकलने के लिए नहीं कह सकते, लेकिन आप एक अलग एजेंट ला सकते हैं, जिसमें पूरी तरह से अलग निर्देश हों, जो शून्य से कोड को देख रहा हो - जिसमें कोई आत्म-औचित्य श्रृंखला संलग्न न हो।

सादृश्य GANs से आता है: एक नेटवर्क बनाता है, दूसरा हमला करता है: निर्माता और जाँचकर्ता। वही पुराना बैंकिंग नियम: जो व्यक्ति पैसे वायर करता है और जो व्यक्ति इसे मंजूरी देता है, उन्हें अलग-अलग लोग होना चाहिए।

इस पाठ के लिए आपका कार्य - दो चीज़ें लिखें:

1) .claude/agents/reviewer.md पर पाँच सेक्शन के साथ एक मूल्यांकनकर्ता सिस्टम प्रॉम्प्ट: ROLE + ASSUME + CHECK + USE + VERDICT।

2) एक /goal कमांड जो इस लूप की रुकने की शर्त घोषित करता है - जिसे एक अलग ताज़ा मॉडल द्वारा आंका जाता है, न कि जनरेटर द्वारा।

1# .claude/agents/reviewer.md  (3 चीज़ें बदलें)
2ROLE: प्रतिकूल कोड समीक्षक।
3ASSUME: यह कोड तब तक टूटा हुआ है जब तक कि अन्यथा सिद्ध न हो जाए।
4प्रशंसा न करें। वह खोजें जो विफल होता है।
5
6# बदलें: CHECK को अपने प्रोजेक्ट के वास्तविक विफलता मोड द्वारा क्रमबद्ध करें,
7# पहले चलने योग्य जाँचें
8CHECK, क्रम में:
9  1. क्या यह चलता है?  (पढ़ें नहीं, निष्पादित करें)
10  2. टेस्ट: उन्हें चलाएँ, वास्तविक आउटपुट चिपकाएँ।
11  3. एज केस जिन्हें लेखक ने छोड़ दिया।
12  4. क्या व्यवहार टिकट से मेल खाता है?
13
14# बदलें: कौन सा MCP आप जो परीक्षण कर रहे हैं उस पर निर्भर करता है —
15# फ्रंटएंड → Playwright, API → curl/httpie
16Playwright MCP का उपयोग करें: पेज खोलें, क्लिक करें,
17स्क्रीनशॉट लें, DOM का निरीक्षण करें।
18व्यवहार का न्याय करें, इरादे का नहीं।
19
20VERDICT: PASS केवल तभी जब प्रत्येक जाँच सही हो।
21         अन्यथा REJECT + प्रत्येक कारण सूचीबद्ध करें।

1# रुकने की शर्त — एक ताज़ा छोटे मॉडल द्वारा आंका गया, जनरेटर द्वारा नहीं
2# बदलें: अपने निष्कर्ष की वास्तविक सत्यापन योग्य स्थिति से बदलें
3/goal test/auth में सभी टेस्ट पास होते हैं और lint चरण साफ है
4
5# सावधान: /goal और /loop एक ही चीज़ नहीं हैं
6#   /loop = अंतराल पर पुनः चलाएँ (कोई रुकने का निर्णय नहीं — खतरनाक)
7#   /goal = तब तक चलाएँ जब तक एक ताज़ा मॉडल स्थिति को सत्य नहीं आंकता

दो एजेंट, आदर्श रूप से दो मॉडल: "एक ही मॉडल, अलग प्रॉम्प्ट" अक्सर समान अंध धब्बों को संरक्षित करता है। यदि संभव हो तो मॉडल भी बदलें।

डिफ़ॉल्ट संदेह: मूल्यांकनकर्ता का आधार रेखा ASSUME BROKEN है - विश्वास जाँच पास करके अर्जित किया जाना चाहिए, डिफ़ॉल्ट रूप से प्रदान नहीं किया जाना चाहिए।

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

कारणों के साथ अस्वीकार करें: सूचीबद्ध कारणों के बिना REJECT कोई अस्वीकार नहीं है - जनरेटर को पता नहीं है कि क्या ठीक करना है।

और एसिड टेस्ट: क्या आपके मूल्यांकनकर्ता ने पिछले 5+ मोड़ों में वास्तव में कुछ अस्वीकार किया है? एक लूप जिसने सैकड़ों मोड़ों में कभी एक बार भी "नहीं" नहीं कहा है, किसी भी वास्तविक कार्यभार पर सांख्यिकीय रूप से असंभव है। इसलिए यह साबित करता है कि मूल्यांकनकर्ता काम नहीं कर रहा है।

यह पाठ जिस बीमारी को रोकता है - नोडिंग लूप (Nodding Loop):

लूप चलता है, एजेंट कोड लिखता है, वही एजेंट कहता है "अच्छा लग रहा है।" हर मोड़ स्व-अनुमोदन करता है, मशीन की गति पर प्रशंसनीय दिखने वाली गलतियों को जमा करता है। समाधान: यह पूरा पाठ: संरचनात्मक पृथक्करण + डिफ़ॉल्ट संदेह + कार्रवाई द्वारा न्याय + तीसरे पक्ष की रुकने की शर्त।

आगे बढ़ने से पहले, इन तीनों का उत्तर दें:

1/ क्या आपका मूल्यांकनकर्ता एक अलग प्रॉम्प्ट वाला एक ही मॉडल है, या एक अलग मॉडल? क्यों?

2/ "व्यवहार का न्याय करें, इरादे का नहीं" का अपने प्रोजेक्ट में अनुवाद करें

एक ठोस वाक्य: "मेरा मूल्यांकनकर्ता कोड नहीं पढ़ता, यह _____ चलाता है, और केवल तभी PASS करता है जब यह _____ देखता है"

3/ एक "काफी करीब" ताज़ा मॉडल के आपकी /goal शर्त को गलत तरीके से PASS करने की कितनी संभावना है?

यदि आपका सबसे डरावना विफलता मोड X है - तो अभी रुकने की शर्त में X के लिए एक जाँच जोड़ें

पाठ 4 परसिस्टेंस: आज के काम को कल तक जीवित रखें

पाठ 3 समाप्त हो गया। आपके मूल्यांकनकर्ता ने तीन निष्कर्षों का न्याय किया - दो PASS, एक REJECT। प्रश्न: वे तीन निर्णय अभी कहाँ रहते हैं?

यदि उत्तर "कॉन्टेक्स्ट विंडो में" है - तो कल सुबह 6 बजे, लूप एक फ्लश किए गए कॉन्टेक्स्ट में जागता है और कुछ भी याद नहीं रखता है। यह स्क्रैच से फिर से ट्राएज करता है, कल के अनफिक्स्ड REJECT पर ठोकर खाता है, शायद इसे फिर से ठीक करने के लिए एक और एजेंट असाइन करता है, शायद इसे पूरी तरह से याद करता है, शायद उसी छेद में गिर जाता है।

यह भूलने वाला लूप (Amnesiac Loop) है - हर दिन एक ही वर्ग से शुरू होता है।

एक पंक्ति में मारक: मेमोरी डिस्क पर लिखी गई स्थिति है, कॉन्टेक्स्ट नहीं। एक मार्कडाउन फ़ाइल, एक Linear बोर्ड, एक डेटाबेस - एक बार जब यह लिख दिया जाता है, तो इससे कोई फर्क नहीं पड़ता कि एजेंट कितनी अच्छी तरह भूल जाता है।

ये दोनों लगातार भ्रमित होते हैं, इसलिए अंतर स्पष्ट करें:

कॉन्टेक्स्ट = वह विंडो जो एजेंट इस मोड़ में देखता है -> हर रिफ्रेश पर साफ़ हो जाती है।

मेमोरी = वह स्थिति जो मोड़ों और दिनों में रहती है -> डिस्क पर लिखी जाती है (मार्कडाउन / DB / बोर्ड)।

एक लूप आज -> कल को केवल मेमोरी के माध्यम से जोड़ता है।

इस पाठ के लिए आपका कार्य:

1. कम से कम 4 कॉलम (निष्कर्ष / स्रोत / प्राथमिकता / स्थिति) के साथ ./state/triage.md बनाएँ - पाठ 1 की स्किल इसे लिखती है, पाठ 2 की वर्कट्री इसे पढ़ती हैं।
2. एक कनेक्टर (MCP) वायर करें: एक PASS निर्णय स्वचालित रूप से एक PR खोलता है, एक REJECT स्वचालित रूप से टिकट अपडेट करता है।
3. सत्यापित करें कि कल का लूप वास्तव में आज की स्थिति को वापस पढ़ सकता है।

1# ./state/triage.md  (लूप की मेमोरी — आवश्यकतानुसार बदलें)
2
3| निष्कर्ष         | स्रोत       | प्राथमिकता | स्थिति     |
4|-----------------|--------------|----------|------------|
5| auth test flaky | CI #4821     | P0       | fixing     |
6| null deref      | issue 92     | P1       | PR open    |
7| stale dep       | commit a3f9c | P2       | inbox      |
8
9# आवश्यकतानुसार कॉलम बढ़ाएँ: last_seen, retry_count, assigned_to
10# यह फ़ाइल रेपो में कमिट की जानी चाहिए —
11# अन्यथा कल का क्लाउड रनर इसे नहीं देख सकता

1// .mcp/connectors.json — लूप को बाहरी दुनिया से जोड़ें
2{
3  "github_pr": {
4    "type": "mcp",
5    "on_event": "evaluator.verdict.PASS",
6    "action": "open_pr",
7    "branch": "fix/${slug}",
8    "auto_merge": false        // ← गलत होना चाहिए। मानव द्वार = पाठ 5
9  },
10  "linear": {
11    "type": "mcp",
12    "on_event": "evaluator.verdict.REJECT",
13    "action": "update_ticket",
14    "fields": { "status": "Blocked", "reason": "${verdict.reasons}" }
15  }
16}

प्रत्येक कॉलम क्यों मायने रखता है: कोई स्रोत नहीं -> आप यह ऑडिट नहीं कर सकते कि निष्कर्ष कहाँ से आया। कोई प्राथमिकता नहीं -> आप काम को ऑर्डर नहीं कर सकते। कोई स्थिति नहीं -> कल बैटन नहीं उठा सकता।

और इस पाठ के लिए सत्यापन एकमात्र ऐसा है जिसे आप नकली नहीं बना सकते: कल तक प्रतीक्षा करें। जागें, जाँचें - क्या इनबॉक्स अभी भी मौजूद है? क्या अधूरे निष्कर्ष अभी भी अपनी स्थिति रखते हैं? क्या सुबह 6 बजे का रन वहीं से शुरू हुआ जहाँ कल रुका था, बजाय फिर से शुरू करने के? यह आपको चलाकर पता चलता है, इसके बारे में तर्क करके नहीं।

एक शांत अनुशासन जो परसिस्टेंस के साथ आता है - एक नमूना पढ़ें, हमेशा।

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

जिस क्षण आप इसे समझा नहीं सकते - आपका मानचित्र पीछे छूट गया है। एक शांत सुबह इसे ठीक करने में दस मिनट लगते हैं। एक उत्पादन घटना के दौरान इसे ठीक करने में बहुत अधिक खर्च होता है।

यह पाठ जिस बीमारी को रोकता है - भूलने वाला लूप (Amnesiac Loop):

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

लक्षण: कोई संचित प्रगति नहीं, हर दिन एक ही स्थान से शुरू होता है। समाधान: डिस्क पर स्थिति फ़ाइल।

आगे बढ़ने से पहले, इन तीनों का उत्तर दें:

1/ "मेमोरी ≠ कॉन्टेक्स्ट" का अपने प्रोजेक्ट से एक ठोस वाक्य में अनुवाद करें

"मेरा _____ मेमोरी है, मेरा _____ कॉन्टेक्स्ट है"

**2/ कल का लूप जागता है - अपनी पहली चाल तय करने के लिए वह state.md का कौन सा कॉलम पहले पढ़ता है? क्या आपने उस कॉलम का सही नाम दिया, या आपने उसके लिए एक लैंडमाइन दफन कर दी?

**3/ अनुशासन: आप दिन में अपना एक नमूना PR किस समय पढ़ेंगे? अभी कैलेंडर रिमाइंडर सेट करें - यह आपके साथ एक अनुबंध है।

पाठ 5 शेड्यूलिंग: इसे वास्तविक बनाएँ, इसे सुरक्षित बनाएँ, एक दरवाज़ा खुला रखें

पाठ 1-4 स्थापित हो चुके हैं, लेकिन लूप अभी भी उसी क्षण रुक जाता है जब आप बटन दबाना बंद कर देते हैं। अंतिम चाल एक क्रिया है: इसे एक ट्रिगर पर लटकाएँ।

लेकिन इस पाठ का सबसे खतरनाक हिस्सा cron को गलत करना नहीं है। यह cron को सही करना है - क्योंकि तब लूप वास्तव में अकेला चलता है, और एक बग इसे पूरी रात घुमा सकता है, सहायक सहायकों को जन्म देते हैं, जब तक कि आप एक ऐसे बिल के साथ नहीं जागते जिसे आप नहीं पहचानते।

इसलिए यह पाठ वास्तव में तीन काम करता है: ट्रिगर लटकाएँ, सीमाएँ सेट करें, एक मानव दरवाज़ा रखें।

पहला - अपना शेड्यूलर चुनें:

1क्लाउड (GH Actions)   डेस्कटॉप शेड्यूल्ड   /loop (CC में)
2कहाँ चलता है          क्लाउड                आपकी मशीन        आपकी मशीन
3मशीन चालू?         आवश्यक नहीं           आवश्यक              आवश्यक
4सत्र खुला?         आवश्यक नहीं           आवश्यक नहीं          आवश्यक
5न्यूनतम अंतराल        1 घंटा               1 मिनट              1 मिनट
6स्थानीय फ़ाइलें देखता है?   नहीं                   हाँ                  हाँ

निर्णायक प्रश्न: क्या यह काम आपका लैपटॉप छोड़ सकता है?

1"हर मिनट मेरे स्थानीय देव सर्वर की जाँच करें"
2   → स्थानीय + /loop होना चाहिए (क्लाउड का 1 घंटे का अंतराल इसे तक नहीं पहुँच सकता)
3
4"सुबह 3 बजे GitHub इश्यू स्कैन करें और PR खोलें"
5   → क्लाउड होना चाहिए (आपका लैपटॉप बंद है — लूप इसकी प्रतीक्षा नहीं कर सकता)

और पूरे अभ्यास में सबसे धूर्त आत्म-धोखा: एक स्थानीय टाइमर को "आपके सोते समय चल रहा है" मानना। ऐसा नहीं है। यह "कुछ अतिरिक्त मोड़ चला रहा है जबकि मैं अभी भी आसपास हूँ।"

इस पाठ के लिए आपका कार्य:

1. .github/workflows/triage.yml को एक क्रॉन ट्रिगर के साथ लिखें जो मॉर्निंग-ट्राइएज स्किल को चलाए।
2. तीन सीमाएँ निर्धारित करें: प्रति-रन बजट, दैनिक बजट, अधिकतम पुनर्प्रयास।
3. वर्कफ़्लो को इस नियम के साथ समाप्त करें: PR कभी भी ऑटो-मर्ज न हों, कोई भी अनिश्चित चीज़ ./inbox/ में जाए।

1# .github/workflows/triage.yml  (3 चीज़ें बदलें)
2name: morning-triage
3
4on:
5  schedule:
6    - cron: '0 6 * * *'        # बदलें: UTC में आपके टाइमज़ोन का 06:00
7
8jobs:
9  triage:
10    runs-on: ubuntu-latest
11    timeout-minutes: 45          # ← प्रति-रन सीमा · बदलें
12    permissions:
13      contents: write
14      pull-requests: write
15    steps:
16      - uses: actions/checkout@v4
17
18      - name: morning triage
19        env:
20          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
21          DAILY_BUDGET_USD: '20'   # ← दैनिक सीमा · बदलें
22          MAX_RETRIES: '3'          # ← पुनर्प्रयास सीमा · बदलें
23        run: |
24          claude --skill morning-triage \
25            --max-retries "$MAX_RETRIES" \
26            --daily-budget-usd "$DAILY_BUDGET_USD"
27
28      - name: PR खोलें (कभी ऑटो-मर्ज न करें)
29        run: |
30          # PR अपने आप खुलते हैं। मर्ज करना मानव का काम रहता है।
31          gh pr create --draft --base main \
32            --title "[लूप] $(date +%F) triage" \
33            --body-file ./state/triage.md
34          # यहाँ जानबूझकर `gh pr merge` नहीं है
35
36      - name: अनिश्चित को इनबॉक्स में भेजें
37        run: |
38          ls ./inbox/ && echo "मानव समीक्षा के लिए आइटम प्रतीक्षा कर रहे हैं"

तीन नियम जो इसे छठे महीने तक जीवित रखते हैं:

भेजने से पहले सीमा लगाएं: तीन स्तर - प्रति-रन टाइमआउट, दैनिक बजट, अधिकतम पुनर्प्रयास - पहली डरावनी बिल के बाद नहीं, बल्कि पहली स्वायत्त रन से पहले सेट करें। टोकन सीमा पैसे बचाने के बारे में नहीं है। यह एक सर्किट ब्रेकर है जो खुले-अंत वाले जोखिम को सीमित जोखिम में बदल देता है। बिना सीमा वाला लूप अपने खर्च करने का अधिकार अपने ही बग्स को सौंप देता है।

पैमाने के लिए: Uber ने अपना AI बजट चार महीनों में जलाने के बाद प्रति व्यक्ति प्रति टूल प्रति माह $1,500 पर इंजीनियरों को सीमित कर दिया। आपकी प्रति-लूप सीमा उस सबक का विस्तृत संस्करण है।

एक दरवाज़ा खुला रखें: PR ऑटो-मर्ज नहीं होते। अनिश्चित आइटम इनबॉक्स में आते हैं। आप एक दिन में एक नमूना पढ़ते हैं। दरवाज़ा इसलिए नहीं है कि एक मानव हमेशा उसमें से गुज़रेगा, बल्कि इसलिए है क्योंकि दरवाज़े का अस्तित्व आपको ऐसी स्थिति में रखता है जहाँ आप गुज़र सकते हैं। हर दरवाज़े को बंद कर दें, और जिस दिन आपको अंदर जाने की ज़रूरत होगी, आपने चाबी खो दी होगी।

सत्यापित करें कि यह वास्तव में जागता है। इसे कम से कम 3 बार चलाएं (ड्राई रन भी गिने जाते हैं)। सबसे आम विफलता: डेमो डे पर शानदार, गुरुवार तक मृत। "आखिरी रन उसी दिन था जब इसे डेमो किया गया था" एक मैनुअल लूप का नैदानिक संकेत है।

Claude Code के बाहर भी वैसे ही काम करता है - क्षमताएं विक्रेता-लॉक नहीं हैं, बस उनका नाम बदल दिया गया है:

1क्षमता               Claude Code          Codex
2शेड्यूलिंग          /loop · worker       Automations टैब
3रन-टू-कंडीशन       /goal                ऑटोमेशन रीरन + जज
4समानांतर अलगाव      --worktree           बैकग्राउंड वर्कट्री
5उप-एजेंट            .claude/agents/      .codex/agents/
6बाहरी कनेक्ट        MCP + प्लगइन्स      MCP कनेक्टर
7स्पष्ट स्किल        SKILL.md             $skill-name
8मशीन बंद होने पर चलता है  Cloud Routines       क्लाउड (योजनाबद्ध)

सवाल कभी "कौन सा विक्रेता" नहीं था। यह है "क्या सभी छह क्षमताएं स्थापित हैं।"

यह पाठ जिस बीमारी को रोकता है - मैनुअल लूप:

चार चालें खूबसूरती से बनाई गईं, कोई क्रॉन नहीं। यह कोई लूप नहीं है - यह एक स्क्रिप्ट है जिसे आपने एक बार चलाया और भूल गए।

समाधान: कोई भी ट्रिगर लगाएं जो आपको याद रखने पर निर्भर न हो।

भेजने से पहले, इन तीनों का उत्तर दें:

1/ आपकी तीन सीमाओं की सटीक संख्याएँ क्या हैं?

अगर कोई बग पूरी रात घूमता रहे - कौन सी सीमा पहले गिरावट को तोड़ती है? अगर उनमें से कोई भी नहीं तोड़ता.. यह आपको क्या बताता है?

2/ आपका मानव दरवाज़ा कैसा दिखता है?

(PR समीक्षा / इनबॉक्स / दैनिक नमूना / साप्ताहिक समाधान?) इसे लिखें = अपने साथ अनुबंध पर हस्ताक्षर करें

3/ समापन प्रश्न: छह महीने बाद, क्या यह लूप आपको मजबूत बनाएगा (समझ, निर्णय, सिस्टम के लिए समझ) - या आपको एक ऐसी मशीन का देखभाल करने वाला बना देगा जिसे आप पढ़ नहीं सकते? दूसरे से बचने के लिए आपकी क्या योजना है?

4 ऋण और इंजीनियर बने रहना

आपका लूप बन चुका है: यह जागता है, काम ढूंढता है, खुद की आलोचना करता है, याद रखता है, और अपने कल का शेड्यूल खुद बनाता है।

जब एक लूप चलता है, चार चीज़ें चुपचाप जमा होती हैं - और उनकी साझा विशेषता यह है कि उनमें से कोई भी अलार्म नहीं बजाती।

1सत्यापन ऋण          अस्वीकृत आउटपुट जमा हो रहा है
2समझ का क्षय         कोडबेस बढ़ता है, आपका मानसिक मानचित्र नहीं
3संज्ञानात्मक समर्पण  "मुझे अब और जाँच करने का मन नहीं करता"
4टोकन विस्फोट         एक बग पूरी रात घूमता है → आप इसे बिल के रूप में देखते हैं

वे एक दूसरे को पोषित करते हैं: असत्यापित आउटपुट आपकी समझ को कमजोर करता है -> कमजोर समझ समर्पण को आमंत्रित करती है -> समर्पण लूप को अधिक समय तक चलने और अधिक खर्च करने देता है -> जो अधिक असत्यापित आउटपुट उत्पन्न करता है।

अपने नए लूप को उसकी पहली एकल रन से पहले सभी चार के खिलाफ ऑडिट करें:

• मेरा मूल्यांकनकर्ता वास्तव में अस्वीकार करता है - यह सजावट नहीं है।
• मैं एक दिन में एक नमूना PR पढ़ता हूँ और समझा सकता हूँ कि क्या बदला।
• मैंने "यह गलत है" कहने की आदत बनाए रखी।
• मेरी सीमाएँ पहली रन से पहले सेट की गई थीं, पहली बिल के बाद नहीं।

और यहाँ वह हिस्सा है जो सब कुछ तय करता है:

एक ही लूप, दो लोगों द्वारा बनाया गया, विपरीत स्थानों पर समाप्त हो सकता है। एक इसका उपयोग कोड पढ़ते हुए और दिशा बनाए रखते हुए तेज़ी से आगे बढ़ने के लिए करता है - लूप उस निर्णय को बढ़ाता है जो उनके पास पहले से है।

दूसरा उसी लूप का उपयोग विशेष रूप से फिर कभी कुछ न समझने के लिए करता है - छह महीने बाद, पहला अधिक तेज है, और दूसरा एक ऐसी मशीन का देखभाल करने वाला है जिसे वे पढ़ नहीं सकते।

Addy Osmani: "लूप बनाएं, लेकिन इसे ऐसे बनाएं जैसे कोई जो इंजीनियर बने रहने का इरादा रखता है - न कि केवल वह व्यक्ति जो 'गो' दबाता है।"

लूप जनरेशन को लगभग मुफ्त बनाते हैं, जो दुर्लभ रहता है वह है निर्णय: कौन सी योजना सही है, किस लाइन पर रुकना है, कौन सी चीज़ चलती है लेकिन जड़ से गलत है। लूप निर्णय का अवमूल्यन नहीं करता - यह वह सब कुछ छीन लेता है जो निर्णय नहीं है, और केवल वही छोड़ता है।

लूप एक वफादार गुणक है:

समझ लाएं - यह समझ को बढ़ाता है।

आलस्य लाएं - यह आलस्य को बढ़ाता है।

तय करें कि आप क्या बढ़ाना चाहते हैं - इसे बनाने से पहले।

बने रहें!

शुभकामनाएँ :)