Claude Code से बेहतर परिणाम कैसे पाएँ

Claude Code से बेहतर परिणाम पाने के लिए हर अनुरोध को इंजीनियरिंग ब्रीफ़ मानें: उसे प्रासंगिक संदर्भ दें, कोड बदलने से पहले जाँचने को कहें, समाधान को सीमित करें और परिणाम के काम करने का साक्ष्य माँगें। यही तरीका bug fixes, refactors, tests और documentation को भी बेहतर बनाता है।

Claude Code के वर्तमान दस्तावेज़ में codebases को समझने, debugging, refactoring, testing और संपादन से पहले planning के लिए workflows शामिल हैं। इन क्षमताओं का उपयोग अनिश्चितता घटाने के लिए करें, उस तर्क को छोड़ने के लिए नहीं जिसकी किसी teammate को आवश्यकता होगी।

“इस hook को global store से बदलें” कार्यान्वयन-प्रथम प्रॉम्प्ट है। सहायक के ownership और failure mode जाँचने से पहले ही यह समाधान चुन लेता है।

इस तरह शुरू करें:

समस्या: navigation के बाद lesson completion indicator कभी-कभी गायब हो जाता है।

देखा गया: completion event रिकॉर्ड होता है, लेकिन अगली स्क्रीन
celebratory state के बिना शुरू होती है।
अपेक्षित: completion event उसके बाद होने वाले navigation में उपलब्ध रहता है,
फिर उचित boundary पर साफ़ होता है।

दायरा: lesson store, completion handler और next-screen
transition जाँचें। असंबंधित dashboard progress code न बदलें।

संपादन से पहले event को write से render तक ट्रेस करें। flag के वर्तमान owner,
संभावित reset points और हर परिकल्पना के साक्ष्य बताएँ।

अनुरोध बदलाव माँगने से पहले मौजूदा व्यवहार का मॉडल माँगता है।

केंद्रित कार्य के लिए शामिल करें:

• विफल command, test, screenshot या error;
• वे files या subsystem जिन्हें पहले जाँचना चाहिए;
• प्रासंगिक project rules या architectural constraints;
• हाल के बदलाव जो regression ला सकते हैं;
• वह व्यवहार जो अपरिवर्तित रहना चाहिए।

पूरा repository प्रॉम्प्ट में न चिपकाएँ। यदि अधिक संदर्भ आवश्यक हो, तो सहायक से अगली आवश्यक फ़ाइल या boundary और उसका कारण बताने को कहें।

जिस काम में जोखिम स्पष्ट न हो, उसमें कार्यान्वयन से पहले read-only analysis माँगें:

मौजूदा subscription-gating flow जाँचें और संपादन से पहले इन सवालों के उत्तर दें:

1. access कहाँ तय होता है?
2. कौन-सी loading state premature redirect रोकती है?
3. कौन-से route और CTA call sites इस निर्णय का उपयोग करते हैं?
4. कौन-सा regression test साबित करेगा कि paid user को pricing पर नहीं भेजा गया?

अभी कोड न लिखें। देखे गए व्यवहार को धारणाओं से अलग रखें।

analysis checkpoint permissions, payments, data migrations, navigation और shared state के लिए मूल्यवान है। बड़े diff बनने से पहले यह आपको समीक्षा के लिए छोटा दस्तावेज़ भी देता है।

सहायक पास के कोड से हर contract का विश्वसनीय अनुमान नहीं लगा सकता। महत्वपूर्ण नियम स्पष्ट करें:

बाध्यताएँ:
- application को static export के साथ संगत रखें;
- internal navigation में सक्रिय locale सुरक्षित रखें;
- server-only runtime behavior न जोड़ें;
- मौजूदा client writer को single source of truth बनाए रखें;
- public route या event names न बदलें;
- कारण समझाए बिना बदलाव को इस feature के बाहर न फैलाएँ।

विशिष्ट बाध्यताएँ समीक्षा को तेज़ बनाती हैं, क्योंकि प्रस्तावित बदलाव को लिखी हुई सीमा से तुलना की जा सकती है।

जोखिमपूर्ण रिफ़ैक्टर को छोटे, जाँचे जा सकने वाले चरणों में बाँटें:

चरण 1: duplicated state transition पहचानें और मौजूदा tests समझाएँ।
चरण 2: केवल shared transition को उसी public API के पीछे निकालें।
चरण 3: केंद्रित tests चलाएँ और बदला हुआ व्यवहार दिखाएँ।
चरण 4: व्यापक cleanup प्रस्तावित करें, लेकिन लागू न करें।

क्रमिक काम आपको ऐसे patch से बचाता है जो rendering, state ownership और tests को एक साथ बदल दे। यदि चरण 2 विफल हो, तो कारण अलग करना आसान है।

साक्ष्य श्रृंखला का उपयोग करें:

साक्ष्य: [logs, stack trace, failing test, command output या user steps]
परिकल्पनाएँ: प्राथमिकता क्रम में सबसे छोटे संभावित कारण सूचीबद्ध करें।
सत्यापन: वह अवलोकन बताएँ जो हर कारण की पुष्टि या खंडन करेगा।
समाधान: साक्ष्य से समर्थित सबसे छोटा बदलाव प्रस्तावित करें।
जाँच: आवश्यक जगह regression test और manual check जोड़ें।

किसी अस्पष्ट लक्षण के आधार पर सहायक से production behavior patch करने को न कहें। भरोसेमंद दिखने वाला fix साक्ष्य नहीं है।

स्वीकृति मानदंड:
- रिपोर्ट की गई विफलता केंद्रित regression test में कवर होती है;
- सफल मौजूदा workflow अब भी पास होता है;
- type checking और प्रासंगिक test command पास होते हैं;
- diff सहमत दायरे में रहता है;
- अंतिम व्याख्या ऐसे व्यवहार का नाम देती है जिसे स्थानीय रूप से सत्यापित नहीं किया जा सका।

इससे Claude Code compilation को सही होने का एकमात्र संकेत मानने के बजाय समीक्षा योग्य अंत बिंदु पर रुकता है।

व्यापक प्रॉम्प्ट ढाँचे के लिए बेहतर AI प्रॉम्प्ट कैसे लिखें से शुरू करें। कार्य-केंद्रित पैटर्न के लिए डेवलपर्स के लिए प्रॉम्प्ट इंजीनियरिंग और production issues को डीबग करने के प्रॉम्प्ट टेम्पलेट का उपयोग करें।

यदि कार्य किसी script या command-based workflow को बदलता है, तो fix माँगने से पहले प्रासंगिक input और output को पुन: उत्पन्न करें। सत्यापन को ठोस बनाने के लिए ब्राउज़र में terminal workflows का अभ्यास करें।