Code Review

Code Review، pull requestهای GitHub تو را تحلیل می‌کند و یافته‌ها را به‌صورت کامنت‌های inline روی همان خطوطِ کدی که مشکل را یافته منتشر می‌کند. ناوگانی از ایجنت‌های تخصصی تغییراتِ کد را در کانتکستِ کلِ کدبیست بررسی می‌کنند و دنبالِ خطاهای منطقی، آسیب‌پذیری‌های امنیتی، edge caseهای خراب و رگرسیون‌های نامحسوس می‌گردند.

یافته‌ها برچسبِ شدت می‌خورند و PRت را تأیید یا مسدود نمی‌کنند، پس ورک‌فلوهای بازبینیِ موجودت دست‌نخورده می‌مانند. می‌توانی با افزودنِ یک فایلِ CLAUDE.md یا REVIEW.md به مخزنت تنظیم کنی که Claude چه چیزی را علامت بزند.

برای اجرای Claude در زیرساختِ CIِ خودت به‌جای این سرویسِ مدیریت‌شده، GitHub Actions یا GitLab CI/CD را ببین. برای مخزن‌های روی یک نمونه‌ی self-hostedِ GitHub، GitHub Enterprise Server را ببین.

این صفحه این‌ها را پوشش می‌دهد:

بازبینی‌ها چطور کار می‌کنند
راه‌اندازی
تریگرِ دستیِ بازبینی‌ها با @claude review و @claude review once
سفارشی‌سازیِ بازبینی‌ها با CLAUDE.md و REVIEW.md
هزینه
عیب‌یابیِ اجراهای ناموفق و کامنت‌های گم‌شده
بازبینیِ یک diff به‌صورتِ محلی با دستورِ /code-review

بازبینی‌ها چطور کار می‌کنند

وقتی یک ادمین Code Review را فعال کرد برای سازمانت، بازبینی‌ها هنگامِ بازشدنِ یک PR، در هر push، یا هنگامِ درخواستِ دستی تریگر می‌شوند، بسته به رفتارِ پیکربندی‌شده‌ی مخزن. کامنت‌گذاریِ @claude review در هر حالت بازبینی را روی یک PR شروع می‌کند.

وقتی یک بازبینی اجرا می‌شود، چند ایجنت به‌موازات روی زیرساختِ Anthropic، diff و کدِ پیرامون را تحلیل می‌کنند. هر ایجنت دنبالِ کلاسِ متفاوتی از مشکل می‌گردد، بعد یک گامِ راستی‌آزمایی نامزدها را در برابرِ رفتارِ واقعیِ کد بررسی می‌کند تا false positiveها فیلتر شوند. نتایج deduplicate می‌شوند، بر اساسِ شدت رتبه‌بندی می‌شوند و به‌صورت کامنت‌های inline روی همان خطوطی که مشکل یافته شد منتشر می‌شوند، همراهِ خلاصه‌ای در بدنه‌ی بازبینی. اگر هیچ مشکلی یافته نشود، Code Review، check runِ GitHub را به‌روز می‌کند تا نشان دهد هیچ مشکلی شناسایی نشد. Claude همچنین ممکن است یک کامنتِ تأییدِ کوتاه روی PR منتشر کند.

بازبینی‌ها از نظرِ هزینه با اندازه و پیچیدگیِ PR مقیاس می‌گیرند و به‌طورِ میانگین در ۲۰ دقیقه تمام می‌شوند. ادمین‌ها می‌توانند فعالیت و خرجِ بازبینی را از طریقِ داشبوردِ analytics مانیتور کنند.

سطوحِ شدت

هر یافته با یک سطحِ شدت برچسب می‌خورد:

نشانگر	شدت	معنا
🔴	Important	باگی که باید پیش از merge اصلاح شود
🟡	Nit	یک مشکلِ جزئی، ارزشِ اصلاح دارد ولی مسدودکننده نیست
🟣	Pre-existing	باگی که در کدبیس وجود دارد ولی این PR آن را معرفی نکرده است

یافته‌ها شاملِ یک بخشِ استدلالِ گسترده‌ی قابلِ‌جمع‌شدن هستند که می‌توانی بازش کنی تا بفهمی چرا Claude مشکل را علامت زده و چطور آن را راستی‌آزمایی کرده است.

امتیازدهی و پاسخ به یافته‌ها

هر کامنتِ بازبینی از Claude با 👍 و 👎 ازپیش‌چسبیده می‌رسد، تا هر دو دکمه برای امتیازدهیِ یک‌کلیکی در UIِ GitHub ظاهر شوند. اگر یافته مفید بود 👍 بزن و اگر اشتباه یا پرسروصدا بود 👎. Anthropic شمارشِ واکنش‌ها را پس از merge شدنِ PR جمع می‌کند و از آن برای تنظیمِ بازبین استفاده می‌کند. واکنش‌ها بازبینیِ دوباره را تریگر نمی‌کنند و چیزی روی PR تغییر نمی‌دهند.

پاسخ‌دادن به یک کامنتِ inline، Claude را به پاسخ یا به‌روزرسانیِ PR وادار نمی‌کند. برای اقدام روی یک یافته، کد را اصلاح و push کن. اگر PR مشترکِ بازبینی‌های push-triggered باشد، اجرای بعدی وقتی مشکل اصلاح شد رشته را حل می‌کند. برای درخواستِ یک بازبینیِ تازه بدونِ push، @claude review once را به‌عنوان یک کامنتِ سطح‌بالای PR بنویس.

خروجیِ check run

فراتر از کامنت‌های بازبینیِ inline، هر بازبینی check runِ Claude Code Review را پر می‌کند که کنارِ CI checkهایت ظاهر می‌شود. لینکِ Details آن را باز کن تا خلاصه‌ی همه‌ی یافته‌ها را یک‌جا و مرتب‌شده بر اساسِ شدت ببینی:

شدت	فایل:خط	مشکل
🔴 Important	`src/auth/session.ts:142`	تازه‌سازیِ توکن با logout race می‌کند و نشست‌های کهنه را فعال نگه می‌دارد
🟡 Nit	`src/auth/session.ts:88`	`parseExpiry` روی ورودیِ خراب بی‌صدا ۰ برمی‌گرداند

هر یافته همچنین به‌صورت یک annotation در تبِ Files changed ظاهر می‌شود، مستقیماً روی خطوطِ مربوطه‌ی diff علامت‌گذاری‌شده. یافته‌های Important با نشانگرِ قرمز رندر می‌شوند، nitها با هشدارِ زرد، و باگ‌های pre-existing با اطلاعیه‌ی خاکستری. annotationها و جدولِ شدت مستقل از کامنت‌های بازبینیِ inline در check run نوشته می‌شوند، پس حتی اگر GitHub یک کامنتِ inline را روی خطی که جابه‌جا شده رد کند، آن‌ها همچنان در دسترس می‌مانند.

check run همیشه با یک نتیجه‌گیریِ neutral تمام می‌شود، پس هیچ‌وقت merge را از طریقِ قواعدِ branch protection مسدود نمی‌کند. اگر می‌خواهی merge را بر اساسِ یافته‌های Code Review مشروط کنی، تفکیکِ شدت را از خروجیِ check run در CIِ خودت بخوان. آخرین خطِ متنِ Details یک کامنتِ ماشین‌خوان است که ورک‌فلوت می‌تواند با gh و jq آن را تجزیه کند:

gh api repos/OWNER/REPO/check-runs/CHECK_RUN_ID \
  --jq '.output.text | split("bughunter-severity: ")[1] | split(" -->")[0] | fromjson'

این یک شیءِ JSON با شمارشِ هر شدت برمی‌گرداند، مثلاً {"normal": 2, "nit": 1, "pre_existing": 0}. کلیدِ normal شمارشِ یافته‌های Important را نگه می‌دارد؛ مقدارِ ناصفر یعنی Claude دستِ‌کم یک باگِ ارزشِ‌اصلاح‌داشته پیش از merge یافته است.

Code Review چه چیزی را بررسی می‌کند

به‌صورتِ پیش‌فرض، Code Review روی درستی تمرکز می‌کند: باگ‌هایی که production را می‌شکنند، نه ترجیحاتِ قالب‌بندی یا پوششِ تستِ مفقود. می‌توانی آنچه را بررسی می‌کند با افزودنِ فایل‌های راهنما به مخزنت گسترش بدهی.

راه‌اندازیِ Code Review

یک ادمین Code Review را یک‌بار برای سازمان فعال می‌کند و انتخاب می‌کند کدام مخزن‌ها گنجانده شوند.

بازکردنِ تنظیماتِ ادمینِ Claude Code

به claude.ai/admin-settings/claude-code برو و بخشِ Code Review را پیدا کن. به دسترسیِ ادمین در سازمانِ Claude‌ات و مجوزِ نصبِ GitHub App در سازمانِ GitHub‌ات نیاز داری.

شروعِ راه‌اندازی

روی Setup کلیک کن. این جریانِ نصبِ GitHub App را آغاز می‌کند.

نصبِ Claude GitHub App

پرامپت‌ها را دنبال کن تا Claude GitHub App را روی سازمانِ GitHub‌ات نصب کنی. اپ این دسترسی‌های مخزنی را درخواست می‌کند:

Contents: خواندن و نوشتن
Issues: خواندن و نوشتن
Pull requests: خواندن و نوشتن

Code Review از دسترسیِ خواندن به contents و دسترسیِ نوشتن به pull requests استفاده می‌کند. مجموعه‌ی گسترده‌ترِ دسترسی‌ها اگر بعداً GitHub Actions را فعال کنی از آن هم پشتیبانی می‌کند.

انتخابِ مخزن‌ها

انتخاب کن کدام مخزن‌ها برای Code Review فعال شوند. اگر مخزنی را نمی‌بینی، مطمئن شو که هنگامِ نصب به Claude GitHub App دسترسی‌اش را داده‌ای. بعداً می‌توانی مخزن‌های بیشتری اضافه کنی.

تنظیمِ تریگرهای بازبینی برای هر مخزن

پس از تکمیلِ راه‌اندازی، بخشِ Code Review مخزن‌هایت را در یک جدول نشان می‌دهد. برای هر مخزن، از منوی کشوییِ Review Behavior استفاده کن تا انتخاب کنی بازبینی‌ها کِی اجرا شوند:

Once after PR creation: بازبینی یک‌بار اجرا می‌شود وقتی یک PR باز یا برای بازبینی آماده علامت می‌خورد
After every push: بازبینی در هر push به شاخه‌ی PR اجرا می‌شود، مشکل‌های تازه را با تکاملِ PR می‌گیرد و وقتی مشکل‌های علامت‌خورده را اصلاح می‌کنی رشته‌ها را خودکار حل می‌کند
Manual: بازبینی‌ها فقط وقتی شروع می‌شوند که کسی @claude review یا @claude review once روی یک PR بنویسد؛ @claude review همچنین PR را مشترکِ بازبینی‌های push‌های بعدی می‌کند

بازبینی در هر push بیشترین تعدادِ بازبینی را اجرا می‌کند و بیشترین هزینه را دارد. حالتِ Manual برای مخزن‌های پرترافیک مفید است که می‌خواهی PRهای مشخصی را opt-in کنی، یا برای اینکه فقط وقتی PRهایت آماده شدند بازبینی‌شان را شروع کنی.

جدولِ مخزن‌ها همچنین میانگینِ هزینه‌ی هر بازبینی را برای هر مخزن بر اساسِ فعالیتِ اخیر نشان می‌دهد. از منوی اکشن‌های ردیف استفاده کن تا Code Review را برای هر مخزن روشن یا خاموش کنی، یا یک مخزن را کاملاً حذف کنی.

برای راستی‌آزماییِ راه‌اندازی، یک PRِ آزمایشی باز کن. اگر یک تریگرِ خودکار انتخاب کردی، یک check run به نامِ Claude Code Review ظرفِ چند دقیقه ظاهر می‌شود. اگر Manual را انتخاب کردی، روی PR @claude review بنویس تا اولین بازبینی شروع شود. اگر هیچ check runی ظاهر نشد، تأیید کن که مخزن در تنظیماتِ ادمینت فهرست شده و Claude GitHub App به آن دسترسی دارد.

