कैसे प्रश्न पूछें और निर्देश दें: Claude के दिल तक बात कैसे पहुँचाएं

📚 सीरीज़ नेविगेशन: पिछला लेख [14 इंटरफ़ेस और शॉर्टकट्स] आपको अपनी उंगलियों को सही जगह पर रखना सिखाता है—कर्सर, एंटर, Esc, और स्लैश कमांड से परिचित कराता है। यह लेख दृष्टिकोण बदलता है: हाथ अब जानते हैं कि कहाँ दबाना है, मुँह को भी पता होना चाहिए कि क्या कहना है। एक ही मांग को, आपने कैसे कहा है, इसके आधार पर Claude का काम ज़मीन-आसमान का अंतर ला सकता है।

कुछ सच जो शायद सुनने में अच्छे न लगें: बहुत से लोग जब शुरुआत में Claude Code का उपयोग करते हैं, तो वे इसे एक सर्च इंजन की तरह इस्तेमाल करते हैं।

इस परिदृश्य की कल्पना करें: प्रोजेक्ट में एक फ़ंक्शन एरर (error) देता है, और आप बस टाइप करते हैं "इस बग (bug) को फिक्स करो", यह बताए बिना कि कौन सी फ़ाइल है, या कौन सा एरर है, और एंटर दबाकर तमाशा देखने लगते हैं। नतीजतन, वह "अनुमान" लगाता है कि बग क्या हो सकता है, तीन फ़ाइलें बदल देता है, और उनमें से एक भी वह जगह नहीं है जिसे आप वास्तव में फिक्स करना चाहते थे। आप पूरे स्क्रीन पर diff (बदलाव) देखकर भ्रमित हो जाते हैं, और मन ही मन सोचते हैं कि "यह AI किसी काम का नहीं है"।

अगर आप मुड़कर सोचें तो आपको समझ आएगा—समस्या AI में नहीं है। समस्या Claude में बिल्कुल नहीं है, उस वाक्य में है जो इतना खराब था: इसमें जानकारी लगभग शून्य थी, उसे केवल अपने मन से अनुमान लगाना पड़ा। अगर वह गलत अनुमान लगाता है, तो किसे दोष दें?

इसे इस तरह समझिए: Claude Code की क्षमता (ceiling) काफी हद तक आपके प्रश्न पूछने के तरीके पर निर्भर करती है। एक ही मॉडल, एक ही प्रोजेक्ट, जो व्यक्ति मांग (requirement) रखना जानता है वह इसे तीन वाक्यों में करवा लेगा, जो नहीं जानता वह पांच बार आगे-पीछे करेगा और फिर भी निराश होगा। आज, मैं आपको "अपनी मांग को स्पष्ट रूप से बताने" के इन सामान्य संवाद नियमों को गहराई से समझाऊंगा—यह आपको टेम्पलेट रटना नहीं सिखा रहा है, बल्कि यह समझना सिखा रहा है कि 'Claude को वास्तव में क्या जानने की आवश्यकता है ताकि वह गलत दिशा में न जाए'।

इस लेख को पढ़ने के बाद, आपको मिलेगा:

• एक "खराब प्रॉम्ट (prompt) vs अच्छा प्रॉम्ट" तुलना तालिका, जिसके अनुसार आप सुधार कर सकते हैं और रीवर्क (rework) की दर कम कर सकते हैं
• मांग रखने के चार मुख्य नियम: विशिष्ट होना, संदर्भ (context) देना, स्वीकृति मानदंड (acceptance criteria) देना, जटिल कार्यों के लिए पहले योजना बनाना
• @ का उपयोग करके फ़ाइलों को संदर्भित करने और दायरे (scope) को सटीक बनाने का सही तरीका
• एक प्रयोग जिसे आप आज़मा सकते हैं, "एक ही मांग के दो तरीके", जिससे आप अंतर अपनी आँखों से देख सकेंगे

---

01 खराब प्रॉम्ट आख़िर कहाँ खराब होता है

आइए ऊपर बताए गए फ्लॉप (flop) को करीब से देखें। "इस बग को फिक्स करो" यह वाक्य, Claude के दृष्टिकोण से, इसमें जानकारी की बहुत ज़्यादा कमी है:

• कौन सा बग? उसे खुद अनुमान लगाना होगा कि आप किस जगह की बात कर रहे हैं।
• कौन सी फ़ाइल? उसे पूरे प्रोजेक्ट में ढूँढना होगा।
• अपेक्षित सही व्यवहार क्या है? उसे बिल्कुल नहीं पता, उसे बस इस आधार पर अनुमान लगाना होगा कि "सामान्य तौर पर क्या होना चाहिए"।

