🔧Toolify

सीनियर कोड रिव्यूअर प्रॉम्प्ट — बग, परफ़ोर्मेंस मुद्दे, एज केस ढूंढता

अधिकांश LLM कोड रिव्यू आपको स्टाइल nitpicks में डुबो देती हैं और वास्तविक बग छूट जाते हैं। यह प्रॉम्प्ट मॉडल को गंभीरता के आधार पर ट्राइएज करने, केवल उन चीज़ों को फ्लैग करने के लिए मजबूर करता है जो सख्त टेक-लीड रिव्यू में जीवित रहेंगी, और जिन सटीक लाइन नंबरों के बारे में चिंतित है उन्हें उद्धृत करता है ताकि आप प्रत्येक खोज को तेज़ी से सत्यापित कर सकें।

श्रेणी: codingइसके लिए अनुशंसित: claude / chatgpt / cursor
prompt
आप एक सीनियर स्टाफ इंजीनियर हैं जो नीचे दिए गए diff की समीक्षा कर रहे हैं। आपका लक्ष्य उन चीज़ों को पकड़ना है जो वास्तव में सख्त टेक-लीड रिव्यू में जीवित रहेंगी — lint शोर नहीं।

रिव्यू नियम:
1. प्रत्येक खोज को निम्न में से एक में ट्राइएज करें: BLOCKER, MAJOR, MINOR, NIT।
2. डिफ़ॉल्ट रूप से केवल BLOCKER और MAJOR उत्सर्जित करें। MINOR और NIT को तब तक दबाएं जब तक मैं स्पष्ट रूप से नहीं पूछता।
3. प्रत्येक खोज के लिए, सटीक फ़ाइल पथ + लाइन नंबर रेंज उद्धृत करें। फिर समझाएं (a) क्या गलत है, (b) उत्पादन में फेल्योर मोड, (c) सुझाया गया फिक्स।
4. यदि आप 80% से कम आश्वस्त हैं कि मुद्दा वास्तविक है, तो खोज को [low-confidence] चिह्नित करें और समझाएं कि कौन सा अतिरिक्त संदर्भ आपको सत्यापित करने देगा।
5. एक-पैराग्राफ समग्र सारांश के साथ समाप्त करें: ship-it / ship-with-followups / do-not-ship।

इस पर टिप्पणी न करें:
- नामकरण प्राथमिकताएं जब तक वे सक्रिय रूप से गुमराह न करें।
- फ़ॉर्मेटिंग/whitespace यदि कोई फ़ॉर्मेटर उपयोग में है।
- काल्पनिक अनुकूलन जिन्हें आप मापे गए हॉट पथ से नहीं जोड़ सकते।
- पैटर्न जो कोडबेस पहले से कहीं और उपयोग करता है (यह एक शैलीगत संगति है, बग नहीं)।

रिव्यू करने के लिए Diff:

[अपना unified diff या फ़ाइल सामग्री यहां पेस्ट करें]

इसे कब उपयोग करें

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

मॉडल टिप्स

claude
Claude (Sonnet 4.6 या Opus 4.7) आमतौर पर सबसे विचारशील ट्राइएज देता है। diff को कोड ब्लॉक में पेस्ट करें; लंबे संदर्भ पूरी-PR रिव्यू को अच्छी तरह संभालते हैं।
chatgpt
GPT-5 / GPT-4o स्टाइल को फ्लैग करने के बारे में अधिक आक्रामक होते हैं। ऊपर का 'suppress MINOR and NIT' नियम इसे ट्रैक पर रखता है।
cursor
Cursor में, इसे .cursorrules एंट्री के रूप में सहेजें या composer में पेस्ट करें। यह @file संदर्भों के साथ अच्छी तरह जोड़ी बनाता है।

उदाहरण आउटपुट

BLOCKER: src/auth/session.ts:42-58
  - what: Session token तुलना === का उपयोग करती है, constant-time compare नहीं।
  - failure mode: रिमोट लॉगिन पर Timing-attack-leakable।
  - fix: buffer जोड़ी पर crypto.timingSafeEqual() पर स्विच करें।

