Claude Code के साथ Code Review: बग्स को प्रोडक्शन तक पहुँचने से पहले पकड़ें

Claude Code Review क्या है?

Claude Code Review एक मल्टी-एजेंट कोड रिव्यू सिस्टम है जो रिपो के संदर्भ में PR की जाँच करता है और संभावित बग्स, सुरक्षा मुद्दों, और रिग्रेशन की रिपोर्ट करता है। GitHub Code Review उन एजेंट्स को GitHub PR पर चलाता है, जबकि लोकल /code-review सीधे Claude Code से आपके करंट डिफ की समीक्षा देता है।

यहाँ महत्वपूर्ण शब्द है संदर्भ। परंपरागत डिफ रिव्यू किसी से बदली गई लाइनों को देखने को कहता है। Claude के रिव्यू एजेंट्स उन्हीं बदलावों को रिपो के संदर्भ में देखते हैं। GitHub वर्कफ़्लो में कई विशेषज्ञ एजेंट्स समानांतर में काम करते हैं, इसके बाद verification, deduplication, और severity ranking होती है।

उदाहरण के लिए, pandas ट्रांसफॉर्मेशन में 10 लाइनों का बदलाव किसी अपस्ट्रीम dbt मॉडल द्वारा बनाए गए स्कीमा, Snowflake टेबल के ग्रेन, और डाउनस्ट्रीम डैशबोर्ड में निहित मान्यताओं पर निर्भर हो सकता है।

Claude न तो PR को approve करता है और न ही block। GitHub Code Review एक neutral check conclusion रिपोर्ट करता है, इसलिए आपके मौजूदा ब्रांच प्रोटेक्शन नियम तब तक अपरिवर्तित रहते हैं जब तक आप चेक आउटपुट के इर्द-गिर्द अपना CI लॉजिक न बनाएं।

तीन रिव्यू सरफेस

वर्तमान में Claude Code के साथ कोड रिव्यू करने के 3 मुख्य तरीके हैं।

लोकल /code-review कमांड आपकी ब्रांच के कमिट्स की समीक्षा करता है। आप किसी विशिष्ट फ़ाइल, ब्रांच, PR नंबर, या Git ref रेंज भी दे सकते हैं।

GitHub Code Review PR-केंद्रित है। रिपो कॉन्फ़िगरेशन पर निर्भर करते हुए, यह PR बनने के बाद एक बार, हर पुश के बाद, या केवल तब रिव्यू कर सकता है जब कोई @claude review से रिव्यू रिक्वेस्ट करे।

/code-review ultra भारी विकल्प है। Anthropic इस फ़ीचर को ultrareview कहता है, और /ultrareview एक alias के रूप में काम करता है जब यह आपके अकाउंट पर उपलब्ध हो। यह रिमोट सैंडबॉक्स में रिव्यूअर एजेंट्स का बेड़ा चलाता है, जहाँ हर रिपोर्टेड बग को findings में आने से पहले पुनरुत्पादित और सत्यापित किया जाता है। यह फिलहाल रिसर्च प्रीव्यू है, और एक सामान्य रिव्यू में लगभग 5 से 10 मिनट लगते हैं।

Claude क्या फ़्लैग करता है बनाम क्या छोड़ता है

Claude Code Review पहले correctness पर फोकस करता है। Anthropic के दस्तावेज़ प्रोडक्शन-इम्पैक्टिंग बग्स को फॉर्मैटिंग पसंदों और मिसिंग टेस्ट कवरेज से स्पष्ट रूप से अलग रखते हैं।

findings में 3 severity स्तर होते हैं:

यह फर्क उपयोगी है क्योंकि डेटा वैज्ञानिकों की राय अक्सर अलग-अलग होती है कि किस पर रिव्यू समय लगना चाहिए। revenue_df बनाम weekly_revenue के नाम पर सुझाव, उस श्रेणी में नहीं आता जहाँ रेवेन्यू 2 गुना हो जाए क्योंकि एक many-to-many जॉइन एक ट्रांसफॉर्मेशन में फिसल गया।

Claude Code में Code Review कैसे सेट करें?

Claude Code Review सेट करना इस पर निर्भर करता है कि आप लोकल रिव्यू चाहते हैं या GitHub PR कोड रिव्यू। लोकल /code-review के लिए GitHub App की ज़रूरत नहीं है और आप यह PR खोलने से पहले कर सकते हैं। 

GitHub Code Review के लिए संगठन के Owner या Primary Owner को Claude GitHub App कॉन्फ़िगर करना और रिपोज़ चुनना होता है। PR रिव्यू करते समय, आप REVIEW.md नाम की एक विशेष फ़ाइल बनाना चाहेंगे जिसमें केवल रिव्यू-सम्बंधी नियम हों।

CLAUDE.md बनाम REVIEW.md

CLAUDE.md और REVIEW.md के उद्देश्य अलग हैं, और दोनों को मिलाना शोरभरे रिव्यू का आसान नुस्ख़ा है।

CLAUDE.md में सामान्य प्रोजेक्ट निर्देश होते हैं जिन्हें Claude विभिन्न कार्यों में उपयोग करता है। कोड रिव्यू भी उन निर्देशों को पढ़ता है, और नए हुए उल्लंघनों को nits के रूप में रिपोर्ट करता है। दूसरी ओर, REVIEW.md विशेष रूप से रिव्यू व्यवहार के लिए है और रिव्यू एजेंट्स को बताता है कि आपकी टीम क्या फ़्लैग करना, छोड़ना, या Important मानना चाहती है।

किसी Python डेटा रिपो के लिए, मैं CLAUDE.md को ऐसी बातों पर केंद्रित रखूँगा जैसे रिपो स्ट्रक्चर, pytest कैसे चलाएँ, ट्रांसफॉर्मेशन pandas या polars से होते हैं या नहीं, और SQL मॉडल्स कहाँ हैं। 

मैं रिव्यू नियमों को REVIEW.md में रखूँगा। संभावित नियमों के कुछ उदाहरण:

• “हर नए ट्रांसफॉर्मेशन के लिए संबंधित टेस्ट जाँचें।”
• “कभी भी क्रेडेंशियल्स लॉग न करें।”
• “जेनरेटेड फ़ाइलें छोड़ें।”

एक छोटा  REVIEW.md कुछ इस तरह दिख सकता है:

# Review instructions

## Important findings

Report as Important:
- Incorrect joins or filters that can change dataset grain
- Missing tenant or customer scoping
- Secrets or credentials written to logs
- Silent changes to revenue or customer metrics

## Do not report
- Formatting already enforced by Ruff
- Generated files
- *.lock files

## Always check
- New transformations have tests
- Joins use the intended keys
- Datetime operations specify timezone assumptions
- Missing values are handled explicitly

मैं सलाह दूँगा कि REVIEW.md को केंद्रित रखें क्योंकि लंबे निर्देश महत्वपूर्ण नियमों को पतला कर सकते हैं। मौजूदा इम्प्लीमेंटेशन फ़ाइल को साधारण निर्देशों की तरह पढ़ता है, इसलिए आपको नियम सीधे इसमें ही रखने चाहिए, @ शॉर्टकट का इस्तेमाल न करें। 

वैसे, जब आप लोकल डेवलप कर रहे होते हैं, /code-review REVIEW.md नहीं पढ़ता। यह CLAUDE.md को फॉलो करता है, जबकि GitHub Code Review पाइपलाइन रिव्यू-विशेष निर्देशों के लिए REVIEW.md का उपयोग करती है।

यदि आप लोकल और GitHub दोनों में एक जैसे रिव्यू नियम चाहते हैं, तो सामान्य नियम CLAUDE.md में रखें और जहाँ ज़रूरी हो, रिव्यू-विशिष्ट नियमों को REVIEW.md में दोहराएँ।

और गहराई से समझने के लिए, हमारा सर्वश्रेष्ठ CLAUDE.md लिखने पर गाइड पढ़ें।

GitHub App और ट्रिगर मोड

GitHub Code Review को संगठन के Owner या Primary Owner द्वारा Claude की admin settings में कॉन्फ़िगर किया जाता है। एडमिन को Claude GitHub App इंस्टॉल करना, उसे रिपो एक्सेस देना, रिव्यू के लिए रिपोज़ चुनना, और फिर हर रिपो को एक रिव्यू बिहेवियर असाइन करना होता है।

3 अलग-अलग ट्रिगर मोड हैं:

इन तीनों में एक अपवाद: Claude कभी भी fork से आई pull request को अपने-आप रिव्यू नहीं करता। किसी को उस पर @claude review कमेंट करना पड़ता है।

जुलाई 2026 अपडेट के अनुसार, मैनुअल कमांड्स भी बदल गए हैं: 

• @claude review एक सिंगल रिव्यू शुरू करता है और PR को भविष्य के पुशेज़ के लिए सब्सक्राइब नहीं करता। 

• @claude review always एक रिव्यू शुरू करता है और PR को भविष्य के पुश-ट्रिगर रिव्यूज़ के लिए सब्सक्राइब करता है।

• @claude review once खाली कमांड जैसा ही व्यवहार करता है।

यदि आपने 2026 की शुरुआत में Claude Code Review सीखा था, तो पुराने ट्यूटोरियल कह सकते हैं कि @claude review PR को भविष्य के रिव्यूज़ के लिए सब्सक्राइब करता है, लेकिन यह व्यवहार जुलाई 2026 में बदल गया और सितंबर 2026 तक यही है।

वे Pro और Max यूज़र जिनके पास संगठन के GitHub Code Review का एक्सेस नहीं है, App को पूरी तरह छोड़ सकते हैं और /code-review लोकल चला सकते हैं, और गहरे रिव्यू के लिए /code-review ultra का उपयोग कर सकते हैं।

आप लोकल डिफ की समीक्षा /code-review से कैसे करते हैं?

लोकल /code-review कमांड PR खोलने से पहले आपकी करंट ब्रांच की समीक्षा करता है। मैं हमेशा यहीं से शुरू करता हूँ क्योंकि यह समस्याएँ उसी समय पकड़ लेता है जब मैं अभी काम कर रहा होता हूँ और यह फेलिंग CI को रोक सकता है।

रिव्यू का केस

मान लें हमारे पास एक ई-कॉमर्स रिपो है जिसमें ऑर्डर्स टेबल में order_id, customer_id, order_date, status, और revenue हैं, और हम साप्ताहिक रेवेन्यू निकालने के लिए weekly_revenue.py बनाते हैं:

orders = load_orders()
customers = load_customers()

# Derive the reporting week from the order date
orders["week"] = orders["order_date"].dt.to_period("W").dt.start_time

weekly_revenue = (
    orders
    .merge(customers, on="customer_id", how="inner")
    .groupby("week", as_index=False)["revenue"]
    .sum()
)

पहली नज़र में कुछ अजीब नहीं लगता। merge() स्पष्ट है, ग्रुपिंग पढ़ने में आसान है, और जॉइन के बाद रेवेन्यू एग्रीगेट हो रहा है।

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

डिफ की स्कोपिंग

अपने Claude Code सत्र से /code-review चलाएँ।

कमांड upstream ब्रांच के आगे आपकी करंट ब्रांच के कमिट्स और अनकमीटेड बदलावों की समीक्षा करता है। आप किसी खास फ़ाइल, ब्रांच, PR, या रेंज जैसे main...feature/weekly-revenue को भी टार्गेट कर सकते हैं।

उदाहरण के लिए:

/code-review weekly_revenue.py

या:

/code-review main...feature/weekly-revenue

आप effort level भी पास कर सकते हैं, जैसे /code-review high। low और medium पर रिव्यू केवल वही findings रिपोर्ट करता है जिन पर उसे सबसे अधिक भरोसा है, जबकि high से max कवरेज बढ़ाते हैं पर संभावित false positives भी बढ़ते हैं। 

रिव्यू को steer करने के लिए फ्लैग्स का उपयोग करें

वर्कफ़्लो में सहज होते ही दो फ्लैग्स काम आने लगते हैं: 

• --fix रिव्यू के बाद findings को आपके working tree पर लागू करता है।