उपमा: एक नए इंटर्न (intern) को गाइड करना। आप एक नए कर्मचारी से कहें, "उस चीज़ को ठीक कर दो," और वह उसे सही कर दे, यह एक चमत्कार होगा। लेकिन अगर आप कहें, "होमपेज के ऊपर दाईं ओर वाले लॉगिन बटन का रंग ग्रे से ब्रांड ब्लू #1A73E8 में बदल दो," तो वह आँख बंद करके भी इसे सही करेगा। निर्देश जितने विशिष्ट होंगे, इंटर्न के गलत दिशा में जाने की संभावना उतनी ही कम होगी; आप जितने अस्पष्ट निर्देश देंगे, उसे उतना ही अधिक अनुमान लगाना पड़ेगा, और गलत होने की संभावना उतनी ही अधिक होगी। Claude बिल्कुल ऐसा ही है।

आधिकारिक दस्तावेज़ में बार-बार ज़ोर दी गई इस तुलना को देखें (आधिकारिक अर्थ के अनुसार अनुवादित):

परिदृश्य	❌ खराब प्रॉम्ट	✅ अच्छा प्रॉम्ट
बग फिक्स	"लॉगिन एरर को फिक्स करो"	"उपयोगकर्ताओं ने रिपोर्ट किया है कि सेशन टाइमआउट के बाद लॉगिन फेल हो जाता है। src/auth/ में ऑथेंटिकेशन फ्लो (authentication flow) चेक करो, खास तौर पर टोकन रिफ्रेश (token refresh) पर ध्यान दो। पहले एक फेलिंग टेस्ट (failing test) लिखो जो समस्या को दोहराए, फिर उसे फिक्स करो"
टेस्ट लिखना	"foo.py के लिए टेस्ट जोड़ो"	"foo.py के लिए टेस्ट लिखो, उपयोगकर्ता के लॉग आउट होने की सीमा स्थिति (edge case) को कवर करो, mock का उपयोग मत करो"
कोड के बारे में पूछना	"ExecutionFactory का यह बेकार API ऐसे क्यों डिज़ाइन किया गया है?"	"ExecutionFactory का git इतिहास देखो, और संक्षेप में बताओ कि इसका API धीरे-धीरे विकसित होकर वर्तमान स्थिति तक कैसे पहुँचा"
सुविधा (feature) जोड़ना	"एक कैलेंडर कंपोनेंट (calendar component) जोड़ो"	"पहले देखो कि होमपेज पर मौजूदा कंपोनेंट्स कैसे लागू (implement) किए गए हैं, HotDogWidget.php एक अच्छा उदाहरण है। इस पैटर्न के अनुसार एक कैलेंडर कंपोनेंट बनाओ, जिसमें उपयोगकर्ता महीना चुन सकें और आगे-पीछे जा सकें। कोडबेस में पहले से मौजूद लाइब्रेरीज़ के अलावा, किसी नई लाइब्रेरी का उपयोग न करें"

क्या आपने पैटर्न देखा? अच्छा प्रॉम्ट एक ही काम करता है: जिन चीज़ों का Claude को अनुमान लगाना पड़ता, उन्हें पहले ही उसे दे देना।

💡 संक्षेप में: खराब प्रॉम्ट इसलिए खराब होता है क्योंकि "जानकारी की कमी Claude के अनुमान पर छोड़ दी जाती है", अच्छा प्रॉम्ट वह है जहाँ आप उसे पहले ही स्पष्ट रूप से बता देते हैं कि उसे क्या अनुमान लगाना पड़ सकता है।

यह Before/After एक ही मांग के दो तरीकों को एक साथ दिखाता है: बाईं ओर अस्पष्ट प्रॉम्ट है, Claude को केवल अनुमान लगाना पड़ता है और कई सवाल पूछने पड़ते हैं; दाईं ओर स्कोप (scope), संदर्भ (context) (@फ़ाइल), और स्वीकृति मानदंड (acceptance criteria) तीनों को एक साथ दिया गया है, वह पहली बार में ही इसे सही करता है और सीधे टेस्ट पास करता है। अंतर Claude में नहीं है, आपके बोलने के तरीके में है।

---

02 नियम एक: विशिष्ट > अस्पष्ट

यह चार नियमों में सबसे महत्वपूर्ण है, इसके बिना कुछ नहीं।

आधिकारिक दस्तावेज़ में एक वाक्य है जिसे याद रखना चाहिए, मूल शब्द हैं:

आपके निर्देश जितने सटीक (precise) होंगे, आपको उतने ही कम सुधार (corrections) की आवश्यकता होगी।

सरल शब्दों में: शुरुआत में एक अतिरिक्त वाक्य कहें, बाद में तीन राउंड का रीवर्क (rework) बचाएं। आपको लगता है कि "समय बचाने" के लिए कम शब्द टाइप करना अच्छा है, लेकिन वो जो शब्द आपने नहीं टाइप किए, वे बाद में आगे-पीछे बहस करने की कीमत बन जाते हैं जो आपको दोगुना चुकानी पड़ती है।

कितना विशिष्ट होना चाहिए? तीन आयामों को इसमें शामिल करें:

पहला, स्कोप (दायरा) निर्धारित करें—कौन सी फ़ाइल, कौन सा फ़ंक्शन (function), कौन सा परिदृश्य (scenario)। उसे पूरे प्रोजेक्ट में सुई खोजने के लिए मत छोड़ें।

दूसरा, बाधाओं (constraints) को स्पष्ट करें—"कोई नई लाइब्रेरी मत जोड़ो", "बैकवर्ड कम्पैटिबिलिटी (backward compatibility) बनाए रखो", "टेस्ट फ़ाइलों को मत छुओ"। यदि आप नहीं बताते हैं, तो वह अपनी प्राथमिकताओं के अनुसार काम करेगा, जो शायद आपके मनमुताबिक न हो।

तीसरा, एक संदर्भ (reference) दें—"HotDogWidget.php वाले पैटर्न को अपनाओ"। यह तरीका परीक्षण के बाद सबसे अधिक चिंता-मुक्त पाया गया है: आप अपनी मनचाही शैली का वर्णन करने के लिए शब्दों का उपयोग करने के बजाय, उसे सीधे एक तैयार उदाहरण (existing example) दें जिससे आप पहले से संतुष्ट हैं, और वह उसकी नकल करेगा, जो लगभग बिल्कुल वैसा ही होगा।

यहाँ एक काउंटर-इंट्यूटिव (counter-intuitive) अपवाद है जिसे स्पष्ट किया जाना चाहिए: अस्पष्ट प्रॉम्ट बिल्कुल गलत नहीं है। जब आप "खोज (exploration) चरण" में होते हैं और आपने खुद दिशा तय नहीं की होती है, तो एक खुला प्रश्न जैसे "आपको क्या लगता है कि इस फ़ाइल में क्या सुधार किया जा सकता है?" अप्रत्याशित रूप से कुछ ऐसी चीज़ें ला सकता है जिनके बारे में आपने पूछा भी नहीं था। आधिकारिक शब्दों में, "जब आप एक्सप्लोर कर रहे हों और दिशा को सही कर सकते हों, तो अस्पष्ट प्रॉम्ट उपयोगी हो सकते हैं"। नियम यह है: जब परिणाम चाहिए तो अत्यधिक विशिष्ट रहें, जब प्रेरणा खोज रहे हों तो जानबूझकर खुला छोड़ दें।

एक छोटा सा टूल बनाते समय इस सीमा को पार करना आसान है—शुरुआत में आप देखना चाहते हैं कि Claude उस अव्यवस्थित कोड को कैसे समझता है, तो जानबूझकर अस्पष्ट पूछें, उसके द्वारा सुझाए गए सुधार वास्तव में प्रेरणादायक हो सकते हैं; लेकिन एक बार जब आपके मन में एक स्पष्ट लक्ष्य हो, तो अस्पष्ट प्रॉम्ट का उपयोग करना केवल समय बर्बाद करना है, उसे हर बार फिर से अनुमान लगाना होगा कि आपको वास्तव में क्या चाहिए।

💡 संक्षेप में: जब आप सुनिश्चित परिणाम चाहते हैं तो अत्यधिक विशिष्ट रहें (स्कोप + बाधाएं + संदर्भ), और केवल तभी खुला छोड़ें जब आप सक्रिय रूप से प्रेरणा खोज रहे हों।

---

03 नियम दो: संदर्भ (Context) दें, उसे अंधाधुंध अनुमान न लगाने दें

विशिष्ट होने के अलावा, दूसरी चाल है "सामग्री (material)" सीधे उसके मुँह में देना, न कि शब्दों से यह बताना कि "सामग्री" कहाँ है।

दो सबसे अधिक उपयोग किए जाने वाले कार्य, जिन्हें याद रखना आधे से अधिक काम कर देगा:

पहला, @ का उपयोग करके फ़ाइलों को संदर्भित (reference) करें। इनपुट बॉक्स में @ टाइप करें, फ़ाइल पथ ऑटो-कम्प्लीशन (auto-completion) पॉप अप होगा, चुनने के बाद उस फ़ाइल की पूरी सामग्री सीधे बातचीत में डाल दी जाएगी—Claude को पहले उसे खोजने और फिर पढ़ने की ज़रूरत नहीं है, यह एक कदम बचाता है और गलतियाँ नहीं करता।

@src/types/user.ts में टाइप डेफिनिशन (type definitions) को देखें, और UserService में टाइप एनोटेशन (type annotations) जोड़ें

यह "प्रोजेक्ट में एक उपयोगकर्ता टाइप (user type) फ़ाइल है, इसे ढूंढें" कहने से दस हज़ार गुना अधिक विश्वसनीय है। आधिकारिक दस्तावेज़ स्पष्ट रूप से बताता है कि @ संदर्भ "उत्तर देने से पहले फ़ाइल की पूरी सामग्री को पढ़ता है"।

