npx claudepluginhub devmuslim/pdm-skills --plugin product-mindsetThis skill uses the workspace's default tool permissions.
```
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.
Analyzes BMad project state from catalog CSV, configs, artifacts, and query to recommend next skills or answer questions. Useful for help requests, 'what next', or starting BMad.
المعلومة موجودة — لكنها تموت في الطريق.
BA يعرف: لماذا هذا الـ Feature مهم
PM يعرف: ما أولويات العميل
Dev يعرف: كيف يُبنى
لكن الثلاثة يعيشون في عوالم منفصلة.
النتيجة: Dev ينفذ بدون سياق — أو يسأل وقت غلط.
الأسباب الشائعة في الفرق:
1. BRD مكتوب للـ BA — لا للـ Dev
→ مليء بمصطلحات business، خالٍ من سياق تقني
2. السياق يُشرح شفهياً في Refinement
→ يُنسى في اليوم التالي
3. "Dev لا يحتاج يعرف لماذا — فقط كيف"
→ ثقافة تُقتل فيها الـ Product Thinking
4. BA يكتب للـ System — Dev يبني للـ User
→ فجوة في الفهم من البداية
كل Story يجب أن تحمل Context Card:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🎯 CONTEXT CARD — [اسم الـ Story]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
👤 المستخدم الحقيقي:
الاسم/الدور: [مثال: سارة — مديرة عقود]
يومه الآن: [كيف يعيش المشكلة يومياً؟]
😣 المشكلة التي يعيشها:
[جملتان بحد أقصى — بلغة إنسانية لا تقنية]
✅ كيف سيتغير يومه بعد هذه الـ Story:
[ماذا سيستطيع يفعل لم يكن يستطيعه قبل؟]
🔗 السياق التجاري:
[لماذا هذا مهم للـ Business الآن؟]
📊 مقياس النجاح:
[رقم واحد نعرف به أننا نجحنا]
⚠️ الافتراض الأكثر خطورة:
[ما الذي إذا كان خاطئاً يفشل كل شيء؟]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
من يكتبها: BA أو PM
متى: قبل Refinement بيوم على الأقل
أين تُحفظ: في Jira Ticket (Description أو Custom Field)
من يراجعها: Tech Lead يتأكد أنها واضحة للـ Dev
القاعدة: إذا Dev لا يستطيع شرح "لماذا نبني هذا"
بعد قراءة الـ Ticket — الـ Context Card ناقصة
الـ Three Amigos التقليدي:
BA + Dev + QA يتفقون على الـ AC
الـ Three Amigos بعقلية Product:
نفس الثلاثة + سؤال إضافي في البداية:
"قبل ما نتكلم عن الـ AC —
من هو المستخدم الذي سيستخدم هذا؟
ما المشكلة التي يحلها؟
كيف نعرف أننا نجحنا؟"
هذا السؤال وحده يغير طبيعة النقاش كاملاً.
القناة 1 — Context Card في كل Ticket (دائم)
القناة 2 — "Story Intro" في أول دقيقتين من Refinement
BA يشرح: من المستخدم؟ ما مشكلته؟
قبل أي حديث تقني
القناة 3 — User Quote حقيقي في الـ Ticket
"المستخدم قال: '...'" — جملة واحدة تكفي
القناة 4 — Sprint Goal مكتوب بلغة المستخدم
لا: "إنهاء Feature X و Y"
نعم: "سارة ستستطيع تعديل عقد في 3 دقائق"
القناة 5 — Review Demo من منظور المستخدم
لا: "بنينا زر الحفظ"
نعم: "سارة الآن تستطيع..."
الأسبوع 1-2: Context Card في Story واحدة فقط
→ اختبر الفكرة بأمان
الأسبوع 3-4: كل Story جديدة تحمل Context Card
→ BA يبدأ يكتبها بشكل عفوي
الشهر 2: Three Amigos يبدأ بالسؤال عن المستخدم
→ Dev يبدأ يسأل "لماذا" بشكل طبيعي
الشهر 3: Sprint Goal يُكتب بلغة المستخدم
→ الفريق كله يفكر بالـ Outcome
علامة النجاح الأولى:
Dev يرفض تقدير Story لأن Context ناقص
إذا كان knowledge-base مفعّلاً:
/index-brd يحفظ السياق التجاري
Context Card تُشير له: "BRD-XXX القسم 3.2"
هذا يعني: Dev يستطيع يقرأ السياق كاملاً
بدون أن يُزعج BA في كل مرة