ما الأمر ‎/code-review في Claude Code؟ طريقة استخدامه، واختيار المستوى، وتسعير ultra، والعيوب، ونتائج تجربته فعليًّا

الأمر /code-review في Claude Code هو أمر يقرأ الفروق (diff) الموجودة لديك الآن (التغييرات غير المُودَعة والإيداعات التي تسبق upstream)، ويبحث فيها عن أخطاء الصحّة البرمجية، ثم يبلّغك بها. وهو مهارة مضمَّنة (bundled skill) تأتي مع Claude Code، فتستطيع تشغيله من الطرفية مباشرةً دون تثبيت أي تطبيق على GitHub. وكتابة /review تشغّل الشيء نفسه.

يعتمد هذا المقال على النصّ الأصلي للوثائق الرسمية لـ Claude Code (قسم Review a diff locally في صفحة Code Review، وصفحة Find bugs with ultrareview، وصفحة Commands) وعلى CHANGELOG، ليشرح ما الذي يفعله، وكيف تختار بين المستويات (من low إلى max) وبين ultra، وكيف تستعمل --fix و--comment. وقد طابقنا كل مواصفة مذكورة هنا مع النصّ الأصلي في 2 أكتوبر 2026. ويتناول القسمان 9 و10 أيضًا ما حدث حين شغّلتُ /code-review high فعلًا على شيفرة هذا الموقع، والعيوب التي لاحظتها في أثناء ذلك.

1. ما الأمر /code-review؟ مهارة مضمَّنة تجد الأخطاء في الفروق

تصفه صفحة Commands المرجعية بأنه أمر يراجع الفروق الحالية، أو رقم PR أو فرعًا أو مسارًا تمرّره إليه، بحثًا عن أخطاء الصحّة البرمجية. وتضيف أن المراجعة تشمل أيضًا فرص التنظيف بحسب النموذج ومستوى الجهد (effort)، بينما تقول صفحة Code Review إنه يبلّغ عن أخطاء الصحّة البرمجية وعن تحسينات تخصّ إعادة الاستخدام والتبسيط والكفاءة. فالبحث عن الأخطاء هو عمله الأساسي، أما اقتراحات التنظيف فتأتي معه بحسب الظروف.

صيغة الأمر كالتالي:

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

وهناك أربع خصائص يحسن أن تعرفها من البداية:

• يعمل في الخلفية. تجري المراجعة في وكيل فرعي (subagent) له نافذة سياق خاصّة به، فلا تملأ محادثتك. وتصل الملاحظات إلى محادثتك حين ينتهي.
• يقرأ CLAUDE.md، لكنه لا يقرأ REVIEW.md. فملف REVIEW.md هو ملف التعليمات لنسخة Code Review العاملة عبر تطبيق GitHub، وسنتناولها أدناه.
• الأمر /review اسم بديل له. وبحسب الوثائق، كان /review قبل الإصدار v2.1.223 أمرًا مستقلًّا يقرأ PR على GitHub في تمريرة واحدة. أما اليوم فهو مطابق لـ /code-review.
• كان اسمه السابق /simplify. فبحسب CHANGELOG، أُعيدت تسمية /simplify إلى /code-review في الإصدار v2.1.147، ثم عاد /simplify لاحقًا أمرًا مستقلًّا يكتفي بالتنظيف ولا يبحث عن الأخطاء.

في الطرفية وفي التشغيل عبر -p، تعود الملاحظات نصًّا ضمن الردّ. أما في التطبيقات التي تطلب قائمة بالملاحظات، مثل تطبيق سطح المكتب، فتُعرض قائمةً يتضمّن كل بند فيها موضع الملف وملخّصًا من جملة واحدة ووسمًا للفئة مثل correctness. وحين يصلحها Claude لاحقًا، يُعلَّم كل بند بأنه أُصلح أو تُخطّي أو لا يحتاج إلى تغيير.

2. الاستخدام الأساسي: اختيار ما تريد مراجعته

أبسط الصيغ أن تكتبه دون أي وسيطات في الجلسة التي تعمل فيها.