MAJOR: src/auth/session.ts:73 [low-confidence]
  - what: Refresh token localStorage में लिखा गया।
  - failure mode: XSS exfiltration जोखिम यदि कोई असुरक्षित उपयोगकर्ता सामग्री पृष्ठ तक पहुंचती है।
  - fix: यदि क्लाइंट को इसे पढ़ने की आवश्यकता नहीं है तो httpOnly कुकी में ले जाएं। (low-confidence: मुझे नहीं दिखता कि फ्रंट-एंड इस टोकन का उपभोग कैसे करता है।)

सारांश: ship-with-followups। constant-time फिक्स पूर्व-मर्ज आवश्यक है; इस PR के बावजूद storage location एक follow-up मुद्दा है जिसे खोलने योग्य है।

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

अधिकांश AI कोड रिव्यू बेकार क्यों हैं

डिफ़ॉल्ट रूप से, भाषा मॉडल कोड-रिव्यू कार्यों पर 'मददगार जूनियर' व्यक्तित्व पर डिफ़ॉल्ट होते हैं। इसका मतलब है कि वे नामकरण पर अधिक टिप्पणी करते हैं, ऐसे कोड के लिए 'क्लीन कोड' रीराइट सुझाते हैं जो ठीक है, और एक वास्तविक बग को सुझावों की दीवार में दफन कर देते हैं जिन्हें आपको नज़रअंदाज़ करना पड़ता है। सिग्नल-टू-शोर अनुपात वर्कफ़्लो को मार देता है — अधिकांश टीमें एक सप्ताह के भीतर रिव्यू के लिए AI का उपयोग करना बंद कर देती हैं।

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

इसे अपनी CI के साथ जोड़ना

इस प्रॉम्प्ट को अपने PR वर्कफ़्लो में 'दूसरी राय' चरण के रूप में चलाएं — gating जांच नहीं। मॉडल अभी भी hallucinate करते हैं, विशेष रूप से क्रॉस-फ़ाइल invariants पर और उस कोड पर जो आपके पेस्ट नहीं किए गए framework परंपराओं पर निर्भर है। आउटपुट को सत्यापित करने योग्य चीज़ों की सूची के रूप में उपयोग करें, यांत्रिक रूप से ठीक करने के लिए मुद्दों की सूची के रूप में नहीं।

यदि आप इसे CI में चाहते हैं, तो खोजों को JSON के रूप में आउटपुट करें (प्रॉम्प्ट को संशोधित करें: 'severity, path, lineStart, lineEnd, what, fix, confidence फ़ील्ड के साथ JSON array लौटाएं')। फिर BLOCKER/MAJOR वाले को PR में 'AI assist — verify before acting' हेडर के साथ एकल टिप्पणी के रूप में पोस्ट करें।

अपनी टीम के लिए प्रॉम्प्ट को अनुकूलित करना

diff के ऊपर 'Codebase context' सेक्शन जोड़ें — अपनी स्टैक, अपनी टेस्ट परंपराओं, और किसी भी गैर-स्पष्ट invariants (जैसे, 'सभी DB writes src/db/withTx के माध्यम से जाती हैं, raw client कभी नहीं') का वर्णन करने वाली 5-10 लाइनें पेस्ट करें। मॉडल अन्यथा कोडबेस-विशिष्ट परंपराओं को छोड़ देते हैं।

यदि आपकी टीम में ज्ञात कमज़ोर बिंदु हैं (job runner में race conditions, किसी विशिष्ट सेवा में N+1 क्वेरीज़), तो 'Watch especially for: …' लाइन जोड़ें। मॉडल बग के उन वर्गों को अधिक महत्व देगा और मौजूद होने पर उन्हें फ्लैग करने की अधिक संभावना है।

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

क्या मैं इसे क्लोज़्ड-सोर्स कोड पर उपयोग कर सकता हूं?

