سير العمل والأتمتة

Claude Code بيتحوّل من مساعد تفاعلي لعضو فعلي في الفريق لما توصّله ببنية الأتمتة بتاعتك. الموديول ده بيغطي تكامل CI/CD، المهام المجدولة، تكامل GitHub Actions، وأنماط بناء سير عمل أتمتة موثوقة.

تكامل CI/CD مع التشغيل البرمجي

الـ flag claude -p هو أساس تكامل CI/CD. بيشغّل Claude بدون تفاعل، بيبعت prompt، وبيرجّع النتيجة على stdout. ادمجه مع --output-format json عشان output منظّم قابل للتحليل، و--permission-mode bypassPermissions للتشغيل الآلي الكامل (بدون أي طلبات موافقة)، و--max-turns عشان تحدد وقت التنفيذ.

نمط شائع هو تشغيل Claude كجزء من عملية مراجعة الـ PR. ضبطه كخطوة في GitHub Actions:

- name: Claude Code Review
  run: |
    DIFF=$(git diff origin/main...HEAD)
    REVIEW=$(echo "$DIFF" | claude -p "Review these changes. Output JSON with fields: summary, critical_issues, suggestions" \
      --output-format json \
      --permission-mode bypassPermissions)
    echo "$REVIEW" | jq '.critical_issues[]' >> $GITHUB_STEP_SUMMARY

الـ flag --from-pr بيفتح الـ session picker مفلتر على جلسات مرتبطة بـ pull request محدد. الـ sessions بتتربط تلقائيًا لما Claude يعمل الـ pull request. من v2.1.119، --from-pr بيقبل رقم PR، أو رابط GitHub أو GitHub Enterprise PR، أو رابط GitLab merge request، أو رابط Bitbucket pull request:

claude --from-pr https://github.com/org/repo/pull/123
claude --from-pr https://gitlab.com/org/repo/-/merge_requests/456
claude --from-pr https://bitbucket.org/org/repo/pull-requests/789

للأتمتة اللي بتستخدمها مرة واحدة، Claude يقدر يولّد tests لكود جديد، يحدّث الـ documentation لما الـ APIs تتغيّر، يشغّل linters ويصلّح المشاكل تلقائيًا، أو يفحص ثغرات أمنية. استخدم --no-session-persistence عشان ما يحفظش جلسة. استخدم --bare عشان تقلّل وقت البدء في الـ CI scripts — بيتخطّى auto-discovery للـ hooks وskills والـ custom commands والـ subagents والـ plugins والـ MCP servers والـ auto memory والـ CLAUDE.md، فبس الـ flags والـ settings اللي تمررها صراحة بتأثّر. الفائدة الأساسية هي بدء أسرع وقابل للتكرار، مش output أنظف.

استخدم prUrlTemplate (جديد في v2.1.119) عشان توجّه الـ footer PR badge لرابط مراجعة كود مخصص بدل رابط github.com الافتراضي — مفيد لـ enterprise deployments اللي عندها GitHub داخلي أو أدوات مراجعة مخصصة:

{
  "prUrlTemplate": "https://review.example.internal/pr/{number}"
}

أمر /install-github-app بيعمل setup للتكامل الرسمي مع GitHub، واللي بيخلّي Claude يرد على منشنات @claude في تعليقات الـ PR والـ issues.

الإشعارات الفورية على الموبايل (Mobile Push Notifications)

لما الـ Remote Control مفعّل، Claude يقدر يبعت إشعارات فورية على موبايلك. Claude بيقرر إمتى يبعت — عادةً لما مهمة طويلة تخلص أو لما يحتاج قرار منك عشان يكمّل. كمان ممكن تطلب واحد في الـ prompt: notify me when the tests finish. الإعداد محتاج تطبيق Claude على الموبايل (iOS أو Android)، مسجّل بنفس الحساب، وPush when Claude decides مفعّل في /config. غير زر التفعيل والإيقاف، مفيش ضبط لكل حدث على حدة. محتاج Claude Code v2.1.110+.

لمراقبة الـ PRs التلقائية، /autofix-pr بيعمل جلسة Claude Code على الويب بتراقب PR الـ branch الحالي. لما CI يفشل أو reviewer يعلّق، Claude بيحقق ويدفع fix. حدد النطاق بـ prompt: /autofix-pr only fix lint and type errors. محتاج Claude GitHub App يكون متثبّت على الريبو، access لـ Claude Code على الويب، ومش متاح للمؤسسات الليفعّلوا Zero Data Retention.

/ultrareview (أُضيف في v2.1.111) بيعمل مراجعة شاملة للكود في cloud باستخدام analysis وcritique من multi-agent متوازية. محتاج تسجيل دخول بـ Claude.ai — لو مسجّل بـ API key بس، شغّل /login الأول. بيشتغل على بنية Claude Code على الويب. استدعيه من غير arguments عشان تراجع الـ branch الحالي، أو /ultrareview <PR#> عشان تجيب وتراجع PR محدد من GitHub. Pro/Max بياخدوا ٣ runs مجانية لمرة واحدة (مخصصة مرة واحدة لكل حساب، مبتتجددش)، وبعدين كل مراجعة بتكلف تقريبًا $٥–$٢٥ كـ usage credits. Team/Enterprise مفيش ليهم runs مجانية وبيتحسبوا كـ usage credits. الـ usage credits لازم تكون مفعّلة على الحساب — لو معطّلة، Claude Code هيمنع التشغيل؛ لو عندك صلاحية إدارة الـ billing هيوديك لرابط إعدادات الـ billing، وعلى خطط Team/Enterprise الأعضاء اللي مالهمش صلاحية billing بيبعتوا طلب من الـ CLI للأدمن عشان يفعّل الـ usage credits. استخدم /tasks عشان تتابع المراجعات اللي شغّالة واللي خلصت، تفتح تفاصيل مراجعة، أو توقف مراجعة في الطريق (التوقيف بحفظ الجلسة السحابية؛ النتائج الجزئية مبتتنزلش). افتراضيًا المراجعة مبتنشرش حاجة — --no-post هو الـ default. لما تراجع PR على github.com، مرّر --post (أُضيف في v2.1.227) عشان Claude ينشر الـ findings النهائية على الـ PR ده كتعليق واحد عادي من حساب GitHub بتاعك (بينتهي بملاحظة “Generated by Claude Code” ومش مراجعة ولا موافقة). في تشغيل تفاعلي، --post بيختار مقدمًا خيار “انشر الـ findings باسمي” وبرضه Claude Code بيسأل قبل ما يبدأ؛ في التشغيل غير التفاعلي، claude ultrareview <PR#> --post بينشر من غير سؤال. النشر بينطبق بس على أهداف الـ PR على github.com — مراجعات الـ branch وPRs الخاصة بـ GitHub Enterprise Server بتعرض الـ findings في جلستك بس. راجع الوثائق الرسمية عشان تتأكد من توافر /ultrareview على منصتك.

ومنذ v2.1.309، claude ultrareview بيحتاج الـ folder يكون موثوق. لما ماقدرش يسألك تثق فيه — زي في CI مثلًا — بيخرج بـ Error: Workspace not trusted. في طريقتين للتعامل مع الموقف ده. الأول: مرّر --trust-workspace عشان تثق في الـ folder الحالي لتلك الـ run بس، من غير ما يسأل، فتقدر script أو CI job تراجع checkout ماوثقتهوش؛ الـ flag ده مابيسحبش أي قيمة، فحط رقم الـ PR أو الـ base branch قبله — زي claude ultrareview 456 --trust-workspace. التاني: اضبط CLAUDE_CODE_DISABLE_ULTRAREVIEW_TRUST_CHECK=1 عشان claude ultrareview مايخرجش بالـ error ده لما ماقدرش يسألك تثق في الـ folder — اضبطه في الـ environment اللي بيشغّل Claude Code، مش في بلوك env جوه الـ settings، وفي المكان ده بس لو كل run من الـ runs دي بيبدأ في folder تثق فيه. الـ runs اللي تقدر تسأل بتفضل تسأل. الاتنين محتاجين Claude Code v2.1.309 أو أحدث.

/ultrareview           # راجع الـ branch الحالي
/ultrareview 456       # راجع PR #456 من GitHub

الـ Self-Hosted Runner

طيب، claude self-hosted-runner بيشغّل أتمتة Claude Code على بنية تحتية أنت بتتحكم فيها بدل الـ cloud المُدار. الـ runner بيستطلع عن jobs، ينفّذها في workspace، ويرجّع النتائج — مفيد لما تحب الـ workspace بتاع التنفيذ يبقى على hosts عندك. ده مش بيغيّر إزاي Claude نفسه بيشتغل: الموديل والـ control plane لسه بره، ونتائج الـ tools ممكن تحتوي على كود أو secrets، فـ ده مش ضمان لـ data residency.