# مراجعة الإيداعات التي تسبق upstream + التغييرات غير المُودَعة
/code-review

# المراجعة بمستوى محدّد
/code-review high

# مرّر رقم PR لمراجعة طلب سحب لزميلك
/code-review high 1234

# مرّر نطاقًا بين فرعين
/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 لا تبلّغ إلا عن الملاحظات التي هي أشدّ ثقةً بها، فترى إنذارات كاذبة أقلّ، بينما المستويات من high إلى max توسّع التغطية وقد تتضمّن ملاحظات أقلّ يقينًا.

القاعدة التقريبية هي مقدار الجهد الذي تستطيع بذله في قراءة الملاحظات. فإن أردت فحصًا سريعًا بين مهمّة وأخرى، فاستعمل low أو medium؛ وإن أردت التقاط المزيد قبل الدمج وكان لديك متّسع لاستبعاد الإنذارات الكاذبة بنفسك، فاستعمل high أو ما فوقه. وهذا التقسيم يتبع وصف الوثائق. أما أن المستويات الأعلى تستهلك رموزًا أكثر فهي الفكرة نفسها التي تنطبق على الجهد عمومًا، لكن الوثائق الرسمية لا تذكر أي أرقام عن الوقت أو الاستهلاك لكل مستوى. ونشرح معنى الجهد نفسه في مقالنا عن إعداد الجهد في Claude Code.

إن لم تذكر المستوى، استُعمل «آخر مستوى كتبته»

إن لم تكتب مستوى، تستعمل المراجعة آخر مستوى بين low وmax كتبته بنفسك. ويشمل ذلك مستوى كتبته في جلسة سابقة، وعندها سترى إشعارًا مثل Reusing high effort, the level you typed last time. والتفاصيل:

• يُحدَّث المستوى المحفوظ حين تكتب شيئًا مثل /code-review high في جلسة تفاعلية.
• المستوى الممرَّر في تشغيل غير تفاعلي عبر -p لا يُحفَظ.
• الوضع ultra لا يستعمل المستوى المحفوظ ولا يحدّثه.
• إن لم تكتب مستوى قطّ، يُستعمل الجهد الحالي للجلسة.

وتنبّه الوثائق أيضًا إلى أن /code-review دون مستوى كان قبل الإصدار v2.1.223 يستعمل دائمًا الجهد الحالي للجلسة. فإن أغفلت المستوى متوقّعًا السلوك القديم، فقد يعمل بمستوى أعلى (أو أدنى) ممّا تتوقّع، لذا إن كان الأمر يهمّك، فاكتب المستوى في كل مرّة.

4. استعمال الخيارين --fix و--comment

ما يفعله --fix قد لا يتراجع عنه /rewind

هذا هو الجزء الذي يستحقّ أشدّ الانتباه. فبحسب الوثائق، التعديلات التي يجريها --fix في مراجعة تعمل في الخلفية تقع خارج نقاط الحفظ (checkpoints) في جلستك، فلا يتراجع عنها /rewind. استعمل git لإعادتها بدلًا من ذلك. أما حين تعمل المراجعة في المقدّمة (مراجعة سابقة ما زالت جارية، أو -p، وما شابه)، فهي تعدّل في أثناء دورك أنت، فيستعيدها /rewind كالمعتاد.

# أودِع حالتك الحالية قبل --fix ليسهل الرجوع إليها
git add -A && git commit -m "wip: before code-review --fix"
/code-review medium --fix

# إن لم تعجبك النتيجة، تراجع عنها بـ git
git diff
git restore .

ويمكنك أيضًا تشغيل المراجعة دون --fix، وقراءة النتائج، ثم أن تطلب «أصلح رقم 1 ورقم 3 فقط». وإن لم تكن متأكّدًا من أن كل الملاحظات ينبغي تطبيقها، فهذا الطريق أسلم. ونشرح نقاط الحفظ بالتفصيل في مقالنا عن نقاط الحفظ و/rewind.

أين ينشر --comment