हां, लेकिन पहले अपने नियोक्ता की नीति जांचें। प्रॉम्प्ट स्वयं हानिरहित है; मायने यह रखता है कि क्या आपको आप जिस मॉडल का उपयोग कर रहे हैं उसमें अपना कोड पेस्ट करने की अनुमति है। Claude और ChatGPT एंटरप्राइज प्लान आमतौर पर आपके इनपुट पर प्रशिक्षित नहीं करते; उपभोक्ता प्लान कर सकते हैं।

MINOR और NIT खोजों को क्यों दबाएं?

क्योंकि व्यवहार में वे रिव्यू थकान पैदा करते हैं। तीसरे 'इसे एक फ़ंक्शन में निकालने पर विचार करें' नोट के बाद, आप पढ़ना बंद कर देते हैं। उन्हें दबाने से BLOCKER/MAJOR सिग्नल तेज़ रहता है। जब आप गहरी समीक्षा चाहते हैं तो 'MINOR और NIT सहित सभी खोजें दिखाएं' के साथ उन्हें वापस चालू करें।

diff कितना लंबा हो सकता है?

Claude Sonnet/Opus और GPT-5 50K+ tokens के diff को आराम से संभालते हैं। बहुत बड़े PR के लिए, समीक्षा को निर्देशिका द्वारा विभाजित करें (पहले src/auth, फिर src/billing) ताकि मॉडल प्रत्येक उपप्रणाली के बारे में अलगाव में सोच सके।

सुरक्षा-विशिष्ट रिव्यू के बारे में क्या?

यह प्रॉम्प्ट स्पष्ट crypto/storage/SSRF मुद्दों को पकड़ता है लेकिन auth या payment कोड पर सुरक्षा समीक्षा का विकल्प नहीं है। उन पथों के लिए, इस प्रॉम्प्ट और एक समर्पित security-review प्रॉम्प्ट को चलाएं (हम एक अलग से प्रकाशित करेंगे)।

क्या यह कई फ़ाइलों में समीक्षा कर सकता है?

हां — सभी फ़ाइलों को शामिल करने वाला diff पेस्ट करें। यह एक पेस्ट के भीतर क्रॉस-फ़ाइल invariants को उचित रूप से अच्छी तरह संभालता है; उन मुद्दों के लिए जो कई PR में फैले हैं (जैसे, 'क्या यह feature flags के gated होने के तरीके से सुसंगत है?'), उन अन्य फ़ाइलों से कुछ प्रतिनिधि अंश शामिल करें।

क्या मुझे [low-confidence] खोजों पर भरोसा करना चाहिए?

उन्हें 'कार्य करने से पहले जांच' के रूप में व्यवहार करें। लगभग आधी low-confidence खोजें वास्तविक हैं लेकिन मॉडल सत्यापित नहीं कर सका; दूसरा आधा गलत पाठ हैं। फ्लैग ईमानदार सिग्नल है, खोज को नज़रअंदाज़ करने का कारण नहीं।

यह मुझसे failure mode निर्दिष्ट करने के लिए क्यों चाहता है?

क्योंकि 'यह गलत है' 'यह unicode इनपुट पर क्रैश हो जाएगा' के बिना बेकार है। failure-mode लाइन आपको प्राथमिकता बताती है: एक फिक्स जो 1-में-दस-लाख एज केस को रोकता है, उससे अलग है जो दैनिक prod incident को रोकता है।

मैं इसे विशेष रूप से Cursor में कैसे उपयोग करूं?

प्रॉम्प्ट बॉडी को अपने repo root पर .cursorrules में सहेजें, या समीक्षाधीन फ़ाइलों के लिए @file संदर्भों के साथ composer में पेस्ट करें। Cursor उस प्रोजेक्ट के लिए नियमों को सक्रिय रखेगा।

संबंधित कैलकुलेटर

संबंधित प्रॉम्प्ट

अंतिम बार अपडेट किया गया: