أحمد حايس
الرئيسيةمن أناالدوراتالمدونةالعروض
أحمد حايس

دورات عربية متخصصة في التقنية والبرمجة والذكاء الاصطناعي.

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

تعلم أسرعوصول مباشر للدورات والمسارات من الموبايل.
تنقل أوضحالروابط الأساسية والدعم في مكان واحد بدون تشتيت.

المنصة

  • الرئيسية
  • من أنا
  • الدورات
  • العروض
  • المدونة

الدعم

  • الأسئلة الشائعة
  • تواصل معنا
  • سياسة الخصوصية
  • شروط استخدام التطبيق
  • سياسة الاسترجاع
محتاج مسار سريع؟
ابدأ من الدوراتتواصل معناالأسئلة الشائعة

© 2026 أحمد حايس. جميع الحقوق محفوظة.

الرئيسيةالدوراتالعروضالمدونةالدخول

أتمتة مراجعة الـ Pull Requests بـ Claude Opus 4.7 داخل GitHub Actions

📅 ٢٠ أبريل ٢٠٢٦⏱ 6 دقائق قراءة
أتمتة مراجعة الـ Pull Requests بـ Claude Opus 4.7 داخل GitHub Actions
لو الـ Pull Request بيقعد يومين في طابور المراجعة علشان السينيور مشغول، الحل مش "هات سينيور تاني". الحل إن أول مراجعة تحصل خلال دقيقتين من فتح الـ PR، آلية، تمسك الأخطاء الواضحة (null checks، SQL injection، N+1 queries)، وتسيب السينيور للـ trade-offs المعمارية بس.

هنا الـ workflow الكامل لمراجع آلي بـ Claude Opus 4.7 جوا GitHub Actions، التكلفة الفعلية لكل PR، الـ trade-offs الحقيقية، وإمتى الطريقة دي متنفعش أصلاً.

شاشة تعرض كود Pull Request مع تعليقات مراجعة آلية من GitHub Actions

المشكلة باختصار

في فرق كتير بتشتغل على monorepo أو مشروع متوسط (50K–200K سطر كود)، متوسط زمن انتظار المراجعة الأولى بيوصل 18 ساعة. الرقم ده من استطلاع DORA 2025 على فرق الـ mid-size. النتيجة: الـ PR بيبات مفتوح، الـ merge conflict بيزيد، والـ developer بيفتح 3 PRs متوازية علشان ميستناش — وده بيخبّص الـ context.

الحل اللي بتعرضه معظم الشركات هو "شيلة تاني reviewer" أو "branching policy أذكى". الطريقة دي بتفشل في الفرق اللي أقل من 8 مطوّرين، لأن مفيش bandwidth فعلاً.

الفكرة الأساسية: مراجع آلي قبل الإنسان، مش بدل الإنسان

قبل ما ندخل في الكود، خليني أوضح الفكرة بمثال بسيط جداً، عشان لو انت لسه مبتدئ في الـ CI/CD متضيعش.

مثال توضيحي للمبتدئين

تخيل إنك شغّال في مكتب بريد. كل يوم بيجيلك 100 خطاب، منهم 70 عليهم أخطاء واضحة (عنوان ناقص، طابع غلط، ظرف مقطوع). بدل ما الموظف الكبير يفتح الـ 100 خطاب بنفسه، في موظف مبتدئ بيعمل فرز أول: "الـ 70 دول فيهم مشاكل، رجّعهم للمرسِل، والـ 30 الباقيين عدّوا للمراجعة النهائية". الموظف الكبير بقى بيركّز على الحاجات الصعبة بس.

الـ Pull Request هو الخطاب. الـ GitHub Action هو الموظف المبتدئ. الـ Senior Developer هو الموظف الكبير. Claude Opus 4.7 هو عقل الموظف المبتدئ.

التعريف التقني الدقيق

GitHub Actions هو نظام CI/CD مدمج في GitHub بيسمح لك تكتب workflows بصيغة YAML تتشغّل على events معيّنة (push, pull_request, schedule). الـ workflow بيشتغل في runner (VM مؤقت)، وبياخد الـ environment variables والـ secrets من الـ repo settings. Claude API هو REST endpoint من Anthropic بيستقبل prompt + context وبيرجّع completion. الربط بينهم هو سكربت shell أو Node يستدعي الـ API من داخل الـ runner.

الـ Workflow الكامل — خطوة بخطوة

الأربع خطوات الأساسية اللي هنعملها:

  1. إنشاء ملف .github/workflows/claude-review.yml يتشغّل على pull_request.
  2. جلب الـ diff الخاص بالـ PR باستخدام gh pr diff.
  3. إرسال الـ diff لـ Claude Opus 4.7 مع system prompt محدد (هنشرحه تحت).
  4. نشر رد Claude كـ PR review comment عبر gh api.
رسم توضيحي لـ workflow في GitHub Actions يشغّل خطوات CI/CD بشكل متسلسل

الكود الفعلي

ده ملف الـ workflow كامل، قابل للنسخ مباشرة:

YAML