تریگرِ دستیِ بازبینی‌ها

دو دستورِ کامنتی یک بازبینی را به‌خواست شروع می‌کنند. هر دو فارغ از تریگرِ پیکربندی‌شده‌ی مخزن کار می‌کنند، پس می‌توانی از آن‌ها برای opt-in کردنِ PRهای مشخص در حالتِ Manual یا برای گرفتنِ یک بازبینیِ دوباره‌ی فوری در حالت‌های دیگر استفاده کنی.

دستور	چه می‌کند
`@claude review`	یک بازبینی شروع می‌کند و PR را برای بازبینی‌های push-triggered از این پس مشترک می‌کند
`@claude review once`	یک بازبینیِ تک شروع می‌کند بدونِ مشترک‌کردنِ PR در push‌های آینده

@claude review once را وقتی استفاده کن که بازخوردی روی وضعیتِ فعلیِ یک PR می‌خواهی ولی نمی‌خواهی هر push بعدی یک بازبینی به‌بار آورد. این برای PRهای طولانی‌مدت با push‌های مکرر مفید است، یا وقتی یک نظرِ دومِ یک‌باره می‌خواهی بدونِ تغییرِ رفتارِ بازبینیِ PR.

برای اینکه هر کدام از این دستورها یک بازبینی را تریگر کند:

آن را به‌صورت یک کامنتِ سطح‌بالای PR بنویس، نه یک کامنتِ inline روی یک خطِ diff
دستور را در ابتدای کامنت بگذار، با once روی همان خط اگر از شکلِ یک‌باره استفاده می‌کنی
باید دسترسیِ owner، member یا collaborator به مخزن داشته باشی
PR باید باز باشد

برخلافِ تریگرهای خودکار، تریگرهای دستی روی PRهای draft هم اجرا می‌شوند، چون یک درخواستِ صریح نشان می‌دهد که بازبینی را همین حالا می‌خواهی، فارغ از وضعیتِ draft.

اگر یک بازبینی همین حالا روی آن PR در حالِ اجراست، درخواست تا تکمیلِ بازبینیِ در‌جریان صف می‌شود. می‌توانی پیشرفت را از طریقِ check run روی PR مانیتور کنی.

سفارشی‌سازیِ بازبینی‌ها

Code Review دو فایل را از مخزنت می‌خواند تا هدایت کند چه چیزی را علامت بزند. این دو در شدتِ تأثیرشان بر بازبینی فرق دارند:

CLAUDE.md: دستورالعمل‌های مشترکِ پروژه که Claude Code برای همه‌ی کارها استفاده می‌کند، نه فقط بازبینی‌ها. Code Review آن را به‌عنوان کانتکستِ پروژه می‌خواند و نقض‌های تازه‌معرفی‌شده را به‌عنوان nit علامت می‌زند.
REVIEW.md: دستورالعمل‌های فقط‌بازبینی، که مستقیماً به هر ایجنت در پایپ‌لاینِ بازبینی به‌عنوان بالاترین اولویت تزریق می‌شوند. از آن استفاده کن تا تغییر دهی چه چیزی، در چه شدتی علامت بخورد و یافته‌ها چطور گزارش شوند.

CLAUDE.md

Code Review فایل‌های CLAUDE.mdِ مخزنت را می‌خواند و نقض‌های تازه‌معرفی‌شده را به‌عنوان یافته‌های در سطحِ nit تلقی می‌کند. این دوسویه کار می‌کند: اگر PRت کد را طوری تغییر دهد که یک عبارتِ CLAUDE.md منسوخ شود، Claude علامت می‌زند که اسناد هم باید به‌روز شوند.

Claude فایل‌های CLAUDE.md را در هر سطحِ سلسله‌مراتبِ دایرکتوری‌ات می‌خواند، پس قواعدِ یک CLAUDE.md در زیردایرکتوری فقط بر فایل‌های زیرِ آن مسیر اعمال می‌شوند. برای جزئیاتِ بیشتر درباره‌ی نحوه‌ی کارِ CLAUDE.md، مستنداتِ حافظه را ببین.

برای راهنماییِ مختصِ بازبینی که نمی‌خواهی بر نشست‌های عمومیِ Claude Code اعمال شود، به‌جایش از REVIEW.md استفاده کن.

REVIEW.md

REVIEW.md فایلی در ریشه‌ی مخزنت است که نحوه‌ی رفتارِ Code Review روی مخزنت را override می‌کند. محتوایش به‌عنوان بالاترین‌اولویتْ بلاکِ دستورالعمل به system promptِ هر ایجنت در پایپ‌لاینِ بازبینی تزریق می‌شود و بر راهنماییِ پیش‌فرضِ بازبینی مقدم می‌شود.

چون عیناً paste می‌شود، REVIEW.md دستورالعملِ ساده است: نحوِ ایمپورتِ @ بسط داده نمی‌شود و فایل‌های ارجاع‌شده به prompt خوانده نمی‌شوند. قواعدی را که می‌خواهی اعمال شوند مستقیماً در فایل بگذار.

چه چیزهایی را می‌توانی تنظیم کنی

REVIEW.md مارک‌داونِ آزاد است، پس هر چیزی که بتوانی به‌صورت یک دستورِ بازبینی بیان کنی در محدوده است. الگوهای زیر در عمل بیشترین اثر را دارند.

شدت: بازتعریف کن که 🔴 Important برای مخزنت چه معنایی دارد. کالیبراسیونِ پیش‌فرض کدِ production را هدف می‌گیرد؛ یک مخزنِ اسناد، یک مخزنِ پیکربندی یا یک نمونه‌ی اولیه ممکن است تعریفِ بسیار باریک‌تری بخواهد. صراحتاً بگو کدام کلاس‌های یافته Important‌اند و کدام حداکثر Nit. می‌توانی در جهتِ دیگر هم تشدید کنی، مثلاً هر نقضِ CLAUDE.md را به‌جای nitِ پیش‌فرض، Important تلقی کنی.

حجمِ nit: سقف بگذار که یک بازبینیِ واحد چند کامنتِ 🟡 Nit منتشر کند. فایل‌های نثر و پیکربندی را تا ابد می‌توان صیقل داد. سقفی مثلِ “حداکثر پنج nit گزارش کن، بقیه را به‌صورت یک شمارش در خلاصه بیاور” بازبینی‌ها را قابلِ‌اقدام نگه می‌دارد.

قواعدِ skip: مسیرها، الگوهای شاخه و دسته‌های یافته را فهرست کن که Claude نباید هیچ یافته‌ای منتشر کند. نامزدهای رایج کدِ تولیدشده، lockfileها، وابستگی‌های vendor‌شده و شاخه‌های ماشین‌نوشت هستند، همراه با هر چیزی که CIت از قبل اعمال می‌کند مثلِ linting یا spellcheck. برای مسیرهایی که کمی بازبینی می‌خواهند ولی نه دقتِ کامل، به‌جای skipِ کامل یک سطحِ بالاتر تعیین کن: “در scripts/، فقط اگر تقریباً قطعی و شدید بود گزارش کن.”

بررسی‌های مختصِ مخزن: قواعدی اضافه کن که می‌خواهی روی هر PR علامت بخورند، مثلِ “روت‌های API تازه باید تستِ یکپارچگی داشته باشند.” چون REVIEW.md به‌عنوان بالاترین اولویت تزریق می‌شود، این‌ها مطمئن‌تر از همان قواعد در یک CLAUDE.mdِ طولانی فرود می‌آیند.

سطحِ راستی‌آزمایی: پیش از انتشارِ یک کلاسِ یافته، شواهد بخواه. مثلاً “ادعاهای رفتاری به یک ارجاعِ file:line در سورس نیاز دارند، نه استنباط از نام‌گذاری” false positiveهایی را که وگرنه به نویسنده یک رفت‌وبرگشت تحمیل می‌کردند کم می‌کند.

هم‌گراییِ بازبینیِ دوباره: به Claude بگو وقتی یک PR قبلاً بازبینی شده چطور رفتار کند. قاعده‌ای مثلِ “پس از اولین بازبینی، nitهای تازه را سرکوب کن و فقط یافته‌های Important منتشر کن” جلوی رسیدنِ یک اصلاحِ یک‌خطی به دورِ هفتم را صرفاً به‌خاطرِ سبک می‌گیرد.

