मैंने एक /goal कमांड कैसे बनाया और यह मेरे लिए कैसे काम करता है

मेरे अधिकांश AI कोडिंग सत्र एक ही तरह से समाप्त होते थे: एक लंबी बातचीत, अधूरा काम, और मैं यह याद करने की कोशिश करता रहता था कि क्या हुआ था और क्या नहीं। इसलिए मैंने एक कमांड बनाया जिसका नाम है /goal. आप इसे एक बड़ा लक्ष्य देते हैं, और यह तब तक काम करता रहता है जब तक कि लक्ष्य पूरा और जाँचा न जाए, या जब तक कि यह किसी वास्तविक रुकावट (ब्लॉकर) से न टकरा जाए।

आज 9 नवंबर, 2026 है। यह बात अभी इसलिए मायने रखती है क्योंकि AI सहायक बहुत तेज़ी से बहुत सारा कोड लिख सकते हैं, और कठिन हिस्सा कोड लिखने से हटकर उस पर भरोसा करने पर आ गया है। /goal उस समस्या का मेरा समाधान है।

/goal वास्तव में क्या है

यह कोई प्रोग्राम नहीं है। यह लिखित निर्देशों का एक सेट है जिसका पालन सहायक तब करता है जब मैं टाइप करता हूँ /goal और उसके बाद एक लक्ष्य। ये निर्देश एक प्रक्रिया का वर्णन करते हैं, ठीक उसी तरह जैसे कोई चेकलिस्ट यह बताती है कि रिलीज़ कैसे की जाए।

लक्ष्य एक वाक्य का हो सकता है। मेरा नवीनतम लक्ष्य था: "Implement the v1.1 plan for my browser extension in full, phase by phase, commit once per phase, and do not push or deploy without my go-ahead." उस एक वाक्य में काम के दस चरण और लगभग पच्चीस commits शामिल थे।

विचार एक पंक्ति में

अलग-अलग कामों के लिए अलग-अलग मॉडल मिलते हैं, और कोई भी अपने खुद के काम की जांच खुद नहीं करता है।

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

यह कदम दर कदम कैसे काम करता है

चरण 1: प्लानिंग पास

किसी भी कोड से पहले, प्लानर प्रोजेक्ट की जांच करता है: खुले नोट्स, अधूरा काम, git स्थिति और निर्माण व परीक्षण के लिए उपयोग किए जाने वाले कमांड। फिर यह लक्ष्य, एक चेकलिस्ट और प्रत्येक आइटम के लिए एक-पंक्ति की ऐसी जांच के साथ एक ट्रैकर फ़ाइल लिखता है जिसे साबित किया जा सके, जैसे कि कोई ऐसा कमांड जिसे पास होना ज़रूरी है। प्रत्येक आइटम को एक मॉडल टैग भी मिलता है। ट्रैकर सच्चाई का एकमात्र स्रोत (single source of truth) है। यदि बातचीत बहुत लंबी हो जाती है और सहायक भूल जाता है, तब भी ट्रैकर को सब पता होता है।

यह निर्णयों को भी रिकॉर्ड करता है। जब मेरी योजना में ऐसे खुले प्रश्न थे जिनका मैंने उत्तर नहीं दिया था, तो ट्रैकर ने प्रत्येक के लिए चुने गए डिफ़ॉल्ट को सूचीबद्ध किया, ताकि मैं बाद में उन्हें बदल सकूं।

चरण 2: प्रति चरण एक नया एजेंट

प्रत्येक चरण का निर्माण एक नए एजेंट द्वारा किया जाता है। यह कोड लिखता है, बिल्ड और टेस्ट चलाता है, विफलताओं को ठीक करता है, और एक सरल संदेश के साथ एक commit करता है। यह ट्रैकर में अपने आइटमों को टिक करता है। फिर यह रुक जाता है, और अगला चरण बिल्कुल नए सिरे से शुरू होता है।

चरण 3: रिव्यू गेट

जब कोई चरण commit हो जाता है, तो एक अलग समीक्षक ट्रैकर की जांच के अनुसार diff को पढ़ता है। यह क्रम से चार चीजों को देखता है: क्या कोड वास्तव में स्वीकृति जांचों को पूरा करता है, क्या यह सुरक्षित है, क्या यह असामान्य स्थितियों (odd cases) को संभालता है, और क्या दस्तावेज़ (docs) कोड के काम से मेल खाते हैं। यह समस्याओं की एक रैंक की गई सूची देता है, प्रत्येक में एक फ़ाइल, एक पंक्ति और एक-वाक्य का विफलता परिदृश्य होता है।

चरण 4: सुधार और पुन: समीक्षा

पुष्टि की गई समस्याएं सुधार कार्यों (fix tasks) के रूप में एक नए एजेंट के पास जाती हैं। सुधार के बाद, समीक्षक फिर से देखता है। खुली पुष्टि की गई समस्या वाले चरण को पूरा (done) चिह्नित नहीं किया जा सकता है, और पूरे लक्ष्य को पूर्ण नहीं कहा जा सकता है।

