code-review-checklist

# machine-translated to hi from skills/code-review-checklist/SKILL.md — review: pending. Native fixes welcome via PR.name: code-review-checklistdescription: "किसी भी पुल रिक्वेस्ट के लिए भाषा, बदलाव के प्रकार और जोखिम स्तर के आधार पर एक अनुकूलित कोड रिव्यू चेकलिस्ट बनाएँ। जब कोई कोड की समीक्षा करने, PR जाँचने, पुल रिक्वेस्ट रिव्यू करने या कोड रिव्यू चेकलिस्ट बनाने को कहे, तब इसका उपयोग करें। भाषा-विशिष्ट जाँचों, जोखिम स्तर के अनुरूप गहराई और स्पष्ट approve/request-changes सिफ़ारिश के साथ एक केंद्रित चेकलिस्ट तैयार करता है।"

कोड रिव्यू चेकलिस्ट स्किल

किसी विशिष्ट पुल रिक्वेस्ट के लिए अनुकूलित कोड रिव्यू चेकलिस्ट तैयार करता है — भाषा, बदलाव के प्रकार और जोखिम स्तर के अनुसार। कोई सामान्य टेम्पलेट नहीं।

बिल्कुल यही नहीं चाहिए? जब आप सिर्फ़ चेकलिस्ट नहीं, बल्कि वरिष्ठ विवेक के साथ रिव्यू खुद करना चाहें, तो code-review-guide का उपयोग करें।

आवश्यक इनपुट

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

• भाषा और फ़्रेमवर्क (जैसे TypeScript + React / Python + FastAPI / Go)
• बदलाव का प्रकार (फ़ीचर / बग फ़िक्स / रीफ़ैक्टर / डिपेंडेंसी अपग्रेड / सुरक्षा पैच / प्रदर्शन)
• जोखिम स्तर (निम्न / मध्यम / उच्च / गंभीर)
• PR विवरण (विवरण पेस्ट करें या PR का लिंक दें)
• कोड या diff (वैकल्पिक — मुख्य बदली हुई फ़ाइलें या git diff पेस्ट करें; चेकलिस्ट की विशिष्टता काफ़ी बढ़ जाती है)
• लेखक का संदर्भ (नया सदस्य / अनुभवी / बाहरी योगदानकर्ता)

आउटपुट फ़ॉर्मैट

---

कोड रिव्यू: [PR शीर्षक या संदर्भ]

1. PR अवलोकन

दायरे का आकलन: [छोटा / मध्यम / बड़ा / बहुत बड़ा — बाँटना चाहिए] अनुशंसित रिव्यू गहराई: [सरसरी / मानक / गहन] अनुमानित रिव्यू समय: [जैसे 20–30 मिनट — मोटे अनुमान के लिए diff की हर 50 पंक्तियों पर 5 मिनट]

2. शुद्धता जाँच

भाषा-विशिष्ट शुद्धता जाँच — बताई गई भाषा के आधार पर चुनें:

TypeScript/JavaScript के लिए:

• टाइप परिभाषाएँ वास्तविक उपयोग से मेल खाती हैं
• गैर-टेस्ट कोड में कोई अंतर्निहित any नहीं
• Async/await का उपयोग सुसंगत; कोई अनहैंडल्ड प्रॉमिस नहीं
• Null/undefined का संचालन स्पष्ट

Python के लिए:

• सार्वजनिक फ़ंक्शन पर टाइप हिंट मौजूद
• अपवाद संचालन विशिष्ट (कोई नंगा except नहीं)
• संसाधन बंद किए जाते हैं (context manager, with ब्लॉक)

Go के लिए:

• त्रुटियाँ सँभाली गईं या टिप्पणी के साथ स्पष्ट रूप से अनदेखी की गईं
• Context का प्रसार सही
• Goroutine की आयु सीमित

[सिर्फ़ बताई गई भाषा से मेल खाने वाला खंड शामिल करें]

3. बदलाव-प्रकार-विशिष्ट जाँच

बग फ़िक्स के लिए:

• ऐसा टेस्ट मौजूद है जो इस बग को पकड़ लेता
• फ़िक्स लक्षण नहीं, मूल कारण को संबोधित करता है
• संबंधित कोड पथों में वही समस्या जाँची गई

फ़ीचर के लिए:

• स्वीकृति मानदंड पूरे
• किनारे के मामले सँभाले गए (खाली, बड़ा, समवर्ती)
• सिर्फ़ सुखद पथ नहीं, त्रुटि पथ भी टेस्ट किए गए
• डीबगिंग के लिए टेलीमेट्री/लॉगिंग जोड़ी गई

रीफ़ैक्टर के लिए:

• व्यवहार अपरिवर्तित (टेस्ट अब भी पास)
• कोई स्कोप क्रीप नहीं — सिर्फ़ रीफ़ैक्टर
• जटिलता घटी, सिर्फ़ इधर-उधर नहीं हुई

डिपेंडेंसी अपग्रेड के लिए:

• Breaking changes की समीक्षा
• सुरक्षा सलाहें जाँची गईं
• लाइसेंस संगतता सत्यापित

[सिर्फ़ बताए गए बदलाव-प्रकार से मेल खाने वाला खंड शामिल करें]

4. जोखिम-अनुरूप जाँच