شکلِ خلاصه: بخواه بدنه‌ی بازبینی با یک شمارشِ یک‌خطی مثلِ 2 factual, 4 style شروع شود، و وقتی این‌طور است با “no factual issues” پیش‌قدم شود. نویسنده می‌خواهد پیش از جزئیات شکلِ کار را بداند.

مثال

این REVIEW.md شدت را برای یک سرویسِ backend بازکالیبره می‌کند، nitها را سقف می‌گذارد، فایل‌های تولیدشده را skip می‌کند و بررسی‌های مختصِ مخزن اضافه می‌کند.

# Review instructions

## What Important means here

Reserve Important for findings that would break behavior, leak data,
or block a rollback: incorrect logic, unscoped database queries, PII
in logs or error messages, and migrations that aren't backward
compatible. Style, naming, and refactoring suggestions are Nit at
most.

## Cap the nits

Report at most five Nits per review. If you found more, say "plus N
similar items" in the summary instead of posting them inline. If
everything you found is a Nit, lead the summary with "No blocking
issues."

## Do not report

- Anything CI already enforces: lint, formatting, type errors
- Generated files under `src/gen/` and any `*.lock` file
- Test-only code that intentionally violates production rules

## Always check

- New API routes have an integration test
- Log lines don't include email addresses, user IDs, or request bodies
- Database queries are scoped to the caller's tenant

متمرکزش نگه دار

طول هزینه دارد: یک REVIEW.mdِ طولانی قواعدی را که بیشترین اهمیت را دارند رقیق می‌کند. آن را به دستورالعمل‌هایی که رفتارِ بازبینی را تغییر می‌دهند محدود کن، و کانتکستِ عمومیِ پروژه را در CLAUDE.md بگذار.

مشاهده‌ی استفاده

به claude.ai/analytics/code-review برو تا فعالیتِ Code Review را در سراسرِ سازمانت ببینی. داشبورد این‌ها را نشان می‌دهد:

بخش	چه نشان می‌دهد
PRs reviewed	شمارشِ روزانه‌ی pull requestهای بازبینی‌شده در بازه‌ی زمانیِ انتخاب‌شده
Cost weekly	خرجِ هفتگیِ Code Review
Feedback	شمارشِ کامنت‌های بازبینی که چون یک توسعه‌دهنده مشکل را برطرف کرد خودکار حل شدند
Repository breakdown	شمارشِ هر مخزن از PRهای بازبینی‌شده و کامنت‌های حل‌شده

جدولِ مخزن‌ها در تنظیماتِ ادمین هم میانگینِ هزینه‌ی هر بازبینی را برای هر مخزن نشان می‌دهد. ارقامِ هزینه‌ی داشبورد برآوردهایی برای مانیتورِ فعالیت‌اند؛ برای خرجِ دقیقِ صورتحساب، به صورتحسابِ Anthropic‌ات رجوع کن.

هزینه

Code Review بر اساسِ مصرفِ توکن صورتحساب می‌شود. هر بازبینی به‌طورِ میانگین ۱۵ تا ۲۵ دلار هزینه دارد، که با اندازه‌ی PR، پیچیدگیِ کدبیس و تعدادِ مشکل‌هایی که راستی‌آزمایی لازم دارند مقیاس می‌گیرد. استفاده‌ی Code Review جداگانه از طریقِ usage credits صورتحساب می‌شود و به استفاده‌ی گنجانده‌شده در پلنت حساب نمی‌شود.

تریگرِ بازبینی که انتخاب می‌کنی بر هزینه‌ی کل اثر می‌گذارد:

Once after PR creation: یک‌بار به‌ازای هر PR اجرا می‌شود
After every push: در هر push اجرا می‌شود و هزینه را در تعدادِ push‌ها ضرب می‌کند
Manual: هیچ بازبینی‌ای تا وقتی کسی روی یک PR @claude review بنویسد

در هر حالت، کامنت‌گذاریِ @claude review ‏PR را به بازبینی‌های push-triggered opt-in می‌کند، پس پس از آن کامنت در هر push هزینه‌ی اضافی انباشته می‌شود. برای اجرای یک بازبینیِ تک بدونِ مشترک‌شدن در push‌های آینده، به‌جایش @claude review once بنویس.

