ينزل PR في قائمتك، ولديك خمس عشرة دقيقة ومئة سطر من منطق شخص آخر لتفحصها. الإخفاق الواضح هو الختم الآلي — تتصفّح، تثق بالـ tests، توافق. Claude يجعل المرور الأول الحادّ رخيصًا: سلّمه الـ diff، اطلب منه أن يفترض وجود bug، ودعه يفحص الصحّة والـ edge cases والأمان و«ما الذي يوقظ أحدهم الساعة الثالثة فجرًا». والمأخذ — وهو الضمان كلّه — أن Claude سيجزم بثقة تامّة بأن شيئًا ليس bug هو bug، فأنت تتحقّق من كل ملاحظة مقابل الكود الحقيقي قبل أن تتصرّف بناءً عليها. هو يسرّع المراجعة؛ لا يملكها. أنت تملكها.
- الـ diff أو الـ PR نفسه — الصقه في المحادثة في Claude Desktop، أو افتح الـ branch في Claude Desktop كي يقرأ الملفات المتغيّرة الفعلية في سياقها، لا الـ patch وحده.
- النيّة: جملة أو جملتان عمّا يُفترض أن يفعله التغيير. مراجع لا يعرف الهدف لا يستطيع إلا فحص الصياغة؛ ومن يعرفه يستطيع فحص ما إذا كان الكود يحقّقه.
- ملف
CLAUDE.mdلديك (من playbook الـ project-context) كي يراجع Claude مقابل أعرافك الحقيقية — معالجتك للأخطاء، وأنماطك، وقواعد بيتك — لا best practice عامّة.
-
سلّم الـ diff واطلب مراجعة متشكّكة حسب البُعد
افتح الـ branch في Claude Desktop والصق الـ diff في المحادثة. لا تسأل «هل هذا جيّد» — اطلب مراجعةً مُنظَّمة حسب الأبعاد التي تنكسر فعلًا في production، كي لا يسقط شيء مهمّ عبر نظرة عابرة غامضة.
أنت تطلبهذا الـ diff وما يُفترض أن يفعله: [النيّة]. راجِعه كمهندس خبير متشكّك، مُنظَّمًا حسب البُعد — الصحّة، والـ edge cases، والأمان، وقابلية التشغيل (ما الذي يوقظ أحدهم الساعة الثالثة فجرًا). لكل مشكلة أعطني الملف والسطر، ولماذا هي مشكلة، ودرجة الخطورة. تجاوز الملاحظات الصغيرة إلا إن كانت bugs حقيقية.ما تحصل عليه مراجعة مُجمَّعة حسب البُعد مع مؤشّرات
file:line، وسبب، ودرجة خطورة لكل ملاحظة — قراءة مُنظَّمة للـ diff، لا «يبدو جيّدًا لي» غامضة.تسمية الأبعاد هي ما يفرض التغطية. «راجِع هذا» يمنحك هزّة كتفين؛ «افحص الصحّة والـ edge cases والأمان وقابلية التشغيل» يمنحك bug الساعة الثالثة فجرًا.
-
ادفعه ليكون عدائيًا — افترض وجود bug
مراجع يريد أن يوافق لا يجد شيئًا. اقلب موقفه: اطلب منه أن يفترض وجود bug وأن يصطاد أسوأه. الصياغة هي الحيلة — تُظهِر ما تنزلق عنه قراءة مهذّبة.
أنت تطلبافترض الآن أن هذا الـ diff فيه bug حقيقي واحد على الأقل وأن مهمّتك إيجاد أسوأه. أين سينكسر تحت حمل، أو input سيّئ، أو race، أو فشل جزئي؟ خُذني إلى المشكلة الأخطر الوحيدة وأرِني بالضبط كيف تنحرف.ما تحصل عليه حالة أسوأ ملموسة — الـ input أو التوقيت الذي يكسره، متتبَّعًا عبر مسار الكود الفعلي — استُخرجت بالصياغة العدائية بدل أن تنزلق عنها قراءة ودودة.
إن عاد بـ «لم أجد شيئًا خطيرًا»، فكُن مرتابًا — على diff غير تافه، هذا يعني عادةً أنه لم ينظر بعمق، لا أن الكود معصوم.
-
اجعله يصوغ تعليقات مراجعة مربوطة بالأسطر
حوّل الملاحظات إلى تعليقات محدّدة قابلة للنشر — مربوطة بسطر، ومصاغة بالطريقة التي تكتبها بها على الـ PR — كي يكون الناتج شيئًا تستطيع استخدامه فعلًا، لا جدار نصّ تضطر إلى إعادة كتابته.
أنت تطلبصُغ تعليقات المراجعة للمشكلات الحقيقية — كلٌّ منها مربوط بملف وسطر محدّدين، ومصاغ بالطريقة التي أنشره بها على الـ PR: ما الخطأ، ولماذا يهمّ، والإصلاح أو السؤال الملموس. أبقِها حادّة ومحدّدة.ما تحصل عليه مجموعة من مسوّدات التعليقات المربوطة بالأسطر — ملموسة، ومحدّدة، وجاهزة للنشر — تحملها مباشرةً إلى الـ PR بعد أن تفحصها.
-
تحقّق من كل ملاحظة جوهرية مقابل الكود — اقتل الـ false positives
هذه الخطوة هي التي تجعل البقية آمنة. سيشير Claude بثقة إلى «bugs» ليست كذلك — حارس موجود أصلًا، أو حالة يعالجها الـ framework، أو سوء قراءة لمسار التحكّم. افحص كل ملاحظة جوهرية مقابل الكود الحقيقي قبل أن تنشر كلمة.
أنت تطلبلكل مشكلة أشرتَ إليها، دُلّني على الأسطر الدقيقة التي تثبت أنها حقيقية — الكود الذي يصنع المشكلة، لا وصفًا لها. إن لم تستطع أن تُريني الأسطر، قُل ذلك وسنُسقط تلك الملاحظة.ما تحصل عليه كل ملاحظة إمّا مستندة إلى أسطر محدّدة تستطيع تأكيدها بنفسك، أو متراجَع عنها بصدق — الـ false positives مقتولة قبل أن تصل إلى المؤلّف كتعليق خاطئ مصاغ بثقة.
هذا هو الضمان، لا تلميع اختياري. نشر ملاحظة غير متحقَّق منها يضيّع وقت المؤلّف ويحرق مصداقيتك كمراجع — تحقّق، ثم علّق.
-
اطلب الـ test الذي كان سيلتقط الـ bug الحقيقي
لكل bug حقيقي نجا من التحقّق، اطلب الـ test الوحيد الذي كان سيلتقطه. هذا يثبت أن الـ bug حقيقي (الـ test يفشل على الكود الحالي) ويمنح المؤلّف خطوة تالية ملموسة بدل مجرّد شكوى.
أنت تطلبللـ bug الحقيقي الذي أكّدناه، اكتب الـ test الوحيد الذي يفشل على الكود الحالي وينجح بمجرّد إصلاحه. سأرفقه بالمراجعة كي يكون للإصلاح شيء يثبت مقابله.ما تحصل عليه test فاشل يثبّت الـ bug المؤكَّد — يحوّل «أظنّ هذا مكسورًا» إلى «هذا الـ test الأحمر الذي يثبته»، وهو تعليق مراجعة أقوى بكثير من النص وحده.
- مراجعة ذاتية قبل الـ PR: شغّل هذا الـ loop كاملًا على branchك أنت قبل أن تفتح الـ PR — التقط bug الساعة الثالثة فجرًا الخاص بك في الخفاء، أطلِق PR أنظف، واصرف انتباه المراجع على القرارات الصعبة بدل الأخطاء الواضحة.
- مرور مُركَّز على الأمان: ضيّق العدسة على بُعد واحد — «راجِع للأمان فقط: injection، وثغرات authz، وأسرار في الـ diff، وdeserialization غير آمن» — حين يمسّ التغيير الـ auth أو معالجة الـ input أو أي شيء يعبر حدّ ثقة.
- *حوّل checklistك إلى prompt أو skill قابل لإعادة الاستخدام (مسار
Power Track):** التقط أبعاد المراجعة وأعراف فريقك كـ slash command/reviewأو skill كي تبدأ كل مراجعة من الـ checklist المتشكّك نفسه الخاصّ ببيتك (انظر تبويب Features).
- Claude يراجع؛ أنت توافق. هو مراجع أول، لا الموافِق أبدًا — إنسان يملك الإمضاء لأن إنسانًا هو المؤلّف المسؤول. كلما أسرع المرور الأول، زاد أهمية أن يبقى القرار النهائي لك.
- سيجزم بثقة تامّة بأن شيئًا ليس bug هو bug. ملاحظة مصاغة بثقة ليست ملاحظة متحقَّقًا منها — يسيء Claude قراءة مسار التحكّم ويشير إلى حرّاس موجودين أصلًا. تحقّق من كل ملاحظة جوهرية مقابل الأسطر الحقيقية قبل أن تعلّق، وإلا أرسلت المؤلّف يطارد شبحًا.
- لا تدعه يختم آليًا. إن عادت المراجعة نظيفة على diff غير تافه، فهو شبه أكيد لم يحفر — ادفعه ليكون عدائيًا ويفترض وجود bug، بدل أن تأخذ «يبدو جيّدًا» نتيجةً.
- أبقِ الكود الخاص داخل الحدود. قد يحمل الـ diff بيانات عملاء، أو أسرارًا، أو معمارية تحت NDA — أبقِه في بيئة تعتمدها مؤسستك، وتذكّر أن المجلد المفتوح هو الحدّ الذي يقرأ منه Claude.
ستحصل في النهاية على مراجعة أحدّ خلال دقائق بدل ساعة — الـ bugs الواضحة ملتقَطة، والحالة الأسوأ مفحوصة بنشاط، والـ false positives مقتولة، والتعليقات مصاغة ومتحقَّق منها — مع بقاء إنسان يتّخذ القرار في الـ merge.
أسئلة يطرحها الناس
- هل يحلّ هذا محلّ مراجعة الكود البشرية؟
- لا. يحلّ محلّ *المرور الأول البطيء*، لا المراجع. Claude سريع في إظهار ثغرات الصحّة، والـ edge cases، وbug قابلية التشغيل الساعة الثالثة فجرًا، لكنه لا يملك الموافقة — إنسان هو المؤلّف المسؤول عن الـ merge، وإنسان يملك السياق والمساءلة اللذين يتطلّبهما الإمضاء. استخدمه لتصل إلى الأسئلة الصعبة أسرع، لا لتتخطّاها.
- كيف أثق بملاحظات Claude إن كان قد يخطئ بثقة؟
- أنت لا تثق بها — تتحقّق منها. سيشير Claude إلى «bug» ليس كذلك، لأنه أحيانًا يسيء قراءة مسار التحكّم أو يفوته حارس موجود أصلًا. اجعله يدلّك على الأسطر الدقيقة التي تثبت أن كل ملاحظة حقيقية قبل أن تنشر كلمة؛ وإن لم يستطع أن يُريك الكود، أسقِط الملاحظة. خطوة التحقّق هي ما يحوّل تخمينًا واثقًا إلى تعليق مراجعة يستحقّ الإرسال.
- هل يستطيع المراجعة مقابل أعراف فريقنا، لا best practice عامّة فقط؟
- نعم — لهذا وُجد `CLAUDE.md`. ضع أعرافك، وأنماط معالجة الأخطاء، وقواعد بيتك في `CLAUDE.md` الخاصّ بمشروعك (انظر playbook الـ project-context) فيراجع Claude الـ diff مقابل *معاييرك* بدل معايير كتاب مدرسي. بدونه تحصل على ملاحظات عامّة؛ معه تحصل على مراجع يعرف كيف يُفترض أن يبدو codebase*ك.
- هل أشغّل هذا على كودي قبل أن أفتح الـ PR؟
- نعم، وهي من أعلى الطرق قيمةً لاستخدامه. تشغيل المراجعة العدائية على branch*ك قبل أن تفتح الـ PR يتيح لك التقاط bug حالتك الأسوأ في الخفاء، وإصلاحه بهدوء، وفتح PR أنظف — ما يعني أن مراجعك البشري يصرف انتباهه على القرارات الصعبة فعلًا بدل الأخطاء التي كان بوسعك التقاطها بنفسك.