निम्न जोखिम: बुनियादी शुद्धता, शैली परंपराएँ, टेस्ट कवरेज मध्यम जोखिम: ऊपर के + रोलबैक प्लान, मॉनिटरिंग अपडेट, प्रदर्शन संबंधी विचार उच्च जोखिम: ऊपर के + सुरक्षा निहितार्थ, डेटा माइग्रेशन की सुरक्षा, फ़ीचर फ़्लैग/क्रमिक रोलआउट गंभीर जोखिम: ऊपर के + स्टेजिंग सत्यापन योजना, इंसिडेंट रिस्पॉन्स योजना, तैनाती-पश्चात सत्यापन चेकलिस्ट

5. टेस्टिंग की पर्याप्तता

• यूनिट टेस्ट नए तर्क को कवर करते हैं
• इंटीग्रेशन टेस्ट कॉन्ट्रैक्ट बदलावों को कवर करते हैं
• किनारे के मामले टेस्ट किए गए
• विफलता के तरीके टेस्ट किए गए
• प्रदर्शन-संवेदनशील हो तो प्रदर्शन टेस्ट

6. रिव्यू निर्णय ढाँचा

Approve करें अगर: [इस PR पर आधारित 2-3 विशिष्ट शर्तें] बदलाव माँगें अगर: [विशिष्ट बाधाएँ] टिप्पणी (गैर-अवरोधक) करें अगर: [चर्चा योग्य पर मर्ज न रोकने वाले बिंदु]

7. इस बदलाव-प्रकार के आम जाल

बदलाव के प्रकार और भाषा के आधार पर 2-3 ऐसी चीज़ें चिह्नित करें जो समीक्षक इस संयोजन में आमतौर पर चूक जाते हैं।

---

गहरी सामग्री

यह स्किल सहायक फ़ाइलों के साथ आती है — उपलब्ध हों तो उनका उपयोग करें:

• references/review-depth-calibration.md — रिव्यू की गहराई का कैलिब्रेशन: हर PR एक जैसी नज़र का हक़दार नहीं। आउटपुट बनाते समय इसे लागू करें; इसमें वह कैलिब्रेशन और निर्णय-विवेक है जिसे ऊपर का संक्षिप्त तरीका संकुचित कर देता है।
• templates/review-record.md — डिलिवरेबल का भरने योग्य संस्करण, गुणवत्ता-जाँच इनलाइन सहित। जब उपयोगकर्ता दस्तावेज़ खुद बनाना चाहे, उसे जनरेट करवाने के बजाय, तब यह पेश करें।

स्कोरिंग रूब्रिक (0–40)

इस स्किल का कोई भी आउटपुट सौंपने से पहले स्कोर करें; 32+ शिप-गुणवत्ता है।

गुणवत्ता जाँच

• चेकलिस्ट बताई गई भाषा के अनुरूप है (सामान्य नहीं)
• बदलाव-प्रकार-विशिष्ट खंड शामिल है
• जोखिम-अनुरूप गहराई बताए गए जोखिम स्तर से मेल खाती है
• निर्णय ढाँचे में कम से कम एक नामित अवरोधक शर्त और एक नामित गैर-अवरोधक टिप्पणी शर्त है
• आम जाल बताई गई भाषा + बदलाव-प्रकार के संयोजन के लिए विशिष्ट हैं ("बग से सावधान रहें" जैसी सामान्य सलाह नहीं)

एंटी-पैटर्न

• बताई गई भाषा की अनदेखी करने वाली सामान्य चेकलिस्ट न बनाएँ — Python और Go की चेकलिस्ट की शुद्धता चिंताएँ मूलतः अलग होती हैं
• "ठीक लग रहा है" को मान्य रिव्यू नतीजा न मानें — चेकलिस्ट विशिष्ट चिंताओं को सामने लाने के लिए है, सतही पढ़ाई को सही ठहराने के लिए नहीं
• "उच्च जोखिम" रिव्यू का दायरा "निम्न जोखिम" जैसा न रखें — गहराई बताए गए जोखिम स्तर के साथ बढ़नी चाहिए
• हर शैलीगत पसंद को अवरोधक मुद्दा न बनाएँ — अवरोधक शुद्धता मुद्दों और गैर-अवरोधक टिप्पणियों में भेद करें
• बताई गई भाषा और बदलाव-प्रकार के संयोजन का "आम जाल" खंड न छोड़ें — सबसे मूल्यवान ज्ञान यहीं रहता है

उपयोग के उदाहरण

• "[PR विवरण] के लिए कोड रिव्यू चेकलिस्ट बनाओ"
• "इस पुल रिक्वेस्ट में मुझे क्या जाँचना चाहिए?"
• "[भाषा] [बदलाव-प्रकार] के लिए कोड रिव्यू चेकलिस्ट दो"
• "[भाषा] में उच्च-जोखिम PR के लिए रिव्यू चेकलिस्ट"

उदाहरण ट्रिगर वाक्य

• "कोड रिव्यू करो।"
• "एक PR जाँचो।"
• "एक पुल रिक्वेस्ट रिव्यू करो।"
• "कोड रिव्यू चेकलिस्ट बनाओ।"

इस स्किल को अपने ब्राउज़र में चलाएँ: https://mohitagw15856.github.io/pm-claude-skills/skill/code-review-checklist.html