افتراضيًا الـ runner بيسجّل نفسه بـ hostname الجهاز كـ client label. استخدم --client-label <label> (أو اعمل set لـ SELF_HOSTED_RUNNER_CLIENT_LABEL) عشان تغيّر الـ label ده، فتقدر تفرّق بين أكتر من runner على نفس الـ host حسب الدور — واحد لـ production jobs، واحد لـ staging، أو هويات حسب الـ tenant ورا hostname مشترك:

# سجّل runner بـ label مخصوص بالدور
claude self-hosted-runner --client-label prod-runner-01

# نفس التأثير من خلال الـ env var، مفيد لوحدات systemd أو entrypoints الـ containers
SELF_HOSTED_RUNNER_CLIENT_LABEL=staging-runner claude self-hosted-runner

استخدم --remove-session-state (اتضاف في v2.1.268، مقفول افتراضيًا) عشان تمسح مجلدات كل جلسة تحت <base-dir>/_sessions/ لما الجلسة تخلص، فالـ runner اللي شغّال لفترة طويلة ما يفضلش يكوّم state قديم بين الـ jobs. اعمل set لـ SELF_HOSTED_RUNNER_REMOVE_SESSION_STATE عشان نفس التأثير من وحدة systemd أو entrypoint بتاع container:

# امسح state كل جلسة لما الجلسة تخلص
claude self-hosted-runner --remove-session-state

# نفس التأثير من خلال الـ env var
SELF_HOSTED_RUNNER_REMOVE_SESSION_STATE=1 claude self-hosted-runner

استخدم --drain-marker-file <path> (اتضاف في v2.1.271) عشان تتحكم في إزاي الـ runner بيبلّغ الـ server عن الـ shutdown بتاعه: لما الـ file ده موجود عند drain من SIGTERM، الـ runner بيبعت خروجه للـ server كـ host drain (telemetry بس). الـ env var الموازي SELF_HOSTED_RUNNER_DRAIN_MARKER_FILE بيخلّي نفس الـ flag ده يتضبط من وحدة systemd أو entrypoint بتاع container:

# قول للـ server إن الخروج ده كان host drain متعمّد، مش crash
claude self-hosted-runner --drain-marker-file /var/lib/claude-runner/drain

# نفس التأثير من خلال الـ env var
SELF_HOSTED_RUNNER_DRAIN_MARKER_FILE=/var/lib/claude-runner/drain claude self-hosted-runner

استخدم --host-config-snapshot disk|memory (اتضاف في v2.1.271) عشان تختار الـ runner بيحتفظ فين بـ snapshot بداية التشغيل للـ host config (settings، skills، plugins، MCP servers) اللي بيغذّي منه كل session. الـ default disk بينسخ الـ snapshot في مجلد مملوك للـ runner تحت --base-dir وبيتحقّق من كل ملف مقابل digest في الذاكرة في بداية كل session، فأي ملف اتعدّل بيفشّل الـ session والـ runner بيرفض أي sessions تانية لحد ما تعيد تشغيله. وmemory بيحتفظ بالـ snapshot كله في الـ heap بحد أقصى 64 MiB — فوق الحد ده الـ sessions بتبدأ من غير host config وبتعرض إشعار — والـ runner كمان بيرجع لـ memory في التشغيلة لو ما قدرش يكتب snapshot الـ disk. الـ env var الموازي SELF_HOSTED_RUNNER_HOST_CONFIG_SNAPSHOT بيعمل نفس الحاجة من وحدة systemd أو entrypoint بتاع container:

# اعمل in-memory snapshot قسريًا (من غير cache على الـ disk بعد البدء)
claude self-hosted-runner --host-config-snapshot memory

# نفس التأثير من خلال الـ env var
SELF_HOSTED_RUNNER_HOST_CONFIG_SNAPSHOT=memory claude self-hosted-runner

استخدم --hold-idle-file <path> (اتضاف في v2.1.311) عشان تبقي الجلسة idle على الـ runner لحد ما العمليات اللي خلّفتها على الـ host تخلص: الـ host بيفضل يغيّر الملف ده، والـ runner بيحتجز الجلسة بدل ما يسيبها. المسار مش مضبوط افتراضيًا. الـ env var الموازي SELF_HOSTED_RUNNER_HOLD_IDLE_FILE بيحط نفس المسار من وحدة systemd أو entrypoint بتاع container:

# الـ host بيلمس الملف ده طول ما العمليات اللي خلّفها لسه شغّالة
claude self-hosted-runner --hold-idle-file /var/lib/claude-runner/hold-idle