चरण 5: ईमानदार रिपोर्ट

अंत में मुझे एक ऐसी रिपोर्ट मिलती है जो केवल तभी COMPLETE कहती है जब हर मानदंड पूरा हो और हर जांच हरी (सफल) हो। अन्यथा यह PARTIAL कहती है और ठीक वही सूची देती है जो गायब है। रिपोर्ट कभी भी बढ़ा-चढ़ाकर नहीं बताती है।

एक वास्तविक प्रोजेक्ट में इसने क्या पकड़ा

यह प्रोजेक्ट एक व्यक्तिगत ब्राउज़र एक्सटेंशन था जो ब्राउज़र टैब का ऑडियो रिकॉर्ड करता है। नए संस्करण ने रिकॉर्डिंग को ब्राउज़र के निजी फ़ाइल सिस्टम में संग्रहीत किया, मुझे नाम से फ़ोल्डरों में सहेजने की अनुमति दी, वीडियो फ़ाइलों की मरम्मत की, और एक लाइब्रेरी पेज जोड़ा।

समीक्षकों ने ऐसे वास्तविक बग खोजे जो परीक्षणों में नहीं मिले थे:

• फ़ोल्डर-सेव सुविधा हर बार बिना बताए पुराने Save As डायलॉग पर वापस चली जाती। बैकग्राउंड पेज जहां सेव चलता था, वह एक्सटेंशन सेटिंग्स नहीं पढ़ सकता है, इसलिए कोड ने चुपचाप डिफ़ॉल्ट विकल्प चुन लिया। परीक्षण पास हो गए क्योंकि वे एक नकली (fake) सेटिंग्स स्टोर का उपयोग कर रहे थे।
• एक मरम्मत चरण एक छोटी की गई फ़ाइल उत्पन्न कर सकता था जो अभी भी अपनी स्वयं की जांच पास कर लेती और फिर मूल फ़ाइल को बदल देती।
• पुनर्प्राप्त रिकॉर्डिंग के फ़ाइल नामों में गलत लंबाई दर्ज हो गई, क्योंकि मरम्मत की गई फ़ाइल में संशोधन की एक नई तिथि होती है।
• एक असफल राइट ऑपरेशन बिना किसी सूचना के शेष रिकॉर्डिंग को छोड़ (ड्रॉप) सकता था।

इनमें से कोई भी असामान्य नहीं था। इनमें से प्रत्येक समस्या हफ्तों बाद एक ऐसी रिकॉर्डिंग के रूप में सामने आती जो गायब थी, छोटी थी या गलत नाम वाली थी।

नियम जो मैंने इसमें लिखे

• प्रश्न पूछने के लिए न रुकें। निर्णय लें, निर्णय को ट्रैकर में लिखें, और जारी रखें।
• अपवाद बाहरी या विनाशकारी कार्य हैं: pushing, deploying, संदेश भेजना, डेटा हटाना, या ऐसा कुछ भी जिसके लिए मेरे पासवर्ड की आवश्यकता हो। वे उस सटीक कमांड के साथ अवरुद्ध (blocked) आइटम बन जाते हैं जिसे मैं चलाऊंगा।
• किसी विफल जांच को पास कराने के लिए उसे कभी अक्षम (disable) न करें, और विफल परीक्षण को कभी न हटाएं।
• कोई असंबंधित सफ़ाई (clean-up) नहीं। केवल वही कोड जो लक्ष्य को पूरा करता हो।
• जब तक मैं कोई फ़्लैग पास न करूँ या ऐसा करने के लिए न कहूँ, तब तक कभी push या release न करें।

निष्कर्ष

/goal मेरे लिए इसलिए काम करता है क्योंकि यह एक अस्पष्ट इच्छा को साबित करने योग्य कदमों की एक ट्रैक की गई सूची में बदल देता है, और क्योंकि जो व्यक्ति किसी हिस्से को बनाता है वह कभी भी उसे मंज़ूरी देने वाला व्यक्ति नहीं होता। यह सहायक को अधिक बुद्धिमान नहीं बनाता है। यह परिणाम को अधिक भरोसेमंद बनाता है और मेरे अपने ध्यान की आवश्यकता को कम करता है।

फायदे

• इनपुट का एक वाक्य काम के एक बड़े, बहु-चरणीय हिस्से को आगे बढ़ा सकता है।
• ट्रैकर लंबे सत्रों और संदर्भ के नुकसान (context loss) के बावजूद बना रहता है।
• स्वतंत्र समीक्षा उन बगों को ढूंढ निकालती है जो लेखक के अपने परीक्षणों से छूट जाते हैं।
• प्रत्येक चरण एक छोटा commit होता है, इसलिए इतिहास को पढ़ना और पूर्ववत करना (undo) आसान होता है।
• अंतिम रिपोर्ट इस बारे में ईमानदार होती है कि क्या सत्यापित किया गया था और क्या नहीं।
• pushing और deploying जैसी जोखिम भरी कार्रवाइयां मेरे नियंत्रण में रहती हैं।