• --comment उन्हें इनलाइन कमेंट्स के रूप में पोस्ट करता है।

Claude रिव्यू को एक बैकग्राउंड सबएजेंट के रूप में चलाता है, इसलिए प्रोसेसिंग के दौरान आप काम जारी रख सकते हैं। रिव्यू पूरा होने पर findings आपके सत्र में लौट आती हैं।

रिव्यू कुछ इस तरह रिपोर्ट कर सकता है:

🔴 Important
weekly_revenue.py:9

The merge on customer_id can duplicate order rows because
customers contains multiple records per customer. This can
inflate revenue when a customer has more than one matching
customer record.

Verify that customer_id is unique in customers or join against
the intended current-record subset before aggregating revenue.

रिव्यू ने एक ठोस फेल्योर मोड पकड़ा और मुझे ऐसा कुछ दिया जिसे मैं वास्तविक स्कीमा के विरुद्ध सत्यापित कर सकता हूँ, बजाय केवल Claude के निर्णय पर भरोसा करने के।

findings पढ़ें

मैं /code-review --fix चलाने से पहले फिर भी सब कुछ मैनुअल पास दूँगा। पहले देखें कि customers कैसे बनता है, उसकी uniqueness constraints जाँचें, और weekly_revenue.py के आसपास के टेस्ट देखें।

यदि customers.customer_id वास्तव में यूनिक है, तो Claude का finding false positive है। यदि टेबल में प्रति कस्टमर प्रति effective date एक रो है, तो finding वास्तविक है और ट्रांसफॉर्मेशन बदलना होगा।

यहाँ कुंजी यह है कि Claude का रिव्यूअर कोड व्यवहार देख रहा है, जबकि डेटा क्या दर्शाता है, यह जानने की ज़िम्मेदारी मेरी है।

आप रिव्यू के बाद Claude से जांच करने को कह सकते हैं:

Investigate the customer_id join finding.
Check how the customers table is built and determine whether
customer_id is unique at the point of this merge. Do not modify
the code yet.

यह दूसरा चरण अक्सर Claude से आँख बंद करके कमेंट “फिक्स” कराने से अधिक उपयोगी होता है। यह रिव्यू को कोड-जनरेशन अभ्यास की बजाय एक संक्षिप्त जांच में बदल देता है।

आप GitHub PR पर Claude Code Review कैसे चलाते हैं?

GitHub Code Review Claude के findings सीधे PR पर डालता है, ताकि रिव्यूअर्स बदले हुए कोड के बगल में मुद्दा देख सकें। 

क्रम मायने रखता है क्योंकि रिव्यू पहले से मौजूद PR से अटैच होता है:

1. git push के जरिए weekly-revenue ब्रांच GitHub पर पुश करें।

2. Pull request खोलें। Claude केवल खुले PR की समीक्षा कर सकता है, इसलिए इससे पहले कुछ नहीं होगा।

3. यदि रिपो ऑटोमैटिक ट्रिगर पर सेट है, तो रिव्यू अपने-आप शुरू हो जाएगा। यदि यह Manual पर है, तो एक टॉप-लेवल PR कमेंट के रूप में @claude review पोस्ट करें।

यहाँ तीन आवश्यकताएँ लोगों को उलझा देती हैं। कमांड एक टॉप-लेवल PR कमेंट होना चाहिए, न कि किसी इनलाइन रिव्यू कमेंट का जवाब; और आपके पास रिपो पर write, maintain, या admin परमिशन होनी चाहिए। कमांड कमेंट की शुरुआत में होना चाहिए, और यदि once या always जोड़ें, तो वे भी उसी लाइन पर हों।

रिव्यू ट्रिगर करें

वास्तव में आपकी लागत दो मैनुअल कमांड्स के बीच के चुनाव से तय होती है, न कि मैनुअल बनाम ऑटोमैटिक से।

@claude review एक रिव्यू चलाता है और PR को अनसब्सक्राइब छोड़ता है। @claude review always एक रिव्यू चलाता है और PR को सब्सक्राइब कर देता है, ताकि हर बाद का पुश नया रिव्यू शुरू करे।

