الـ Skeleton الرباعي

كل code-generation prompt بيعدّي review عنده نفس الـ 4 blocks. احفظهم، ومش هتكتب prompt كود غامض تاني.

Block	بيجاوب على إيه	مثال
INTENT	الـ function ليه؟	"Write dedupe_preserve_order(items: list[str]) -> list[str]."
CONSTRAINTS	إيه القواعد اللي لازم الكود يلتزم بيها؟	"O(n) time. مفيش external imports. Type hints مطلوبة."
TESTS	هعرف إنه صح إزاي؟	"ضمّن 4 assert cases في if __name__ == '__main__':."
FORMAT	شكل الإجابة المفروض إزاي؟	"Output ONLY a single Python code block, no prose."

ليه الأربعة دول؟ كل block بيقفل نوع من الفشل اللي شفته في الدرس الأول:

• من غير INTENT الموديل بيخترع الـ signature. ممكن يديك dedupe_list بدل dedupe_preserve_order.
• من غير CONSTRAINTS الموديل بيختار defaults مش هتعدي code review. ممكن يستورد package من برّه، أو يستخدم O(n^2) عشان "أوضح."
• من غير TESTS هتضطر تكتبهم إنت قبل ما تثق في الـ function. والأوحش، الموديل أحياناً بيرجع كود بيتجمّع بس فيه خطأ خفي.
• من غير FORMAT الموديل بيلف الكود في tutorials و"ممكن كمان تعجبك…" sections. مش هتقدر تلصقه في ملف .py.

الترتيب مهم. INTENT الأول عشان الموديل محتاج يعرف هيبني إيه قبل ما يفكر هيبني إزاي. CONSTRAINTS تاني عشان بيشكّل الـ implementation. TESTS تالت عشان هي التعريف القابل للتنفيذ للصح. FORMAT آخراً عشان بيتحكم في شكل المخرج، مش في الجوهر.

الـ skeleton متراكم من فوق لتحت:

هتشوف في الدروس التلاتة الجاية إن كل block ليه micro-skills. INTENT أكتر من جملة — لازم تحدد الـ signature، والـ side-effects، والـ failure modes. CONSTRAINTS بتغطي الأداء، dependencies، الستايل، والأمان. TESTS هي اللي بتبدّل verbosity بـ correctness — 3 asserts حادة أحسن من 10 غامضة. وFORMAT هو الفرق بين كود تعمله Cmd+V على طول، وكود لازم تنضّفه الأول.

الـ skeleton ده شغّال مع Python، TypeScript، Go، Rust، SQL — language-agnostic. وكمان شغّال على scales أكبر من function واحدة: هتعيد استخدامه في module 3 لـ refactor prompts، وفي module 6 لـ capstone PR.

التالي: إزاي تكتب INTENT و CONSTRAINTS صح. :::