• طلبات السحب على GitHub: ينشر الملاحظات تعليقاتٍ على الأسطر المعنيّة.
• طلبات الدمج على GitLab: ينشرها ملاحظةً واحدة عبر glab، أداة سطر الأوامر الخاصّة بـ GitLab (الإصدار v2.1.257 أو أحدث). وإن لم يكن glab مثبّتًا، تُطبع الملاحظات في الطرفية فقط.

على GitLab، مرّر MR على شكل رابط أو بالصيغة !123. ولا يُعامَل الرقم المجرّد أو اسم الفرع على أنه MR إلا إذا كان origin على gitlab.com؛ أما مع نسخة GitLab مُدارة ذاتيًّا، فتقول الوثائق أن تستعمل الرابط أو !123. ولا تذكر الوثائق الرسمية حتى 2 أكتوبر 2026 ما إذا كان النشر على GitHub يتطلّب مصادقة مثل gh.

5. وضع ultra: مراجعة سحابية متعدّدة الوكلاء وتسعيرها

الأمر /code-review ultra مراجعة معمّقة تشغّل عدّة وكلاء مراجعين بالتوازي داخل بيئة معزولة في سحابة Anthropic، لا على جهازك. وهي معاينة بحثية تُسمّى ultrareview، وفي الحسابات التي تتوفّر فيها يكون /ultrareview اسمًا بديلًا لها. وتذكر الوثائق الرسمية ثلاث مزايا لها مقارنةً بـ /code-review المحلي:

• إشارة أنقى: كل ملاحظة يبلَّغ عنها تُستنسخ وتُتحقَّق منها على نحو مستقلّ، فتركّز النتائج على الأخطاء الحقيقية لا على اقتراحات الأسلوب.
• تغطية أوسع: يستكشف عدد أكبر من الوكلاء التغيير بالتوازي، فتظهر مشكلات قد تفوت المراجعة المحلية.
• لا موارد محلية: يعمل في السحابة، فتستطيع مواصلة أعمال أخرى في طرفيتك في أثناء ذلك.

التسعير والتشغيلات المجانية

يُحتسب ultra من رصيد الاستخدام (الاستخدام الإضافي)، لا من الاستخدام المشمول في خطّتك.

• التشغيلات المجانية: التشغيلات الثلاثة في Pro وMax حصّة لمرّة واحدة لكل حساب، ولا تتجدّد.
• تكلفة التشغيل الواحد: بعد استنفاد التشغيلات المجانية، تكون عادةً من 5 إلى 25 دولارًا من رصيد الاستخدام، بحسب حجم التغيير. ويعرض مربّع حوار الإطلاق تقديرًا قبل كل تشغيل.
• كيف تُحسب التشغيلات: يُحسب التشغيل بمجرّد أن تبدأ الجلسة السحابية. فإيقافه في منتصفه أو فشله يستهلك هو أيضًا تشغيلًا مجانيًّا واحدًا. أما المراجعات المدفوعة فتُحتسب بحسب ما جرى تشغيله فعلًا.
• شرط مسبق: لا تنطلق المراجعات المدفوعة ما لم يكن رصيد الاستخدام مفعّلًا. ويمكنك التحقّق من ذلك بـ /usage-credits. ويظهر تأكيد الاحتساب من رصيد الاستخدام مرّة واحدة في كل محادثة.

أمّا هل مبلغ 5 إلى 25 دولارًا غالٍ أم رخيص فيتوقّف على ما تقارنه به. فمقارنةً بـ /code-review في المستويات من low إلى max، الذي يبقى ضمن حدود خطّتك دون رسوم منفصلة، يمثّل ultra نفقة إضافية. أما مقارنةً بنسخة Code Review العاملة عبر تطبيق GitHub الموصوفة أدناه (بمتوسّط 15 إلى 25 دولارًا لكل مراجعة)، فإن نطاقَي السعر يتداخلان. غير أن Code Review نظام مختلف يعمل تلقائيًّا على كل PR، والرقمان معبَّر عنهما بطريقتين مختلفتين («متوسّط» مقابل «نطاق معتاد»)، فلا تصحّ المقارنة المباشرة بينهما.