# نفس التأثير من خلال الـ env var
SELF_HOSTED_RUNNER_HOLD_IDLE_FILE=/var/lib/claude-runner/hold-idle claude self-hosted-runner

استخدم --max-hold-min <n> (اتضاف في v2.1.311) عشان تحدّ سقف الحجز ده: مع --hold-idle-file، الـ runner بيسيب الجلسة المحتجزة على أي حال بعد N دقيقة من ما بقيت idle. أي قيمة أقل من أو زي --release-idle-session-min مابتستحجزش حاجة، و0 بيقفل الحجز. الـ default 1440 دقيقة. الـ env var الموازي SELF_HOSTED_RUNNER_MAX_HOLD_MS بيحط نفس السقف بالـ milliseconds من وحدة systemd أو entrypoint بتاع container:

# احجز الجلسة idle، بس سيبها بعد 4 ساعات بالكتير من ما بقيت idle
claude self-hosted-runner \
  --hold-idle-file /var/lib/claude-runner/hold-idle \
  --max-hold-min 240

# نفس التأثير من خلال الـ env vars
SELF_HOSTED_RUNNER_HOLD_IDLE_FILE=/var/lib/claude-runner/hold-idle \
  SELF_HOSTED_RUNNER_MAX_HOLD_MS=14400000 \
  claude self-hosted-runner

المهام المجدولة والـ Routines والأتمتة في الخلفية

Claude Code بيدعم طبقات جدولة متعددة. /loop بيعمل فحوصات متكررة داخل الجلسة طول ما Claude Code شغّال. الـ Routines هي مهام مجدولة في الـ cloud بتفضل شغّالة مستقلة عن الـ terminal المحلي — كل run بيعمل clone جديد للريبو، يشتغل لوحده، ويقدر يعمل push لـ branches أو يفتح PRs.

# فحص حالة البناء كل 5 دقائق (داخل الجلسة)
/loop 5m check if the build succeeded and summarize any failures

# إنشاء routine سحابي من الـ CLI
/schedule "run a full security audit at 2am"
/schedule daily PR review at 9am

الـ Routines

الـ routine هو إعداد Claude Code محفوظ — prompt وريبو واحد أو أكتر ومجموعة connectors — بيتحزم مرة واحدة ويشتغل تلقائيًا على بنية Anthropic التحتية المُدارة. أنشئهم وأدِرهم من الويب على claude.ai/code/routines، أو من الـ Desktop app، أو عبر /schedule في الـ CLI. استخدم /schedule list لعرض كل الـ routines، و/schedule update لتعديل واحد، و/schedule run لتشغيل واحد فورًا.

لما تنشئ routine أو تعدّله بيشتغل في الـ cloud، اختار الموديل اللي Claude هيفضل يستخدمه في كل تشغيل من model selector الموجود في prompt input. لو الموديل بيقدّم effort levels، فـ Effort في نفس الـ selector بيعرض المستوى الحالي — واختار مستوى تاني عشان تغيّره. خيار Default في الـ selector مابيقدّمش أي مستويات.

كل routine ممكن يكون عنده أكتر من trigger مع بعض:

• مجدول — تكرار دوري (كل ساعة، يومي، أيام العمل، أسبوعي) أو تشغيل لمرة واحدة في وقت محدد. التشغيل لمرة واحدة بيتحسب من نفس الحد الساعي بتاع التشغيلات المجدولة التانية (100 تشغيل مجدول في الساعة، والتشغيل لمرة واحدة منهم). cron expressions مخصصة متاحة عبر /schedule update (أقل فاصل: ساعة).
• API — endpoint HTTP مخصص لكل routine. ابعت POST بـ bearer token عشان تشغّل run، مع إمكانية تمرير سياق في حقل text. وصّله بأنظمة التنبيه أو pipelines النشر أو الأدوات الداخلية.
• GitHub — بيتفاعل مع أحداث الريبو زي pull requests أو releases. الفلاتر بتخلّيك تضيّق حسب المؤلف والعنوان والـ labels والـ base/head branch وحالة الـ draft وغيرها. محتاج Claude GitHub App متثبّت على الريبو.