यह व्यवहार जुलाई 2026 के बाद और सितंबर 2026 तक का है। उससे पहले, खाली @claude review कमांड PR को भविष्य के रिव्यूज़ के लिए सब्सक्राइब करता था, इसलिए यदि आप पुराना ट्यूटोरियल फॉलो कर रहे हैं, तो पहले यह जाँच लें।

रिव्यू में अक्सर लगभग 20 मिनट लगते हैं, हालाँकि Anthropic कहता है कि लागत और अवधि PR के आकार और जटिलता पर निर्भर करती है। हर रिव्यू Team या Enterprise प्लान के included usage की बजाय usage credits से अलग से बिल होता है। यदि आप लागत संरचना के बारे में अधिक जानना चाहते हैं, तो हमारा Claude Code usage limits गाइड पढ़ें।

इनलाइन कमेंट्स और चेक रन पढ़ें

रिव्यू पूरा होने पर, Claude संबंधित लाइनों पर इनलाइन कमेंट्स पोस्ट करता है। GitHub चेक रन में severity सारांश भी होता है, जो उपयोगी है जब किसी PR में weekly_revenue.py, SQL मॉडल्स, और टेस्ट फ़ाइलों में कई findings हों।

उदाहरण के लिए:

इनलाइन कमेंट पर मैं वास्तविक मुद्दे की जांच करूँगा। चेक रन से मैं रिव्यू की समग्र तस्वीर लूँगा।

ध्यान दें, 👍 या 👎 क्लिक करने से नया रिव्यू ट्रिगर नहीं होता, और इनलाइन कमेंट का जवाब देने पर Claude प्रतिक्रिया नहीं देता। दूसरा रिव्यू पाने के लिए, कोड फिक्स करें और पुश करें, या नया टॉप-लेवल PR कमेंट के रूप में @claude review पोस्ट करें।

रिव्यू स्वयं मर्जिंग को ब्लॉक नहीं करता। चेक न्यूट्रल निष्कर्ष देता है, हालाँकि चेक आउटपुट में मशीन-रीडेबल severity सूचना होती है जिसे टीम gh और jq के जरिए उपयोग कर अपनी मर्ज गेट बना सकती है।

आप Claude के रिव्यू कमेंट्स को कैसे त्रिआज़ करते हैं?

पूरा उद्देश्य रिव्यू चक्र के दौरान human-in-the-loop बनाए रखना है। इसका मतलब है कि हर Claude रिव्यू में यह तय करना पड़ता है कि प्रत्येक finding वास्तविक बग है, नॉन-ब्लॉकिंग सुधार है, या false positive है। क्योंकि कोड रिव्यूअर इम्प्लीमेंटेशन व्यवहार देख सकता है, लेकिन हर डेटासेट या मैट्रिक के बिज़नेस अनुमानों को नहीं जानता।

मैं एक सरल 3-तरफा निर्णय उपयोग करता हूँ:

यह आख़िरी श्रेणी महत्वपूर्ण है। 30 findings रिपोर्ट करने वाला रिव्यूअर 5 रिपोर्ट करने वाले से ज़रूरी नहीं बेहतर हो। pandas मर्ज पर एक false-positive कमेंट में मूल कोड बदलाव से ज़्यादा समय लग सकता है।

Fix, skip, या push back

यदि डुप्लिकेटेड कस्टमर रो का बग वास्तविक है, तो मैं Claude से upstream मॉडल inspect करवाकर यह फिक्स कराने को कह सकता हूँ:

The customer_id finding is valid. Inspect the existing customer
model and update weekly_revenue.py to join only the current
customer record. Add a regression test for a customer with
multiple historical records, then run the relevant tests.

इसके बाद Claude रिपो inspect कर सकता है, Python कोड बदल सकता है, टेस्ट जोड़ सकता है, और टेस्ट सूट चला सकता है।

यदि आप GitHub रिव्यू कमेंट्स से काम करना चाहते हैं, तो Claude Code GitHub CLI (gh) के जरिए भी रिपो से इंटरैक्ट कर सकता है। महत्वपूर्ण फ़र्क यह है कि मैं वे ही विशेष फिक्स चुनूँगा जिन्हें आप वैध मानते हैं, न कि पूरा रिव्यू देकर "सब कुछ फिक्स" करने को कहूँ।