المدّة والنطاق وأين لا يتوفّر

• المدّة: من 5 إلى 10 دقائق عادةً. يعمل في الخلفية، ويمكنك متابعته أو إيقافه بـ /tasks. والإيقاف لا يعيد أي نتائج جزئية.
• النطاق: دون وسيطات، يراجع فرعك الحالي مقارنةً بالفرع الافتراضي للمستودع، إضافةً إلى التغييرات غير المُودَعة والمجهَّزة (staged). وهذا أساس مختلف عن «ما يسبق upstream» في /code-review المحلي. ولتغيير الأساس، مرّر اسم فرع كما في /code-review ultra develop.
• مراجعة PR: مرّر رقمًا كما في /code-review ultra 1234، فلا يُرفع شيء من جهازك، بل تستنسخ السحابة PR مباشرةً. ويعمل ذلك مع github.com ومع GitHub Enterprise Server المتّصل.
• الحدود: مراجعة الفرع تغطّي افتراضيًّا ما يصل إلى 500 ملف متغيّر و8,000 سطر متغيّر (وتنصّ الوثائق على أن هذه القيم قابلة للتغيير).
• أين لا يتوفّر: يتطلّب تسجيل الدخول بحساب claude.ai، ولا يتوفّر عبر Amazon Bedrock أو Agent Platform من Google Cloud أو Microsoft Foundry، ولا للمؤسّسات التي تعتمد Zero Data Retention. وحين لا يتوفّر، يعمل /code-review ultra مراجعةً محلية.

مراجعة الفرع تجمع حالة مستودعك المحلي وترفعها إلى السحابة. والتغييرات غير المُودَعة على ملفات تحمل أسماء توحي ببيانات اعتماد، مثل .env و*.tfvars، تخضع للقواعد نفسها المتّبعة في الرفع إلى جلسة سحابية. ونشرح طريقة عمل الجلسات السحابية عمومًا في مقالنا عن الجلسات السحابية.

نشر النتائج على PR (--post) وتشغيله من السكربتات

حين تراجع PR على github.com بوضع ultra، يمكنك نشر النتائج على PR في تعليق واحد من حسابك أنت على GitHub (الإصدار v2.1.227 أو أحدث). وهو تعليق عادي، لا مراجعة ولا موافقة، والافتراضي ألّا يُنشر (--no-post). والأمر /code-review ultra 1234 --post يختار النشر مسبقًا في مربّع حوار الإطلاق، لكنك تحصل على التأكيد قبل البدء مع ذلك. ويبدأ النشر حين تنتهي المراجعة، لذا عليك إبقاء الجلسة مفتوحة حتى تنتهي.

أما في CI أو السكربتات، فاستعمل الأمر الفرعي claude ultrareview. فهو ينتظر النتائج ويكتبها إلى stdout (وتتوفّر معه --json و--timeout (الافتراضي 45 دقيقة) و--post). أما claude -p '/code-review ultra' فيكتفي بإطلاق المراجعة ثم يخرج دون انتظار، فلا تحصل على النتائج، وحين يكون الاحتساب من رصيد الاستخدام مطلوبًا لا ينطلق أصلًا.

# راجِع PR رقم 1234 بوضع ultra من سكربت واحصل على النتائج
claude ultrareview 1234

# استعمل أساسًا غير الفرع الافتراضي
claude ultrareview origin/main

6. الفرق بينه وبين الميزات المشابهة

في Claude Code عدّة ميزات للمراجعة بأسماء متشابهة. ومن السهل خصوصًا الخلط مع ميزة تطبيق GitHub المسمّاة Code Review، لأنها موثّقة في الصفحة نفسها التي يُشرح فيها الأمر /code-review.