उपमा: USB पोर्ट। @ एक "फ़ाइल USB ड्राइव" को सीधे Claude के वर्कबेंच में प्लग करने जैसा है—प्लग एंड प्ले (plug and play), जिस सामग्री की उसे आवश्यकता है वह एक सेकंड में मौजूद है; यदि आप केवल अपने मुँह का उपयोग करके कहते हैं कि "सामग्री तीसरी मंजिल के पुरालेख कक्ष के दूसरे कैबिनेट में है," तो उसे खुद वहां जाना होगा, और गलत जगह जाने से काम में और देरी होगी।

दूसरा, एरर (error) को पूरी तरह से पेस्ट करें। इसे अपनी मांसपेशियों की स्मृति (muscle memory) का हिस्सा बनाएं—जब भी आपको कोई ट्रैसबैक (traceback) मिले, "इसने नल पॉइंटर (null pointer) एरर दिया है" कहकर इसे संक्षेप में न बताएं, पूरा स्टैक (stack) वैसा का वैसा चिपका दें:

रनटाइम (runtime) पर यह एरर आ रहा है, कारण ढूँढने में मेरी मदद करें:
TypeError: Cannot read properties of null (reading 'userId')
    at getUserProfile (src/services/user.ts:42:18)
    at async ProfileController.getProfile (src/controllers/profile.ts:15:20)

पूरा स्टैक क्यों पेस्ट करें? क्योंकि स्टैक में फ़ाइल का नाम, लाइन नंबर और कॉल चेन (call chain) सब कुछ होता है, और Claude user.ts:42 का पालन करके सटीक रूप से समस्या का पता लगा सकता है। यदि आप इसे संक्षेप में बताते हैं, तो आप इन सभी महत्वपूर्ण निर्देशांक (coordinates) को हटा रहे हैं, और उसे फिर से खरोंच से अनुमान लगाना होगा।

आप जो सामग्री देना चाहते हैं	❌ मुँह से वर्णन करें	✅ सीधे दें
किसी फ़ाइल की सामग्री	"प्रोजेक्ट में ऑथेंटिकेशन (authentication) को हैंडल करने वाली एक फ़ाइल है"	@src/auth/session.ts
एक एरर (Error)	"यह undefined का एरर दे रहा है"	पूरा traceback वैसा का वैसा पेस्ट करें
एक UI समस्या	"बटन की स्थिति गलत है"	सीधे स्क्रीनशॉट चिपकाएँ (Claude छवियों को पढ़ने का समर्थन करता है)
एक API विनिर्देश (specification)	"हमारे API स्पेसिफिकेशन का पालन करें"	@docs/api-spec.md

एक वाक्य में: जो कुछ भी "पेस्ट" किया जा सकता है, उसके लिए कभी भी "बोलने" का उपयोग न करें। Claude का स्रोत सामग्री को पढ़ना, आपके द्वारा उस सामग्री के दूसरे हाथ के वर्णन को पढ़ने से हमेशा अधिक सटीक होता है।

💡 संक्षेप में: फ़ाइलों को संदर्भित करने के लिए @ का उपयोग करें, एरर और स्क्रीनशॉट को सीधे उसके सामने पेस्ट करें, उसे आपके वर्णन के आधार पर अनुमान लगाने न दें।

---

04 नियम तीन: एक "सत्यापन योग्य (verifiable)" सफलता मानदंड (criteria) दें

इसे आसानी से अनदेखा कर दिया जाता है, लेकिन यह बहुत शक्तिशाली है: आपको Claude को बताना होगा कि "कैसा दिखने पर काम सफल माना जाएगा", और आदर्श रूप से यह ऐसा मानदंड होना चाहिए जिसे वह खुद सत्यापित कर सके।

यह क्यों महत्वपूर्ण है? आधिकारिक दस्तावेज़ ने इसके मूल तर्क को स्पष्ट किया है—

जब काम पूरा हुआ प्रतीत होता है, तो Claude रुक जाता है। यदि कोई ऐसा चेक (check) नहीं है जिसे वह चला सके, तो "पूरा हुआ प्रतीत होना" एकमात्र उपलब्ध संकेत है, और आप सत्यापन लूप (verification loop) बन जाते हैं: प्रत्येक एरर आपके ध्यान देने का इंतजार कर रहा होता है।

इसका क्या मतलब है? यदि आप कोई मानक (standard) नहीं देते हैं, तो Claude इस भावना के आधार पर रुक जाएगा कि "यह लगभग हो गया है", और आप वह व्यक्ति होंगे जिसे अंतिम रूप से काम को स्वीकार करना होगा, आपको प्रत्येक बग को व्यक्तिगत रूप से पकड़ना होगा। लेकिन एक बार जब आप उसे "पास / फेल" (pass / fail) वाला चेक दे देते हैं, तो यह लूप अपने आप बंद (close) हो जाता है: वह काम पूरा करता है → चेक चलाता है → परिणाम देखता है → यदि पास नहीं हुआ, तो वह सुधारना जारी रखता है, आपको उसे देखने की आवश्यकता भी नहीं है।