name: Claude Code Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
      contents: read
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Get PR diff
        id: diff
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          gh pr diff ${{ github.event.pull_request.number }} > pr.diff
          echo "size=$(wc -c < pr.diff)" >> $GITHUB_OUTPUT

      - name: Skip if diff too large
        if: steps.diff.outputs.size > 50000
        run: echo "Diff > 50KB, skipping AI review" && exit 0

      - name: Call Claude API
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          DIFF=$(cat pr.diff | jq -Rs .)
          curl -s https://api.anthropic.com/v1/messages \
            -H "x-api-key: $ANTHROPIC_API_KEY" \
            -H "anthropic-version: 2023-06-01" \
            -H "content-type: application/json" \
            -d "{
              \"model\": \"claude-opus-4-7\",
              \"max_tokens\": 2048,
              \"system\": \"You are a senior code reviewer. Focus ONLY on: null safety, SQL injection, N+1 queries, missing error handling, and obvious logic bugs. Ignore style. Be terse. If diff is fine, say exactly: LGTM.\",
              \"messages\": [{\"role\": \"user\", \"content\": $DIFF}]
            }" | jq -r '.content[0].text' > review.md

      - name: Post review comment
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          gh pr comment ${{ github.event.pull_request.number }} \
            --body-file review.md

اتنين Secrets بس محتاجهم في الـ repo: ANTHROPIC_API_KEY (من console.anthropic.com)، وGITHUB_TOKEN (موجود تلقائياً في كل workflow).

الـ System Prompt — القلب الفعلي للـ workflow

الفرق بين مراجع آلي مفيد ومراجع آلي بيضيّع وقت الفريق هو الـ system prompt. الـ prompt اللي فوق مقصّر لأغراض المقال، بس في production هتحتاج تحدد:

  • نطاق المراجعة: "ركز على الـ security + logic bugs، تجاهل الـ style لأن عندنا Prettier."
  • سياق المشروع: "ده Next.js 16 مع Postgres، الـ queries المفروض تعدي من Prisma فقط."
  • صيغة الإخراج: "كل ملاحظة في سطر واحد بالصيغة: file.ts:line — المشكلة — الإصلاح المقترح."
  • شرط الصمت: "لو مفيش مشاكل حقيقية، اكتب LGTM بس، ممنوع تعليقات تشجيعية."

التكلفة الحقيقية بالأرقام

متوسط حجم الـ diff في فرق الـ mid-size حوالي 400 سطر (≈ 8,000 token). Claude Opus 4.7 بتكلفة $15 / 1M input tokens و $75 / 1M output. الرد المتوسط حوالي 500 token.

  • Input cost: 8,000 × $15 / 1,000,000 = $0.12
  • Output cost: 500 × $75 / 1,000,000 = $0.0375
  • إجمالي لكل PR: ~$0.16

فريق بيفتح 200 PR شهرياً = ~$32 شهرياً. قارنها بتكلفة ساعة senior واحدة مهدورة في مراجعات سطحية ($50–$120). الـ ROI واضح لو الفريق فعلاً عنده bottleneck في المراجعة.

الـ Trade-offs — بتكسب إيه، بتخسر إيه

المكسب: أول feedback على الـ PR في أقل من 3 دقائق، تغطية ثابتة لـ 4–5 فئات bugs شائعة، وتحرير السينيور للقرارات المعمارية.

الخسارة: بتضيف dependency على Anthropic API (uptime ~99.9% بس لسه nodo واحد في الـ chain)، بتسرّب الـ diff بتاعك لخدمة خارجية (خطر لو الكود فيه IP حساس)، وبتخلق توقع عند الـ junior devs إن الأداة هتشوف كل حاجة — وده مش صحيح. Claude هيفوّت bugs في الـ business logic المعقّد لأنه مش شايف الـ context الكامل للنظام.

متى لا تستخدم هذه الطريقة

فيه تلات حالات الـ automation دي بتبقى فيها مضيعة أو خطر:

  • كود بيمس بيانات regulated (healthcare, finance, defense): إرسال الـ diff لطرف ثالث بيخرق HIPAA / PCI-DSS. في الحالة دي استخدم self-hosted model (Llama 3 أو DeepSeek) بدل API خارجي.
  • فرق أقل من 3 مطوّرين: المراجعة الآلية بتضيف noise أكتر من القيمة لأن الـ PRs قليلة والسياق مشترك بين الكل.
  • PRs فيها auto-generated code (migrations, proto files, lock files): Claude هيولّد ملاحظات كتير على كود المفروض يتجاهل أصلاً. استثنيهم بـ paths-ignore في الـ workflow.

الخطوة التالية

انسخ الـ workflow اللي فوق في .github/workflows/claude-review.yml، ضيف الـ ANTHROPIC_API_KEY في Repo Settings → Secrets، افتح PR صغير (20–50 سطر) وشوف التعليق الأول. لو لقيت Claude بيعلّق على حاجات مش مهمة (whitespace, naming)، عدّل الـ system prompt وضيف قواعد أوضح على "إيه اللي يتجاهل". الإعداد الصحيح ياخد 2–3 PRs تجريبية قبل ما يبقى production-ready.

مصادر

  • Anthropic API Documentation — docs.anthropic.com/en/api/messages
  • Anthropic Model Pricing — anthropic.com/pricing
  • GitHub Actions Documentation — docs.github.com/en/actions
  • GitHub CLI Manual (gh pr diff, gh pr comment) — cli.github.com/manual
  • DORA State of DevOps Report 2025 — dora.dev/research
]]>

هل استفدت من المقال؟

اطّلع على المزيد من المقالات والدروس المجانية من نفس المسار المعرفي.

تصفّح المدونة