यह डेवलपर्स को रिव्यू लूप में रखता है:

1. Claude संभावित समस्या ढूँढता है।
2. मैं समस्या को कोड और डेटा मान्यताओं के विरुद्ध सत्यापित करता हूँ।
3. Claude अनुरोधित फिक्स करता है।
4. टेस्ट चलते हैं।
5. Claude फिर से उत्पन्न डिफ की समीक्षा करता है।

यह लूप पहले रिव्यू आउटपुट को automated refactoring queue की तरह मानने से कहीं सुरक्षित है।

डेटा PR में इंसान की अब भी क्या ज़रूरत है?

वह फेल्योर मोड जिसे Claude कवर नहीं कर सकता, वह है—कोड सही चलता है पर फिर भी गलत काम करता है। तीन रूप बार-बार दिखते हैं:

• मान्यताएँ जो डिफ के बाहर रहती हैं। Claude आपका रिपो पढ़ता है, आपका डेटा वेयरहाउस, आपका कॉन्फ़िग सर्विस, या किसी दूसरी टीम का कॉन्ट्रैक्ट नहीं। जॉइन सही keys का उपयोग कर सकता है और फिर भी रिज़ल्ट का ग्रेन बदल सकता है, क्योंकि per-key रो की संख्या अपस्ट्रीम टेबल की प्रॉपर्टी है, न कि आपके सामने के कोड की।

• परिभाषाएँ जो केवल आपकी टीम रखती है। रेवेन्यू ऑर्डर, कस्टमर, या सप्ताह के स्तर पर गिना जाए या नहीं—यह बिज़नेस निर्णय है। Claude आपको बता सकता है कि groupby() उसे दी गई किसी भी रो का जोड़ लगा देगा। वह यह नहीं बता सकता कि आपकी फाइनेंस टीम किस संख्या पर हस्ताक्षर करती है।

• समय और प्रकार की मान्यताएँ। 2026-08-27 का मतलब UTC दिन है, लोकल बिज़नेस डे, या अपस्ट्रीम मॉडल द्वारा सेट की गई रिपोर्टिंग तिथि? साइलेंट coercion का भी वही आकार है: object, nullable integer, timezone-aware datetime, और string कॉलम्स के पार ऑपरेशंस कुछ plausible लौटाते हैं जबकि चुपचाप कम्पैरिज़न्स का व्यवहार बदल देते हैं।

डेटा लीकेज पहले श्रेणी का सबसे तीखा उदाहरण है। एक फ़ीचर ट्रांसफॉर्मेशन ट्रेनिंग सेट को ऐसी टेबल से जॉइन कर सकता है जिसमें केवल prediction date के बाद मौजूद जानकारी हो। जॉइन वैध है, रो काउंट अपेक्षित है, और मॉडल भ्रष्ट हो जाता है।

इसलिए मैं Claude को इम्प्लीमेंटेशन व्यवहार का रिव्यूअर मानता हूँ, परिभाषा का मालिक नहीं।

आप Code Review बनाम Ultrareview कब उपयोग करें?

तेज़ लोकल फ़ीडबैक के लिए /code-review का उपयोग करें और गहरे प्री-मर्ज पास के लिए /code-review ultra का। दोनों कोड की समीक्षा करते हैं, लेकिन /code-review iteration के लिए डिज़ाइन है, जबकि ultra रिव्यू कई रिमोट एजेंट्स चलाता है और रिपोर्टेड बग्स को स्वतंत्र रूप से सत्यापित करता है।

Anthropic फिलहाल ultra review को रिसर्च प्रीव्यू बताता है। Pro और Max सब्सक्राइबर्स को एक बार के लिए 3 मुफ्त रन मिलते हैं जो रिफ्रेश नहीं होते; उसके बाद रिव्यू सामान्यतः $5 से $25 पड़ता है, बदलाव के आकार पर निर्भर। Team और Enterprise यूज़र्स को ये मुफ्त रन नहीं मिलते, और यह फ़ीचर Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry, तथा Zero Data Retention सक्षम संगठनों पर उपलब्ध नहीं है।