तुलना करें और आप समझ जाएंगे:

कार्य	❌ कोई स्वीकृति मानदंड नहीं	✅ सत्यापन योग्य मानदंड दिया गया
फ़ंक्शन लिखना	"ईमेल को वैलिडेट (validate) करने वाला फ़ंक्शन लागू करें"	"एक validateEmail फ़ंक्शन लिखें। टेस्ट केस: user@example.com के लिए true, invalid के लिए false, user@.com के लिए false होना चाहिए। काम पूरा होने पर टेस्ट रन करें"
UI बदलना	"इस डैशबोर्ड को बेहतर बनाएं"	"[डिज़ाइन का स्क्रीनशॉट पेस्ट करें] इसे इसके अनुसार लागू करें, फिर परिणाम का स्क्रीनशॉट लें, इसकी तुलना मूल चित्र से करें, अंतरों की सूची बनाएं और उन्हें ठीक करें"
बिल्ड (Build) फिक्स करना	"बिल्ड फेल हो गया है"	"बिल्ड में यह एरर है: [एरर पेस्ट करें]। इसे फिक्स करें और सत्यापित करें कि बिल्ड पास हो गया है। मूल कारण को हल करें, एरर को दबाएं नहीं"

अंतिम पंक्ति के उस वाक्य पर ध्यान दें "मूल कारण को हल करें, एरर को दबाएं नहीं" - यह एक ऐसा वाक्य है जिसे मैंने नुकसान उठाने के बाद जोड़ना सीखा है। यदि आप यह वाक्य नहीं लिखते हैं, तो कभी-कभी यह सुविधा के लिए सीधे try/except का उपयोग करेगा, या लाल रेखा को हटाने के लिए @ts-ignore जोड़ देगा, एरर तो चला जाएगा, लेकिन मूल समस्या अभी भी वहीं रहेगी।

उन्नत तरीका (Advanced): /goal के उपयोग से स्वीकृति मानदंड को "लक्ष्य पूरा न होने तक काम बंद न करें" में बदलें। (इसके लिए Claude Code v2.1.139 या उच्चतर की आवश्यकता है) सामान्य प्रॉम्ट में स्वीकृति मानदंड लिखना "इस राउंड के लिए रन करना" है; जबकि /goal इस मानदंड को पूरे सेशन के लक्ष्य के रूप में सेट करता है—प्रत्येक राउंड के बाद, एक छोटा मॉडल (डिफ़ॉल्ट रूप से Haiku) आपकी शर्तों के आधार पर इसे फिर से चेक करेगा, यदि यह पूरा नहीं होता है, तो यह स्वचालित रूप से अगला राउंड शुरू करेगा, और आपको नियंत्रण वापस नहीं देगा, जब तक कि शर्तें पूरी न हो जाएं।

/goal test/auth में सभी टेस्ट पास होने चाहिए, और lint स्टेप एकदम साफ़ होना चाहिए

/goal का उपयोग करते समय एक महत्वपूर्ण विवरण है: वह छोटा मूल्यांकन मॉडल (evaluator model) केवल उसी को देखता है जो Claude बातचीत में "दिखाता" है, वह खुद कमांड रन नहीं करेगा या फ़ाइलें नहीं पढ़ेगा। इसलिए आपकी शर्त ऐसी होनी चाहिए जिसे Claude का अपना आउटपुट साबित कर सके—"test/auth टेस्ट सभी पास हो गए" इसलिए काम करता है क्योंकि Claude वास्तव में टेस्ट रन करेगा, परिणाम बातचीत में प्रिंट होगा, और मूल्यांकन मॉडल इसे पढ़ सकेगा। यदि आप लिखते हैं "कोड की गुणवत्ता बहुत अधिक है", जिसे आउटपुट से नहीं देखा जा सकता, तो वह इसका मूल्यांकन नहीं कर पाएगा।

💡 संक्षेप में: उसे एक ऐसा चेक (check) दें जो पास / फेल का परिणाम दे सके (टेस्ट, स्क्रीनशॉट तुलना, बिल्ड एग्जिट कोड), ताकि लूप अपने आप बंद हो जाए; अगर आप चाहते हैं कि वह "लक्ष्य पूरा होने तक हार न माने", तो /goal का उपयोग करें।

---

05 नियम चार: जटिल कार्यों के लिए, काम शुरू करने से पहले उससे योजना बनाने (Plan) के लिए कहें

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