الـ routines بتشتغل كجلسات Claude Code سحابية كاملة من غير أي permission prompts. بتقدر تستخدم الـ MCP connectors المتوصلة بتاعتك (مضافة افتراضيًا — شيل اللي مش محتاجها) وبتتحدد بالريبوهات اللي اخترتها وصلاحيات الشبكة في البيئة السحابية والـ connectors. افتراضيًا، Claude بيعمل push على branch بتبدأ بـ claude/ إلا لو الـ prompt بتاعك وجّهه لفرع تاني. تتحكم في الـ branches اللي الـ run يقدر يعمل push عليها عن طريق branch protection rules أو rulesets على GitHub.

الـ routines متاحة على خطط Pro وMax وTeam وEnterprise مع تفعيل Claude Code على الويب. Owners في Team وEnterprise يقدروا يعطّلوا الـ scheduled tasks لكل الأعضاء عبر toggle Scheduled tasks (Was Routines) في Organization settings > Capabilities > Remote sessions (claude.ai/admin-settings/capabilities). الـ API triggers بتتظبط من واجهة الويب بس — مش تقدر تضيف API trigger ولا تدير الـ token بتاعه من الـ CLI. والـ GitHub triggers ينفع تضيفها من الـ CLI كمان: نزّل Claude GitHub App من صفحة GitHub App الأول، وبعدين اطلب من Claude يربط GitHub trigger بـ scheduled task موجودة (محتاج Claude Code v2.1.225 أو أحدث). /schedule في الـ CLI بيعمل routines مجدولة.

الأتمتة في الخلفية

الـ subagents في الخلفية بـ background: true في الـ frontmatter بتاعهم بيشتغلوا من غير ما يعطّلوا المحادثة الرئيسية. ده بيخلّيك تبدأ تحليل طويل، تكمّل شغل تاني، وتتبلّغ لما يخلص. لو محتاج أتمتة حوالين شغل المتابعة، استخدم أحداث الـ hook الموثّقة: TaskCompleted لتغييرات حالة المهمة وTeammateIdle لما عضو في فريق الـ agents على وشك يبقى idle.

{
  "hooks": {
    "TaskCompleted": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "curl -X POST $SLACK_WEBHOOK -d '{\"text\": \"Task completed: $TASK_NAME\"}'"
          }
        ]
      }
    ]
  }
}

للأبحاث الطويلة اللي بتمتد على جلسات متعددة، الـ agents القابلة للاستئناف وسير عمل الذاكرة العادي أأمن. خلّي الـ agent يكتب نتائجه في الذاكرة أو ملفات المشروع، وبعدين استأنف الـ agent أو الجلسة بعدين لما تحتاج.

الـ Dynamic Workflows

بعد patterns الجلسات المفردة، Claude Code بيدعم dynamic workflows — ميزة في الـ research preview اتضافت في v2.1.154 بتخلّيك تنسّق من dozens لـ hundreds من subagents من script بلغة JavaScript بيكتبه Claude. على عكس /loop أو /batch اللي بيشتغلوا جوه محادثة واحدة، الـ workflow بينقل الخطة لـ script: الـ script هو اللي ماسك الـ loop والـ branching والنتائج الوسيطة، فـ context بتاع Claude يفضل فيه الإجابة النهائية بس.

عشان تشغّل workflow، حُط كلمة ultracode في أي مكان في الـ prompt بتاعك (الكلمة اللي بتفعّله اتسمّت من workflow لـ ultracode في v2.1.160؛ لو طلبت workflow بصياغتك الطبيعية لسه شغّال)، أو فعّل /effort ultracode عشان Claude يخطّط واحد لكل مهمة أساسية. Claude بيكتب orchestration script متفصّل على هدفك، وبعدين runtime بينفّذه في الخلفية والجلسة بتاعتك فاضلة شغّالة. الاستئناف (resume) بتشتغل جوه نفس جلسة Claude Code — لو خرجت من Claude Code وواحد workflow شغّال، الجلسة الجاية هتبدأ الـ workflow من جديد. الـ dynamic workflows بتنفع للـ audits على مستوى الـ codebase كله، والـ migrations الكبيرة، والبحث المُتحقّق منه، وأي مهمة محتاجة agents أكتر مما تقدر جلسة واحدة تنسّقه.

محتوى السكربت JavaScript عادي بـ top-level await. agent() بيشغّل subagent واحد، وpipeline() بيشغّل واحد على كل عنصر في list، وparallel() بيشغّل مجموعة agent tasks في نفس الوقت ويستنى كلهم لحد ما يخلصوا:

const files = ["src/auth.ts", "src/db.ts"];

const findings = await parallel(
  files.map((file) => agent(`Audit ${file} for secrets`))
);

