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
للأتمتة اللي بتستخدمها مرة واحدة، Claude يقدر يولّد tests لكود جديد، يحدّث الـ documentation لما الـ APIs تتغيّر، يشغّل linters ويصلّح المشاكل تلقائيًا، أو يفحص ثغرات أمنية. استخدم --no-session-persistence عشان ما يحفظش جلسة، واستخدم --bare لما تحتاج أنظف output ممكن في الـ scripts.
أمر /install-github-app بيعمل setup للتكامل الرسمي مع GitHub، واللي بيخلّي Claude يرد على منشنات @claude في تعليقات الـ PR والـ issues. ده بيشغّل Claude في بيئة sandboxed مع access لسياق الـ PR.
المهام المجدولة والأتمتة في الخلفية
Claude Code بيدعم أنماط جدولة متعددة. /loop بيعمل فحوصات متكررة داخل الجلسة طول ما Claude Code شغّال. /schedule هو نقطة الدخول المحادثية للمهام المجدولة في الـ cloud اللي بتفضل شغّالة مستقلة عن الـ terminal المحلي. استخدمهم لمراقبة خدمات، توليد تقارير، أو صيانة دورية:
# Check build status every 5 minutes
/loop 5m check if the build succeeded and summarize any failures
# One-time scheduled task
/schedule "run a full security audit at 2am"
الـ 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 أو الجلسة بعدين لما تحتاج.
أنماط سير العمل متعدد الخطوات
أكتر سير عمل موثوق بيدمج 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 عشان متخصصين مختلفين يراجعوا في نفس الوقت. agent بيفحص الأمان، واحد تاني بيفحص الأداء، وواحد تالت بيفحص تغطية الـ tests. قائد الفريق بيجمّع نتائجهم في تقرير واحد.
للمهام اللي بتعدّل ملفات كتيرة عبر الكود، /batch <instruction> بيخطط الشغل، بيقسّمه على agents في الخلفية في git worktrees منعزلة، ومصمّم للـ refactors الكبيرة أو التغييرات المتكررة. حسب سير العمل، ممكن كمان يشغّل خطوات تحقق ويساعد يفتح PRs للنتائج.
الـ git worktrees (isolation: worktree على الـ subagents) مفيدة كمان للشغل التجريبي. الـ agent بيعمل التغييرات في branch منعزل، بيرجّع مسار الـ worktree لما يخلص، وأنت بتراجع أو تلغي من غير ما تأثر على الـ working tree بتاعك.