इसका उल्लेख अध्याय 06 (योजनाएं और बिलिंग) में किया गया था, यहाँ हम इसके कारण को स्पष्ट करेंगे। आधिकारिक दस्तावेज़ का निष्कर्ष बहुत स्पष्ट है:

Claude को सीधे प्रोग्रामिंग करने के लिए कहने से वह गलत समस्या को हल करने वाला कोड बना सकता है।

सरल शब्दों में, पहले अन्वेषण (explore) करें, फिर योजना (plan) बनाएं, और अंत में प्रोग्रामिंग (programming) करें—ताकि वह गलत दिशा में तेज़ी से आगे न बढ़े, और जब आपको पता चले तब तक वह बहुत सी फ़ाइलें बदल चुका हो।

उपमा: घर का नवीनीकरण (renovation) करते समय दीवार तोड़ने से पहले ब्लूप्रिंट बनाना। कोई भी समझदार ठेकेदार बिना कुछ कहे हथौड़ा लेकर लोड-बियरिंग (load-bearing) दीवार को नहीं तोड़ेगा। वह पहले आपसे पुष्टि करेगा कि "इस दीवार को तोड़ना है, यहाँ से तार जाएंगे, पानी के पाइप को यहाँ से मोड़ा जाएगा," और जब आप हाँ कहेंगे तभी वह काम शुरू करेगा। योजना (Plan), दीवार तोड़ने से पहले Claude द्वारा आपको सौंपा गया वह ब्लूप्रिंट है—ब्लूप्रिंट पर गलती मिलने पर उसे ठीक करने की लागत, दीवार टूटने के बाद सुधार करने की लागत से बहुत कम होती है।

उसे ब्लूप्रिंट बनाने के लिए कैसे कहें? दो तरीके हैं:

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

मैं सेटिंग्स पेज में डार्क मोड (dark mode) स्विच जोड़ना चाहता हूँ। पहले मुझे बताएं कि किन फ़ाइलों को बदलना होगा और बदलाव का तरीका क्या होगा,
इस चरण में अभी कोई कोड न बदलें।

तरीका दो, Plan Mode (योजना मोड) में स्विच करें। यह Claude Code का "केवल-पढ़ने के लिए योजना (read-only plan)" मोड है—यह फ़ाइलों को पढ़ेगा, प्रस्ताव देगा, लेकिन जब तक आप इसे स्वीकृति (approve) नहीं देते, वह एक भी शब्द नहीं लिखेगा। इसे दर्ज करने का तरीका: सत्र में Shift + Tab दबाएं (एक या दो बार दबाकर Plan Mode में जाएं), मोड default → acceptEdits → plan के बीच घूमेगा। यदि आप केवल एक प्रॉम्ट को Plan Mode में चलाना चाहते हैं और पूरे सत्र को स्विच नहीं करना चाहते हैं, तो उस संदेश के सामने /plan प्रीफिक्स (prefix) जोड़ें।

हालाँकि, आधिकारिक टीम ने एक बहुत ही व्यावहारिक चेतावनी भी दी है, चरम सीमाओं पर न जाएं और हर चीज़ के लिए योजना न बनाएं:

स्पष्ट दायरे वाले और छोटे फिक्स वाले कार्यों के लिए (जैसे स्पेलिंग की गलतियों को ठीक करना, लॉग लाइनें जोड़ना, या वैरिएबल का नाम बदलना), Claude को सीधे कार्य निष्पादित करने के लिए कहें। योजना तब सबसे उपयोगी होती है जब आप तरीके (approach) के बारे में अनिश्चित हों, बदलाव कई फ़ाइलों को प्रभावित करता हो, या आप बदले जाने वाले कोड से अपरिचित हों। यदि आप एक वाक्य में diff का वर्णन कर सकते हैं, तो योजना छोड़ दें।

सबसे व्यावहारिक तरीका यह अंतिम आधा वाक्य है: "क्या मैं एक वाक्य में स्पष्ट रूप से बता सकता हूँ कि बदलाव के बाद यह कैसा दिखेगा?" यदि हाँ, तो सीधे काम करें; यदि आप अटक जाते हैं, तो इसका मतलब है कि कार्य काफी जटिल है, पहले उसे योजना बनाने दें। स्पेलिंग की गलती सुधारने के लिए भी Plan Mode का उपयोग करना, खुद के लिए काम बढ़ाना है।

💡 संक्षेप में: अनिश्चित / क्रॉस-फ़ाइल / अपरिचित कोड → पहले उसे एक योजना बनाने दें (एक वाक्य में कहें "अभी बदलाव न करें" या Shift+Tab दबाकर Plan Mode में प्रवेश करें); छोटे काम जिन्हें आप एक वाक्य में स्पष्ट कर सकते हैं, उन्हें सीधे करें।

---

06 हैंड्स-ऑन: एक ही मांग, दो तरीकों में अंतर देखें

