مشاركة سياق مشروع Claude مع فريقك

يبني كل عضو في الفريق علاقته الخاصة مع Claude، ويعيد شرح نفس البنية والمعايير. عندما يغيب أحدهم، يبدأ من يحل محله من الصفر.

هذه هي الفجوة التي يسدّها إصدار اليوم. مهارة في مجال الأتمتة مبنية لـكلود، وتحتاج نحو عشر دقائق للإعداد أول مرة. بعدها تعمل في أقل من دقيقة.

لمن هذه المهارة

قادة الفرق الهندسية الذين يديرون فرقاً تستخدم Claude في مراجعة الأكواد أو تصحيح الأخطاء أو التوثيق

كيف تعمل

يقوم ملف المهارة بخمسة أمور، بهذا الترتيب.

1. أنشئ مجلد docs في المستودع. أضف مجلد /docs/ai-context/ إلى مستودعك الرئيسي بحيث يكون كل سياق الأوامر تحت نظام التحكم في الإصدارات.

2. وثّق حقائق المشروع لا التفضيلات الشخصية. اكتب التقنيات المستخدمة وهيكل المجلدات وأنماط التسمية وعقود API وعملية النشر التي تنطبق على الجميع.

3. أضف ملف أمثلة تطبيقية. أضف مثالين أو ثلاثة من المهام الفعلية التي أنجزها فريقك مع Claude، مع إظهار المدخلات والمخرجات المفيدة.

4. حدد دورة مراجعة. عيّن شخصاً واحداً في كل سبرنت لتحديث ملفات السياق عند تغيير البنية أو ظهور أنماط جديدة.

5. اكتب خطوة إعداد من ثلاثة أسطر. أضف تعليمات إلى ويكي فريقك: الصق ملف السياق في Claude Projects في بداية كل محادثة جديدة.

ما ستحصل عليه

مكتبة سياق تحت نظام التحكم في الإصدارات يستخدمها كل أعضاء الفريق، مما يقلل وقت الإعداد ويحافظ على اتساق إجابات Claude عبر الفريق

الخطأ الذي يجب تجنبه

احتفظ بأساليب الأوامر الشخصية في ملف منفصل خارج السياق المشترك. الملف المشترك يغطي الحقائق، والملف الشخصي يغطي تفضيلات الأسلوب وصيغة المخرجات.

طريقة التشغيل

احفظ الملف باسم SKILL.md داخل مجلد يحمل اسم المهارة، ثم ضع المجلد في مجلد المهارات لدى Claude Code أو ارفعه إلى مشروع في Claude. يقرأ كلود بيانات الرأس ليقرر متى تنطبق المهارة، لذا أبقِ سطر description كما هو. وللتشغيل لمرة واحدة، الصق نص الطلب مباشرة.

أين تندرج هذه المهارة

مهارة واحدة توفر ساعة أسبوعياً. لكن الأثر يتضاعف حين تعمل ثلاث أو أربع مهارات بالتتابع على المدخل نفسه، فالتفريغ الذي ينتج نطاق العمل ينتج أيضاً رسالة المتابعة وموجز المشروع. عند هذه النقطة تتوقف عن كونها طلباً وتصبح أداة داخلية. وإذا أردت ربط ذلك بالأنظمة التي يستخدمها فريقك فعلاً، فهذا ما تقوم به 67 Digital.

داخل الملف

You are working on {project_name}, a {brief_description}.

Stack and tools:
{list_of_technologies}

Repository structure:
{folder_layout_summary}

Naming conventions:
{variable_function_file_naming_rules}

API contracts:
{key_endpoints_or_interface_patterns}

Deployment:
{deployment_process_summary}

Current sprint focus:
{active_feature_or_refactor}

Team patterns we follow:
{code_review_checklist_or_style_decisions}

Recent example tasks:
1. {task_description}: {approach_taken}
2. {task_description}: {approach_taken}

When you generate code, follow these conventions. When you review code, check against these patterns. When you suggest architecture, respect this structure.

What would you like help with today?