تصلك مهمة ميزة، والخطوة السهلة أن تبدأ بالكتابة — أو أن تدع Claude يبدأ بالكتابة — لتكتشف بعد ساعة أن المقاربة كانت خاطئة، وأن الـ diff صار 300 سطر، وأن لا شيء مُختبَرًا. الـ loop الأفضل ممل عن قصد: دوّن ما يعنيه «منتهٍ»، احصل على الخطة أولًا واقرأها وهي ما زالت نصًّا رخيصًا، ثم دع Claude يبني خلف suite تثبت أنها تعمل. هنا تلتقي العادات الهندسية الثلاث في سير عمل واحد — خطّط قبل الـ diff، أثبت بالـ tests، ابقَ المؤلّف المسؤول — ولهذا هو الـ loop الجدير بأن يصير muscle memory.
- الـ repo مفتوحًا في Claude Desktop، مع ملف
CLAUDE.mdفي مكانه (من playbook الـ project-context) كي يعرف Claude مسبقًا أعرافك، والـ stack الخاص بك، والأمر الدقيق الذي يشغّل الـ tests لديك. - وصفًا واضحًا مكتوبًا للميزة — ماذا تفعل، ولمن — وطريقةً ملموسة تعرف بها أنها أصبحت منتهية (الـ acceptance criteria، ولو كانت أوّلية).
- أي artifacts حقيقية تثبّت النطاق: المهمة، ملاحظة تصميم، شكل الـ API، مثال على الـ payload. أعطِ Claude الشيء الحقيقي، لا إعادة صياغتك له.
-
اكتب الـ spec وثبّت النطاق
افتح المجلد في Claude Desktop واشتغل على الـ spec في المحادثة — لا حاجة للـ Terminal. قبل أي كود، احصل على «منتهٍ» مكتوبًا: ماذا تفعل الميزة، والـ acceptance criteria، وبوضوح ما هو خارج النطاق. النطاق المثبَّت هو ما يمنع ميزة من ملفّين أن تتحوّل بهدوء إلى ميزة من تسعة ملفّات.
أنت تطلبهذه الميزة التي أريد بناءها: [صِفها]. ساعدني على تحويل هذا إلى spec قصير — ملخّص من فقرة واحدة، و4–6 acceptance criteria مصاغة كعبارات قابلة للاختبار، وقائمة صريحة بـ «خارج النطاق الآن». لا تكتب أي كود بعد.ما تحصل عليه spec محكم تستطيع أن تحمله في ذهنك — السلوك، والمعايير التي ستختبر عليها، وقائمة بغير الأهداف. هذا هو العقد الذي يُقاس عليه بقية الـ loop.
سطر «خارج النطاق» يؤدّي عملًا حقيقيًا. تسمية ما لا تبنيه الآن هو أرخص وسيلة لإيقاف scope creep قبل أن يبدأ.
-
احصل على الخطة أولًا — وانقدها نصًّا
فعّل plan mode واطلب المقاربة قبل كتابة سطر واحد. قراءة خطة خاطئة في فقرة تكلّفك دقيقة؛ فكّ diff خاطئ من 300 سطر يكلّفك فترة بعد ظهر كاملة. اعترِض على الخطة بلغة بسيطة حتى تصير صحيحة.
أنت تطلباستخدم plan mode. بالنظر إلى هذا الـ spec، اعرض خطة التنفيذ: أي الملفات ستمسّها ولماذا، وترتيب التغييرات، والـ data والـ types المعنيّة، وأين تذهب الـ tests. لا تكتب كودًا — أريد مراجعة المقاربة أولًا.ما تحصل عليه خطة خطوة بخطوة تستطيع تقييمها فعلًا — الملفات، والتسلسل، واستراتيجية الـ tests — قبل وجود أي diff. إن كانت المقاربة خاطئة، تلتقطها هنا بثمن جملة.
انقدها كمراجعة تصميم: «هذا يمسّ مسار auth — لا تفعل»، «نفّذه خلف الـ flag الموجود»، «افصِل الـ migration على حدة». تصحيح النص رخيص؛ تصحيح الـ diff ليس كذلك.
-
وافِق على الخطة وراقب وصول الـ diffs
بمجرّد أن تصير الخطة صحيحة، دع Claude يُنفّذها. في Claude Desktop يعود كل تغيير على شكل diff مرئي تقبله أو ترفضه مباشرةً في المحادثة — فتُراجِع وهو يبني، لا أن تختم على جدار كود في النهاية.
أنت تطلبالخطة تبدو صحيحة — تابِع ونفّذها. اشتغل بخطوات صغيرة وأرِني كل تغيير على شكل diff قبل أن تنتقل، حتى أقبل أو أرفض أثناء سيرك.ما تحصل عليه الميزة تتشكّل كسلسلة من الـ diffs المقروءة تقبلها أو ترفضها في لوحة الملفات — لا تغييرًا عملاقًا واحدًا يُلقى في النهاية. تبقى ضمن الـ loop بينما يقوم هو بالكتابة.
القبول/الرفض لكل تغيير هو الغاية من Claude Desktop هنا. إن انحرف diff عن الخطة، ارفضه وقل لماذا — لا تقبله وتخطّط لإصلاحه لاحقًا.
-
اجعله يثبت السلوك الجديد
ميزة بلا test هي ادّعاء، لا ميزة. احصل على tests تثبّت السلوك الجديد و الـ edge cases التي ألمح إليها الـ spec، ثم شغّل الـ suite حتى تصير خضراء. الـ tests الناجحة هي الإيصال على أن المعايير من الخطوة الأولى مُحقَّقة فعلًا.
أنت تطلباكتب الآن tests تثبّت السلوك الجديد مقابل كل acceptance criterion، إضافةً إلى الـ edge cases الواضحة — input فارغ، والقيم الحدّية، ومسار الخطأ. شغّل الـ suite كاملًا وأرِني أنها خضراء.ما تحصل عليه ملف tests يتطابق مع الـ acceptance criteria لديك، وsuite خضراء، وأي edge case لم يُسمِّه الـ spec مطروحًا أمامك لتحكم فيه. تشغيل الـ suite خطوة في مسار
Power Track— يحتاج جلسة مفعّلة للـ Terminal — لكن الـ tests نفسها تُكتب وتُراجَع في Claude Desktop.راجِع الـ tests مقابل المعايير بنفسك: test ينجح على assertion خاطئ أسوأ من لا test. «إنه ينجح» لا يُحتسب إلا بعد أن تتأكّد أنه يختبر الشيء الصحيح.
-
اقرأ الـ diff كاملًا وcommit في أجزاء منطقية
قبل أن ينزل أي شيء، اقرأ الـ diff كاملًا من بدايته إلى نهايته — أنت المؤلّف المسؤول، وستحمل
git blameاسمك. ثم commit العمل في أجزاء صغيرة منطقية برسائل تشرح لماذا، لا ماذا فقط.أنت تطلبأرِني الـ diff الكامل للميزة بأكملها لأقرأه من بدايته إلى نهايته. ثم stage وcommit في أجزاء صغيرة منطقية — همّ واحد لكل commit — وصُغ رسالةً لكلٍّ منها تشرح لماذا يوجد التغيير، لا ماذا يفعل فقط.ما تحصل عليه diff نهائي قرأته فعلًا، ثم كومة صغيرة نظيفة من الـ commits — كلٌّ منها متماسك، وكل رسالة تشرح التعليل — تاريخ تسرّك أن تشغّل عليه
git blameبعد ستة أشهر.مراجعة الـ diff الكامل غير قابلة للتفاوض حتى لو بدت كل خطوة سليمة بمعزل. الكلّ هو حيث يختبئ تفاعل غير مقصود.
- spike ثم إعادة بناء: إن كنت لا تفهم المشكلة بعد، اطلب prototype للرمي أولًا كي تتعلّم الشكل — ثم تخلّص منه وشغّل هذا الـ loop كما يجب بخطة حقيقية. الـ spike للتعلّم، لا للإطلاق.
- feature-flag للطرح: اطلب من Claude أن يضع المسار الجديد خلف flag كي تستطيع الـ merge مبكرًا وتفعيله بقصد — diffs أصغر وأأمن، وkill switch فوري إن أساء التصرّف في production.
- التقط الشكل كـ slash command (مسار `Power Track`): بعد أن تشغّل هذا الـ loop بضع مرّات، يستحقّ شكل الميزة المتكرّر (spec ← خطة ← تنفيذ ← test ← commit) أن يُحفظ كـ slash command قابل لإعادة الاستخدام
/featureكي تبدأ الميزة التالية مهيكلةً مسبقًا (انظر تبويب Features).
- خطة لم تقرأها هي diff ستضطر إلى فكّه. قيمة plan mode كلها تتبخّر إن وافقت على الخطة دون قراءتها — اقرأها، اعترِض، ثم وافِق. تصحيح المقاربة نصًّا أرخص بمراتب من تصحيحها في الكود.
- «إنه ينجح» ليست «إنه منتهٍ». suite خضراء تثبت أن الـ tests تنجح، لا أن الكود صحيح — ما زلت تقرأ الـ diff كاملًا، وما زلت تتأكّد أن الـ tests تختبر الشيء الصحيح. الثقة في الناتج ليست دليلًا.
- أبقِ النطاق مثبَّتًا وإلا زاد التزويق. متروكًا مفتوحًا، سيظلّ الـ agent «يحسّن» كودًا مجاورًا لم تطلب منه أبدًا أن يمسّه. قائمة غير الأهداف من الخطوة الأولى هي دفاعك — أشِر إليها.
- الـ specs الخاصة تبقى داخل الحدود. قد تحمل المهمة وملفّات التصميم بيانات عملاء، أو معمارية داخلية، أو ما هو تحت NDA — أبقِها في بيئة تعتمدها مؤسستك، وتذكّر أن المجلد المفتوح هو الحدّ الذي يقرأ منه Claude.
ستحصل في النهاية على ميزة مُخطَّطة قبل أن تُبنى، ومُنفَّذة خلف suite تثبتها، ومُختبَرة مقابل المعايير التي دوّنتها، ومقروءة سطرًا سطرًا، وموضوعة في تاريخ نظيف — مُطلَقة بالطريقة التي يُطلق بها مهندس خبير، مع قيام Claude بالكتابة وامتلاكك أنت لكل قرار.
أسئلة يطرحها الناس
- لماذا أستخدم plan mode بدل أن أطلب من Claude بناء الميزة مباشرةً؟
- لأن أرخص مكان لالتقاط مقاربة خاطئة هو فقرة، لا diff من 300 سطر. plan mode يجعل Claude يعرض أي الملفات سيمسّها وبأي ترتيب *قبل* كتابة أي شيء، فتراجع الاستراتيجية بينما يكلّفك تصحيحها جملة. لتغيير من سطر واحد هو مبالغة؛ لأي شيء يمسّ عدة files أو مسارًا تهتمّ به، قراءة الخطة أولًا هي الدقيقة الأعلى مردودًا في الـ loop.
- كم من الـ spec يكفي قبل أن أبدأ؟
- ما يكفي لتدوين ما يعنيه «منتهٍ» — ملخّص من فقرة، و4–6 acceptance criteria يمكن تحويلها إلى tests، وقائمة صريحة بما هو خارج النطاق. لست بحاجة إلى PRD رسمي؛ أنت بحاجة إلى عقد دقيق بما يكفي ليتّفق أنت وClaude على الهدف وليجد الـ tests شيئًا ملموسًا يثبّتونه. إن لم تستطع ذكر الـ acceptance criteria، فتلك إشارة إلى أن الميزة غير معرّفة بعد، لا إلى أنك يجب أن تبدأ الكتابة.
- ماذا أفعل إن كانت الخطة التي يقترحها Claude خاطئة؟
- انقدها نصًّا واطلب نسخة منقّحة — هذا تحديدًا ما خُصِّص له plan mode. قل ما الخطأ («لا تمسّ مسار auth»، «ضع هذا خلف الـ flag الموجود»، «افصِل الـ migration في تغيير خاصّ به») واجعله يعيد التخطيط قبل وجود أي كود. التكرار على فقرة سريع ورخيص؛ الغاية كلها أن تضبط المقاربة وهي ما زالت كلمات، لا diff تضطر إلى فكّه.
- هل يكتب Claude الـ tests أيضًا، وهل أثق بها؟
- نعم، يكتبها — لكن «الثقة» إطار خاطئ: أنت *تتحقّق* منها. اجعله يكتب tests مقابل كل acceptance criterion، ثم اقرأها وتأكّد أن كلًّا منها يؤكّد السلوك الذي تريده فعلًا، لأن test ينجح على assertion خاطئ أسوأ من لا test إطلاقًا. الـ suite الخضراء ضرورية لا كافية — تثبت أن الـ tests تنجح، ومراجعتك تثبت أنها تختبر الشيء الصحيح.