متى تُستعمل: "Use to draft an Arabic feature spec (PRD) from an owner's request, report or idea: problem, goals, explicit non-goals, user stories, P0/P1/P2 requirements with acceptance criteria, measurable success, open questions. Output is a DRAFT only. استخدمها عند «اكتب مواصفة»، «حوّل هذا البلاغ/الفكرة إلى مواصفة»، «ما خارج النطاق؟»، «معايير القبول» — ولو لم تُذكر. ليست لـ: إنشاء بطاقة (ledger.py)، التنفيذ، الخارطة، القرارات الحاكمة."

كتابة مواصفة بالعربية (مسوّدة)

الضوابط الستّة — إلزاميّة، وتسبق كلّ خطوة

1. المخرج مسوّدةٌ فقط: نصٌّ يُعرض على صاحب القرار؛ لا يُعتمد ولا يُنفَّذ ولا يُعامَل أمراً.
2. لا ledger.py add: لا تُنشأ بطاقةٌ ولا يُحرَّك الدفتر بهذه المهارة.
3. لا كتابةَ في الخارطة (/roadmap/ وهجراتها) ولا في أيّ سجلٍّ حيّ.
4. لا بطاقةَ بلا أمر المالك: من يرغب بتحويل المسوّدة إلى عمل يعرضها على 0101، والبطاقةُ تُنشأ بأمر المالك وبمواصفة 0301 وحدها.
5. لا مواصفةَ في الجدول المدرسيّ ولا الصلاحيّات ولا الأمن: هذه قراراتٌ للمالك تُعرض عليه كما هي ولا تُصاغ تصميماً.
6. لا بياناتِ إنتاج ولا توصيلاتٍ خارجيّة: لا طلبَ بياناتٍ حقيقيّةٍ (أسماءُ طلبةٍ ومعلّمين) ولا أدواتٍ مربوطة؛ يُعمل بما قدّمه المستخدم في المحادثة فقط.

الخطوات

1. افهم الطلب: اسم الميزة أو نصّ المشكلة أو بلاغ المالك. اطلب أهمّ ما ينقص أوّلاً، وسؤالاً أو اثنين في المرّة؛ ولا تسأل عمّا يُستنتج من السياق.
2. اجمع السياق من المستخدم: المشكلةُ ومن يعانيها، المستخدمون المستهدَفون، كيف نعرف أنها نجحت، القيود (مدّة، اعتماديّات، أنظمة)، وهل جُرّب حلٌّ سابق.
3. اكتب المواصفة بهذه الأقسام:
   • المشكلة: جملتان أو ثلاث: من المتضرّر وكم مرّة وما كلفة تركها، مع الدليل إن وُجد.
   • الأهداف: من 3 إلى 5 نتائج قابلة للقياس (نتيجة لا مُخرَج: «يقلّ زمن التسجيل إلى النصف» لا «بناء شاشة»).
   • خارج النطاق: من 3 إلى 5 بنود، لكلٍّ سببٌ موجز. هو أهمّ قسمٍ يمنع عودة ملاحظات المالك.
   • قصص المستخدم: «بصفتي [دور محدّد] أريد [قدرة] لكي [فائدة]»، مرتّبةً بالأهمّية، وتشمل الحالات الحدّيّة (فراغ، خطأ).
   • المتطلّبات: P0 (لا إطلاقَ بدونها)، P1 (تحسّن كبير ويُلحق سريعاً)، P2 (لا تُبنى الآن لكن يُراعيها التصميم). لكلّ متطلّبٍ وصفٌ واضح ومعايير قبول.
   • مقاييس النجاح: مؤشّرات سريعة (أيام) وبطيئة (أسابيع)، لكلٍّ هدفٌ رقميّ وطريقةُ قياس وموعد تقييم.
   • أسئلة مفتوحة: لكلٍّ منها من يجيب (المالك، الهندسة، التصميم، الامتثال)، وهل هو معطِّل للبدء.
   • اعتبارات الزمن: مواعيد ثابتة واعتماديّات وتقسيم إلى مراحل إن كبر الحجم.
4. راجع مع المستخدم: هل يحتاج قسمٌ تعديلاً؟ واعرض التوسّع في قسمٍ بعينه.

معايير القبول

اكتبها «بافتراض… عندما… فإنّ…» أو قائمةَ فحص. غطِّ المسار السليم والخطأ والحالة الحدّيّة، وما لا يجب أن يحدث. كلّ معيارٍ قابلٌ للاختبار وحده؛ وتجنّب «سريع» و«سهل» بلا تعريف رقميّ.

ضبط النطاق

• كلّ إضافةٍ بعد الاعتماد تأتي بحذفٍ مقابل أو تمديد؛ وإلا فهي زحفُ نطاق.
• فصل «الآن» عن «لاحقاً» صراحةً؛ وما لا يخدم المشكلة الأصليّة يُنقل إلى «خارج النطاق».
• إن كبرت الفكرة فاقترح تقسيمها واكتب مواصفة المرحلة الأولى فقط.
• كن حاسماً في الأولويّة: إن كان كلّ شيءٍ P0 فلا شيءَ P0.

الإخراج

Markdown بعناوين واضحة، يُقرأ من العناوين والخط الغليظ وحدها. يُنهى بسطر: «مسوّدة — لا تُنشأ بطاقةٌ منها إلا بأمر المالك عبر 0301».