مواصفات ميزات Claude Code من الشفرة: سير عمل بسيط

لماذا تحتاج مواصفات تطابق الشفرة\n\nيختلف الناس حول ما يفعله التطبيق لأن كل واحد يتذكّر نسخة مختلفة منه. فريق الدعم يتذكّر آخر تذكرة غاضبة. فريق المبيعات يتذكّر مسار العرض. المهندسون يتذكّر ما كان المقصود أن تفعله الميزة. اسأل ثلاثة أشخاص وستحصل على ثلاث إجابات واثقة، ولا يتطابق أي منها مع النسخة الحالية.\n\nمع مرور الوقت، تصبح الشفرة المصدر الوحيد الذي يبقى محدثًا. الوثائق تنحرف، التذاكر تُغلق، والإصلاحات السريعة تتراكم. تُضاف قاعدة تحقق جديدة لمسار، يتغيّر الوضع الافتراضي لتبديل في الواجهة، يبدأ معالج بإرجاع أخطاء مختلفة. لا أحد يُحدّث المواصفة لأنها تبدو اختيارية، وكل تغيير يبدو صغيرًا جدًا لتوثيقه.\n\nهذا يخلق مشاكل متوقعة. الفرق تُصدر تغييرات تكسر حالات حافة لم يكونوا يعلمون بوجودها. قسم الاختبار يتقصى المسار السعيد ويفوته قواعد مدفونة في المعالجات. الزملاء الجدد يقلّدون السلوك من الواجهة دون فهم القيود الحقيقية. الأطراف المعنية تتجادل حول الآراء بدل الإشارة إلى سلوك متفق عليه.\n\nالنتيجة الجيدة ليست وثيقة مثالية، بل وضوح مشترك. يجب أن يكون بإمكان أي شخص الإجابة عن: "ماذا يحدث إذا فعلت X؟" و"ما الذي يضمنه النظام؟" بدون تخمين. تحصل على مفاجآت أقل، دورات مراجعة أقصر، ولحظات "انتظر، إنه يفعل ذلك بالفعل" أقل لأن الفريق ينظر إلى نفس الحقيقة.\n\nعندما تطابق المواصفة الشفرة، يصبح من الآمن التخطيط للتغييرات. يمكنك رؤية ما هو مستقر، وما هو عرضي، وما الذي ينقص قبل الإطلاق.\n\n## ما هي المواصفة الحية وقائمة الفجوات\n\nالمواصفة الحية هي وصف قصير وقابل للتحرير لما يفعله التطبيق فعليًا اليوم. ليست وثيقة لمرة واحدة. تتغير كلما تغيّر السلوك، لذا يمكن للفريق الوثوق بها.\n\nعند الحديث عن مواصفات ميزات مكتوبة من الشفرة (على سبيل المثال باستخدام Claude Code)، الهدف بسيط: اقرأ السلوك الحقيقي من المسارات والمعالجات والشاشات، ثم اكتب ذلك بلغة بسيطة.\n\nالمواصفة الحية المفيدة تركز على ما يراه المستخدم وما الذي يضمنه النظام. يجب أن تغطي:\n\n- السلوك المرئي للمستخدم (ماذا يحدث عند النقر، الإرسال، تسجيل الدخول)\n- القواعد والقيود (الحقول المطلوبة، الحدود، الحسابات)\n- حالات الحافة (الحالات الفارغة، الأخطاء، المحاولات المتكررة، المهلات)\n- الأذونات (من يمكنه العرض، الإنشاء، التعديل، الحذف)\n- المخرجات المهمة (رسائل البريد المرسلة، السجلات المُنشأة، تغيّر الحالات)\n\nما لا يجب أن تغطيه هو كيفية تنظيم الشفرة. إذا بدأت بتسمية الملفات وخطط إعادة التهيئة، فأنت تنحرف إلى تفاصيل التنفيذ. تجنّب:\n\n- أسماء الدوال والفئات، شجرة المكوّنات\n- نقاشات العمارة وخطط إعادة الكتابة\n\nقائمة الفجوات منفصلة. هي قائمة صغيرة بعدد التباينات والمجهولات التي تجدها أثناء كتابة المواصفة.\n\n- الخطأ: الشفرة تنتهك السلوك الحالي أو قاعدة متفق عليها.\n- طلب ميزة: تريد سلوكًا جديدًا.\n- الفجوة: لا يمكنك معرفة السلوك الصحيح، أو السلوك غير متسق بين الشاشات/الأدوار.\n\nمثال: مسار واحد يرفض الملفات الأكبر من 10MB، لكن الواجهة تقول 25MB. هذه فجوة حتى يقرر الفريق أي القاعدة حقيقية ويحدّث الشفرة أو المواصفة.\n\n## اختر نطاقًا وشكل مواصفة بسيط\n\nابدأ صغيرًا. إذا حاولت توثيق التطبيق كله ستنتهي بكومة ملاحظات لا يثق بها أحد. اختر شريحة يمكن للمستخدم وصفها في جملة، مثل "دعوة زميل" أو "الدفع" أو "إعادة تعيين كلمة المرور." النطاق الجيد هو مجال ميزة واحد، وحدة واحدة، أو رحلة مستخدم من نقطة الدخول إلى النتيجة.\n\nاختر نقطة الدخول بناءً على مكان وجود الحقيقة:\n\n- إذا كنت بحاجة إلى القواعد الحقيقية، ابدأ من المسارات والمعالجات.\n- إذا كنت بحاجة إلى التجربة الحقيقية، ابدأ من نقاط دخول الواجهة.\n- إذا كانت الميزة متشابكة، ابدأ من أعلى صفحة/متحكم واعمل للخارج.\n\nقبل قراءة الشفرة، اجمع بعض المدخلات حتى تبدو التباينات بارزة بسرعة: أي وثائق API موجودة، ملاحظات منتج قديمة، تذاكر دعم، و"نقاط الألم المعروفة" التي يشتكي منها الناس. هذه لا تلغي الشفرة، لكنها تساعدك على ملاحظة حالات مفقودة مثل الأخطاء وحالات الحافة والأذونات.\n\nاجعل شكل المواصفة مملاً ومتماشيًا. تلتقي الفرق بشكل أسرع عندما تقرأ كل مواصفة بنفس الطريقة.\n\n### قالب المواصفة (كرر لكل تدفق مرئي للمستخدم)\n\n- Purpose: ما الذي يحاول المستخدم إنجازه\n- Entry points: أين يبدأ التدفق (URL، قائمة، زر)\n- Preconditions: المصادقة، الأدوار، البيانات المطلوبة\n- Main flow: 5–10 خطوات بلغة بسيطة\n- Data and side effects: السجلات المُنشأة/المُحدّثة، الرسائل، السجلات\n- Errors and edge cases: ماذا يحدث عندما تسوء الأمور\n- Open questions: سلوك غير واضح تحتاج تأكيده\n\nاستخدم هذا الهيكل تكراريًا وستبقى مواصفات الميزات قابلة للقراءة والمقارنة وسهلة التحديث.\n\n## استخراج السلوك من المسارات والمعالجات\n\nابدأ بنقاط دخول الخادم. المسارات والمعالجات تظهر "ما الذي يفعله التطبيق" بعبارات ملموسة: من يمكنه استدعاؤها، ما الذي يجب إرساله، ما الذي يحصل عليه المستدعي، وما الذي يتغير في النظام.\n\nسجّل المسارات ضمن النطاق وربط كل منها بهدف مستخدم. لا تكتب "POST /api/orders." اكتب "تقديم طلب" أو "حفظ مسودة." إذا لم تستطع تسمية الهدف بكلمات بسيطة، فهذه بالفعل فجوة في المواصفة.\n\nأثناء قراءة كل معالج، التقط المدخلات وقواعد التحقق كمتطلبات مرئية للمستخدم. تضمّن الحقول المطلوبة، الصيغ المسموح بها، والقواعد التي تسبب أخطاء فعلية. على سبيل المثال: "Email must be valid"، "Quantity must be at least 1"، "Start date can't be in the past."\n\nاكتب فحوصات المصادقة والدور بنفس الطريقة. بدلًا من "middleware: requireAdmin" وثّق: "Only admins can cancel any order. Regular users can only cancel their own order within 10 minutes." إذا كانت الشفرة تفحص الملكية، أو أعلام الميزات، أو حدود المستأجر، أدرجها أيضًا.\n\nثم أشر إلى المخرجات والنتائج. ماذا تُرجع الناجحة (معرّف مُنشأ، كائن مُحدّث)؟ ماذا تبدو الأخطاء الشائعة (401 غير مسجل، 403 غير مسموح، 404 غير موجود، 409 تعارض، 422 خطأ تحقق)؟\n\nأخيرًا، سجّل الآثار الجانبية لأنها جزء من السلوك: السجلات التي تُنشأ أو تُحدّث، الرسائل أو الإشعارات المرسلة، الأحداث المنشورة، مهام الخلفية المأهولة، وأي شيء يُطلق تدفقات أخرى. هذه التفاصيل تمنع المفاجآت عندما تعتمد الفرق على المواصفة لاحقًا.\n\n## استخراج السلوك من المكوّنات وتدفقات الواجهة\n\nالمسارات تخبرك بما يمكن للتطبيق فعله. المكوّنات تخبرك بما يختبره المستخدم فعليًا. تعامل مع الواجهة كجزء من العقد: ما يظهر، ما الذي يُمنع، وماذا يحدث عند حدوث أخطاء.\n\nابدأ بالعثور على شاشات الدخول للميزة. ابحث عن مكوّن الصفحة، غلاف التخطيط، وبعض مكونات "القرار" التي تتحكم في الجلب، الأذونات، والتنقل. عادةً ما يكون السلوك الحقيقي هناك.\n\nأثناء قراءة المكونات، التقط القواعد التي يشعر بها المستخدمون: متى تُعطّل الإجراءات، الخطوات المطلوبة، الحقول الشرطية، حالات التحميل، وكيف تظهر الأخطاء (أخطاء حقل داخلية مقابل إشعار، إعادة المحاولة التلقائية، أزرار "حاول مرة أخرى"). لاحظ أيضًا سلوك الحالة والتخزين المؤقت مثل عرض بيانات قديمة أولًا، التحديثات التفاؤلية، أو طوابع "آخر حفظ".\n\nراقب التدفقات الخفية التي تغير ما يراه المستخدمون بصمت. ابحث عن أعلام الميزات، مجموعات الاختبار، وأبواب المشرف فقط. سجّل أيضًا عمليات إعادة التوجيه الصامتة، مثل إرسال المستخدمين غير المسجلين إلى تسجيل الدخول أو إرسال المستخدمين بدون صلاحية إلى شاشة الترقية.\n\nمثال ملموس: في شاشة "Change Email" وثّق أن زر الحفظ يبقى معطّلًا حتى يصبح البريد صالحًا، يظهر مؤشر تحميل أثناء الطلب، تؤدي النجاحات إلى شريط تأكيد، وأخطاء التحقق من الخادم تُعرض تحت الحقل. إذا أظهرت الشفرة علمًا مثل newEmailFlow، فسجّل كلا النسختين وما الذي يختلف بينهما.\n\nاكتب كل تدفق واجهة كمجموعة خطوات قصيرة (ما يفعله المستخدم، ما تفعله الواجهة ردًا) واحتفظ بالشروط والأخطاء بجانب الخطوة التي تؤثر عليها. هذا يحافظ على قابلية قراءة المواصفة ويسهّل اكتشاف الفجوات.\n\n## تحويل الملاحظات إلى مواصفات ميزات قابلة للقراءة\n\nالملاحظات الخام من المسارات والمكوّنات مفيدة، لكن يصعب مناقشتها. أعد صياغة ما لاحظت إلى مواصفة يمكن لمدير المنتج والمصمم والمهندس والاختبار قراءتها والموافقة عليها.\n\nنمط عملي هو قصة مستخدم واحدة لكل مسار أو شاشة. اجعله صغيرًا ومحددًا. مثال: "As a signed-in user, I can reset my password so I can regain access." إذا أظهرت الشفرة سلوكًا مختلفًا حسب الدور (مسؤول مقابل مستخدم)، اقسمها إلى قصص منفصلة بدل إخفائها في الحواشي.\n\nثم اكتب معايير قبول تعكس مسارات الشفرة الحقيقية، لا المنتج المثالي. إذا أرجع المعالج 401 عند غياب الرمز، فهذه معيار. إذا عطّلت الواجهة Submit حتى يصبح الحقل صالحًا، فهذه معيار.\n\nأدرج قواعد البيانات بلغة بسيطة، خاصة التي تسبب مفاجآت: الحدود، الفرز، التفرد، الحقول المطلوبة. "Usernames must be unique (checked on save)" أوضح من "فهرس فريد."\n\nحالات الحافة غالبًا ما تفرق بين وثيقة لطيفة وواحدة مفيدة. اذكر الحالات الفارغة، القيم null، المحاولات المتكررة، المهلات، وماذا يرى المستخدم عندما يفشل استدعاء API.\n\nعند مواجهة المجهولات، علّمها بدل التخمين:\n\n- Unknown: what message should appear when the email isn't found?\n- Unknown: should we allow 0 items, or force at least 1?\n- Unknown: is this error meant to be user-facing or only logged?\n\nتتحوّل هذه العلامات إلى أسئلة سريعة للفريق بدلًا من افتراضات صامتة.\n\n## إنشاء قائمة فجوات دون تحويلها إلى قائمة مهام\n\nقائمة الفجوات ليست Jira ثاني. هي سجل قصير مبني على الأدلة لأين لا تتطابق الشفرة والسلوك المقصود، أو أين لا يستطيع أحد بوضوح تفسير ما هو "صحيح". إذا نُفّذت جيدًا، تصبح أداة للاتفاق لا معركة للتخطيط.\n\nكن صارمًا بشأن ما يُحتسب كفجوة:\n\n- سلوك غير واضح: التطبيق يفعل شيئًا لكن القاعدة غير موثقة.\n- عدم اتساق: مكانان يتصرفان بشكل مختلف لنفس الحالة.\n- قاعدة مفقودة: حالة حافة موجودة لكن لا يوجد قرار في الشفرة أو الوثائق.\n\nعند تسجيل فجوة، أدرج ثلاثة أجزاء لتظل مبنية على أرضية واقعية:\n\n- Type: bug (الشفرة تبدو خاطئة) أو missing decision (النية غير واضحة)\n- Impact: ارتباك المستخدم، خطر أمني، فقدان بيانات، أو بسيط\n- Evidence: أين رأيتها وماذا لاحظت (route/handler/component)\n\nالأدلة هي ما يمنع القائمة من التحول إلى آراء. مثال: "POST /checkout/apply-coupon يقبل القسائم المنتهية، لكن CouponBanner.tsx يمنعها في الواجهة. الأثر: إيرادات وارتباك المستخدم. النوع: bug أو missing decision (تأكيد القاعدة المقصودة)."\n\nاجعلها قصيرة. ضع حدًا صارمًا، مثل 10 عناصر للمرّة الأولى. إذا وجدت 40 مشكلة، جمّعها إلى أنماط (تباينات التحقق، فحوصات الأذونات، حالات فارغة) واحتفظ بأمثلة رئيسية فقط.\n\nتجنّب إضافة تواريخ وجدولة داخل قائمة الفجوات. إذا كنت تحتاج ملكية، اجعلها خفيفة: اذكر من يجب أن يتخذ القرار (المنتج) أو من يمكنه التحقق (الهندسة)، ثم انقل التخطيط الحقيقي إلى قائمة المهام لديك.\n\n## مثال: توثيق ميزة حقيقية من الشفرة\n\nاختر نطاقًا صغيرًا عالي الحركة: الدفع مع رموز الترويج وخيارات الشحن. الهدف ليس إعادة كتابة المنتج، بل التقاط ما يفعله التطبيق اليوم.\n\nابدأ بالمسارات الخلفية. غالبًا ما تظهر القواعد هناك أولًا. قد تجد مسارات مثل POST /checkout/apply-promo, GET /checkout/shipping-options, وPOST /checkout/confirm.\n\nمن تلك المعالجات، اكتب السلوك بكلمات بسيطة:\n\n- تُتحقَّق رموز الترويج في الخادم (منتهية، حد الاستخدام، أهلية العميل).\n- تُعاد حسابات الإجماليات بعد تطبيق الكوبون، لكن فقط بعد إعادة التحقق من المخزون.\n- خيارات الشحن تعتمد على الوجهة، الوزن، وما إذا كان أي عنصر مُعلّم كـ "restricted."\n- تفشل عملية التأكيد إذا تغيّر مخزون بند line item منذ تحميل السلة.\n- تُحسب الضريبة بعد اختيار الشحن (وليس عند تطبيق الكوبون).\n\nثم تفقد مكوّنات الواجهة. قد يظهر PromoCodeInput أن الإجماليات تُحدّث فقط بعد استجابة ناجحة وأن الأخطاء تُعرض تحت الحقل. قد يختار ShippingOptions أرخص خيار تلقائيًا عند التحميل الأول ويطلق تحديث تفصيلي للأسعار عند تغيّر المستخدم للاختيار.\n\nالآن لديك مواصفة قابلة للقراءة وقائمة فجوات صغيرة. مثال: تختلف رسائل الأخطاء بين مسار الترويج والواجهة ("Invalid code" مقابل "Not eligible"), ولا يستطيع أحد تحديد قاعدة تقريب الضريبة (لكل بند أم لإجمالي الطلب).\n\nفي التخطيط، يتفق الفريق على الواقع أولًا ثم يقرر ما الذي سيتغيّر. بدلًا من مناقشة الآراء، تستعرضون السلوك الموثق، تختارون تباينًا واحدًا لإصلاحه، وتتركون الباقي كـ "السلوك الحالي المعروف" حتى يستحق إعادة النظر.\n\n## تحقق من المواصفة مع الفريق وابقها محدثة\n\nالمواصفة تساعد فقط إذا اتفق الفريق أنها تطابق الواقع. قم بقراءة سريعة مع مهندس واحد وشخص من المنتج. اجعلها مركّزة: 20–30 دقيقة عن ما يمكن للمستخدم فعله وماذا يفعل النظام ردًا.\n\nأثناء القراءة، حوّل العبارات إلى أسئلة نعم/لا. "عندما يصل المستخدم إلى هذا المسار، هل نعيد دائمًا 403 بدون جلسة؟" "هل هذه الحالة الفارغة مقصودة؟" هذا يفصل السلوك المقصود عن السلوك العرضي الذي تسلل مع مرور الوقت.\n\nاتفقوا على المصطلحات قبل التحرير. استخدم الكلمات التي يراها المستخدم في الواجهة (تسميات الأزرار، عناوين الصفحات، رسائل). أضف الأسماء الداخلية فقط عندما تساعد المهندسين على العثور على الشفرة (أسماء المسارات، أسماء المكوّنات). هذا يمنع عدم التطابق مثل قول المنتج "Workspace" بينما تقول المواصفة "Org."\n\nللحفاظ عليها محدثة، اجعل الملكية والإيقاع واضحين:\n\n- Spec owner: شخص واحد يدمج تغييرات المواصفة (غالبًا صاحب الميزة أو القائد الفني)\n- Update trigger: عند دمج PR لتغيّر سلوكي، أو عند كل إصدار\n- فحص سريع: أضف خانة "هل تم تحديث المواصفة؟" إلى قالب PR\n- التخزين: احتفظ بها قريبًا من الشفرة حتى تتغير مع الشفرة\n\nإذا كنت تستخدم أداة مثل Koder.ai، تساعد اللقطات والاسترجاع على مقارنة "قبل" و"بعد" السلوك عند تحديث المواصفة، خصوصًا بعد إعادة تهيئة كبيرة.\n\n## الأخطاء والفخاخ الشائعة\n\nأسرع طريق لفقدان الثقة في المواصفة هو وصف المنتج الذي تريده بدل المنتج الذي لديك. ضع قاعدة صارمة: كل عبارة يجب أن تدعمها شيء يمكنك الإشارة إليه في الشفرة أو شاشة حقيقية.\n\nفخ شائع آخر هو نسخ شكل الشفرة داخل الوثيقة. مواصفة تظهر كـ "Controller -> Service -> Repository" ليست مواصفة، بل خريطة مجلدات. اكتب بمصطلحات مرئية للمستخدم: ما الذي يطلق الإجراء، ماذا يرى المستخدم، ماذا يُحفَظ، وماذا تبدو الأخطاء.\n\nغالبًا ما تُتجاهل الأذونات والأدوار حتى النهاية، ثم ينهار كل شيء. أضف قواعد الوصول مبكرًا، حتى لو كانت فوضوية. اذكر أي الأدوار يمكنها العرض، الإنشاء، التعديل، الحذف، التصدير، أو الموافقة، وأين تُنفَّذ القاعدة (واجهة فقط، API فقط، أو كلاهما).\n\nلا تتخطَ المسارات غير السعيدة. السلوك الحقيقي يختبئ في المحاولات المتكررة، الفشل الجزئي، والقواعد القائمة على الزمن مثل الانتهاء، فترات التبريد، أو حدود "مرة واحدة في اليوم". تعامل معها كأفعال أولى.\n\nطريقة سريعة لابراز الفجوات هي البحث عن:\n\n- فشل التحقق ورسائل الخطأ الدقيقة التي يرىها المستخدم\n- معالجة الإرسال المزدوج (قابلية التكرار)\n- العمل الخلفي (الطوابير، cron) وماذا يحدث إذا فشل\n- قضايا التزامن (شخصان يغيران نفس السجل)\n- السلوك القائم على الزمن (مهلات، انتهاء صلاحية، حدود المعدل)\n\nأخيرًا، حرّك قائمة الفجوات. يجب تصنيف كل فجوة كواحدة من: "unknown, needs decision," "bug, fix," أو "missing feature, plan." إذا لم يُصنّف شيء، تتوقف القائمة وتتوقف المواصفة عن كونها "حية."\n\n## قائمة تحقق سريعة قبل المشاركة\n\nمرّر بسرعة للتحقق من الوضوح والتغطية وقابلية التنفيذ. يجب أن يفهم شخص لم يكتبها ما الذي تفعله الميزة اليوم وما الذي لا يزال غير واضح.\n\n### الوضوح والفهم المشترك\n\nاقرأ المواصفة كزميل جديد في اليوم الأول. إذا استطاع تلخيص الميزة في دقيقة، فأنت قريب. إذا ظل يسأل "أين يبدأ هذا؟" أو "ما هو المسار السعيد؟" شدد المقدمة.\n\nتحقق من:\n\n- اختبار الصفحة الواحدة: الافتتاحية تذكر هدف المستخدم، أين يبدأ التدفق، وأين ينتهي.\n- الأدوار والوصول: الأدوار الأساسية وما الذي يستطيع كل منها فعله وعدم فعله.\n- النتائج: ماذا يبدو النجاح وماذا يرى المستخدم عند الفشل (رسائل، إعادة توجيه، محاولات)\n- الحواف والحدود: حدود الحجم، حدود المعدل، المهلات، قواعد التحقق، وماذا يحدث عند غياب البيانات.\n- اللغة: استخدم مصطلحات الواجهة أولًا؛ عرّف المصطلحات الداخلية غير القابلة للتجنّب مرة واحدة.\n\n### فجوات تساعد، لا ضوضاء\n\nيجب أن تكون كل فجوة محددة وقابلة للاختبار. بدلًا من "عدم وضوح معالجة الأخطاء،" اكتب: "إذا أعاد مزود الدفع 402، تعرض الواجهة إشعارًا عامًا؛ أكد الرسالة المرغوبة وسلوك إعادة المحاولة." أضف إجراءً واحدًا لاحقًا (سؤال للمنتج، إضافة اختبار، فحص السجلات) واذكر من يجب أن يجيب.\n\n## الخطوات التالية لبدء هذا الأسبوع\n\nاختر مجال ميزة وحدده بمدة زمنية 60 دقيقة. اختر شيئًا صغيرًا لكن حقيقيًا (تسجيل الدخول، الدفع، البحث، شاشة إدارة). اكتب جملة واحدة للنطاق: ما الذي يتضمنه وما الذي لا يتضمنه.\n\nشَغِّل سير العمل مرة واحدة من البداية للنهاية: تصفّح المسارات/المعالجات الرئيسية، تتبع تدفق الواجهة الرئيسي، واكتب السلوكيات القابلة للملاحظة (المدخلات، المخرجات، التحقق، حالات الخطأ). إذا علِقت، سجّل السؤال كفجوة وواصل.\n\nعند الانتهاء، شارك المواصفة حيث يمكن للفريق التعليق، وضع قاعدة واحدة: يجب تحديث المواصفة مع أي تغيير سلوكي مُشحون في نفس نافذة التسليم، حتى لو كان خمسة أسطر.\n\nاحتفظ بالفجوات منفصلة عن قائمة المهام. جمّعها ضمن "سلوك غير معروف," "سلوك غير متسق," و"اختبارات مفقودة," ثم راجعها سريعًا أسبوعيًا لتقرر ما المهم الآن.\n\nإذا بدا المسودة والتكرار بطيئين، يمكن لأداة محادثة مثل Koder.ai مساعدتك في إخراج نسخة أولية بسرعة. صِف الميزة، ألصق مقتطفات أو أسماء مسارات رئيسية، حسّن الصياغة بالمحادثة، وصدر المصدر عند الحاجة. الفكرة هي السرعة والوضوح المشترك، لا عملية أكبر.