lean-mode کیا ہے؟
lean-mode کوڈنگ Agent کے لیے ایک SKILL.md فائل ہے۔ اس کا مقصد “کوڈ جتنا کم ہو اتنا بہتر” نہیں، بلکہ Agent کو واضح معیار فراہم کرنا ہے تاکہ وہ انجینئرنگ کے دو سوالوں کا جواب دے سکے:
- کیا بظاہر محفوظ کوڈ لکھنا واقعی ضروری ہے، مثلاً توثیق،
try/catch، تجریدی پرت، متبادل منطق یا اضافی حفاظتی ذیلی نظام؟ - موجودہ تعمیر اور ٹیسٹ اتنے سست کیوں ہیں، اور غیر مؤثر توثیقی چکر کو مناسب حد تک کیسے مختصر کیا جائے؟
یہ اسکل فائل skills/lean-mode/SKILL.md میں موجود ہے اور معیاری frontmatter استعمال کرتی ہے، یعنی name، description اور Markdown متن۔ یہ کسی مخصوص میزبان پر منحصر نہیں؛ جو بھی Agent SKILL.md کے طریقہ کار کو سپورٹ کرتا ہو، اسے استعمال کر سکتا ہے۔
یہ کن بنیادی مسائل کو حل کرتی ہے؟
طویل کوڈنگ سیشنز میں ماڈل عموماً دو نظامی رجحانات کا شکار ہو جاتا ہے: حد سے زیادہ دفاعی پروگرامنگ اور غیر مؤثر توثیقی چکر۔
حد سے زیادہ دفاعی پروگرامنگ
عام صورتوں میں قابلِ اعتماد اندرونی ڈیٹا پر بار بار null چیک کرنا، اصل وجہ چھپانے کے لیے استثنا پکڑنا، ایک ہی implementation کے لیے وقت سے پہلے تجرید بنانا، اور مسئلے کا ماخذ معلوم کیے بغیر مسلسل متبادل منطق شامل کرنا شامل ہیں۔ کوڈ بظاہر زیادہ “محفوظ” لگتا ہے، مگر حقیقت میں دیکھ بھال کی لاگت بڑھا سکتا ہے اور واضح ناکامی کو ایسے غلط نتائج میں بدل سکتا ہے جن کا سراغ لگانا مشکل ہو۔
غیر مؤثر توثیقی چکر
عام صورتوں میں بار بار مکمل تعمیر چلانا، مسلسل clean استعمال کرنا، مستقل چلنے والے عمل غیر فعال کرنا، ہر بار تمام ٹیسٹ چلانا، اور بظاہر اٹکے ہوئے کمانڈ کو طویل عرصے تک انتظار کروانا شامل ہیں۔ lean-mode ان رویوں کو عمل کے دوبارہ استعمال، اضافی تعمیر، دائرہ کار کے کنٹرول، ترتیبِ اجرا، کال کی فریکوئنسی اور ٹائم آؤٹ مینجمنٹ کے چھ اصولوں کے ذریعے محدود کرتی ہے۔
README میں موجود مقداری اعداد و شمار تقریباً 20k لائنوں والے Java اور Gradle پروجیکٹ کے ایک طویل سیشن سے لیے گئے ہیں۔ یہ صرف مسئلے کے حقیقی وجود کو واضح کرنے کے لیے ہیں، انہیں مختلف ماڈلز یا پروجیکٹس کے لیے صنعتی معیار نہ سمجھا جائے۔
اہم صلاحیتیں
- صرف اعتماد کی حد پر ایک بار توثیق: پہلے یہ سوال کرنے کا تقاضا کرتی ہے کہ “یہ null کہاں سے آیا؟” تاکہ قابلِ اعتماد ڈیٹا کے نظام میں داخل ہونے کے بعد بھی بار بار ایک ہی چیک نہ کیا جائے۔
- اصل وجہ کو نہ چھپائیں:
catchکے بعدnull،false، خالی مجموعہ یا صفر واپس کرنے سے محتاط رہیں، کیونکہ اس سے واضح استثنا کو ایسے غلط نتیجے میں بدلا جا سکتا ہے جس کا سراغ لگانا زیادہ مشکل ہو۔ - وقت سے پہلے تجرید کو محدود کریں: صرف ایک implementation ہونے کی صورت میں، یا صرف مستقبل میں ممکنہ تبدیلی کے لیے بنائی گئی تجرید، ضروری نہیں کہ واقعی مستحکم توسیعی حد بنائے۔
- اصل وجہ کی اصلاح کو ترجیح دیں: متبادل منطق شامل کرنے کا مطلب ہے کہ اصل وجہ ابھی مکمل طور پر حل نہیں ہوئی۔ واقعی ضرورت ہو تو مسئلے کی ملکیت، حذف کرنے کی شرط اور تصدیق شدہ بنیاد واضح کی جائے۔
- تبدیلی کے حجم کو رویے کی تبدیلی سے ہم آہنگ رکھیں: جب نیا کوڈ 50 لائنوں سے زیادہ ہو تو پہلے کل لائنوں، توثیق اور متبادل منطق میں شامل لائنوں، اور یہ کوڈ نہ لکھنے کی حقیقی لاگت کی اطلاع دیں۔
- محفوظ کوڈ لکھنے سے پہلے تین سوالوں کے جواب دیں: کیا مسئلہ واقعی پیش آ سکتا ہے؟ پیش آنے پر صارف پر کیا اثر ہوگا؟ اور اسے نہ لکھنے کی لاگت کیا ہے؟ کسی بھی سوال کا جواب نہ ہو تو پہلے کوڈ شامل نہ کریں۔
- توثیقی چکر مختصر کریں: Gradle، Maven، Go، Node اور TypeScript، Rust، Python، .NET سمیت سات اقسام کے تعمیراتی نظاموں کے لیے کم سے کم توثیقی طریقہ فراہم کرتی ہے۔
- “تبدیلی کی ضرورت نہیں” کا نتیجہ بھی قابلِ قبول رکھیں: مقصد مسئلہ حل کرنا ہے، زبردستی کوڈ تیار کرنا نہیں؛ اور جہاں صارف نے مطالبہ نہ کیا ہو وہاں غیر ضروری مضبوطی بھی شامل نہیں کی جانی چاہیے۔
- موجودہ کوڈ کے آڈٹ کا طریقہ فراہم کریں: پہلے کثافت کو مقداری شکل دیں، پھر سب سے سنگین فائلیں دیکھیں، ہر معاملے میں حذف، اوپر منتقل یا برقرار رکھنے کا فیصلہ کریں، اور ترمیم سے پہلے صارف کو نتائج کی جدول پیش کریں۔
دفاعی کوڈ کے لیے یہ اسکل Java، Go، TypeScript اور Python میں چار مخالف مثالیں فراہم کرتی ہے، تاکہ Agent مختلف syntax کے پیچھے موجود ایک جیسے مسائل کو پہچان سکے۔
lean-mode انسٹال کریں
طریقہ اول: URL سے حاصل کریں
اگر میزبان URL سے اسکل درآمد کرنے کی سہولت فراہم کرتا ہے، مثلاً Vantaloom کا اسکل صفحہ، تو ریپوزٹری کا پتہ براہِ راست چسپاں کیا جا سکتا ہے۔ میزبان اسکل فائل کو skills/lean-mode/ کے تحت تلاش کر لے گا۔
https://github.com/Timefiles404/lean-mode-skillطریقہ دوم: ورک اسپیس میں نقل کریں
پہلے ریپوزٹری کلون کریں، پھر اسکل ڈائریکٹری کو میزبان کے مقررہ مقام پر نقل کریں۔ Vantaloom ورک اسپیس کے طریقے کے ساتھ یہ کمانڈ چلائیں:
git clone https://github.com/Timefiles404/lean-mode-skill.git
cp -r lean-mode-skill/skills/lean-mode <آپ کی ورک اسپیس>/.vantaloom/skills/اگر میزبان Claude طرز کی اسکل ڈائریکٹری استعمال کرتا ہے تو اسے .claude/skills/ میں نقل کریں:
cp -r lean-mode-skill/skills/lean-mode <آپ کی ورک اسپیس>/.claude/skills/طریقہ سوم: اسکل دستی طور پر بنائیں
میزبان میں نئی اسکل بنائیں، پھر ریپوزٹری کی skills/lean-mode/SKILL.md کا مکمل متن اس میں چسپاں کریں۔ اوپر موجود frontmatter کو نہ چھوڑیں، کیونکہ میزبان اسی کے description کی بنیاد پر فیصلہ کرتا ہے کہ اسکل کب لوڈ کرنی ہے۔
بنیادی استعمال کا طریقہ
انسٹالیشن کے بعد lean-mode بنیادی طور پر اسکل کی وضاحت کو ضرورت کے وقت context میں شامل کرنے پر منحصر ہے۔ جب Agent توثیق، استثنا پکڑنے، تجریدی پرت، متبادل منطق یا اضافی حفاظتی ذیلی نظام شامل کرنے کی تیاری کرے، یا ایک مرحلے میں کئی بار تعمیر اور ٹیسٹ چلا چکا ہو، تو اسے فعال ہونا چاہیے۔
منظرنامہ اول: نئی توثیق کی ضرورت کا فیصلہ
- پہلے ڈیٹا کا ماخذ معلوم کریں اور تصدیق کریں کہ آیا وہ بیرونی input، interface boundary یا کسی دوسرے ناقابلِ اعتماد ماخذ سے آیا ہے۔
- دیکھیں کہ آیا یہی پابندی اعتماد کی حد پر پہلے ہی جانچی جا چکی ہے۔
- جواب دیں کہ مسئلہ واقعی پیش آ سکتا ہے یا نہیں، صارف پر کیا اثر ہوگا، اور توثیق نہ لکھنے کی لاگت کیا ہے۔
- اگر ڈیٹا اندرونی حصے میں داخل ہونے کے بعد قابلِ اعتماد ہو چکا ہے تو ہر سطح پر اسی قسم کی runtime توثیق دوبارہ شامل نہ کریں۔
مثلاً جب Agent متعدد اندرونی طریقوں میں بار بار Objects.requireNonNull شامل کرنا چاہے تو صرف اس وجہ سے اسے شامل نہیں کرنا چاہیے کہ پیرامیٹر “نظری طور پر null ہو سکتا ہے”۔ پہلے null کا حقیقی ماخذ معلوم کریں اور فیصلہ کریں کہ آیا حد پر پہلے ہی توثیق مکمل ہو چکی ہے۔
منظرنامہ دوم: استثنا سنبھالنا
جب Agent استثنا پکڑ کر default value واپس کرنے کی تیاری کرے تو پہلے تصدیق کرے کہ آیا اس عمل سے اصل وجہ چھپ تو نہیں جائے گی۔ درج ذیل pattern کو خاص طور پر جانچنا چاہیے:
catch (...) {
return false;
}مقصد تمام استثنا پکڑنے پر پابندی لگانا نہیں، بلکہ ایسی قابلِ سراغ ناکامی کو کم context والے false، null، خالی نتیجے یا صفر میں تبدیل ہونے سے روکنا ہے۔ اگر کاروباری ضرورت کے تحت degrade کرنا واقعی ضروری ہو تو اسکل میں دی گئی استثنائی شرائط کے مطابق جائزہ لیں۔
منظرنامہ سوم: تجریدی پرت کا جائزہ
اگر کسی interface کی فی الحال صرف ایک implementation ہے، اور اسے بنانے کی واحد وجہ “مستقبل میں شاید اسے تبدیل کیا جائے” ہے، تو Agent کو رک کر حقیقی تبدیلی کی حد کا جائزہ لینا چاہیے۔ lean-mode تجرید کی نفی نہیں کرتی، بلکہ موجودہ ضرورت اور مستحکم حد کے بغیر وقت سے پہلے بالواسطہ پرت بنانے کی مخالفت کرتی ہے۔
منظرنامہ چہارم: تعمیر اور ٹیسٹ مختصر کرنا
- موجودہ تعمیراتی عمل کو ترجیحاً دوبارہ استعمال کریں اور غیر ضروری طور پر بار بار cold start سے بچیں۔
- اضافی تعمیر کے نتائج برقرار رکھیں اور عادتاً
cleanنہ چلائیں۔ - پہلے صرف compile، صرف متعلقہ module کی جانچ، یا صرف ایک test چلانے والی کم سے کم command چلائیں۔
- کم سے کم توثیق کامیاب ہونے کے بعد module tests یا مکمل tests تک دائرہ بتدریج بڑھائیں۔
- بار بار call کی فریکوئنسی محدود کریں، اور code میں تبدیلی نہ ہونے پر ایک ہی command دوبارہ نہ چلائیں۔
- ممکنہ طور پر اٹکنے والی command کے لیے مناسب timeout مقرر کریں، اور ناکامی کے بعد پہلے بنیادی وجہ کا تجزیہ کریں۔
README میں موجود مکمل اسکل متن سات تعمیراتی نظاموں کے لیے “صرف یہی چلائیں” والا کم سے کم توثیقی چکر فراہم کرتا ہے۔ عملی استعمال میں ان مثالوں کو پہلے پروجیکٹ میں براہِ راست چلنے والی حقیقی commands سے بدلنا چاہیے۔
حد سے زیادہ دفاعی کوڈ کا آڈٹ
lean-mode “پہلے مقدار، پھر حذف” کا آڈٹ طریقہ فراہم کرتی ہے، جو ان پروجیکٹس کے لیے موزوں ہے جہاں بہت سی توثیقات، متبادل منطق یا استثنا نگلنے والی منطق جمع ہو چکی ہو۔
- تلاش اور مقداری جائزہ: زبان کے مطابق ضمیمے میں موجود search patterns استعمال کریں اور متعلقہ patterns کی تعداد اور کثافت گنیں۔
- جانچ کا دائرہ محدود کریں: صرف مسئلے کے لحاظ سے سب سے زیادہ مرتکز 5 فائلیں دیکھیں، شروع ہی میں پوری ریپوزٹری کا آڈٹ نہ کریں۔
- ہر معاملے کی درجہ بندی کریں: ہر منطقی حصے کو “حذف”، “اوپر منتقل” یا “برقرار” کا نشان دیں۔ “اوپر منتقل” عموماً توثیق کو حقیقی اعتماد کی حد پر مرکوز کرنے کی علامت ہے۔
- پہلے رپورٹ، پھر ترمیم: پہلے آڈٹ جدول صارف کو انتخاب کے لیے دیں، تصدیق کے بغیر بڑے پیمانے پر حذف نہ کریں۔
- مرحلہ وار توثیق: ترمیم کے بعد کم سے کم تعمیر اور ٹیسٹ کے دائرے سے جانچ کریں، پھر نتائج کے مطابق دائرہ بڑھائیں۔
یہ طریقہ قابلِ مشاہدہ، قابلِ انتخاب اور واپس کیے جا سکنے والے عمل پر زور دیتا ہے، تاکہ “دفاعی کوڈ کم کرنا” ایک اور بے قابو بڑی refactor نہ بن جائے۔
SKILL.md کو حسبِ ضرورت تبدیل کریں
SKILL.md خود Markdown ہے اور اسے براہِ راست ایڈٹ کیا جا سکتا ہے۔ درج ذیل تین قسم کی تخصیص سب سے زیادہ مفید ہیں۔
پروجیکٹ کی توثیقی commands تبدیل کریں
ساتویں حصے کی عمومی commands کو موجودہ پروجیکٹ میں واقعی چلنے والی “صرف compile” اور “صرف ایک test چلائیں” commands سے بدلیں۔ براہِ راست نقل کر کے چلائی جا سکنے والی command عموماً Agent کے رویے کو مجرد اصول سے زیادہ بہتر محدود کرتی ہے۔
Search patterns کو ایڈجسٹ کریں
پروجیکٹ کے code style کے مطابق ضمیمے کے search rules تبدیل کریں۔ مثلاً Java پروجیکٹ میں Guava کی Preconditions استعمال ہو سکتی ہے، یا بنیادی طور پر Objects.requireNonNull۔ Search patterns حقیقی code کے مطابق ہونے چاہییں۔
حوالہ جاتی کثافت ایڈجسٹ کریں
اسکل ہر 200 سے 500 لائنوں میں ایک توثیق کو تجرباتی حوالہ سمجھتی ہے، مگر یہ کوئی یکساں معیار نہیں۔ parser، protocol boundary اور کاروباری CRUD میں مناسب توثیقی کثافت مختلف ہوتی ہے؛ اسے domain risk اور ڈیٹا کے ماخذ کے مطابق ایڈجسٹ کریں۔
اعلیٰ سطح کی استعمالی تجاویز
- استثنائیں بھی context میں رکھیں: اسکل کے معیار heuristic rules ہیں، theorem نہیں۔ صرف “توثیق نہ کریں” یا “catch نہ کریں” جیسے مختصر نعروں تک محدود نہ ہوں۔
- Agent سے تبدیلی کی ساخت رپورٹ کروائیں: جب نئی تبدیلی 50 لائنوں سے زیادہ ہو تو اس سے کل لائنیں، توثیق اور متبادل منطق کی لائنیں، اور یہ logic نافذ نہ کرنے کی لاگت واضح طور پر بتانے کو کہیں۔
- توثیقی دائرہ بتدریج بڑھائیں: متعلقہ فائل، ایک test یا module سے شروع کریں، پھر بڑے test دائرے میں جائیں، تاکہ ہر ترمیم پر مکمل تعمیر نہ چلے۔
- متبادل منطق کے لیے ثبوت استعمال کریں: اسے برقرار رکھنا ضروری ہو تو مسئلے کا مخصوص ماخذ، تصدیقی نتیجہ اور مستقبل میں حذف کرنے کی شرط درج کریں؛ ناقابلِ تصدیق جملے جیسے “کچھ ماحول میں خرابی آ سکتی ہے” استعمال نہ کریں۔
- “ترمیم نہ کرنا” کو مؤثر نتیجہ سمجھیں: اگر مسئلہ موجودہ logic سے حل ہو چکا ہے، یا نئی code کی واضح افادیت نہیں، تو Agent کو براہِ راست بتانے دیں کہ تبدیلی ضروری نہیں۔
صلاحیت کی حدود اور اختیاری تکمیلی اجزا
lean-mode ماڈل کے رجحان کو بدلتی ہے، ماڈل کی صلاحیت کو نہیں۔ یہ ماڈل کو کسی خاص قسم کا کوڈ لکھنے سے زبردستی نہیں روک سکتی؛ صرف مناسب وقت پر معیار کو context میں شامل کر سکتی ہے، اس لیے یہ مفید ہے مگر ضمانت نہیں۔
یہ static analyzer بھی نہیں ہے اور خودکار طور پر code پڑھ یا scan نہیں کرے گی۔ ضمیمے میں موجود آڈٹ کے لیے Agent کو متعلقہ search command خود چلانی اور نتائج کی بنیاد پر فیصلہ کرنا ہوگا۔
اختیاری Vantaloom کا ہم نام plugin ہر مرحلے کے dynamic context میں مختصر اصول مسلسل شامل کرتا ہے، اور tool results کے اختتامی نوٹس اور lean_review tool فراہم کرتا ہے۔ Plugin مسلسل یاد دہانی کراتا ہے، جبکہ skill مکمل معیار فراہم کرتی ہے۔ Plugin انسٹال نہ کرنے کی صورت میں بھی یہ skill آزادانہ طور پر استعمال کی جا سکتی ہے۔
پروجیکٹ ریپوزٹری GitHub پر lean-mode-skill میں دیکھی جا سکتی ہے اور MIT لائسنس کے تحت جاری کی گئی ہے۔
اختتامیہ
lean-mode کی قدر میکانکی طور پر code کم کرنے میں نہیں، بلکہ اس بات میں ہے کہ ہر توثیق، استثنا سنبھالنے، تجرید، متبادل منطق اور توثیقی command کے لیے وجہ بیان کی جا سکے۔ انسٹالیشن کے بعد اسے پروجیکٹ کی حقیقی commands، search patterns اور risk density کے مطابق حسبِ ضرورت ڈھالنے سے کوڈنگ Agent کو اصل وجوہ پر زیادہ توجہ مرکوز کرنے اور مختصر، زیادہ قابلِ اعتماد انجینئرنگ feedback loop قائم کرنے میں مدد مل سکتی ہے۔