केवल सिद्धांत सुनने से काम नहीं चलेगा, आइए एक छोटा सा प्रयोग करें जहाँ आप अपनी आँखों से अंतर देख सकें। बस तीन पंक्तियों वाली एक टॉय फ़ाइल (toy file) तैयार करें, यह आपके किसी मौजूदा प्रोजेक्ट पर निर्भर नहीं करती है। टर्मिनल खोलें और इसका पालन करें।

पहला कदम: एक "बग" वाली टॉय फ़ाइल बनाएं (Mac / Linux)

mkdir prompt-demo
cd prompt-demo
echo 'def average(nums):
    return sum(nums) / len(nums)' > stats.py

Windows उपयोगकर्ता: mkdir prompt-demo और cd prompt-demo टाइप करें, stats.py को नोटपैड का उपयोग करके बनाएं और उसमें उन दो पंक्तियों को पेस्ट करें।

इस फ़ंक्शन (function) में एक बग है: जब एक खाली सूची (empty list) [] पास की जाती है, तो len(nums) 0 होता है, और यह "शून्य से विभाजन (divide by zero)" क्रैश ट्रिगर करेगा। हम इसे अपनी टेस्टिंग के लिए उपयोग करेंगे।

दूसरा कदम: प्रोजेक्ट डायरेक्टरी में Claude शुरू करें

claude

अपेक्षित परिणाम: वेलकम स्क्रीन दिखाई देती है, जिसके नीचे एक इनपुट बॉक्स है।

तीसरा कदम: पहले "खराब प्रॉम्ट" का उपयोग करें, और देखें कि वह कैसे अनुमान लगाता है

@stats.py इस फ़ंक्शन को ठीक करने में मेरी मदद करें

अपेक्षित परिणाम: इस बात की बहुत अधिक संभावना है कि Claude "अनुमान" लगाएगा कि आप क्या करना चाहते हैं—शायद टाइप एनोटेशन (type annotations) जोड़ना, या डॉकस्ट्रिंग (docstring) जोड़ना, लेकिन उसे नहीं पता कि आप वास्तव में उस खाली सूची क्रैश की परवाह करते हैं, इसलिए वह पूरी तरह से किस्मत के भरोसे दिशा चुनेगा। यह अस्पष्ट प्रॉम्ट की कीमत है: वह आपके लिए निर्णय ले रहा है।

चौथा कदम: "अच्छा प्रॉम्ट" अपनाएँ—विशिष्ट + संदर्भ + स्वीकृति मानदंड तीनों का उपयोग करें

@stats.py में average फ़ंक्शन में एक बग है: जब एक खाली सूची पास की जाती है तो शून्य से विभाजन के कारण क्रैश हो जाता है।
अपेक्षित व्यवहार यह है कि खाली सूची 0 वापस करे।
इसे फिक्स करने में मेरी मदद करें, और एक टेस्ट जोड़ें: average([]) को 0 वापस करना चाहिए, average([2, 4]) को 3 वापस करना चाहिए।
लिखने के बाद टेस्ट को रन करें, और पुष्टि करें कि यह पास हो गया है।

अपेक्षित परिणाम: इस बार Claude की एक्शन चेन (action chain) बहुत स्पष्ट है—खाली सूची ब्रांच का पता लगाना → खाली होने पर 0 वापस करने का लॉजिक जोड़ना → आपके द्वारा बताए गए दो टेस्ट केस (test cases) लिखना → वास्तव में टेस्ट रन करना → पास होने का परिणाम आपको दिखाना। वह अब अनुमान नहीं लगाता कि आपको क्या चाहिए, क्योंकि आपने स्पष्ट कर दिया है कि "कहाँ फिक्स करना है, कैसा बनाना है, और सफल किसे माना जाएगा"।

पाँचवाँ कदम: बाहर निकलें, और देखें कि क्या बदलाव लागू हुए हैं

cat stats.py

(Windows PowerShell के लिए type stats.py का उपयोग करें)

अपेक्षित परिणाम: stats.py में, खाली सूची के लिए लॉजिक जुड़ गया है (कुछ इस तरह if not nums: return 0)। यह आपके चौथे कदम की मांग से मेल खाता है = अब आप "बात स्पष्ट करने" का तरीका समझ गए हैं।

दोनों प्रॉम्ट्स को अगल-बगल रखें, और अंतर स्पष्ट है:

	तीसरा कदम ❌ खराब प्रॉम्ट	चौथा कदम ✅ अच्छा प्रॉम्ट
कहाँ बदलना है	नहीं बताया, वह पूरी फ़ाइल में अनुमान लगाता है	average फ़ंक्शन का नाम स्पष्ट रूप से लिया
क्या बदलना है	नहीं बताया, उसने अपने मन से काम किया	खाली सूची 0 वापस करेगी, स्पष्ट रूप से बताया गया है
सफल कैसे माना जाएगा	कोई मानदंड नहीं, "लगने" पर काम रोक दिया गया	दो टेस्ट केस + सत्यापन के लिए एक बार रन करना
आपका अनुभव	diff देखकर सोचना "मुझे यह नहीं चाहिए था"	वह आपकी स्क्रिप्ट (script) के अनुसार काम करता है, एक बार में पास