قبل v2.1.305، الـ agents اللي خلصوا كانوا ممكن يركضوا تاني لما تعيد تشغيل سكربت من غير ما تعدّله، لو items الـ pipeline() أو tasks الـ parallel() بتاعته كانت كل واحدة فيها أكتر من agent؛ دلوقتي بيتخدموا من journal الـ run.

الـ workflow المدمج /deep-research <question> بيعمل أتمتة للبحث من مصادر متعددة: بينشر web searches على زوايا مختلفة، يجيب المصادر ويتحقق منها مع بعض، يعمل vote على كل claim، ويرجّع تقرير بـ citations مع شطب الـ claims اللي ما عدّتش التحقّق. محتاج الـ WebSearch tool يكون متاح:

/deep-research What changed in the Node.js permission model between v20 and v22?

شغّل /workflows عشان تشوف الـ workflows الشغّالة والمكتملة وتفتح progress view بيعرض لكل phase عدد الـ agents وإجمالي الـ tokens والوقت المنقضي. لما run يعمل اللي إنت عايزه، اختاره في الـ /workflows view واضغط s عشان تحفظ الـ script بتاعه كـ command — وبعدين بيشتغل كـ /<name> في الجلسات الجاية، جنب الـ workflows المدمجة. إعادة الاستخدام بتفيد في الشغل المتكرر زي مراجعة كود أسبوعية أو checklist إصدار.

/effort ultracode بيفعّل الـ orchestration التلقائي للـ workflows على مستوى الـ effort اللي الجلسة شغّالة بيه أصلًا — Claude بيحدد إمتى المهمة محتاجة workflow وبينسّق الـ agents من غير ما حد يطلب منه، من غير ما يرفع مستوى الـ effort نفسه. وعشان تبدأ الجلسة كمان على effort نوع xhigh، شغّل claude --effort ultracode (محتاج v2.1.203+). بيفضل شغّال للجلسة الحالية؛ وقّفه بـ /effort ultracode off للشغل الروتيني.

الـ dynamic workflows محتاجة Claude Code v2.1.154+ ومتاحة على كل الخطط المدفوعة (Pro، Max، Team، Enterprise). على Pro، فعّلها من صف Dynamic workflows في /config. عشان تعطّلها، اقفل Dynamic workflows من /config، أو اضبط "disableWorkflows": true في الإعدادات، أو اضبط CLAUDE_CODE_DISABLE_WORKFLOWS=1.

أنماط سير العمل متعدد الخطوات

أكتر سير عمل موثوق بيدمج skills و hooks و subagents في pipeline كل خطوة فيها عندها inputs واضحة، outputs، ومعالجة أخطاء.

نمط “طوّر وتحقق” (develop and verify) بيربط prompt hook من نوع Stop بيفحص معايير الإكمال مع skill التنفيذ. لما Claude يوقف، الـ hook بيقيّم لو كل المتطلبات اتحققت. لو لأ، بيقول لـ Claude إيه الناقص و Claude بيكمّل:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "prompt",
            "prompt": "Check: 1) Were all files in the spec modified? 2) Do tests pass? 3) Is the implementation complete per the requirements? If anything is incomplete, explain what remains.",
            "timeout": 30
          }
        ]
      }
    ]
  }
}

نمط “المراجعة المتوازية” (parallel review) بيستخدم Agent Teams (تجريبي، مقفول افتراضيًا — محتاج CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1) عشان متخصصين مختلفين يراجعوا في نفس الوقت. agent بيفحص الأمان، واحد تاني بيفحص الأداء، وواحد تالت بيفحص تغطية الـ tests. قائد الفريق بيجمّع نتائجهم في تقرير واحد. الـ Agent Teams عندها قيود معروفة حول استئناف الجلسات وتنسيق المهام وسلوك الإيقاف.

للمهام اللي بتعدّل ملفات كتيرة عبر الكود، /batch <instruction> بيخطط الشغل، بيقسّمه على agents في الخلفية في git worktrees منعزلة، ومصمّم للـ refactors الكبيرة أو التغييرات المتكررة. حسب سير العمل، ممكن كمان يشغّل خطوات تحقق ويساعد يفتح PRs للنتائج.

الـ git worktrees (isolation: worktree على الـ subagents) مفيدة كمان للشغل التجريبي. الـ agent بيعمل التغييرات في branch منعزل، بيرجّع مسار الـ worktree لما يخلص، وأنت بتراجع أو تلغي من غير ما تأثر على الـ working tree بتاعك.