Stats
Actions
Tags
How this skill is triggered — by the user, by Claude, or both
Slash command
/lead-intelligence:communicationThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
---
S — Situation: "في اجتماع Refinement أمس..."
B — Behavior: "لاحظت أنك قاطعت QA 3 مرات..."
I — Impact: "هذا جعل QA يتوقف عن المشاركة."
Intent: "أريد أن أفهم وجهة نظرك."
❌ لا تقل: "أنت دائماً تسيطر على الاجتماعات"
✅ قل: "في اجتماع أمس، لاحظت أن QA لم يكمل أفكاره ثلاث مرات، وأثّر هذا على مشاركة الفريق"
C — Context: اذكر السياق بدقة وبدون حكم
O — Observation: ما رأيته أو سمعته بالضبط
I — Impact: ما أثره على الفريق / المشروع / الشخص
N — Next: ماذا تريد أن يحدث بعد ذلك
مثال — Dev يرسل Code بدون Review:
C: "في آخر 3 Sprints..."
O: "لاحظت أن 4 PRs مُرسلة للـ Merge مباشرة بدون Approval"
I: "هذا أدى لـ Bug في Production الأسبوع الماضي وأخّرنا يوماً كاملاً"
N: "أريد نفهم لماذا يحدث هذا، وكيف نمنع تكراره"
قاعدة: Management يتحرك بـ 3 أشياء فقط:
1. البيانات التي تؤثر على أهدافهم
2. المخاطر التي يخشونها
3. الحلول الجاهزة — لا المشاكل فقط
إطار رسالة لـ Management:
┌─────────────────────────────────────────────┐
│ الوضع الحالي: [خبر واحد بالأرقام] │
│ التأثير على الهدف: [ربطه بأولويتهم] │
│ الخيارات: A / B / C [مع trade-offs] │
│ توصيتي: [خيار واحد + سببه] │
│ ما أحتاجه منك: [طلب محدد وقابل للتنفيذ] │
└─────────────────────────────────────────────┘
مثال:
"Sprint Velocity انخفضت 30% (الوضع).
هذا سيؤثر على موعد التسليم Q2 (التأثير).
عندنا 3 خيارات: نضيف Dev، نقلص الـ Scope، أو نؤجل Release.
أوصي بتقليص الـ Scope في Feature X لأنها أقل أولوية.
أحتاج موافقتك اليوم حتى نعدّل الخطة مع PO."
النمط 1: الشخص الدفاعي
───────────────────────
السلوك: يفسر كل Feedback كهجوم
التقنية: Validate أولاً، ثم اطرح السؤال
"أنا واضح إنك بذلت جهداً كبيراً في هذا.
ولدي سؤال — ما الذي كان يمكن أن يكون أفضل؟"
النمط 2: الصامت في الاجتماعات
────────────────────────────────
السلوك: لا يتكلم في المجموعة، لكنه يتذمر خارجها
التقنية: اسأله مباشرة + أعطِه وقتاً للتفكير
"أحمد، أنت الأقرب لهذا الموضوع — ما رأيك؟"
أو: "خليكم تفكروا دقيقتين وبعدين نشارك"
النمط 3: الـ Blocker — "مستحيل / لن يعمل"
──────────────────────────────────────────
السلوك: يرفض كل مقترح بدون بديل
التقنية: اسأل عن الشرط لا عن الاتفاق
"ما الذي يحتاج أن يتغير حتى يصبح ممكناً؟"
النمط 4: الـ People Pleaser
────────────────────────────
السلوك: يوافق على كل شيء ثم لا يُنفّذ
التقنية: احصل على التزام محدد + موعد
"رائع. بالضبط ماذا ستفعل؟ ومتى ستنتهي؟"
النمط 5: الخبير المتعجرف
──────────────────────────
السلوك: يرفض آراء الآخرين بسبب "خبرته"
التقنية: استخدم خبرته، لا تتحداها
"خبرتك في هذا مهمة. كيف تقترح أن نحل X؟"
البشر يتذكرون القصص — لا الأرقام.
إطار Data Storytelling:
1. الشخصية: "الفريق / العميل / المشروع"
2. التحدي: "واجهنا X"
3. البيانات: "الأرقام تظهر Y"
4. القرار: "لذلك قررنا Z"
5. النتيجة: "وحققنا W"
بدلاً من: "Velocity انخفضت من 45 إلى 30"
قل: "كان الفريق ينجز 45 نقطة — ما يكفي لتسليم Feature X في الموعد.
في Sprint الأخير وصلنا 30 — والفجوة الـ 15 نقطة تعني تأخيراً بأسبوعين.
السبب: 3 Stories دخلت Sprint بدون DoR واضح.
الحل الذي طبقناه: Three Amigos في كل Refinement.
النتيجة المتوقعة: عودة الـ Velocity في Sprint القادم."
5 سلوكيات تبنيه فوراً:
1. اعترف بعدم معرفتك أولاً
"لا أعرف الإجابة — من يعرف أكثر مني هنا؟"
2. اشكر الأخطاء علناً
"شكراً لرفعك هذا Bug مبكراً — هذا أنقذنا"
3. اسأل عن الرأي بدل الأمر
"ما رأيكم قبل أن أشارككم فكرتي؟"
4. تحمّل المسؤولية عن أخطاء الفريق للخارج
أمام Management: "هذا قصور في التخطيط — مسؤوليتي"
للداخل: "ما الذي يمكننا تحسينه معاً؟"
5. افصل بين الشخص والفكرة
"هذه الفكرة لا تناسب السياق الحالي"
لا: "هذه فكرة غير ناضجة"
npx claudepluginhub devmuslim/pdm-skills --plugin lead-intelligenceBlocks Edit/Write/Bash actions until Claude investigates importers, data schemas, and user instructions. Improves output quality by forcing concrete facts before edits.