महत्वपूर्ण फ़र्क verification है. /code-review ultra रिपो स्थिति को रिमोट सैंडबॉक्स में भेजता है और रिव्यूअर एजेंट्स का बेड़ा चलाता है, जहाँ रिपोर्टेड बग्स findings के रूप में लौटने से पहले स्वतंत्र रूप से पुनरुत्पादित होते हैं।

मैं इसे हर कमिट पर नहीं चलाऊँगा। यदि मैं Python नोटबुक में वैरिएबल नाम बदल रहा हूँ या dbt मॉडल का फॉर्मैटिंग समायोजित कर रहा हूँ, तो लोकल /code-review पर्याप्त है। यदि मैं प्रोडक्शन मॉडल की फ़ीचर-जनरेशन लॉजिक बदल रहा हूँ, कोई रेवेन्यू ट्रांसफॉर्मेशन फिर से लिख रहा हूँ, या कस्टमर-स्तरीय एग्रीगेशन बदल रहा हूँ, तो अतिरिक्त रिव्यू पास अधिक तर्कसंगत है।

नामकरण में एक बारीकी भी है। documented कमांड /code-review ultra है, और /ultrareview एक alias है जो तब काम करता है जब ultrareview आपके अकाउंट पर उपलब्ध हो। पुराने ट्यूटोरियल्स अक्सर /ultrareview को प्राथमिक कमांड की तरह दिखाते हैं, लेकिन Anthropic का दस्तावेज़ अब डीप क्लाउड रिव्यू को /code-review परिवार का हिस्सा मानता है, और /code-review ultra क्लाउड फ़ीचर अनुपलब्ध होने पर लोकल रिव्यू पर fallback कर देता है।

उसी PR पर ultra रिव्यू चलाएँ

रिपो से चलाएँ:

/code-review ultra

GitHub PR को सीधे रिव्यू करने के लिए:

/code-review ultra <pr#>

बिना आर्गुमेंट के, /code-review ultra आपकी करंट ब्रांच की तुलना डिफ़ॉल्ट ब्रांच से करता है और अनकमीटेड व स्टेज्ड बदलाव शामिल करता है। ब्रांच रिव्यू डिफ़ॉल्ट रूप से लगभग 500 बदली फ़ाइलों और 8,000 बदली लाइनों तक सीमित रहता है, हालाँकि Anthropic कहता है कि ये संख्याएँ बदल सकती हैं। यदि आपका डिफ बहुत बड़ा है, तो ब्रांच पुश करें और उसे PR के रूप में रिव्यू करें।

PR नंबर के साथ, रिमोट एनवायरनमेंट GitHub से PR क्लोन करता है, और आपकी मशीन से कुछ अपलोड नहीं होता।

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

हमारे weekly_revenue.py उदाहरण के लिए, मैं यह मानने के बजाय findings की तुलना करूँगा कि गहरा रिव्यू ज़रूर सही है।

यदि /code-review कस्टमर जॉइन को फ़्लैग करता है और ultra रिव्यू स्वतंत्र रूप से वही रेवेन्यू डुप्लिकेशन पुनरुत्पादित करता है, तो उस finding पर मेरा भरोसा बढ़ता है। यदि ultra रिव्यू इसे नज़रअंदाज़ करता है क्योंकि upstream टेबल uniqueness गारंटी देती है, तो मैं दोनों रिव्यूज़ के साक्ष्य और वास्तविक मॉडल डिफ़िनिशन देखकर ही कोड बदलूँगा।

एकाधिक रिव्यूअर्स का यह भी एक उपयोगी गुण है: असहमति आपको जांच के लिए कुछ देती है।

लागत का पहलू भी है। GitHub Code Review फिलहाल प्रति रिव्यू औसतन $15 से $25 पड़ता है, जबकि ultra रिव्यू मुफ्त Pro और Max रन के बाद सामान्यतः $5 से $25 का होता है। GitHub Code Review की लागत included प्लान usage से अलग है, और Anthropic संगठनों के लिए खर्च नियंत्रण देता है।

