डिबगिंग, रीफैक्टर और आर्किटेक्चर रिव्यू के लिए Claude कोडिंग प्रॉम्प्ट पैक

वे चार शर्तें जो नीचे दिए हर प्रॉम्प्ट को कारगर बनाती हैं

प्रॉम्प्ट से पहले, वे नियम जो इन सभी में साझा हैं। इन्हें किसी भी कोडिंग प्रॉम्प्ट में जोड़ना मॉडल बदलने से ज़्यादा आउटपुट को बेहतर बनाता है।

अपना वर्शन बताएं। ट्रेनिंग डेटा उस मेजर वर्शन की ओर झुका होता है जिसके बारे में सबसे ज़्यादा लिखा गया है, जो अक्सर वह नहीं होता जिस पर आप हैं। We are on [framework] [version], [language] [version] ज़्यादातर पुराने जवाबों को रोकता है।

डिफ़ को सीमित करें। फिक्स मांगिए और अक्सर आपको रीफैक्टर मिल जाता है। Change as little as possible, preserve existing structure and naming, and list every line you changed with a one line reason इस दस्तावेज़ का सबसे उपयोगी वाक्य है।

समाधान से पहले परिकल्पनाएं मांगें। जब मॉडल से पूछा जाए कि गड़बड़ी क्या है, तो वह एक अनुमान को निष्कर्ष के रूप में पेश करता है। जब रैंक की गई वजहों और सस्ती जांचों के लिए पूछा जाए, तो वह एक डिबगिंग योजना देता है।

फेल्योर मोड ज़रूर पूछें। What could this break, and is this fixing the cause or the symptom? AI सहायता की सबसे महंगी श्रेणी को पकड़ता है: वह बदलाव जो लक्षण को गायब कर देता है जबकि खामी बनी रहती है।

डिबगिंग

1. रैंक की गई परिकल्पनाएं

Here is the error, the relevant code, and what I have already ruled out. Do not give me a fix yet. List the four most likely causes ranked by probability, and for each the single cheapest check that would confirm or eliminate it. Error: [paste]. Code: [paste]. Already ruled out: [list]. Stack: [language, framework, versions].

2. रुक-रुक कर आने वाली बग

This fails intermittently, roughly [frequency], under [conditions]. Enumerate the categories of intermittent failure that could produce this specific symptom: timing, ordering, resource exhaustion, an external dependency, state leaking between runs, clock or timezone, caching. For each, say what in the code supports or contradicts it, and exactly what I should log to distinguish them. Code: [paste].

3. यह लोकली काम करता है

This works locally and fails in [environment]. List every category of environment difference that could cause this specific symptom: configuration, environment variables, versions, filesystem and case sensitivity, timezone and locale, network and DNS, permissions, resource limits, and build or bundling differences. Rank by likelihood given the symptom, and give me the diagnostic command for each.

4. फिक्स अपनाने से पहले उसे समझाएं

Explain why this fix works, what it does not fix, and what it could break. If the real cause is elsewhere and this is a symptom patch, say so directly.

कोड रिव्यू

5. एक डिफ़ रिव्यू करें

Review this diff as a demanding reviewer. Categories in priority order: correctness bugs, security issues, unhandled failure modes, race conditions, then style. For each finding give severity, the specific line, and why it matters in this codebase rather than in general. Do not comment on formatting. If the diff is sound, say so rather than manufacturing findings. Conventions: [describe]. Diff: [paste].

6. सिक्योरिटी पास

Review this code for security issues specifically: injection, authentication and authorisation gaps, unsafe deserialisation, secrets in code or logs, unvalidated input reaching a sensitive operation, and dependency risk. For each, give the attack path concretely rather than naming the category. State clearly what you cannot assess without seeing [deployment, auth layer, data sensitivity].

7. फेल्योर मोड ऑडिट

For each external call in this code, state what happens when it is slow, when it fails, when it returns unexpected data, and when it succeeds but partially. Which of those are currently unhandled, and which would be silent?