कमियां

• यह धीमा है। इस प्रोजेक्ट में कई घंटे लगे क्योंकि हर चरण में बिल्ड, रिव्यू और फिक्स का एक लूप होता है।
• यह बहुत सारे टोकन का उपयोग करता है, क्योंकि कई एजेंट एक ही कोड को पढ़ते हैं।
• समीक्षक अंतहीन छोटे-छोटे एज केस ढूंढ सकते हैं, इसलिए आपको समीक्षा राउंड पर एक सीमा तय करने की आवश्यकता होती है।
• एक नकली वातावरण में चलने वाले परीक्षण वास्तविक डिवाइस के व्यवहार को साबित नहीं कर सकते हैं। कुछ जांचों के लिए अभी भी किसी व्यक्ति की आवश्यकता होती है।
• एक कमजोर लक्ष्य विवरण एक कमजोर योजना बनाता है। कमांड ऐसे लक्ष्य को ठीक नहीं कर सकता जो अस्पष्ट हो।

सावधानी

यह लेख शैक्षिक है और मेरे अपने सेटअप का वर्णन करता है। नाम, पथ (paths) और प्रोजेक्ट विवरण सामान्यीकृत हैं, और आपके अपने कमांड में किसी भी प्लेसहोल्डर मान को आपके अपने मानों से बदला जाना चाहिए। मॉडल के नाम और टूल का व्यवहार अक्सर बदलता रहता है, इसलिए हर दावे को सत्यापित करें और महत्वपूर्ण काम के लिए इस पर भरोसा करने से पहले एक छोटे, कम जोखिम वाले प्रोजेक्ट पर इस प्रक्रिया का परीक्षण करें।

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

• /goal कमांड क्या है? — यह निर्देशों का एक सहेजा गया सेट है जो एक AI कोडिंग सहायक से एक बड़े लक्ष्य की योजना बनवाता है, उसे तैयार करवाता है, समीक्षा करवाता है और सत्यापित करवाता है, फिर ईमानदारी से रिपोर्ट करता है।
• क्या यह कोई प्रोग्राम या प्लगइन है? — नहीं। यह एक कमांड फ़ाइल में लिखी गई प्रक्रिया है जिसका पालन सहायक करता है, इसलिए आप इसे किसी भी टेक्स्ट दस्तावेज़ की तरह संपादित कर सकते हैं।
• प्रत्येक कार्य के लिए एक अलग मॉडल का उपयोग क्यों करें? — प्लानिंग, रूटीन कोडिंग और सावधानीपूर्वक समीक्षा के लिए अलग-अलग क्षमताओं की आवश्यकता होती है, और प्रत्येक के लिए सही मॉडल का उपयोग करने से लागत बचती है और गुणवत्ता में सुधार होता है।
• हर चरण के लिए एक नया एजेंट क्यों? — एक नया एजेंट लंबी, आंशिक रूप से भूली हुई बातचीत के बजाय ट्रैकर से शुरुआत करता है, जो भटकाव (drift) और पुराने अनुमानों से बचाता है।
• समीक्षक निर्माता (बिल्डर) से अलग क्यों होना चाहिए? — एक लेखक अपने काम पर भरोसा करने की प्रवृत्ति रखता है, इसलिए एक पाठक जिसने कोड नहीं लिखा है वह उन समस्याओं को ढूंढ लेता है जिन्हें लेखक नज़रअंदाज़ कर देता है।
• क्या यह कोड को अपने आप deploy या push करता है? — नहीं। Pushing, releasing और deploying के लिए मेरी स्पष्ट मंज़ूरी की आवश्यकता होती है, और कमांड इसके बजाय उन्हें अवरुद्ध (blocked) चरणों के रूप में सूचीबद्ध करता है।
• जब यह कुछ पूरा नहीं कर पाता तो क्या करता है? — यह उस आइटम को अवरुद्ध (blocked) चिह्नित करता है, सटीक त्रुटि लिखता है और बताता है कि क्या चीज़ इसे अनब्लॉक करेगी, और फिर स्वतंत्र काम पर आगे बढ़ जाता है।
• क्या यह अतिरिक्त समय लगाने लायक है? — बड़े या जोखिम भरे बदलावों के लिए, हाँ, क्योंकि समीक्षा राउंड बग्स को शुरुआत में ही पकड़ लेते हैं। एक छोटे सुधार के लिए, एक सामान्य चैट अधिक तेज़ होती है।

टैग

#ClaudeCode #AICoding #DeveloperWorkflow #CodeReview #Automation #SoftwareEngineering #AIAgents #Productivity #DevTools #BuildInPublic