यदि आप अकेले काम कर रहे हैं, तो लोकल /code-review और बीच-बीच में /code-review ultra एक उचित शुरुआती वर्कफ़्लो है। यदि आप Team या Enterprise प्लान पर हैं और हर PR पर स्वचालित रिव्यू चाहते हैं, तो GitHub Code Review अधिक समझ में आता है।

एक व्यावहारिक Claude Code Review वर्कफ़्लो

उपयोगी वर्कफ़्लो "हर मर्ज से पहले Claude चलाएँ" नहीं है। यह एक क्रम है जहाँ हर रिव्यू डेवलपमेंट के अलग समय पर होता है, क्योंकि हर एक की लागत अलग है और अलग श्रेणी की समस्या पकड़ता है।

प्रोडक्शन बदलाव के लिए मैं यह प्रक्रिया अपनाऊँगा:

Write code
	   ↓
Run tests and data checks
	   ↓
/code-review
	   ↓
Fix verified findings
	   ↓
Open GitHub PR
	   ↓
GitHub Code Review
	   ↓
Human triage
	   ↓
/code-review ultra for higher-risk changes
	   ↓
Final tests
	   ↓
Human merge

लोकल रिव्यू समस्याओं को उस समय पकड़ता है जब उन्हें ठीक करना सस्ता होता है। GitHub रिव्यू व्यापक टीम को findings का साझा रिकॉर्ड देता है, जबकि ultra रिव्यू किसी निर्णायक मर्ज से पहले उच्च-प्रयास वाली दूसरी राय प्रदान करता है।

डेटा वैज्ञानिकों के लिए अतिरिक्त जाँचें

डेटा कार्य के लिए, मैं Claude से पूरी समीक्षा की उम्मीद करने की बजाय उसके इर्द-गिर्द 4 जाँचें जोड़ूँगा:

• महत्वपूर्ण जॉइन्स से पहले और बाद में रो काउंट्स और डेटासेट ग्रेन जाँचें
• ट्रांसफॉर्मेशंस और फ़ीचर लॉजिक के आसपास यूनिट या इंटीग्रेशन टेस्ट चलाएँ।
• मशीन लर्निंग फ़ीचर्स बनाते समय लीकेज की जाँच करें।
• बिज़नेस मैट्रिक्स को किसी विश्वसनीय क्वेरी या डैशबोर्ड से वैलिडेट करें।

Claude इन सभी 4 गतिविधियों में भाग ले सकता है, लेकिन अपेक्षित परिणाम कोड, टेस्ट, या डेटा से आना चाहिए—Claude की व्याख्या से नहीं।

अंतिम विचार

जब मैं Claude Code Review को रिव्यू थ्रेड पर एक और इंजीनियर की तरह मानता हूँ, न कि automated approval स्टैम्प की तरह, तब यह सबसे अच्छा काम करता है।

लोकल /code-review कमांड PR बनने से पहले तेज़ रिव्यू देता है। GitHub Code Review Team और Enterprise संगठनों के लिए मल्टी-एजेंट findings को PR में लाता है, जबकि /code-review ultra तब गहरा रिमोट रिव्यू देता है जब बदलाव एक और पास का हकदार हो।

मैं छोटे से शुरू करूँगा। /code-review को अपनी सामान्य ब्रांच वर्कफ़्लो में शामिल करें, अपने GitHub रिव्यू के लिए छोटा REVIEW.md लिखें, और उन बदलावों पर /code-review ultra आज़माएँ जिनमें खराब मर्ज आपकी वाकई कीमत बढ़ा सकता है।

आधारभूत मॉडल अवधारणाओं के लिए, हमारा Introduction to Claude Models कोर्स व्यापक संदर्भ देता है, जबकि GitHub Foundations और Intermediate GitHub Concepts Git और GitHub वर्कफ़्लो कवर करते हैं, जिन पर Code Review टिका है। GitHub रिपोज़ को Claude से त्रिआज़ करने की और प्रेरणा के लिए, हमारा Claude Code connector ट्यूटोरियल पढ़ने की भी सलाह देता हूँ।