Claude Code PR review: प्री-रिव्यू diffs तेज और सुरक्षित करें

क्यों PR समीक्षा का समय बढ़ जाता है

PR समीक्षाएँ अक्सर इसी लिए लंबी होती हैं क्योंकि कोड "कठिन" है—बल्कि इसलिए कि रिव्यूअर को सिर्फ़ बदलाओं से इरादा, जोखिम और प्रभाव को फिर से बनाना पड़ता है। एक diff बदलाव दिखाता है, पूरा संदर्भ नहीं।

एक छोटा सा एडिट छुपी हुई निर्भरताओं को छू सकता है: फ़ील्ड का नाम बदलें और रिपोर्ट टूट सकती है, डिफ़ॉल्ट बदलें और व्यवहार बदल सकता है, एक कंडीशनल थोड़ी सी छेड़छाड़ से एरर हैंडलिंग बदल सकती है। जब रिव्यूअर को संदर्भ के लिए क्लिक-करना, ऐप लोकली चलाना और सिर्फ़ समझने के लिए फ़ॉllo-अप प्रश्न पूछना पड़ता है, तो समीक्षा का समय बढ़ता है।

यहाँ एक मानवीय पैटर्न की भी दिक्कत है। लोग diffs को अनुमानित तरीकों से स्किम करते हैं: हम मुख्य बदलाव पर ध्यान देते हैं और उन उबाऊ लाइनों को मिस कर देते हैं जहाँ बग छिपते हैं (बाउंडरी चेक, null हैंडलिंग, लॉगिंग, क्लीनअप)। हम वही पढ़ने की प्रवृत्ति रखते हैं जो हम उम्मीद करते हैं, इसलिए copy-paste गलतियाँ और उल्टे कंडीशन्स छूट सकते हैं।

एक अच्छी पूर्व-समीक्षा निर्णायक नहीं होती। यह तेज़, संरचित दूसरी नज़र होती है जो बताती है कहाँ इंसान को धीमा होना चाहिए। सबसे अच्छा आउटपुट होना चाहिए:

• क्या बदला, इसे सादा हिंदी में सारांश
• विशेष जोखिम बिंदु (फाइलें, फ़ंक्शन्स, मान्यताएँ)
• पठनीयता नोट्स (नामकरण, भ्रमित करने वाला कंट्रोल फ्लो)
• सटीकता की चिंताएँ (लॉजिक, एरर हैंडलिंग, डेटा संगति)
• परिक्षण के लिए किन किन एज केसों की ज़रूरत है (इनपुट, समय, परमिशन्स, खाली स्टेट)

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

AI मदद मध्यम आकार के PRs पर सबसे मजबूत है जो बिजनेस लॉजिक या रेफ़ैक्टर को छूते हैं जहाँ अर्थ खो सकता है। जब सही उत्तर गहरी संगठन-विशेष जानकारी पर निर्भर हो (लिगेसी व्यवहार, प्रोडक्शन प्रदर्शन की विशेषताएँ, आंतरिक सुरक्षा नियम), तब यह कमजोर हो सकता है।

उदाहरण: एक PR जो "सिर्फ़ pagination अपडेट करता है" अक्सर ऑफ-बाय-वन पेजेस, खाली परिणाम, और API और UI के बीच असंगत सॉर्टिंग छुपाता है। एक पूर्व-समीक्षा को ये प्रश्न मानव के 30 मिनट खोने से पहले उठाने चाहिए।

पूर्व-समीक्षा में Claude से क्या पूछें

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

उसे वही दें जो एक निष्पक्ष मानव रिव्यूअर को चाहिए:

• PR का लक्ष्य (1 से 3 वाक्य)
• क्या बिल्कुल नहीं टूटना चाहिए (API आकार, बैकवर्ड कम्पैटिबिलिटी, परफ़ॉर्मेंस बजट, सुरक्षा नियम)
• कोई विशेष बाधाएँ या ट्रेडऑफ़ (डेडलाइन, आंशिक रोलआउट)
• प्रासंगिक diff hunks, पर्याप्त आस-पास के कोड के साथ ताकि इरादा समझ में आ सके

अगर PR किसी उच्च-जोखिम क्षेत्र को छूता है, तो पहले ही बता दें (auth, billing, migrations, concurrency)।

फिर ऐसे आउटपुट माँगें जिनपर आप कार्रवाई कर सकें। एक मजबूत अनुरोध इस तरह दिखता है:

