ملاحظة من المؤلف: جمعت لكم 25 موجهًا (Prompt) لمراجعة الكود باستخدام Claude Code، تم التحقق منها عمليًا وتغطي 7 سيناريوهات رئيسية تشمل المراجعة الأمنية، تحليل الأداء، مراجعة البنية، اكتشاف الأخطاء (Bug)، ومراجعة طلبات السحب (PR Review)، مع إرفاق صيغة لكتابة الموجهات.
يأتي Claude Code مزودًا بأمر /security-review ونظام وكلاء متعددين لمراجعة الكود، ولكن مخرجات المراجعة الافتراضية غالبًا ما تكون مطولة وتغرق في تفاصيل غير ضرورية. يجب أن يكون موجه المراجعة الجيد دقيقًا مثل حالات الاختبار (Test Cases)؛ حيث يحدد النطاق، ويضع الأولويات، ويطلب أرقام أسطر محددة واقتراحات للإصلاح. جمعت في هذا المقال 25 موجهًا تغطي 7 سيناريوهات لمراجعة الكود، بدءًا من المراجعة الأمنية وصولاً إلى مراجعة البنية، وكلها جاهزة للنسخ والاستخدام مباشرة.
القيمة الأساسية: 25 موجهًا تغطي أكثر سيناريوهات مراجعة الكود شيوعًا، مع صيغة لكتابة الموجهات ومقارنة بين الموجهات الجيدة والسيئة.
مراجعة صيغة كتابة الموجه (Prompt)
الموجه الجيد للمراجعة دقيق مثل حالات الاختبار، بينما الموجه الضعيف يشبه رسالة غامضة على Slack.
صيغة العناصر الخمسة
[الدور] بصفتك مهندس {لغة/مجال} خبير
[النطاق] راجع {الملف/المجلد/PR} الخاص بـ {محتوى التغيير}
[التركيز] ركز بشكل أساسي على {الأمان/الأداء/المنطق/البنية}
[التنسيق] تنسيق المخرجات: {قائمة مرقمة/جدول/تعليقات مضمنة}
[المستوى] حدد مستوى الخطورة: {Critical/High/Medium/Low}
| العنصر | مثال سيء | مثال جيد |
|---|---|---|
| الدور | (غير محدد) | "بصفتك مهندس خلفية (Backend) خبير" |
| النطاق | "ألقِ نظرة على هذا الكود" | "راجع git diff الأخير لـ src/auth/" |
| التركيز | "أعطني بعض الملاحظات" | "ركز على حقن SQL وتجاوز المصادقة" |
| التنسيق | (مخرجات عشوائية) | "قائمة مرقمة، كل عنصر يتضمن الملف:رقم السطر، وصف المشكلة، اقتراح الإصلاح" |
| المستوى | (بدون طلب) | "حدد مستوى الخطورة Critical/High/Medium/Low" |
السيناريو الأول: المراجعة الأمنية (4 موجهات)
تعد المراجعة الأمنية السيناريو الأعلى أولوية في مراجعة الكود (Code Review). يأتي Claude Code مع أمر /security-review مدمج، ولكن الموجهات المخصصة يمكنها التعمق أكثر.
الموجه #1: فحص شامل وفق OWASP Top 10
بصفتك مهندس تدقيق أمني، راجع جميع الملفات التي تم تعديلها مؤخراً في مجلد src/.
تحقق من كل بند وفقاً لقائمة OWASP Top 10:
1. الحقن (SQL/NoSQL/Command Injection)
2. عيوب المصادقة
3. كشف البيانات الحساسة
4. XXE
5. عيوب التحكم في الوصول
6. أخطاء التكوين الأمني
7. XSS
8. إلغاء التسلسل (Deserialization)
9. استخدام مكونات بها ثغرات
10. عدم كفاية السجلات والمراقبة
تنسيق المخرجات: قائمة مرقمة، كل عنصر يتضمن [الملف:رقم السطر] [مستوى الخطورة] [وصف المشكلة] [اقتراح الإصلاح].
أبلغ فقط عن المشكلات الفعلية الموجودة، ولا تبلغ عن مخاطر نظرية.
الموجه #2: المراجعة الأمنية لنقاط نهاية API
راجع جميع ملفات مسارات API (routes/، controllers/)، وركز على:
- هل توجد نقاط نهاية تفتقر إلى وسيط (middleware) المصادقة؟
- هل تم التحقق من صحة المدخلات وتعقيمها؟
- هل توجد مخاطر التعيين الجماعي (mass assignment)؟
- هل تم تكوين تحديد معدل الطلبات (rate limiting)؟
- هل تسرب استجابات الخطأ معلومات داخلية؟
تنسيق المخرجات جدول: مسار نقطة النهاية | المشكلة | مستوى الخطورة | حل الإصلاح
الموجه #3: الكشف عن تسريب المعلومات الحساسة
افحص المشروع بالكامل، وتحقق مما إذا كانت المعلومات الحساسة التالية مشفرة برمجياً (hardcoded) أو مكشوفة عن طريق الخطأ:
- مفاتيح API، الأسرار (Secrets)، والرموز (Tokens)
- سلاسل اتصال قاعدة البيانات
- المفاتيح الخاصة والشهادات
- عناوين IP الداخلية وأسماء النطاقات
- كلمات المرور أو بيانات الاعتماد في التعليقات
يشمل نطاق الفحص: الكود المصدري، ملفات التكوين، .env.example، docker-compose.yml، README
حدد مسار الملف ورقم السطر لكل اكتشاف.
الموجه #4: مراجعة منطق المصادقة والتفويض
بصفتك خبيراً أمنياً، راجع الكود المتعلق بالمصادقة والتفويض:
1. هل منطق التحقق من رمز JWT مكتمل (انتهاء الصلاحية، التوقيع، التلاعب)؟
2. هل يتم تخزين كلمات المرور باستخدام تشفير آمن (bcrypt/argon2)؟
3. هل إدارة الجلسة (Session) عرضة لهجمات تثبيت الجلسة؟
4. هل تكوين CORS متساهل للغاية؟
5. هل يتحقق رد اتصال OAuth من معامل state؟
أبلغ فقط عن المشكلات بمستوى Critical و High، وأرفق أمثلة للكود المصحح.
السيناريو الثاني: اكتشاف الأخطاء البرمجية (Bug) (4 موجهات)
الموجه #5: المؤشرات الفارغة (Null) والشروط الحدية
راجع الملفات المعدلة مؤخرًا للبحث عن الأخطاء المحتملة التالية:
- أماكن الوصول إلى الخصائص دون التحقق من null/undefined
- الوصول إلى خارج حدود المصفوفة
- خطأ القسمة على صفر
- السلاسل النصية الفارغة التي لم تتم معالجتها
- قيم NaN الناتجة عن parseInt/parseFloat التي لم تتم معالجتها
لكل خطأ يتم العثور عليه، قدم شروط التشغيل (ما هو المدخل الذي سيؤدي إلى الانهيار) وكود الإصلاح.
الموجه #6: مشاكل العمليات غير المتزامنة والتزامن
راجع جميع الأكواد غير المتزامنة في المشروع (async/await، Promise، الدوال الاسترجاعية)، وتحقق من:
- وجود Promise بدون معالجة خطأ (catch)
- وجود حالات سباق (race condition)
- وجود await داخل حلقة تكرارية مما يؤدي إلى تنفيذ تسلسلي (يجب استخدام Promise.all)
- وجود تعقيد في الدوال الاسترجاعية (callback hell) يمكن إعادة هيكلته
- ما إذا كانت المعاملات (transactions) تعالج التراجع (rollback) بشكل صحيح
قم بوضع علامة [الملف:رقم السطر] [المشكلة] [التأثير] [خطة الإصلاح]
الموجه #7: صائد الأخطاء المنطقية
اقرأ المنطق البرمجي للدوال التالية بعناية، وابحث عن:
- ما إذا كانت فروع if/else تغطي جميع الحالات
- ما إذا كانت شروط إنهاء الحلقات صحيحة
- ما إذا كانت معاملات المقارنة صحيحة (== مقابل ===، > مقابل >=)
- ما إذا كان نطاق المتغيرات صحيحًا
- ما إذا كانت قيم الإرجاع معرفة في جميع المسارات
لا تركز على أسلوب كتابة الكود، بل ركز فقط على صحة المنطق.
الموجه #8: مراجعة معالجة الأخطاء
راجع آلية معالجة الأخطاء في المشروع:
1. هل كتل try/catch تلتقط استثناءات محددة بدلاً من Error عام؟
2. هل كتلة catch تبتلع الخطأ فقط (catch فارغ)؟
3. هل يتم تمرير الخطأ بشكل صحيح إلى المستويات الأعلى؟
4. هل رسائل الخطأ الظاهرة للمستخدم ودودة (لا تكشف معلومات داخلية)؟
5. هل توجد آليات تراجع عند الفشل للعمليات الحساسة (الدفع، تغيير البيانات)؟
رتب النتائج حسب مستوى الخطورة.
السيناريو الثالث: تحليل الأداء (3 موجهات)
الموجه #9: أداء استعلامات قاعدة البيانات
راجع جميع أكواد استعلام قاعدة البيانات (models/، repositories/، استدعاءات ORM)، وتحقق من:
- مشكلة استعلامات N+1 (تنفيذ استعلامات داخل حلقة)
- حقول الاستعلام التي تفتقر إلى الفهارس (indexes)
- ما إذا كان ينبغي استبدال SELECT * بحقول محددة
- ما إذا كانت الاستعلامات ذات البيانات الضخمة تحتوي على ترقيم صفحات (pagination)
- ما إذا كانت هناك استعلامات متكررة يمكن تحسينها باستخدام التخزين المؤقت
لكل مشكلة، قدر التأثير على الأداء (منخفض/متوسط/عالي)، وقدم الكود بعد التحسين.
الموجه #10: تسريب الذاكرة والموارد
راجع احتمالات تسريب الذاكرة والموارد في المشروع:
- هل تتم إزالة مستمعي الأحداث عند إلغاء تحميل المكون؟
- هل يتم تنظيف المؤقتات (setInterval/setTimeout)؟
- هل يتم إغلاق اتصالات قاعدة البيانات بشكل صحيح؟
- هل يتم تحرير مقابض الملفات في finally؟
- هل يتم إلغاء مرجعية المصفوفات/الكائنات الكبيرة بعد الاستخدام؟
ركز بشكل خاص على تنظيف useEffect في مكونات React ومعالجة التدفق (streams) في Node.js.
الموجه #11: مراجعة تعقيد الخوارزميات
راجع الدوال المعدلة مؤخرًا، وحلل التعقيد الزمني والمكاني:
- هل هناك تنفيذ بتعقيد O(n²) أو أعلى يمكن تحسينه؟
- هل هناك أماكن يمكن فيها استبدال البحث الخطي بجدول هاش (hash table)؟
- هل هناك نسخ عميق (deep copy) غير ضروري؟
- هل يجب استخدام StringBuilder/join لدمج السلاسل النصية؟
- هل تم استخدام الخوارزمية المناسبة للترتيب؟
حدد التعقيد الحالي ← التعقيد الذي يمكن الوصول إليه ← خطة التحسين المحددة.
السيناريو الرابع: مراجعة البنية الهندسية (4 موجهات)
الموجه #12: تحليل التبعيات والاقتران
حلل تبعيات الوحدات في مجلد src/:
1. ارسم مخطط التبعية بين الوحدات (أي وحدة تستورد أي وحدات أخرى)
2. حدد التبعيات الدائرية (Circular Dependencies)
3. حدد الوحدات ذات الاقتران الأعلى (التي تعتمد عليها معظم الوحدات الأخرى)
4. اقترح أي التبعيات يجب فك اقترانها باستخدام الواجهات (Interfaces) أو التجريد (Abstraction)
المخرجات: جدول التبعيات + قائمة التبعيات الدائرية + مقترحات فك الاقتران
الموجه #13: فحص الامتثال للبنية الطبقية
افحص ما إذا كان الكود يتبع مبادئ البنية الطبقية (Layered Architecture):
- هل تحتوي طبقة Controller على منطق عمل (يجب أن تقتصر فقط على التوجيه والتحقق من المعاملات)؟
- هل تتعامل طبقة Service مباشرة مع قاعدة البيانات (يجب أن تمر عبر Repository)؟
- هل تحتوي طبقة Model/Entity على منطق متعلق بـ HTTP؟
- هل توجد استدعاءات عبر الطبقات (مثل استدعاء Controller لـ Repository مباشرة)؟
أدرج كل ملف ينتهك مبادئ الطبقات مع تحديد موقع الكود بدقة.
الموجه #14: مراجعة تصميم API
بناءً على أفضل ممارسات تصميم RESTful API، راجع جميع نقاط نهاية API:
- هل تتبع تسمية الـ URL اتفاقيات REST (أسماء بصيغة الجمع، علاقات هرمية)؟
- هل استخدام طرق HTTP صحيح (GET للقراءة فقط، POST للإنشاء، PUT للتحديث، DELETE للحذف)؟
- هل تنسيق الاستجابة متسق (رموز الخطأ، تنسيق الترقيم، تنسيق الوقت)؟
- هل التحكم في إصدارات API مطبق بشكل جيد؟
- هل توجد نقاط نهاية زائدة يمكن دمجها؟
المخرجات: جدول مقترحات التحسين (الحالي ← المقترح ← السبب)
الموجه #15: تقييم الديون التقنية
قم بإجراء تقييم شامل للديون التقنية للمشروع:
1. حزم التبعيات وإصدارات الإطار (Framework) القديمة
2. استدعاءات API المهجورة
3. قيم الإعدادات المرمزة (Hardcoded) (يجب استخدام متغيرات البيئة)
4. كتل الكود المكررة (نسخ ولصق)
5. الوحدات الرئيسية التي تفتقر إلى اختبارات الوحدة (Unit Tests)
6. الدوال المعقدة للغاية (تعقيد حلقي > 15)
رتب النتائج حسب إلحاح الإصلاح: حظر (يجب إصلاحه فوراً) > مرتفع > متوسط > منخفض
السيناريو الخامس: مراجعة طلبات السحب (PR Review) (4 موجهات)
الموجه #16: مراجعة سريعة لـ PR Diff
راجع الفرق (diff) بين الفرع الحالي وفرع main، وقم بالتقييم من منظور مهندس أول:
1. ما هو الغرض من هذا الـ PR (استنتج ذلك من الـ diff)؟
2. هل التغييرات كاملة (هل هناك ملفات أو منطق مفقود)؟
3. هل تم إدخال أخطاء جديدة أو تراجعات (Regression)؟
4. هل تغطية الاختبار كافية؟
5. هل هناك تغييرات غير ضرورية (كود تصحيح الأخطاء، ضجيج التنسيق)؟
أبلغ فقط عن المشكلات ذات المستوى العالي (High) والحرجة (Critical). لا تدقق في أسلوب كتابة الكود (nit-pick).
الموجه #17: فحص التوافق مع الإصدارات السابقة
راجع جميع تغييرات الـ PR الحالي، وتحقق مما إذا كانت هناك تغييرات غير متوافقة مع الإصدارات السابقة:
- هل تغير توقيع أو قيم إرجاع واجهات API العامة؟
- هل هناك تغييرات جذرية (Breaking Changes) في مخطط قاعدة البيانات؟
- هل تغير تنسيق ملفات الإعدادات؟
- هل تم حذف دوال تستخدمها وحدات أخرى؟
- هل تغير اسم أو تنسيق متغيرات البيئة؟
لكل عنصر غير متوافق، قم بتقييم نطاق التأثير وخطة الترحيل.
الموجه #18: مراجعة كفاية الاختبارات
قارن بين تغييرات الكود في الـ PR وتغييرات الاختبارات:
1. هل تحتوي جميع الدوال المضافة على اختبارات وحدة مقابلة؟
2. هل تم تحديث الاختبارات الموجودة عند تعديل المنطق؟
3. هل تغطي الاختبارات الحالات الحدية (Boundary Conditions) ومسارات الاستثناءات؟
4. هل تغطي اختبارات التكامل (Integration Tests) نقاط نهاية API الجديدة؟
5. هل بيانات الاختبار معقولة (ليست مجرد 123 أو abc عشوائية)؟
أدرج مقترحات لحالات الاختبار المفقودة: اسم الدالة | سيناريو الاختبار المفقود | الأولوية
الموجه #19: مراجعة جودة الالتزام (Commit)
راجع سجل الالتزامات (commit history) للـ PR الحالي:
1. هل تصف رسائل الالتزام محتوى التغييرات بوضوح؟
2. هل كل التزام ذري (هدف واحد لكل التزام)؟
3. هل هناك التزامات تافهة يمكن دمجها (squash)؟
4. هل هناك التزامات مؤقتة مثل "fix typo" أو "wip" يجب تنظيفها؟
5. هل ترتيب الالتزامات منطقي (البنية التحتية أولاً ثم منطق العمل)؟
اقترح الالتزامات التي تحتاج إلى تنظيم وهيكل الالتزام النهائي.
المشهد السادس: القابلية للقراءة (3 موجهات)
الموجه #20: مراجعة التسميات
راجع تسميات جميع المتغيرات والدوال والفئات (Classes) في الملفات المعدلة مؤخراً:
- هل توجد أسماء غامضة المعنى (مثل: data، info، temp، res، obj)؟
- هل توجد اختصارات مفرطة (مثل: usr ← user، btn ← button)؟
- هل توجد قيم منطقية (Boolean) لا تبدأ بـ is/has/should؟
- هل تبدأ أسماء الدوال بأفعال تصف السلوك بدقة؟
- هل تبدأ أسماء الفئات بأسماء تصف المسؤوليات بدقة؟
لكل تسمية غير مناسبة، اقترح اسماً بديلاً أفضل.
الموجه #21: مراجعة جودة التعليقات
راجع جودة التعليقات في الكود:
- هل هناك تعليقات تشرح "ماذا" (what) يجب تحويلها إلى "لماذا" (why)؟
- هل هناك تعليقات قديمة (لا تتوافق مع الكود الحالي)؟
- هل هناك تعليقات يجب استخراجها كاسم دالة؟
- هل تفتقر منطق الأعمال المعقد إلى تعليقات توضيحية؟
- هل تحتوي واجهات البرمجة العامة (Public API) على JSDoc/docstring؟
لا تقترح إضافة تعليقات بديهية (مثل "// زيادة العداد").
الموجه #22: اقتراحات تقسيم الدوال
راجع جميع الدوال التي تتجاوز 30 سطراً، وقيّم ما إذا كان يجب تقسيمها:
- هل للدالة مسؤوليات متعددة (تقوم بأكثر من شيء غير مترابط)؟
- هل تتجاوز مستويات التداخل 3 مستويات؟
- هل يتجاوز عدد المعاملات 4 معاملات؟
- هل هناك منطق متكرر يمكن استخراجه؟
قدم خطة تقسيم محددة: الدالة الأصلية ← قائمة الدوال بعد التقسيم ← مسؤولية كل دالة.
المشهد السابع: اقتراحات إعادة الهيكلة (3 موجهات)
الموجه #23: كشف انتهاك مبدأ DRY (لا تكرر نفسك)
افحص الكود بحثاً عن التكرار:
- حدد كتل الكود المتكررة لأكثر من 3 أسطر.
- حدد الكود ذو المنطق المتشابه ولكن بطرق كتابة مختلفة.
- حدد الأنماط العامة التي يمكن استخراجها كدوال مساعدة (Utility functions).
لكل مجموعة من الكود المتكرر، قدم الكود الفعلي لاستخراجه كدالة عامة.
الموجه #24: تحسين أنماط التصميم
راجع الكود من منظور خبير في أنماط التصميم:
- هل يجب استبدال كثرة الـ if/else أو switch بنمط الاستراتيجية (Strategy Pattern)؟
- هل يجب استخدام نمط المصنع/الباني (Factory/Builder) لإنشاء الكائنات المعقدة؟
- هل يجب استخدام نمط طريقة القالب (Template Method) للكود المتكرر؟
- هل يجب استخدام نمط سلسلة المسؤولية (Chain of Responsibility) لتقليل التداخل في الـ Callbacks؟
- هل يجب استخدام نمط المراقب (Observer) لإدارة الحالة العامة؟
اقترح التحسينات فقط إذا كانت ستقلل التعقيد بشكل ملحوظ، وتجنب التصميم المفرط.
الموجه #25: تحديث الكود القديم
راجع الكود القديم في المشروع وحدد الأجزاء التي يمكن إعادة كتابتها باستخدام قواعد لغوية حديثة:
- var ← const/let
- دوال الـ Callback ← async/await
- حلقات for ← map/filter/reduce
- دمج السلاسل النصية ← قوالب السلاسل (Template Strings)
- require ← import
- Class ← مكونات دالة + Hooks (في React)
قدم مقارنة بين الكود قبل وبعد إعادة الهيكلة، وقيّم مخاطر التعديل (منخفضة/متوسطة/عالية).
🎯 نصيحة للاستخدام: يُنصح بحفظ موجهات المراجعة الأكثر استخداماً في ملف
CLAUDE.mdأو مجلد.claude/skills/لتوحيد المعايير داخل الفريق. يمكنك عبر/loopأتمتة مراجعات الأمان وطلبات السحب (PR Review).
إذا كنت تبني نظام مراجعة آلي عبر API، نوصي باستخدام خدمة وكيل API من APIYI (apiyi.com) للوصول إلى Claude Opus 4.6 بخصم 20%.
الأسئلة الشائعة
س1: ماذا أفعل إذا كان الأمر الافتراضي /code-review مطولاً جداً؟
قم بإنشاء ملف REVIEW.md في المجلد الرئيسي للمشروع أو أضف قواعد المراجعة في ملف CLAUDE.md لتحدد بوضوح لـ Claude ما يجب التركيز عليه وما يجب تجاهله. على سبيل المثال: "أبلغ فقط عن المشكلات ذات المستوى الحرج (Critical) والعالي (High). لا تدقق في أسلوب كتابة الكود أو التسميات. لا تقترح إضافة تعليقات." سيقوم Claude Code بقراءة هذا الملف تلقائياً عند كل عملية مراجعة.
س2: كيف أحفظ الموجه (Prompt) كمهارة (Skill) قابلة لإعادة الاستخدام؟
احفظ موجه مراجعة الأمان الخاص بك في المسار .claude/skills/security-review/SKILL.md واضبط user-invocable: true؛ سيتم تسجيله كأمر مائل /security-review. بعد ذلك، يمكنك كتابة /security-review مباشرة للتنفيذ دون الحاجة للنسخ واللصق في كل مرة. يمكنك حفظ عدة موجهات كمهارات متعددة.
س3: هل يمكن إرسال مراجعة طلب السحب (PR Review) تلقائياً إلى تعليقات GitHub؟
نعم. هناك طريقتان: 1) اكتب @claude review في تعليقات طلب السحب (PR)، وسيقوم Claude بتحليل الفرق (diff) ونشر النتائج كتعليقات مضمنة؛ 2) استخدم الأمر /code-review --comment ليقوم Claude بنشر نتائج المراجعة كتعليق على طلب السحب. في مارس 2026، أطلقت Anthropic نظاماً متعدد الوكلاء (Multi-Agent) متخصصاً في مراجعة الكود، يمكنه جدولة مجموعة من الوكلاء المحترفين لمراجعة طلبات السحب من زوايا متعددة مثل الأمان، والمنطق، والاختبار.
س4: كم يستهلك موجه المراجعة من الرموز (Tokens)؟
يعتمد ذلك على نطاق المراجعة. مراجعة ملف واحد تستهلك حوالي 2000-5000 رمز، بينما قد يستهلك الفحص الأمني للمشروع بالكامل ما بين 10000-30000 رمز. ننصح بتحديد نطاق المراجعة بملفات أو مجلدات معينة لتجنب إهدار الرموز في "مسح جميع الملفات". يمكنك تقليل تكاليف المراجعة بشكل كبير من خلال الوصول إلى Claude Opus 4.6 عبر APIYI (apiyi.com) بخصم 20%.
ملخص
النقاط الجوهرية لموجهات مراجعة الكود في Claude Code:
- 25 موجهاً تغطي 7 سيناريوهات رئيسية: مراجعة الأمان (4)، اكتشاف الأخطاء (4)، تحليل الأداء (3)، مراجعة البنية (4)، مراجعة طلبات السحب (4)، القابلية للقراءة (3)، اقتراحات إعادة الهيكلة (3) — يمكنك نسخها واستخدامها مباشرة.
- معادلة العناصر الخمسة للموجه الجيد: الدور + النطاق + التركيز + التنسيق + مستوى الخطورة. اجعلها دقيقة كحالات الاختبار، وليست غامضة كرسائل Slack.
- نظام المراجعة ثلاثي المستويات: الأوامر المدمجة (/security-review) ← الموجهات المخصصة (الـ 25 المذكورة في المقال) ← المراجعة المستمرة المؤتمتة عبر
/loop.
نوصي بالوصول إلى واجهة برمجة تطبيقات Claude Opus 4.6 عبر APIYI (apiyi.com) بخصم 20% لبناء نظام مؤتمت لمراجعة الكود.
📚 المراجع
-
الوثائق الرسمية لـ Claude Code Code Review: شرح كامل لميزة المراجعة المدمجة
- الرابط:
code.claude.com/docs/en/code-review - الوصف: تتضمن مراجعة طلبات السحب (PR Review)، وأنظمة الوكلاء المتعددين، وطرق التخصيص.
- الرابط:
-
Claude Code Security Review: خطة المراجعة الأمنية الرسمية من Anthropic
- الرابط:
github.com/anthropics/claude-code-security-review - الوصف: تتضمن التنفيذ الكامل لأمر
/security-review.
- الرابط:
-
7 موجهات لمراجعة طلبات السحب (PR Review) عبر Claude: موجهات مراجعة معتمدة من المجتمع
- الرابط:
rephrase-it.com/blog/7-claude-pr-review-prompts-for-2026 - الوصف: تتضمن قوالب موجهات مهيكلة لمراجعة طلبات السحب.
- الرابط:
-
مركز وثائق APIYI: وصول بخصم 20% إلى واجهة برمجة تطبيقات Claude Opus 4.6
- الرابط:
docs.apiyi.com - الوصف: الحل الأمثل لواجهة برمجة التطبيقات (API) لبناء أنظمة مراجعة آلية.
- الرابط:
المؤلف: فريق APIYI التقني
التواصل التقني: نرحب بمناقشاتكم في قسم التعليقات، وللمزيد من الموارد يمكنكم زيارة مركز وثائق APIYI على الرابط docs.apiyi.com