💡 संक्षेप में: एक ही फ़ाइल, एक ही बग, खराब प्रॉम्ट Claude को आपके लिए निर्णय लेने देता है, अच्छा प्रॉम्ट स्पष्ट रूप से बताता है "क्या बदलना है, कैसा बनाना है, और सफल किसे माना जाएगा" — इन दो चरणों को खुद करने से अंतर स्पष्ट हो जाएगा, जो दस बार सिद्धांत पढ़ने से भी ज़्यादा कामगर है।

---

07 सारांश

इस लेख में बस एक ही बात बताई गई है: Claude को एक वाक्य में अपनी मांग इस तरह कैसे बताएं कि वह उसे सटीक रूप से समझ सके।

चार नियमों का निष्कर्ष, अगर आप उन्हें याद नहीं रख सकते हैं तो बस इस टेबल को याद रखें:

नियम	एक वाक्य में	इसे कैसे लागू करें
विशिष्ट > अस्पष्ट	दायरा (scope) + बाधाएं + संदर्भ स्पष्ट रूप से बताएं	" average को बदलें, नई लाइब्रेरी का उपयोग न करें, xxx के पैटर्न का पालन करें"
संदर्भ (Context) दें	जो पेस्ट किया जा सकता है उसे मुँह से न बताएं	@फ़ाइल, पूरा एरर पेस्ट करें, स्क्रीनशॉट चिपकाएँ
स्वीकृति मानदंड (Acceptance criteria) दें	उसे खुद "पास / फेल" का सत्यापन करने दें	टेस्ट केस दें, उसे रन करने के लिए कहें; और कड़ा करना हो तो /goal का उपयोग करें
पहले योजना बनाएं	बड़े कार्यों के लिए, दीवार तोड़ने से पहले ब्लूप्रिंट देखें	एक वाक्य में कहें "अभी बदलाव न करें" या Shift+Tab दबाकर Plan Mode में प्रवेश करें

अब आप सक्षम होने चाहिए: एक अस्पष्ट "मेरी मदद करो" को एक ऐसी मांग में अनुवादित करने में जिसे Claude वास्तव में संभाल सके—दायरा (scope) निर्धारित करें, पर्याप्त संदर्भ (context) दें, सत्यापन योग्य (verifiable) सफलता मानदंड दें, और जटिल कार्यों के लिए पहले उसे योजना (plan) बनाने के लिए कहें। यह संवाद नियम Claude Code के साथ भविष्य में आपके सभी कार्यों का "आधार (foundation)" है—फीचर्स कितने भी आकर्षक क्यों न हों, यदि दिया गया प्रॉम्ट खराब है, तो परिणाम भी अच्छा नहीं होगा।

इसके विपरीत सोचने के लिए एक प्रश्न: चूँकि "अपनी बात स्पष्ट करना" इतना महत्वपूर्ण है, क्या आपको कुछ नियम (जैसे "इस प्रोजेक्ट में कभी भी नई लाइब्रेरी का उपयोग न करें" या "टेस्ट हमेशा tests/ डायरेक्टरी में रखे जाने चाहिए") हर बार दोहराने पड़ते हैं? क्या Claude को इन्हें "याद रखने" का कोई तरीका है, ताकि आपको उन्हें बार-बार दोहराना न पड़े?

---

अगला लेख 16 "आम वर्कफ़्लो (Common Workflows)"—इस लेख ने आपको "एक वाक्य को स्पष्ट रूप से कहने" के सामान्य नियम सिखाए हैं, अगला लेख इन नियमों को चार सबसे अधिक आवृत्ति वाले (high-frequency) विशिष्ट कार्यों पर लागू करेगा: अपरिचित कोडबेस को समझना, बग फिक्स करना, रीफैक्टरिंग (refactoring), टेस्ट लिखना, और प्रत्येक प्रकार के लिए आपको एक मानक (standard) दृष्टिकोण देगा जिसे आप सीधे लागू कर सकते हैं। नियम तैयार हैं, अब समय आ गया है कि हम चालें (moves) सीखें।

---

अनुशंसित पठन

• चार सबसे आम काम: कोडबेस एक्सप्लोर करना, बग फिक्स करना, रीफैक्टरिंग, टेस्ट लिखना
• उप-एजेंट (Subagents): काम को आउटसोर्स करें, सब कुछ खुद न करें
• डेवलपमेंट कॉन्फ़िगरेशन (Development Config): Claude के "कार्य वातावरण (work environment)" को सुचारू रूप से सेट करना