Claude Code का /code-review क्या है? इस्तेमाल का तरीक़ा, लेवल कैसे चुनें, ultra की क़ीमत, कमियाँ और सच में इस्तेमाल करने के नतीजे

Claude Code का /code-review एक ऐसा कमांड है जो आपका मौजूदा diff (अनकमिटेड बदलाव और upstream से आगे के कमिट) पढ़ता है, उसमें correctness से जुड़े बग खोजता है और उनकी रिपोर्ट देता है। यह Claude Code के साथ आने वाली बिल्ट-इन स्किल (bundled skill) है, इसलिए कोई GitHub ऐप इंस्टॉल किए बिना इसे सीधे टर्मिनल से चला सकते हैं। /review टाइप करने पर भी यही चलता है।

यह लेख Claude Code के आधिकारिक दस्तावेज़ (Code Review का "Review a diff locally" सेक्शन, Find bugs with ultrareview और Commands) तथा CHANGELOG के मूल पाठ के आधार पर बताता है कि यह क्या करता है, लेवल (low से max) और ultra में से कैसे चुनें, और --fix व --comment का इस्तेमाल कैसे करें। यहाँ लिखी हर विशेषता को 2 अक्टूबर 2026 को मूल पाठ से मिलाकर जाँचा गया है। सेक्शन 9 और 10 में यह भी है कि इस साइट के कोड पर /code-review high सच में चलाने पर क्या मिला, और उस दौरान कौन-सी कमियाँ दिखीं।

1. /code-review क्या है? diff में बग ढूँढने वाली बिल्ट-इन स्किल

Commands रेफ़रेंस इसे ऐसे बताता है: मौजूदा diff की, या आप जो PR नंबर, ब्रांच या पाथ दें उसकी, correctness बग के लिए समीक्षा करना। आगे लिखा है कि मॉडल और effort लेवल के हिसाब से समीक्षा में कोड सुधारने (cleanup) के मौक़े भी शामिल होते हैं, और Code Review पेज के मुताबिक़ यह correctness बग के साथ-साथ दोबारा इस्तेमाल (reuse), सरलीकरण और कुशलता से जुड़े सुधार भी बताता है। मुख्य काम बग खोजना है; सुधार के सुझाव हालात के हिसाब से साथ आते हैं।

इसका सिंटैक्स ऐसा है:

/code-review [low|medium|high|xhigh|max|ultra] [--fix] [--comment] [pr#|branch|path]

शुरू में ही चार बातें जान लेना अच्छा है:

• यह बैकग्राउंड में चलता है। समीक्षा अपनी अलग कॉन्टेक्स्ट विंडो वाले सबएजेंट के रूप में चलती है, इसलिए आपकी बातचीत नहीं भरती। काम पूरा होने पर नतीजे बातचीत में आ जाते हैं।
• यह CLAUDE.md पढ़ता है, लेकिन REVIEW.md नहीं। REVIEW.md, Code Review के GitHub App वाले संस्करण की निर्देश-फ़ाइल है, जिसका ज़िक्र आगे है।
• /review इसका दूसरा नाम (alias) है। दस्तावेज़ के अनुसार v2.1.223 से पहले /review एक अलग कमांड था, जो GitHub PR को एक ही बार में पढ़ता था। अब यह /code-review जैसा ही है।
• इसका पुराना नाम /simplify था। CHANGELOG के अनुसार v2.1.147 में /simplify का नाम बदलकर /code-review किया गया, और बाद में /simplify एक अलग कमांड के रूप में लौटा, जो सिर्फ़ कोड सुधारता है और बग नहीं खोजता।

टर्मिनल में और -p से चलाने पर नतीजे जवाब में टेक्स्ट के रूप में आते हैं। डेस्कटॉप ऐप जैसे जो ऐप नतीजों की सूची माँगते हैं, उनमें ये एक सूची में दिखते हैं, जिसकी हर प्रविष्टि में फ़ाइल की जगह, एक वाक्य का सार और correctness जैसा श्रेणी टैग होता है। जब Claude बाद में इन्हें ठीक करता है, तो हर प्रविष्टि पर ठीक किया गया, छोड़ा गया या बदलाव की ज़रूरत नहीं, ऐसा निशान लग जाता है।

2. बुनियादी इस्तेमाल: किसकी समीक्षा करनी है, यह चुनना

सबसे आसान तरीक़ा है, जिस सेशन में आप काम कर रहे हैं उसमें इसे बिना किसी आर्ग्युमेंट के टाइप करना।

# Review commits ahead of upstream + uncommitted changes
/code-review

# Review at a specific level
/code-review high

# Pass a PR number to review a colleague's pull request
/code-review high 1234

# Pass a branch range
/code-review main...my-feature

बिना आर्ग्युमेंट के, दस्तावेज़ के अनुसार लक्ष्य होता है आपकी ब्रांच के वे कमिट जो उसके upstream से आगे हैं, साथ में सारे अनकमिटेड बदलाव। अगर ब्रांच या वर्किंग ट्री में कुछ नया नहीं है, तो रिपोर्ट करने को कुछ नहीं होता। किसी और चीज़ की समीक्षा करनी हो तो लक्ष्य दें:

जब तक आप ultra न जोड़ें, लेवल और फ़्लैग के बाद जो कुछ बचता है, उसे समीक्षा का लक्ष्य माना जाता है। उदाहरण के लिए, /code-review /fix-issue 123 में /fix-issue दूसरी स्किल के रूप में लोड नहीं होता; /fix-issue 123 टेक्स्ट को ही लक्ष्य के रूप में पढ़ा जाता है।

इन हालात में यह बैकग्राउंड की जगह फ़ोरग्राउंड में, यानी आपकी बातचीत के अंदर चलता है: जब पिछली समीक्षा अभी चल रही हो और आप इसे फिर चलाएँ, जब -p या Agent SDK से नॉन-इंटरैक्टिव मोड में चलाएँ, और जब एनवायरनमेंट वेरिएबल CLAUDE_CODE_DISABLE_BACKGROUND_TASKS को 1 पर सेट करें (इससे बाक़ी सारे बैकग्राउंड फ़ीचर भी बंद हो जाते हैं)।

3. लेवल कैसे चुनें: low से max

लेवल इस बात का संतुलन है कि समीक्षा कितना बड़ा दायरा देखे और उसके नतीजे कितने पक्के हों। दस्तावेज़ समझाता है कि low और medium पर समीक्षा सिर्फ़ वही नतीजे बताती है जिन पर उसे सबसे ज़्यादा भरोसा हो, इसलिए ग़लत चेतावनियाँ (false positive) कम दिखती हैं, जबकि high से max तक दायरा बढ़ता है और ऐसे नतीजे भी आ सकते हैं जिन पर समीक्षा को कम भरोसा हो।

चुनने का सीधा पैमाना है नतीजे पढ़ने में आप कितनी मेहनत लगा सकते हैं। दो कामों के बीच जल्दी से जाँच करनी हो तो low या medium लें; merge से पहले ज़्यादा पकड़ना हो और ग़लत चेतावनियाँ ख़ुद छाँट सकते हों, तो high या उससे ऊपर लें। यह बँटवारा दस्तावेज़ के वर्णन के मुताबिक़ है। ऊँचे लेवल पर ज़्यादा टोकन लगना effort की आम बात जैसा ही है, लेकिन आधिकारिक दस्तावेज़ हर लेवल के समय या उपयोग का कोई आँकड़ा नहीं देता। effort का मतलब क्या है, यह Claude Code की effort सेटिंग वाले हमारे लेख में समझाया गया है।

लेवल न लिखें तो "पिछली बार टाइप किया गया लेवल" दोबारा लगता है

अगर आप लेवल टाइप नहीं करते, तो समीक्षा low से max में से वह आख़िरी लेवल इस्तेमाल करती है जो आपने ख़ुद टाइप किया था। इसमें पिछले सेशन में टाइप किया गया लेवल भी शामिल है, और तब Reusing high effort, the level you typed last time जैसी सूचना दिखती है। बारीकियाँ:

• याद रखा गया लेवल तब अपडेट होता है जब आप इंटरैक्टिव सेशन में /code-review high जैसा कुछ टाइप करते हैं।
• नॉन-इंटरैक्टिव -p रन में दिया गया लेवल याद नहीं रखा जाता।
• ultra याद रखे गए लेवल को न इस्तेमाल करता है, न अपडेट करता है।
• अगर आपने कभी लेवल टाइप नहीं किया, तो सेशन का मौजूदा effort इस्तेमाल होता है।

दस्तावेज़ यह भी बताता है कि v2.1.223 से पहले बिना लेवल वाला /code-review हमेशा सेशन का मौजूदा effort इस्तेमाल करता था। पुराने व्यवहार की उम्मीद में लेवल छोड़ देंगे तो यह आपकी सोच से ऊँचे (या नीचे) लेवल पर चल सकता है, इसलिए अगर फ़र्क़ पड़ता हो तो हर बार लेवल लिखें।

4. --fix और --comment का इस्तेमाल

--fix को शायद /rewind से वापस न लिया जा सके

सबसे ज़्यादा ध्यान इसी हिस्से पर देना चाहिए। दस्तावेज़ के अनुसार बैकग्राउंड समीक्षा में --fix के बदलाव आपके सेशन के चेकपॉइंट के बाहर होते हैं, इसलिए /rewind उन्हें वापस नहीं करता। उन्हें git से वापस करें। जब समीक्षा फ़ोरग्राउंड में चलती है (पिछली समीक्षा अभी चल रही हो, -p वग़ैरह), तो बदलाव आपकी अपनी बारी में होते हैं, इसलिए /rewind उन्हें सामान्य रूप से वापस कर देता है।

# Commit your current state before --fix so it's easy to go back
git add -A && git commit -m "wip: before code-review --fix"
/code-review medium --fix

# If you don't like the result, undo it with git
git diff
git restore .

आप --fix के बिना समीक्षा चलाकर नतीजे पढ़ सकते हैं, और फिर कह सकते हैं कि "सिर्फ़ #1 और #3 ठीक करो"। अगर पक्का नहीं है कि हर नतीजा लागू करना चाहिए, तो यही ज़्यादा सुरक्षित रास्ता है। चेकपॉइंट के बारे में विस्तार से चेकपॉइंट और /rewind वाले हमारे लेख में बताया गया है।

--comment कहाँ पोस्ट करता है

• GitHub पुल रिक्वेस्ट: नतीजों को संबंधित लाइनों पर इनलाइन कमेंट के रूप में पोस्ट करता है।
• GitLab मर्ज रिक्वेस्ट: GitLab के CLI glab के ज़रिए इन्हें एक नोट के रूप में पोस्ट करता है (v2.1.257 या बाद का)। अगर glab इंस्टॉल नहीं है, तो नतीजे सिर्फ़ टर्मिनल में दिखते हैं।

GitLab पर MR को URL के रूप में या !123 के रूप में दें। सिर्फ़ नंबर या ब्रांच का नाम तभी MR माना जाता है जब origin gitlab.com पर हो; अपने सर्वर पर चलने वाले (self-managed) GitLab के लिए दस्तावेज़ URL या !123 इस्तेमाल करने को कहता है। GitHub पर पोस्ट करने के लिए gh जैसे ऑथेंटिकेशन की ज़रूरत है या नहीं, यह 2 अक्टूबर 2026 तक आधिकारिक दस्तावेज़ में नहीं लिखा है।

5. ultra: कई एजेंट वाली क्लाउड समीक्षा और उसकी क़ीमत

/code-review ultra एक गहरी समीक्षा है जो आपकी मशीन पर नहीं, बल्कि Anthropic के क्लाउड के एक sandbox में कई reviewer एजेंट समानांतर चलाती है। यह ultrareview नाम का रिसर्च प्रीव्यू है, और जिन अकाउंट पर यह उपलब्ध है, उन पर /ultrareview इसका alias है। आधिकारिक दस्तावेज़ लोकल /code-review की तुलना में इसके तीन फ़ायदे गिनाता है:

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

क़ीमत और मुफ़्त रन

ultra का ख़र्च आपके प्लान में शामिल उपयोग से नहीं, बल्कि यूसेज क्रेडिट (usage credits / extra usage) से कटता है।

• मुफ़्त रन: Pro और Max के तीन रन हर अकाउंट के लिए एक ही बार मिलते हैं और दोबारा नहीं भरते।
• हर रन की लागत: मुफ़्त रन ख़त्म होने के बाद बदलाव के आकार के हिसाब से आम तौर पर $5 से $25 यूसेज क्रेडिट लगते हैं। हर रन से पहले लॉन्च डायलॉग में अनुमान दिखता है।
• रन कैसे गिने जाते हैं: क्लाउड सेशन शुरू होते ही रन गिन लिया जाता है। बीच में रोकने या फ़ेल होने पर भी एक मुफ़्त रन ख़र्च हो जाता है। पेड समीक्षा में जितना असल में चला, उतने का बिल बनता है।
• पहले की शर्त: यूसेज क्रेडिट चालू न हों तो पेड समीक्षा शुरू नहीं होती। इसे /usage-credits से जाँच सकते हैं। यूसेज क्रेडिट से बिल करने की पुष्टि हर बातचीत में एक बार माँगी जाती है।

"$5–25" महँगा है या सस्ता, यह इस पर निर्भर है कि किससे तुलना करें। low से max वाले /code-review से तुलना करें, जो बिना अलग शुल्क के प्लान की सीमा में रहता है, तो ultra एक अतिरिक्त ख़र्च है। दूसरी ओर, आगे बताए गए GitHub App वाले Code Review से तुलना करें (औसतन $15–25 प्रति समीक्षा), तो दोनों की क़ीमत की रेंज एक-दूसरे पर चढ़ती है। लेकिन Code Review एक अलग व्यवस्था है जो हर PR पर अपने-आप चलती है, और आँकड़े भी अलग ढंग से बताए गए हैं (औसत बनाम आम रेंज), इसलिए इनकी सीधी तुलना नहीं हो सकती।

समय, दायरा और जहाँ यह उपलब्ध नहीं है

• अवधि: आम तौर पर 5 से 10 मिनट। यह बैकग्राउंड में चलता है, और /tasks से इसकी स्थिति देख सकते हैं या इसे रोक सकते हैं। रोकने पर अधूरे नतीजे नहीं मिलते।
• दायरा: बिना आर्ग्युमेंट के यह रिपॉज़िटरी की डिफ़ॉल्ट ब्रांच की तुलना में आपकी मौजूदा ब्रांच की समीक्षा करता है, साथ में अनकमिटेड और staged बदलाव भी। यह लोकल /code-review के "upstream से आगे" वाले आधार से अलग है। आधार बदलना हो तो /code-review ultra develop की तरह ब्रांच का नाम दें।
• PR की समीक्षा: /code-review ultra 1234 की तरह नंबर दें, तो आपकी मशीन से कुछ अपलोड नहीं होता; क्लाउड सीधे PR को क्लोन करता है। यह github.com और जुड़े हुए GitHub Enterprise Server पर काम करता है।
• सीमाएँ: ब्रांच समीक्षा डिफ़ॉल्ट रूप से अधिकतम 500 बदली गई फ़ाइलें और 8,000 बदली गई लाइनें कवर करती है (दस्तावेज़ के अनुसार ये मान बदल सकते हैं)।
• जहाँ यह उपलब्ध नहीं है: इसके लिए claude.ai अकाउंट से साइन-इन ज़रूरी है, और यह Amazon Bedrock, Google Cloud के Agent Platform या Microsoft Foundry के ज़रिए, या Zero Data Retention वाले संगठनों के लिए उपलब्ध नहीं है। जहाँ यह उपलब्ध नहीं, वहाँ /code-review ultra लोकल समीक्षा के रूप में चलता है।

ब्रांच समीक्षा आपकी लोकल रिपॉज़िटरी की स्थिति को बंडल करके क्लाउड पर अपलोड करती है। .env और *.tfvars जैसे क्रेडेंशियल-जैसे नाम वाली फ़ाइलों के अनकमिटेड बदलावों पर वही नियम लागू होते हैं जो क्लाउड सेशन में अपलोड करते समय होते हैं। क्लाउड सेशन आम तौर पर कैसे काम करते हैं, यह क्लाउड सेशन वाले हमारे लेख में बताया गया है।

नतीजे PR पर पोस्ट करना (--post) और स्क्रिप्ट से चलाना

github.com के PR की ultra से समीक्षा करते समय आप नतीजों को अपने GitHub अकाउंट से PR पर एक कमेंट के रूप में पोस्ट कर सकते हैं (v2.1.227 या बाद का)। यह एक साधारण कमेंट है, review या approval नहीं, और डिफ़ॉल्ट रूप से पोस्ट नहीं होता (--no-post)। /code-review ultra 1234 --post लॉन्च डायलॉग में पोस्ट करने का विकल्प पहले से चुन देता है, लेकिन शुरू होने से पहले पुष्टि फिर भी माँगी जाती है। पोस्टिंग समीक्षा पूरी होने पर शुरू होती है, इसलिए काम पूरा होने तक सेशन खुला रखना ज़रूरी है।

CI या स्क्रिप्ट के लिए claude ultrareview सबकमांड इस्तेमाल करें। यह नतीजों का इंतज़ार करता है और उन्हें stdout पर लिखता है (--json, --timeout (डिफ़ॉल्ट 45 मिनट) और --post उपलब्ध हैं)। claude -p '/code-review ultra' सिर्फ़ समीक्षा शुरू करके इंतज़ार किए बिना बाहर निकल जाता है, इसलिए नतीजे नहीं मिलते, और जब यूसेज क्रेडिट से बिल करना ज़रूरी हो, तब तो यह शुरू भी नहीं होता।

# Review PR 1234 with ultra from a script and get the results
claude ultrareview 1234

# Use a base other than the default branch
claude ultrareview origin/main

6. मिलते-जुलते फ़ीचर से फ़र्क़

Claude Code में मिलते-जुलते नाम वाले कई समीक्षा फ़ीचर हैं। GitHub App का "Code Review" नाम वाला फ़ीचर ख़ास तौर पर उलझन पैदा करता है, क्योंकि उसका दस्तावेज़ /code-review कमांड वाले पेज पर ही है।

• /simplify: चार एजेंट समानांतर जाँचते हैं कि मौजूदा helper दोबारा इस्तेमाल हो रहे हैं या नहीं, कोड सरल किया जा सकता है या नहीं, कुशलता कैसी है और बदलाव सही abstraction स्तर पर है या नहीं, फिर सुधार लागू करते हैं। यह correctness बग नहीं खोजता। Code Review पेज यह सलाह भी देता है कि अगर आपने बग खोजने के लिए /simplify को स्क्रिप्ट में डाला था, तो /code-review --fix पर चले जाएँ।
• /security-review: आपकी मौजूदा ब्रांच और origin की डिफ़ॉल्ट ब्रांच के बीच के diff में injection, ऑथेंटिकेशन की समस्याएँ और डेटा लीक जैसी कमज़ोरियाँ जाँचता है। इसके लिए origin रिमोट ज़रूरी है।
• Code Review (GitHub App): संगठन का Owner इसे चालू कर दे, तो PR खुलने पर, हर push पर, या किसी के @claude review लिखने पर Anthropic के इन्फ़्रास्ट्रक्चर पर कई एजेंट PR की जाँच करते हैं और लाइन-स्तर के कमेंट छोड़ते हैं। यह सिर्फ़ Team और Enterprise के लिए रिसर्च प्रीव्यू है (Zero Data Retention वाले संगठनों के लिए उपलब्ध नहीं)। क़ीमत टोकन के हिसाब से बढ़ती है, औसतन $15–25 प्रति समीक्षा, औसतन 20 मिनट लगते हैं, और बिल प्लान की सीमा से अलग यूसेज क्रेडिट से बनता है। क्या पकड़ना है, यह REVIEW.md से तय कर सकते हैं।
• claude-code-action: आपकी अपनी रिपॉज़िटरी के GitHub Actions वर्कफ़्लो में Claude Code चलाता है। आधिकारिक दस्तावेज़ का समीक्षा वाला उदाहरण PR पर कमेंट करने के लिए code-review स्किल का प्लगइन संस्करण (/code-review:code-review --comment) बुलाता है। लागत है Claude API की क़ीमत (या सब्सक्रिप्शन टोकन) और GitHub Actions का रन टाइम।

इन्हें "कहाँ चलता है, पैसा कौन देता है और क्या देखता है" के हिसाब से बाँटें तो बात साफ़ हो जाती है। अपना diff लोकल रूप से जाँचना हो तो /code-review; merge से पहले गहराई से देखना हो तो ultra; टीम के हर PR पर अपने-आप चलाना हो तो GitHub App का Code Review या claude-code-action।

7. Claude इसे ख़ुद कब चलाता है, और उसे कैसे रोकें

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

अगर Claude और शेड्यूल्ड टास्क दोनों को इसे शुरू करने से रोकना है, लेकिन ख़ुद टाइप करने पर इसे उपलब्ध रखना है, तो ~/.claude/settings.json जैसी सेटिंग फ़ाइल में यह जोड़ें:

{
  "skillOverrides": {
    "code-review": "user-invocable-only"
  }
}

बैकग्राउंड समीक्षाएँ सबएजेंट के रूप में चलती हैं। सबएजेंट कॉन्टेक्स्ट और मॉडल को कैसे संभालते हैं, यह सबएजेंट और एजेंट टीम वाले हमारे लेख में समझाया गया है।

8. कब क्या इस्तेमाल करें

आधिकारिक दस्तावेज़ की तुलना तालिका के अनुसार लोकल /code-review काम करते-करते जल्दी फ़ीडबैक पाने के लिए सबसे अच्छा है, और ultra बड़े बदलावों को merge करने से पहले भरोसा पाने के लिए। रोज़ के काम पर लागू करें तो तस्वीर कुछ ऐसी बनती है:

ultra के 3 मुफ़्त रन दोबारा नहीं भरते, इसलिए उन्हें छोटे सुधारों के बजाय दूर तक असर डालने वाले बदलावों, या उन बदलावों के लिए बचाकर रखना फ़ायदेमंद है जिनमें लोकल समीक्षा से बात तय नहीं हुई। इसी तरह, सुरक्षा कमज़ोरियों पर ध्यान देना हो तो /security-review, और बग खोजने के बजाय पठनीयता सुधारनी हो तो /simplify इस्तेमाल करें; दस्तावेज़ भी इन्हें मक़सद के हिसाब से ऐसे ही बाँटता है।

9. इस साइट के कोड पर आज़माकर देखा

2 अक्टूबर 2026 को मैंने इस साइट पर प्रकाशित AI इमेज डिटेक्टर टूल के कोड पर /code-review high चलाया। यह टूल किसी इमेज का मेटाडेटा और उत्पत्ति का रिकॉर्ड (C2PA) पूरी तरह ब्राउज़र के अंदर पढ़ता है, और लक्ष्य चार फ़ाइलें थीं: UI का लॉजिक, पार्सिंग का लॉजिक (एक Web Worker), कंट्रोलर और पेज टेम्पलेट। मैंने इसे Claude Code डेस्कटॉप ऐप में चलाया (साथ आया Claude Code 2.1.284, मॉडल Opus 5.5), और वह भी ठीक उसके बाद, जब मैं ख़ुद बग खोजकर पाँच ठीक कर चुका था।

हर नतीजा "कौन-सी फ़ाइल, कौन-सी लाइन" और "कौन-सा इनपुट देने पर क्या होता है" के रूप में आया। मैंने हर एक को उस लाइब्रेरी (exifr) के सोर्स कोड से, जिससे टूल इमेज का मेटाडेटा पढ़ता है, और ख़ुद बनाई टेस्ट इमेजों से मिलाकर जाँचा, फिर जो 9 असली निकले, उन सबको ठीक किया। मुख्य नतीजे:

यानी ख़ुद खोजकर ठीक करने के ठीक बाद भी अलग तरह के 9 बग बचे हुए थे। ख़ास तौर पर धारणाओं वाले नतीजे ("लाइब्रेरी ऐसे बर्ताव करती होगी") लाइब्रेरी का सोर्स पढ़े बिना पकड़ना मुश्किल था। फिर भी, यह एक कोडबेस पर एक बार चलाने का नतीजा है। ज़रूरी नहीं कि यह हर बार इसी दर से असली बग ढूँढे, और मैंने इसकी low, medium या max से तुलना नहीं की, न ही पेड ultra आज़माया।

10. कमियाँ और सावधानियाँ

इस्तेमाल करने और आधिकारिक दस्तावेज़ पढ़ने के बाद, ध्यान रखने लायक़ पाँच बातें:

• यह आपकी सीमा ख़र्च करता है। लोकल समीक्षा भी Claude के सामान्य उपयोग से कटती है, और ऊँचे लेवल ज़्यादा ख़र्च करते हैं। ultra में Pro और Max के 3 मुफ़्त रन ख़त्म होने के बाद (Team और Enterprise को शुरू से ही) हर रन के लगभग $5–25 यूसेज क्रेडिट देने पड़ते हैं।
• नतीजों को आँख मूँदकर न मानें। दस्तावेज़ ख़ुद कहता है कि high और उससे ऊपर कम भरोसे वाले नतीजे भी आ सकते हैं। इस बार 10 में से 9 असली थे, फिर भी हर एक को जाँचने में मेहनत लगती है।
• --fix को /rewind से वापस नहीं लिया जा सकता। बैकग्राउंड में हुए बदलाव git से वापस करने पड़ते हैं, इसलिए इस्तेमाल से पहले कमिट करें।
• यह सिर्फ़ कोड की correctness जाँचता है। यह नहीं देखता कि लेख या सेटिंग की सामग्री तथ्यों से मेल खाती है या नहीं। उदाहरण के लिए, इस साइट पर अक्सर आने वाली समस्या, यानी लेख में आधिकारिक विनिर्देश से अलग बात लिखी होना, इसके दायरे से बाहर है।
• Claude इसे अपने-आप शुरू कर सकता है। अगर यह नहीं चाहिए, तो सेक्शन 7 की सेटिंग इसे सिर्फ़ हाथ से चलाने तक सीमित कर देती है।

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

सारांश

/code-review एक बिल्ट-इन स्किल है जो आपके लोकल diff या PR की समीक्षा करती है, और उसका ध्यान correctness बग पर रहता है। यह बैकग्राउंड में चलती है, इसलिए आपके काम में बाधा नहीं डालती, और इसकी लागत आपके सामान्य उपयोग के भीतर रहती है। low या medium पर सिर्फ़ पक्के नतीजे मिलते हैं; high से max पर दायरा बड़ा होता है लेकिन नतीजे छाँटने पड़ते हैं; और लेवल न लिखें तो पिछली बार टाइप किया गया लेवल दोबारा लगता है।

ठीक करने तक जाने वाला --fix सुविधाजनक है, लेकिन बैकग्राउंड के बदलाव /rewind से वापस नहीं होते, इसलिए पहले कमिट करना सुरक्षित है। गहराई से देखना हो तो ultra क्लाउड में लगभग 5 से 10 मिनट लगाकर सिर्फ़ जाँचे हुए नतीजे लौटाता है; Pro और Max को एक बार के 3 मुफ़्त रन मिलते हैं, उसके बाद हर रन के लगभग $5–25 यूसेज क्रेडिट लगते हैं। मिलते-जुलते नाम वाले GitHub App के Code Review और claude-code-action अलग चीज़ें हैं, चलने की जगह और लागत दोनों में।

इस साइट के कोड पर एक बार चलाने पर, ख़ुद सुधार करने के ठीक बाद भी, इसके 10 में से 9 नतीजे असली बग निकले। हर नतीजे को जाँचना ज़रूर पड़ता है, लेकिन नए कोड या बड़े बदलाव के बाद इसे एक बार चलाना पूरी तरह फ़ायदेमंद है।

FAQ

Q. /review और /code-review में क्या फ़र्क़ है?

A. अब दोनों एक ही हैं। /review, /code-review का alias है और वही लेवल व फ़्लैग लेता है। आधिकारिक दस्तावेज़ के अनुसार v2.1.223 से पहले /review एक अलग, सिर्फ़ पढ़ने वाला कमांड था, जो GitHub PR की एक ही बार में समीक्षा करता था।

Q. /code-review इस्तेमाल करने का अलग से पैसा लगता है?

A. low से max तक नहीं। आधिकारिक दस्तावेज़ की तुलना तालिका में इसकी लागत सामान्य उपयोग में गिनी गई है। अलग से पैसा ultra में लगता है: Pro और Max पर 3 मुफ़्त रन के बाद हर रन के लगभग $5–25 यूसेज क्रेडिट।

Q. क्या ultra के 3 मुफ़्त रन हर महीने रीसेट होते हैं?

A. नहीं। आधिकारिक दस्तावेज़ के अनुसार Pro और Max के तीन रन हर अकाउंट के लिए एक ही बार मिलते हैं और दोबारा नहीं भरते। बीच में रोकी गई या फ़ेल हुई समीक्षा भी एक रन गिनी जाती है। Team और Enterprise को कोई मुफ़्त रन नहीं मिलता।

Q. क्या --fix से हुए बदलाव वापस किए जा सकते हैं?

A. git इस्तेमाल करें। बैकग्राउंड में चली समीक्षा के बदलाव आपके चेकपॉइंट के बाहर होते हैं, इसलिए /rewind उन्हें वापस नहीं करता। अगर समीक्षा फ़ोरग्राउंड में चली थी (पिछली समीक्षा अभी चल रही हो, -p वग़ैरह), तो /rewind उन्हें वापस कर सकता है। शक हो तो --fix से पहले कमिट कर लें।

Q. क्या REVIEW.md के नियम /code-review पर लागू होते हैं?

A. नहीं। लोकल /code-review CLAUDE.md का पालन करता है, लेकिन REVIEW.md नहीं पढ़ता। REVIEW.md, Code Review के GitHub App वाले संस्करण की निर्देश-फ़ाइल है। जो नियम लोकल समीक्षा से मनवाने हैं, उन्हें CLAUDE.md में लिखें।

स्रोत

• Claude Code आधिकारिक दस्तावेज़: Code Review ("Review a diff locally" सेक्शन सहित)
• Claude Code आधिकारिक दस्तावेज़: Find bugs with ultrareview
• Claude Code आधिकारिक दस्तावेज़: Commands
• Claude Code आधिकारिक दस्तावेज़: Claude Code GitHub Actions
• Claude Code: CHANGELOG

सभी स्रोत 2 अक्टूबर 2026 को मूल पाठ से मिलाकर जाँचे गए। आधिकारिक दस्तावेज़ के अनुसार ultrareview एक रिसर्च प्रीव्यू है, और इसके फ़ीचर, क़ीमत और उपलब्धता बदल सकते हैं।