• /simplify: أربعة وكلاء يفحصون بالتوازي إعادة استعمال الدوال المساعدة الموجودة، والتبسيط، والكفاءة، وما إذا كان التغيير في المستوى الصحيح من التجريد، ثم يطبّقون الإصلاحات. ولا يبحث عن أخطاء الصحّة البرمجية. وتنصح صفحة Code Review أيضًا بأنه إن كنت قد وضعت /simplify في سكربتات للبحث عن الأخطاء، فعليك الانتقال إلى /code-review --fix.
• /security-review: يفحص الفروق بين فرعك الحالي والفرع الافتراضي في origin بحثًا عن ثغرات مثل الحقن ومشكلات المصادقة وكشف البيانات. ويتطلّب وجود remote باسم origin.
• Code Review (تطبيق GitHub): بعد أن يفعّله مالك (Owner) المؤسّسة، يفحص عدّة وكلاء على بنية Anthropic التحتية طلب السحب حين يُفتح، ومع كل دفع، أو حين يكتب أحدهم @claude review، ويتركون تعليقات على مستوى الأسطر. وهو معاينة بحثية لخطّتي Team وEnterprise فقط (ولا يتوفّر للمؤسّسات التي تعتمد Zero Data Retention). يتدرّج تسعيره مع الرموز بمتوسّط 15 إلى 25 دولارًا لكل مراجعة، ويستغرق 20 دقيقة في المتوسّط، ويُحتسب من رصيد الاستخدام منفصلًا عن حدود الخطّة. ويمكنك ضبط ما يشير إليه عبر REVIEW.md.
• claude-code-action: يشغّل Claude Code ضمن سير عمل GitHub Actions في مستودعك أنت. ومثال المراجعة في الوثائق الرسمية يستدعي نسخة الإضافة (plugin) من مهارة code-review (/code-review:code-review --comment) للتعليق على PR. والتكلفة هي تسعير Claude API (أو رموز الاشتراك) إضافةً إلى وقت تشغيل GitHub Actions.

يتّضح الأمر أكثر حين ترتّبها بحسب «أين يعمل، ومن يدفع، وإلامَ ينظر». فلفحص فروقك محليًّا استعمل /code-review؛ وللنظر بعمق قبل الدمج استعمل ultra؛ وللتشغيل التلقائي على كل PR للفريق استعمل Code Review في تطبيق GitHub أو claude-code-action.

7. متى يشغّله Claude من تلقاء نفسه، وكيف تمنع ذلك

يستطيع Claude تشغيل /code-review من تلقاء نفسه. فإن طلبت منه بلغة عادية أن يراجع تغييراتك، فقد يشغّل المهارة دون أن تكتب الأمر، كما أن مهمّة مجدولة موجّهها /code-review تشغّل مراجعة هي أيضًا. لكن المهمّة المجدولة لا تطلق ultra (المراجعة السحابية) أبدًا؛ فهو لا يعمل إلا حين تكتب /code-review ultra بنفسك.

ولمنع Claude والمهامّ المجدولة كليهما من تشغيله، مع إبقائه متاحًا حين تكتبه بنفسك، أضف ما يلي إلى ملف إعدادات مثل ~/.claude/settings.json:

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

المراجعات العاملة في الخلفية تعمل وكلاءً فرعيين. ونشرح كيف يتعامل الوكلاء الفرعيون مع السياق والنماذج في مقالنا عن الوكلاء الفرعيين وفرق الوكلاء.

8. ماذا تستعمل ومتى

يذكر جدول المقارنة في الوثائق الرسمية أن /code-review المحلي أنسب لملاحظات سريعة في أثناء التكرار، وأن ultra أنسب للاطمئنان قبل دمج التغييرات الكبيرة. وإذا طبّقنا ذلك على سير عمل يومي، فسيبدو هكذا:

ولأن التشغيلات المجانية الثلاثة في ultra لا تتجدّد، فمن المجدي ادّخارها للتغييرات واسعة الأثر، أو للتغييرات التي لم تحسم المراجعة المحلية أمرها، بدلًا من الإصلاحات الصغيرة. وبالمثل، استعمل /security-review حين تريد التركيز على الثغرات، و/simplify حين تريد تحسين قابلية القراءة لا البحث عن الأخطاء؛ فالتقسيم بحسب الغرض هو ما تصفها به الوثائق.