هزینه‌ها روی صورتحسابِ Anthropic‌ات ظاهر می‌شوند، فارغ از اینکه سازمانت برای دیگر قابلیت‌های Claude Code از Amazon Bedrock یا Google Vertex AI استفاده می‌کند یا نه. برای تعیینِ سقفِ خرجِ ماهانه برای Code Review، به claude.ai/admin-settings/usage برو و محدودیت را برای سرویسِ Claude Code Review پیکربندی کن.

خرج را از طریقِ نمودارِ هزینه‌ی هفتگی در analytics یا ستونِ میانگینِ هزینه‌ی هر مخزن در تنظیماتِ ادمین مانیتور کن.

عیب‌یابی

اجراهای بازبینی best-effort هستند. یک اجرای ناموفق هیچ‌وقت PRت را مسدود نمی‌کند، ولی خودبه‌خود هم دوباره تلاش نمی‌کند. این بخش پوشش می‌دهد که چطور از یک اجرای ناموفق بازیابی کنی و کجا را بگردی وقتی check run مشکل‌هایی را گزارش می‌کند که نمی‌توانی پیدایشان کنی.

تریگرِ دوباره‌ی یک بازبینیِ ناموفق یا منقضی

وقتی زیرساختِ بازبینی به یک خطای داخلی برمی‌خورد یا از محدودیتِ زمانش می‌گذرد، check run با عنوانِ Code review encountered an error یا Code review timed out تمام می‌شود. نتیجه‌گیری همچنان neutral است، پس چیزی merge‌ات را مسدود نمی‌کند، ولی هیچ یافته‌ای منتشر نمی‌شود.

برای اجرای دوباره‌ی بازبینی، روی PR @claude review once بنویس. این یک بازبینیِ تازه شروع می‌کند بدونِ مشترک‌کردنِ PR در push‌های آینده. اگر PR از قبل مشترکِ بازبینی‌های push-triggered باشد، push کردنِ یک کامیتِ تازه هم یک بازبینیِ تازه شروع می‌کند.

دکمه‌ی Re-run در تبِ Checksِ GitHub، Code Review را دوباره تریگر نمی‌کند. به‌جایش از دستورِ کامنتی یا یک push تازه استفاده کن.

بازبینی اجرا نشد و PR یک پیامِ سقفِ‌خرج نشان می‌دهد

وقتی سقفِ خرجِ ماهانه‌ی سازمانت پر شود، Code Review یک کامنتِ واحد روی PR منتشر می‌کند که توضیح می‌دهد بازبینی رد شد. بازبینی‌ها خودکار در آغازِ دوره‌ی صورتحسابِ بعدی از سر گرفته می‌شوند، یا فوراً وقتی یک ادمین سقف را در claude.ai/admin-settings/usage بالا ببرد.

یافتنِ مشکل‌هایی که به‌صورتِ کامنتِ inline نشان داده نمی‌شوند

اگر عنوانِ check run می‌گوید مشکل‌هایی یافته شد ولی کامنت‌های بازبینیِ inline را روی diff نمی‌بینی، در این مکان‌های دیگر که یافته‌ها نمایان می‌شوند بگرد:

Check run Details: روی Details کنارِ check runِ Claude Code Review در تبِ Checks کلیک کن. جدولِ شدت هر یافته را با فایل، خط و خلاصه‌اش فهرست می‌کند، فارغ از اینکه کامنتِ inline پذیرفته شده باشد یا نه.
Files changed annotations: تبِ Files changed روی PR را باز کن. یافته‌ها به‌صورت annotationهای متصل مستقیم به خطوطِ diff رندر می‌شوند، جدا از کامنت‌های بازبینی.
Review body: اگر هنگامی که یک بازبینی در حالِ اجرا بود به PR push کردی، برخی یافته‌ها ممکن است به خطوطی ارجاع دهند که دیگر در diffِ فعلی وجود ندارند. آن‌ها زیرِ عنوانِ Additional findings در متنِ بدنه‌ی بازبینی ظاهر می‌شوند نه به‌صورتِ کامنت‌های inline.