• क्या बदला, सादा भाषा में सारांश दें।
• पठनीयता की समस्याएँ फ़्लैग करें (नामकरण, संरचना, हैरान करने वाली चीज़ें, असंगत पैटर्न)।
• सटीकता के जोखिम पहचानें (null हैंडलिंग, एरर पाथ्स, ऑफ-बाय-वन, डेटा शेप मिसमैच)।
• परिक्षण के लिए एज केस और फेलियर मोड्स की सूची दें (timeouts, retries, खाली इनपुट, आंशिक अपडेट)।
• मिसिंग टेस्ट सुझाएँ और हर टेस्ट क्या साबित करता है बताएं।
• एक छोटा रिव्यूअर चेकलिस्ट और 5 से 10 "मर्ज से पहले पूछने वाले प्रश्न" तैयार करें।

इन्सान को नियंत्रण में रखें: Claude से कहें कि वह निष्कर्षों को "diff से निश्चित" बनाम "पुष्टि चाहिए" के लेबल के साथ चिह्नित करे, और हर चिंता को ट्रिगर करने वाली सटीक लाइनों को कोट करे।

प्रॉम्प्ट देने से पहले diff और संदर्भ तैयार करें

Claude उतना ही अच्छा है जितना कि आप उसे दिखाते हैं। अगर आप एक विशाल diff चिपकाते हैं बिना लक्ष्य या सीमाओं के, तो आप सामान्य सलाह पाएँगे और असली जोखिम छूट जाएगा।

एक ठोस लक्ष्य और सफलता मानदंड के साथ शुरू करें। उदाहरण: “यह PR login endpoint में rate limiting जोड़ता है ताकि दुरुपयोग कम हो। यह response shape नहीं बदलना चाहिए। औसत लैटेंसी 50 ms से कम रहनी चाहिए।”

इसके बाद, केवल वही शामिल करें जो मायने रखता है। अगर 20 फाइल बदली हैं पर केवल 3 में लॉजिक है, तो उन 3 पर फ़ोकस करें। जब कोई स्निपेट भ्रामक होगा तो आसपास का संदर्भ शामिल करें, जैसे फ़ंक्शन सिग्नेचर, मुख्य टाइप्स, या कॉन्फ़िग जो व्यवहार बदलता है।

अंत में, टेस्टिंग अपेक्षाओं के बारे में स्पष्ट रहें। अगर आप एज केस के लिए यूनिट टेस्ट चाहते हैं, क्रिटिकल पाथ के लिए इंटीग्रेशन टेस्ट, या मैनुअल UI रन-थ्रू चाहिए तो बताएं। अगर टेस्ट जानबूझकर गायब हैं, तो कारण लिखें।

एक सरल "कॉन्टेक्स्ट पैक" जो अच्छा काम करता है:

• PR लक्ष्य: क्या बदल रहा है, उपयोगकर्ता क्या देखेंगे, क्या बेहतर होगा
• प्रासंगिक diff चंक्स: केवल प्रमुख फाइलें, पर्याप्त आस-पास के कोड के साथ
• हार्ड कंस्ट्रेंट्स: परफ़ॉर्मेंस बजट, कम्पैटिबिलिटी आवश्यकताएँ, सुरक्षा/गोपनीयता नियम
• टेस्ट अपेक्षाएँ: क्या कवर होना चाहिए, क्या जोड़ा गया, कैसे चलाएं
• "नहीं बदलना चाहिए" आइटम: सार्वजनिक API कांट्रैक्ट, DB स्कीमा, UX व्यवहार, लॉगिंग/ऑडिट फॉर्मैट

स्टेप बाय स्टेप: एक दोहराव योग्य पूर्व-समीक्षा फ्लो

एक अच्छा Claude Code PR रिव्यू कड़ी लूप की तरह काम करता है: बस पर्याप्त संदर्भ दें, संरचित नोट्स पाएं, फिर उन्हें कार्रवाइयों में बदल दें। यह इंसानों की जगह नहीं लेता। यह आसान मिस्स पकड़ता है इससे पहले कि किसी टीममेट को लंबे समय तक पढ़ना पड़े।

5-पास फ्लो

हर बार वही पास इस्तेमाल करें ताकि परिणाम अनुमानित रहें:

1. बदलाव को सादा भाषा में समझाइए। Claude से कहें कि PR क्या करता है, कौन सी फाइलें बदलीं, और बदलाव का संभावित कारण क्या है। अगर वह सरलता से समझा नहीं पाता, तो संभव है कि PR को स्पष्ट विवरण या छोटा स्कोप चाहिए।
2. सबसे पहले सटीकता देखें। लॉजिक त्रुटियाँ, टूटी मान्यताएँ, और मौन व्यवहार परिवर्तन (डिफ़ॉल्ट, एरर हैंडलिंग, परमिशन्स, टाइमज़ोन, ऑफ-बाय-वन) खोजें।
3. मिसिंग केस स्कैन करें। उपयोगकर्ता और प्रोडक्शन की तरह सोचें: खाली इनपुट, nulls, retries, आंशिक फेल्यर, concurrency, बैकवर्ड कम्पैटिबिलिटी।
4. पठनीयता और रखरखाव देखें। भ्रमित करने वाले नाम, लंबे फ़ंक्शन, डुप्लीकेट लॉजिक, अस्पष्ट कमेंट्स, और छोटे रेफ़ैक्टर जो भविष्य की समीक्षा समय घटाएँ।
5. निर्देशों के साथ रिव्यू कमेन्ट्स ड्राफ्ट करें। कमेंट्स को फ़ाइल के हिसाब से ग्रुप करें और फ़ंक्शन का नाम या उद्धृत स्निपेट शामिल करें ताकि इंसान तेज़ी से जगह ढूँढ सके।

नोट्स मिलने के बाद, उन्हें एक छोटा मर्ज गेट बनाएं:

मर्ज चेकलिस्ट (संक्षिप्त रखें):

• नए व्यवहार और कम से कम एक एज केस को टेस्ट कवर करे
• त्रुटियाँ सुसंगत रूप से हैंडल हों (और ज़रूरत पर लॉग हों)
• बिना स्पष्ट माइग्रेशन पथ के कोई ब्रेकिंग चेंज न हो
• नामकरण और संरचना नज़दीकी कोड से मेल खाये
• जोखिमपूर्ण हिस्सों के लिए रोलबैक योजना मौजूद हो

अंत में 3 से 5 ऐसे प्रश्न माँगें जो अस्पष्टताओं को मजबूर करें, जैसे "अगर API खाली लिस्ट लौटाए तो क्या होगा?" या "क्या यह कॉनकरेंट रिक्वेस्ट्स के तहत सुरक्षित है?"

एक साधारण रूब्रिक (पठनीयता, सटीकता, एज केस)

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

एक व्यावहारिक रूब्रिक:

• पठनीयता: साफ़ नाम, सरल फ्लो, छोटे फ़ंक्शन, कमेंट्स जो क्यों बताते हैं, कोई मृत कोड या बचा हुआ डिबग आउटपुट नहीं।
• सटीकता: मुख्य इन्वेरिएंट लागू हों, त्रुटियाँ सुसंगत रूप से हैंडल हों, null/empty सुरक्षित हों, सीमाएँ सही हों (ऑफ-बाइ-वन, राउंडिंग)।
• एज केस: खाली/विशाल इनपुट, मिसिंग ऑप्शनल फ़ील्ड्स, टाइम ज़ोन्स/डे लाइट सेविंग्स, retries जो डबल-राइट्स का जोखिम बनाते हैं, concurrency रेस।
• सुरक्षा और गोपनीयता: ऑथ चेक सही जगह पर हों, कोई सीक्रेट कोड में/लॉग में नहीं हो, लॉग संवेदनशील payload नहीं लीक करें।
• कम्पैटिबिलिटी और रोलआउट सुरक्षा: पुराने क्लाइंट और स्टोर किया डाटा टूटेगा नहीं, माइग्रेशन्स सुरक्षित हों, रोलबैक प्लान हो।

प्रॉम्प्ट करते समय कहें: हर कैटेगरी के लिए एक छोटा पैराग्राफ दें और "सबसे उच्च-जोखिम मुद्दा पहले" माँगें। यह क्रम इंसानों को केंद्रित रखता है।

उपयोगी रिव्यू नोट्स देने वाले प्रॉम्प्ट टेम्पलेट्स

एक पुन: प्रयोज्य बेस प्रॉम्प्ट का उपयोग करें ताकि परिणाम हर PR में समान दिखें। PR विवरण चिपकाएँ, फिर diff। अगर व्यवहार यूज़र-फेसिंग है, तो 1-2 वाक्यों में अपेक्षित व्यवहार जोड़ें।

You are doing a pre-review of a pull request.

Context
- Repo/service: <name>
- Goal of change: <1-2 sentences>
- Constraints: <perf, security, backward compatibility, etc>

Input
- PR description:
<...>
- Diff (unified diff):
<...>

Output format
1) Summary (max 4 bullets)
2) Readability notes (nits + suggested rewrites)
3) Correctness risks (what could break, and why)
4) Edge cases to test (specific scenarios)
5) Reviewer checklist (5-10 checkboxes)
6) Questions to ask the author before merge (3-7)

Rules
- Cite evidence by quoting the relevant diff lines and naming file + function/class.
- If unsure, say what info you need.