9. جرّبته على شيفرة هذا الموقع

في 2 أكتوبر 2026، شغّلتُ /code-review high على شيفرة أداة كاشف صور الذكاء الاصطناعي المنشورة على هذا الموقع. تقرأ هذه الأداة البيانات الوصفية للصورة ومصدرها (C2PA) داخل المتصفّح بالكامل، وكان الهدف أربعة ملفات: منطق الواجهة، ومنطق التحليل (Web Worker)، والمتحكّم (controller)، وقالب الصفحة. شغّلته في تطبيق سطح المكتب لـ Claude Code (مع Claude Code 2.1.284 المضمَّن، والنموذج Opus 5.5)، مباشرةً بعد أن بحثت بنفسي عن الأخطاء وأصلحت خمسة منها.

جاءت كل ملاحظة على صيغة «أيّ ملف، وأيّ سطر» و«أيّ مُدخل يسبّب ماذا». فطابقت كل واحدة منها مع الشيفرة المصدرية للمكتبة التي تستعملها الأداة لقراءة البيانات الوصفية للصور (exifr) ومع صور اختبار أنشأتها فعلًا، ثم أصلحت الأخطاء التسعة التي تبيّن أنها حقيقية. وأبرزها:

فحتى مباشرةً بعد أن بحثت وأصلحت بنفسي، كانت هناك 9 أخطاء من نوع آخر ما زالت موجودة. وكان من الصعب خصوصًا رصد الملاحظات المتعلّقة بالافتراضات («يُفترض أن تتصرّف المكتبة هكذا») دون قراءة الشيفرة المصدرية للمكتبة. ومع ذلك، فهذه نتيجة تشغيل واحد على قاعدة شيفرة واحدة. ولن يجد بالضرورة أخطاء حقيقية بالنسبة نفسها في كل مرّة، كما أنني لم أقارنه بـ low أو medium أو max، ولم أجرّب ultra المدفوع.

10. العيوب وما ينبغي الانتباه إليه

من واقع الاستعمال وقراءة الوثائق الرسمية، إليك خمسة أمور ينبغي الانتباه إليها:

• يستهلك من حدودك. فالمراجعات المحلية أيضًا تُحتسب من استخدامك المعتاد لـ Claude، والمستويات الأعلى تستهلك أكثر. ومع ultra، بعد أن يستنفد مستخدمو Pro وMax التشغيلات المجانية الثلاثة (ومستخدمو Team وEnterprise من البداية)، تدفع نحو 5 إلى 25 دولارًا للتشغيل الواحد من رصيد الاستخدام.
• لا تأخذ الملاحظات على علّاتها. فالوثائق نفسها تقول إن high وما فوقه قد يتضمّن ملاحظات أقلّ ثقة. وفي هذه المرّة كانت 9 من 10 حقيقية، لكن التحقّق من كل واحدة يتطلّب جهدًا مع ذلك.
• ما يفعله --fix لا يتراجع عنه /rewind. فالتغييرات التي تجري في الخلفية يجب إعادتها بـ git، لذا أودِع قبل أن تستعمله.
• لا يفحص إلا صحّة الشيفرة. فهو لا يتحقّق ممّا إذا كان مضمون النصوص أو الإعدادات مطابقًا للحقائق. فمثلًا، مشكلة شائعة في هذا الموقع مثل «المقال يقول شيئًا يخالف المواصفة الرسمية» تقع خارج نطاقه.
• قد يشغّله Claude من تلقاء نفسه. وإن لم ترد ذلك، فالإعداد المذكور في القسم 7 يقصره على التشغيل اليدوي.

رأيي: تشغيله مرّة واحدة بمستوى high بعد كتابة شيفرة جديدة أو إجراء تغيير كبير هو الاستعمال الذي برّر الجهد والاستهلاك. وفي المقابل، لا يناسب تعديلات النصوص أو التغييرات الصغيرة في الإعدادات.

الخلاصة