بازبینیِ یک diff به‌صورتِ محلی

دستورِ /code-review یک diff را در ترمینالت بدونِ نصبِ GitHub App بازبینی می‌کند. آن را در هر نشستِ Claude Code اجرا کن: باگ‌های درستی و {/* min-version: 2.1.151 */}پاکسازی‌های مربوط به بازاستفاده، ساده‌سازی و کارایی را گزارش می‌دهد. به‌صورتِ پیش‌فرض، بازبینیِ محلی کامیت‌های شاخه‌ات را که جلوتر از upstream‌اش هستند به‌علاوه‌ی هر تغییرِ کامیت‌نشده در working tree پوشش می‌دهد. --comment را پاس بده تا یافته‌ها به‌صورتِ کامنت‌های inlineِ PR منتشر شوند، یا --fix تا یافته‌ها پس از بازبینی روی working tree‌ات اعمال شوند.

سطوحِ تلاشِ پایین‌تر یافته‌های کمتر و با اطمینانِ بالاتر برمی‌گردانند، در حالی که high تا max پوششِ گسترده‌تر می‌دهند و ممکن است یافته‌های نامطمئن را هم شامل شوند. بدونِ آرگومانِ تلاش، بازبینی از تلاشِ فعلیِ نشست استفاده می‌کند. برای بازبینیِ چیزی غیر از diffِ پیش‌فرض، یک هدف پاس بده: یک مسیرِ فایل، یک شماره‌ی PR، یک نامِ شاخه، یا یک بازه‌ی ref مثلِ main...my-feature. شکلِ بازه‌ی ref همان diffِ کامیت‌شده‌ای را بازبینی می‌کند که یک pull request از my-feature به main دربر می‌گرفت، فارغ از اینکه upstreamِ شاخه چطور پیکربندی شده.

/code-review ultra --fix نسخه‌ی عمیق‌ترِ ultrareview را در ابر اجرا می‌کند، بعد یافته‌هایش را وقتی به نشستت برمی‌گردند روی working tree‌ات اعمال می‌کند. ultrareview محدوده‌ی خودش را دارد: شاخه‌ی فعلی‌ات در برابرِ شاخه‌ی پیش‌فرضِ مخزن، به‌علاوه‌ی هر تغییرِ کامیت‌نشده و staged در working tree.

این دستور پیش از نسخه‌ی v2.1.147 /simplify نام داشت، وقتی به‌صورتِ پیش‌فرض اصلاحات را اعمال می‌کرد. {/* min-version: 2.1.154 */}از نسخه‌ی v2.1.154، /simplify یک بازبینیِ جداگانه‌ی فقط‌پاکسازی اجرا می‌کند که اصلاحات را بدونِ شکارِ باگ اعمال می‌کند. اگر /simplify را برای باگ‌یابی اسکریپت کرده‌ای، به /code-review --fix سوییچ کن که بدونِ تغییر مانده است.

منابعِ مرتبط

Code Review طوری طراحی شده که کنارِ بقیه‌ی Claude Code کار کند. اگر می‌خواهی پیش از بازکردنِ یک PR بازبینی‌ها را محلی اجرا کنی، به یک راه‌اندازیِ self-hosted نیاز داری، یا می‌خواهی عمیق‌تر بفهمی CLAUDE.md چطور رفتارِ Claude را در سراسرِ ابزارها شکل می‌دهد، این صفحه‌ها ایستگاه‌های خوبِ بعدی‌اند:

Commands: /code-review را در یک نشستِ محلیِ Claude Code اجرا کن تا پیش از push یک diff را بررسی کنی
GitHub Actions: Claude را در ورک‌فلوهای GitHub Actionsِ خودت اجرا کن برای خودکارسازیِ سفارشی فراتر از code review
GitLab CI/CD: یکپارچگیِ self-hostedِ Claude برای پایپ‌لاین‌های GitLab
Memory: اینکه فایل‌های CLAUDE.md در سراسرِ Claude Code چطور کار می‌کنند
Analytics: ردگیریِ استفاده‌ی Claude Code فراتر از code review