यह आखिरी वाला सामान्य रिव्यू से ज़्यादा असली प्रोडक्शन इश्यू पकड़ता है, क्योंकि यह उन रास्तों के बारे में पूछता है जिनके लिए किसी ने टेस्ट नहीं लिखा।

रीफैक्टरिंग और आर्किटेक्चर

8. रीफैक्टर योजना

Propose a sequenced plan to refactor [description]. Constraints: the public API of [x] cannot change, we deploy continuously so every step must be independently shippable, and tests must pass after each step. For each step give the change, the risk, how to verify it, and how to roll it back. Order by risk, lowest first. Do not write the code yet.

9. दूसरे पक्ष की दलील दें

I am choosing [approach A] over [approach B] for [context and constraints]. Make the strongest case for B. What would have to be true about our constraints for B to be correct, and is any of it true here? Do not conclude that both are valid.

10. समझें कि आपको क्या विरासत में मिला

Here are the main source files. Produce: the entry points, the data flow from request to response, the state that is shared and where it is mutated, external dependencies and what happens when each is unavailable, and the three areas most likely to contain bugs based on complexity and coupling. State explicitly what you cannot determine from what I provided.

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

टेस्ट

11. वे टेस्ट जो आपने नहीं लिखे होते

Write test cases for this function, focusing on inputs I probably have not considered: boundaries, empty and null, unicode, very large values, concurrent calls, and any implicit assumption in the implementation. For each test, state the assumption it is checking. Function: [paste].

12. टेस्ट सुइट की जांच करें

Here is a function and its existing tests. What behaviour is not covered? Specifically: error paths, boundary values, interactions between parameters, and anything the implementation does that no test asserts. Do not rewrite the existing tests.

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

सेकंड-ओपिनियन पैटर्न

इस पूरे पैक की सबसे असरदार आदत, और वह भी जिसके लिए एक से ज़्यादा मॉडल चाहिए।

एक मॉडल से जवाब लें। फिर बदलें और उसे सौंप दें:

Another engineer proposed this solution to this problem. Find what is wrong with it: correctness under edge cases, concurrency, error handling, performance at [scale], or a simpler approach that was missed. If it is genuinely sound, say so plainly rather than inventing objections. Problem: [paste]. Proposed solution: [paste].

दो नतीजे हो सकते हैं और दोनों काम के हैं। या तो दूसरा मॉडल कोई असली खामी ढूंढ लेता है, जिसे अब आप मर्ज करने से पहले जान लेते हैं, या फिर वह असहमत होने के लिए उकसाए जाने के बावजूद सहमत होता है, जो एक सार्थक पुष्टि है। एक ही मॉडल के साथ दोहराने से आपको इनमें से कुछ नहीं मिलता, क्योंकि अपने ही आउटपुट को रिव्यू करने वाला मॉडल ज़्यादातर खुद से सहमत होता है।

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

किन बातों का ध्यान रखें

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

कॉन्फ़िडेंस सिग्नल का न होना। एक सही फिक्स और एक सूक्ष्मता से गलत फिक्स बिल्कुल एक जैसे भरोसे के साथ आते हैं। टोन कुछ नहीं बताती।

चुपचाप स्कोप बढ़ना। यही वजह है कि दूसरी शर्त बनाई गई है।

सिक्योरिटी थिएटर। आपके कोड में वल्नरेबिलिटी क्लास के नाम गिनाना एक उपयोगी पहला पास है। यह ऑडिट नहीं है, और मॉडल को आपका थ्रेट मॉडल, डिप्लॉयमेंट या डेटा संवेदनशीलता पता नहीं है।

जिन प्रॉम्प्ट का इस्तेमाल आप हर हफ़्ते करते हैं उन्हें कहीं ऐसी जगह रखें जहां से आप पेस्ट कर सकें, और स्थायी शर्तों को प्रोजेक्ट के इंस्ट्रक्शंस में डालें ताकि वे उस प्रोजेक्ट की हर चैट पर अपने आप लागू हों।