الأمر /code-review هو مهارة مضمَّنة تراجع فروقك المحلية أو PR، مع التركيز على أخطاء الصحّة البرمجية. يعمل في الخلفية فلا يقاطع عملك، وتبقى تكلفته ضمن استخدامك المعتاد. في low أو medium لا تحصل إلا على الملاحظات عالية الثقة؛ وفي المستويات من high إلى max يوسّع نطاق بحثه لكن عليك فرز النتائج؛ وإن لم تذكر المستوى، استُعمل آخر مستوى كتبته.

الخيار --fix، الذي يصل إلى الإصلاح، مريح، لكن التعديلات التي تجري في الخلفية لا يتراجع عنها /rewind، فالإيداع أوّلًا هو الخطوة الآمنة. وحين تريد نظرة أعمق، يقضي ultra نحو 5 إلى 10 دقائق في السحابة ويعيد الملاحظات المتحقَّق منها فقط؛ ويحصل مستخدمو Pro وMax على 3 تشغيلات مجانية لمرّة واحدة، تكلّف بعدها نحو 5 إلى 25 دولارًا للتشغيل الواحد من رصيد الاستخدام. أما Code Review في تطبيق GitHub وclaude-code-action، وأسماؤهما مشابهة، فهما شيئان مختلفان، سواء في مكان عملهما أو في تكلفتهما.

حين شغّلته مرّة واحدة على شيفرة هذا الموقع، كانت 9 من ملاحظاته العشر أخطاءً حقيقية، حتى مباشرةً بعد أن أصلحت أشياء بنفسي. صحيح أن عليك التحقّق من كل ملاحظة، لكنه يستحقّ أن تشغّله مرّة بعد كتابة شيفرة جديدة أو إجراء تغيير كبير.

أسئلة شائعة

س. ما الفرق بين /review و/code-review؟

ج. هما الشيء نفسه الآن. فالأمر /review اسم بديل لـ /code-review ويقبل المستويات والخيارات نفسها. وبحسب الوثائق الرسمية، كان /review قبل الإصدار v2.1.223 أمرًا مستقلًّا للقراءة فقط يراجع PR على GitHub في تمريرة واحدة.

س. هل لاستعمال /code-review تكلفة إضافية؟

ج. ليس في المستويات من low إلى max. ففي جدول المقارنة في الوثائق الرسمية، تُحتسب تكلفته ضمن الاستخدام المعتاد. أما الذي يكلّف إضافيًّا فهو ultra: بعد التشغيلات المجانية الثلاثة في Pro وMax، يكلّف نحو 5 إلى 25 دولارًا للتشغيل الواحد من رصيد الاستخدام.

س. هل تتجدّد التشغيلات المجانية الثلاثة في ultra كل شهر؟

ج. لا. تصف الوثائق الرسمية التشغيلات الثلاثة في Pro وMax بأنها حصّة لمرّة واحدة لكل حساب لا تتجدّد. والمراجعات التي توقفها في منتصفها أو التي تفشل تُحسب هي أيضًا تشغيلًا واحدًا. ولا تحصل خطّتا Team وEnterprise على تشغيلات مجانية.

س. هل يمكنني التراجع عن التغييرات التي أجراها --fix؟

ج. استعمل git. فالتعديلات الصادرة عن مراجعة عملت في الخلفية تقع خارج نقاط الحفظ، فلا يتراجع عنها /rewind. أما إن عملت المراجعة في المقدّمة (مراجعة سابقة ما زالت جارية، أو -p، وما شابه)، فيستطيع /rewind استعادتها. وإن ساورك الشكّ، فأودِع قبل استعمال --fix.

س. هل تنطبق القواعد الموجودة في REVIEW.md على /code-review؟

ج. لا. فالأمر /code-review المحلي يتبع CLAUDE.md لكنه لا يقرأ REVIEW.md. وملف REVIEW.md هو ملف التعليمات لنسخة Code Review العاملة عبر تطبيق GitHub. فضع القواعد التي تريد أن تتبعها المراجعة المحلية في 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 معاينة بحثية، وأن ميزاتها وتسعيرها وتوفّرها قابلة للتغيير.