lean-mode কী
lean-mode হলো কোডিং Agent-এর জন্য তৈরি একটি SKILL.md। এর লক্ষ্য “কোড যত কম তত ভালো” নয়; বরং এটি Agent-কে স্পষ্ট মানদণ্ড দেয়, যাতে সে দুটি ইঞ্জিনিয়ারিং প্রশ্নের উত্তর দিতে পারে:
- দেখতে নিরাপদ কোনো কোড লেখা সত্যিই দরকার কি না, যেমন যাচাই,
try/catch, অ্যাবস্ট্রাকশন স্তর, ফলব্যাক লজিক বা অতিরিক্ত নিরাপত্তা সাবসিস্টেম। - বর্তমান বিল্ড ও টেস্ট এত ধীর কেন এবং কীভাবে অদক্ষ যাচাইকরণ চক্রকে যুক্তিসংগত সময়ে আনা যায়।
স্কিল ফাইলটি skills/lean-mode/SKILL.md-এ রয়েছে। এতে স্ট্যান্ডার্ড frontmatter, অর্থাৎ name, description এবং Markdown মূল লেখা ব্যবহার করা হয়েছে। এটি কোনো নির্দিষ্ট হোস্টের ওপর নির্ভরশীল নয়; SKILL.md কনভেনশন সমর্থনকারী যেকোনো Agent এটি ব্যবহার করতে পারে।
এটি যে মূল সমস্যাগুলো সমাধান করে
দীর্ঘ কোডিং সেশনে মডেলের মধ্যে দুটি পদ্ধতিগত প্রবণতা দেখা দিতে পারে: অতিরিক্ত প্রতিরক্ষামূলক প্রোগ্রামিং এবং অদক্ষ যাচাইকরণ চক্র।
অতিরিক্ত প্রতিরক্ষামূলক প্রোগ্রামিং
সাধারণ লক্ষণগুলোর মধ্যে রয়েছে অভ্যন্তরীণভাবে বিশ্বাসযোগ্য ডেটায় বারবার null যাচাই করা, মূল কারণ আড়াল করতে ব্যতিক্রম ধরা, একটি বাস্তবায়নের জন্য আগেভাগেই অ্যাবস্ট্র্যাকশন তৈরি করা এবং সমস্যার উৎস নিশ্চিত না করেই ধারাবাহিকভাবে ফলব্যাক যোগ করা। কোড বাইরে থেকে আরও “নিরাপদ” মনে হতে পারে, কিন্তু এতে রক্ষণাবেক্ষণের খরচ বাড়ে এবং স্পষ্ট ব্যর্থতা অনুসরণ করা কঠিন এমন ত্রুটিমূল্যে পরিণত হয়।
অদক্ষ যাচাইকরণ চক্র
সাধারণ লক্ষণগুলোর মধ্যে রয়েছে ঘন ঘন সম্পূর্ণ বিল্ড চালানো, বারবার clean ব্যবহার করা, দীর্ঘস্থায়ী প্রসেস নিষ্ক্রিয় করা, প্রতিবার সব টেস্ট চালানো এবং স্পষ্টভাবে আটকে থাকা কমান্ডকে দীর্ঘ সময় অপেক্ষা করতে দেওয়া। lean-mode প্রসেস পুনর্ব্যবহার, ইনক্রিমেন্টাল এক্সিকিউশন, পরিসর নিয়ন্ত্রণ, এক্সিকিউশন ক্রম, কলের ঘনত্ব ও টাইমআউট ব্যবস্থাপনা এই ছয় ধরনের নিয়মের মাধ্যমে আচরণগুলো নিয়ন্ত্রণ করে।
README-এর পরিমাণগত তথ্য প্রায় 20k লাইনের Java ও Gradle প্রকল্পে একটি দীর্ঘ সেশনের ফল। এগুলো শুধু সমস্যাটি বাস্তব என்பதை বোঝাতে ব্যবহৃত হয়েছে; বিভিন্ন মডেল বা প্রকল্পের জন্য শিল্পমান হিসেবে বিবেচনা করা উচিত নয়।
প্রধান সক্ষমতা
- বিশ্বাসের সীমানায় একবারই যাচাই করুন: প্রথমে “এই null কোথা থেকে এসেছে” প্রশ্নের উত্তর দিতে বলে, যাতে বিশ্বাসযোগ্য ডেটা সিস্টেমে প্রবেশের পরও স্তরে স্তরে একই যাচাই না হয়।
- মূল কারণ গিলে ফেলবেন না:
catch-এর পরnull,false, খালি সংগ্রহ বা শূন্যমান ফেরানোর বিষয়ে সতর্ক করে, কারণ এগুলো স্পষ্ট ব্যর্থতাকে আরও কঠিনে শনাক্তযোগ্য ত্রুটিতে রূপান্তর করতে পারে। - আগাম অ্যাবস্ট্র্যাকশন সীমিত করুন: কেবল একটি বাস্তবায়ন থাকা অবস্থায়, ভবিষ্যতে পরিবর্তন হতে পারে এমন সম্ভাবনার জন্য তৈরি অ্যাবস্ট্র্যাকশন সবসময় সত্যিকারের স্থিতিশীল সম্প্রসারণসীমা তৈরি করে না।
- মূল কারণ আগে ঠিক করুন: ফলব্যাক যোগ করার অর্থ মূল কারণ এখনো পুরোপুরি সমাধান হয়নি। সত্যিই ফলব্যাক দরকার হলে সমস্যার দায়িত্ব, অপসারণের শর্ত এবং যাচাই করা ভিত্তি ব্যাখ্যা করতে হবে।
- পরিবর্তনের পরিমাণকে আচরণগত পরিবর্তনের সঙ্গে সামঞ্জস্য করুন: নতুন কোড 50 লাইনের বেশি হলে আগে মোট লাইন, যাচাই ও ফলব্যাকের লাইনের সংখ্যা এবং এই কোড না লেখার বাস্তব খরচ জানাতে হবে।
- নিরাপদ কোড লেখার আগে তিনটি প্রশ্নের উত্তর দিন: সমস্যাটি কি সত্যিই ঘটবে, ঘটলে ব্যবহারকারীর কী হবে, এবং যাচাই না লেখার খরচ কী। কোনো প্রশ্নের উত্তর না জানা থাকলে আগে কোড যোগ করবেন না।
- যাচাইকরণ চক্র ছোট করুন: Gradle, Maven, Go, Node ও TypeScript, Rust, Python এবং .NET এই সাত ধরনের বিল্ড সিস্টেমের জন্য ন্যূনতম যাচাইকরণ পদ্ধতি অন্তর্ভুক্ত করে।
- “কোনো পরিবর্তন দরকার নেই” সিদ্ধান্তের অনুমতি দিন: লক্ষ্য হলো সমস্যা সমাধান করা, জোর করে কোড তৈরি করা নয়; ব্যবহারকারী না চাইলে অপ্রাসঙ্গিক অংশে অতিরিক্ত শক্তিশালীকরণও করা উচিত নয়।
- বিদ্যমান কোড অডিটের প্রক্রিয়া দিন: প্রথমে ঘনত্ব পরিমাপ করুন, তারপর সবচেয়ে গুরুতর ফাইলগুলো পরীক্ষা করুন, প্রতিটি ক্ষেত্রে অপসারণ, উপরে সরানো বা রেখে দেওয়ার সিদ্ধান্ত নিন এবং পরিবর্তনের আগে ব্যবহারকারীর কাছে ফলাফলের টেবিল জমা দিন।
প্রতিরক্ষামূলক কোডের জন্য স্কিলে Java, Go, TypeScript ও Python-এর চারটি ভাষার পাল্টা উদাহরণ রয়েছে, যা Agent-কে বিভিন্ন সিনট্যাক্সের আড়ালে থাকা একই ধরনের সমস্যা শনাক্ত করতে সাহায্য করে।
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 মূলত প্রয়োজন অনুযায়ী স্কিলের বিবরণ কনটেক্সটে প্রবেশের ওপর নির্ভর করে। Agent যখন যাচাই, ব্যতিক্রম ধরা, অ্যাবস্ট্র্যাকশন স্তর, ফলব্যাক বা অতিরিক্ত নিরাপত্তা সাবসিস্টেম যোগ করতে প্রস্তুত হয়, অথবা একটি ধাপে একাধিকবার বিল্ড ও টেস্ট চালায়, তখন এটি সক্রিয় হওয়া উচিত।
পরিস্থিতি এক: নতুন যাচাই দরকার কি না নির্ধারণ
- প্রথমে ডেটার উৎস নির্ধারণ করুন এবং এটি বাহ্যিক ইনপুট, ইন্টারফেস সীমানা বা অন্য কোনো অবিশ্বাসযোগ্য উৎস থেকে এসেছে কি না নিশ্চিত করুন।
- একই সীমাবদ্ধতা ইতিমধ্যে বিশ্বাসের সীমানায় যাচাই করা হয়েছে কি না পরীক্ষা করুন।
- সমস্যাটি সত্যিই ঘটতে পারে কি না, ঘটলে ব্যবহারকারীর ওপর কী প্রভাব পড়বে এবং যাচাই না লেখার খরচ কত, তা নির্ধারণ করুন।
- ডেটা অভ্যন্তরীণ ব্যবহারে প্রবেশের পর বিশ্বাসযোগ্য হলে একই ধরনের রানটাইম যাচাই স্তরে স্তরে পুনরায় যোগ করবেন না।
উদাহরণস্বরূপ, Agent যদি একাধিক অভ্যন্তরীণ পদ্ধতিতে বারবার Objects.requireNonNull যোগ করতে চায়, তাহলে শুধু প্যারামিটারটি “তাত্ত্বিকভাবে null হতে পারে” বলে তা যোগ করা উচিত নয়। বরং null-এর বাস্তব উৎস অনুসরণ করে দেখতে হবে এবং সীমানায় ইতিমধ্যে যাচাই সম্পন্ন হয়েছে কি না নির্ধারণ করতে হবে।
পরিস্থিতি দুই: ব্যতিক্রম পরিচালনা
Agent যখন ব্যতিক্রম ধরে ডিফল্ট মান ফেরাতে প্রস্তুত হয়, তখন প্রথমে নিশ্চিত হওয়া উচিত যে এতে মূল কারণ আড়াল হবে কি না। নিচের ধরনটি বিশেষভাবে পর্যালোচনা করা দরকার:
catch (...) {
return false;
}লক্ষ্য সব ব্যতিক্রম ধরা নিষিদ্ধ করা নয়; বরং শনাক্তযোগ্য ব্যর্থতাকে প্রাসঙ্গিক তথ্যহীন false, null, খালি ফলাফল বা শূন্যমানে পরিণত করা এড়ানো। ব্যবসায়িক প্রয়োজনে সত্যিই অবনমন দরকার হলে স্কিলের ব্যতিক্রম শর্ত অনুযায়ী তা মূল্যায়ন করতে হবে।
পরিস্থিতি তিন: অ্যাবস্ট্র্যাকশন স্তর মূল্যায়ন
কোনো ইন্টারফেসের বর্তমানে যদি মাত্র একটি বাস্তবায়ন থাকে এবং এটি তৈরির একমাত্র কারণ যদি হয় “ভবিষ্যতে বদলাতে পারে”, তাহলে Agent-এর থেমে প্রকৃত পরিবর্তনসীমা পরীক্ষা করা উচিত। lean-mode অ্যাবস্ট্র্যাকশন অস্বীকার করে না; বর্তমান প্রয়োজন ও স্থিতিশীল সীমার অনুপস্থিতিতে আগেভাগে একটি মধ্যবর্তী স্তর তৈরির বিরোধিতা করে।
পরিস্থিতি চার: বিল্ড ও টেস্ট ছোট করা
- বিদ্যমান বিল্ড প্রসেস পুনর্ব্যবহারকে অগ্রাধিকার দিন এবং অপ্রয়োজনীয়ভাবে বারবার নতুন করে চালু করা এড়ান।
- ইনক্রিমেন্টাল আর্টিফ্যাক্ট রেখে দিন; অভ্যাসবশত
cleanচালাবেন না। - প্রথমে শুধু কম্পাইল, শুধু সংশ্লিষ্ট মডিউল পরীক্ষা বা শুধু একটি টেস্ট চালানোর মতো ন্যূনতম কমান্ড ব্যবহার করুন।
- ন্যূনতম যাচাই সফল হলে ধীরে ধীরে মডিউল টেস্ট বা সম্পূর্ণ টেস্টে বিস্তৃত করুন।
- পুনরাবৃত্ত কলের ঘনত্ব নিয়ন্ত্রণ করুন; কোড পরিবর্তন না হলে একই কমান্ড বারবার চালাবেন না।
- আটকে যেতে পারে এমন কমান্ডের জন্য যুক্তিসংগত টাইমআউট নির্ধারণ করুন এবং ব্যর্থতার পর প্রথমে প্রথম মূল কারণ বিশ্লেষণ করুন।
README-এর সম্পূর্ণ স্কিলের মূল লেখায় সাতটি বিল্ড সিস্টেমের জন্য “শুধু এইটিই চালান” ধরনের ন্যূনতম যাচাইকরণ চক্র দেওয়া হয়েছে। বাস্তব ব্যবহারে এসব উদাহরণ প্রকল্পে সরাসরি চালানো যায় এমন প্রকৃত কমান্ড দিয়ে প্রতিস্থাপন করা উচিত।
অতিরিক্ত প্রতিরক্ষামূলক কোড অডিট করা
lean-mode-এর সঙ্গে “আগে পরিমাপ, পরে অপসারণ” ধরনের একটি অডিট প্রক্রিয়া রয়েছে, যা ইতিমধ্যে বিপুল যাচাই, ফলব্যাক বা ব্যতিক্রম-গোপনকারী লজিক জমে থাকা প্রকল্পে উপযোগী।
- খুঁজে পরিমাণ নির্ধারণ করুন: ভাষাভেদে পরিশিষ্টের অনুসন্ধান প্যাটার্ন ব্যবহার করে সংশ্লিষ্ট প্যাটার্নের সংখ্যা ও ঘনত্ব গণনা করুন।
- পর্যালোচনার পরিসর সংকুচিত করুন: প্রথমেই পুরো রিপোজিটরি অডিট না করে সমস্যার ঘনত্ব সবচেয়ে বেশি এমন 5টি ফাইল দেখুন।
- প্রতিটি ক্ষেত্রে শ্রেণিবিন্যাস করুন: প্রতিটি লজিককে “অপসারণ”, “উপরে সরানো” বা “রেখে দেওয়া” হিসেবে চিহ্নিত করুন। “উপরে সরানো” সাধারণত প্রকৃত বিশ্বাসের সীমানায় যাচাই কেন্দ্রীভূত করা বোঝায়।
- আগে রিপোর্ট, পরে পরিবর্তন: প্রথমে অডিট টেবিল ব্যবহারকারীর কাছে দিয়ে তার পছন্দ নিন; নিশ্চিত না হয়ে বড় পরিসরে অপসারণ করবেন না।
- ধাপে ধাপে যাচাই করুন: পরিবর্তনের পর ন্যূনতম বিল্ড ও টেস্ট পরিসরে যাচাই করুন, তারপর ফলাফল অনুযায়ী পরিসর বাড়ান।
এই প্রক্রিয়ায় পর্যবেক্ষণযোগ্যতা, পছন্দের সুযোগ ও প্রত্যাবর্তনযোগ্যতার ওপর জোর দেওয়া হয়, যাতে “প্রতিরক্ষামূলক কোড কমানো” আরেকটি নিয়ন্ত্রণহীন বড় রিফ্যাক্টরিংয়ে পরিণত না হয়।
SKILL.md কাস্টমাইজ করা
SKILL.md নিজেই Markdown, তাই এটি সরাসরি সম্পাদনা করা যায়। নিচের তিন ধরনের কাস্টমাইজেশন সবচেয়ে মূল্যবান।
প্রকল্পের যাচাইকরণ কমান্ড বদলান
সপ্তম অংশের সাধারণ কমান্ডগুলো বর্তমান প্রকল্পে সত্যিই চালানো যায় এমন “শুধু কম্পাইল” এবং “শুধু একটি টেস্ট চালানো” কমান্ড দিয়ে বদলান। সরাসরি কপি করে চালানো যায় এমন একটি কমান্ড প্রায়ই বিমূর্ত নীতির চেয়ে Agent-এর আচরণকে ভালোভাবে নিয়ন্ত্রণ করে।
অনুসন্ধান প্যাটার্ন সামঞ্জস্য করুন
প্রকল্পের কোড স্টাইল অনুযায়ী পরিশিষ্টের অনুসন্ধান নিয়ম পরিবর্তন করুন। উদাহরণস্বরূপ, Java প্রকল্পে Guava Preconditions ব্যবহৃত হতে পারে, আবার প্রধানত Objects.requireNonNull-ও ব্যবহৃত হতে পারে। অনুসন্ধান প্যাটার্ন বাস্তব কোডের সঙ্গে সামঞ্জস্যপূর্ণ হওয়া উচিত।
রেফারেন্স ঘনত্ব সামঞ্জস্য করুন
স্কিলে প্রতি 200 থেকে 500 লাইনে একটি যাচাইকে অভিজ্ঞতাভিত্তিক রেফারেন্স হিসেবে ধরা হয়েছে, কিন্তু এটি কোনো সার্বজনীন মান নয়। পার্সার, প্রোটোকল সীমানা ও ব্যবসায়িক CRUD-এর যুক্তিসংগত যাচাই ঘনত্ব আলাদা; তাই ডোমেইনের ঝুঁকি ও ডেটার উৎস অনুযায়ী তা সামঞ্জস্য করুন।
উন্নত ব্যবহারের পরামর্শ
- ব্যতিক্রমগুলোও কনটেক্সটে রাখুন: স্কিলের মানদণ্ড হিউরিস্টিক নিয়ম, উপপাদ্য নয়। শুধু “যাচাই করবেন না” বা “catch করবেন না” ধরনের সরল স্লোগান রেখে দেবেন না।
- Agent-কে পরিবর্তনের গঠন জানাতে বলুন: নতুন কোড 50 লাইনের বেশি হলে মোট লাইন, যাচাই ও ফলব্যাকের লাইনের সংখ্যা এবং এই লজিক বাস্তবায়ন না করার খরচ স্পষ্টভাবে জানাতে বলুন।
- যাচাইয়ের পরিসর ধাপে ধাপে বাড়ান: সংশ্লিষ্ট ফাইল, একক টেস্ট বা মডিউল দিয়ে শুরু করে পরে বড় টেস্ট পরিসরে যান, যাতে প্রতিটি পরিবর্তনে সম্পূর্ণ বিল্ড চালু না হয়।
- প্রমাণ দিয়ে ফলব্যাক ব্যাখ্যা করুন: ফলব্যাক রাখতেই হলে নির্দিষ্ট সমস্যার উৎস, যাচাইয়ের ফল এবং ভবিষ্যতে অপসারণের শর্ত নথিবদ্ধ করুন; যাচাই করা যায় না এমন “কিছু পরিবেশে সমস্যা হতে পারে” ধরনের বক্তব্য ব্যবহার করবেন না।
- “পরিবর্তন না করা”-কে বৈধ ফল হিসেবে গ্রহণ করুন: বিদ্যমান লজিকেই সমস্যা সমাধান হয়ে গেলে, অথবা নতুন কোডে স্পষ্ট সুবিধা না থাকলে, Agent যেন সরাসরি জানাতে পারে যে কোনো পরিবর্তন দরকার নেই।
সক্ষমতার সীমা ও ঐচ্ছিক সহায়ক উপাদান
lean-mode মডেলের প্রবণতা বদলায়, মডেলের সক্ষমতা নয়। এটি মডেলকে কোনো নির্দিষ্ট ধরনের কোড লেখা থেকে জোর করে বিরত রাখতে পারে না; শুধু উপযুক্ত সময়ে মানদণ্ড কনটেক্সটে যুক্ত করতে পারে। তাই এটি কার্যকর হলেও নিশ্চয়তা নয়।
এটি কোনো স্ট্যাটিক অ্যানালাইজারও নয়; স্বয়ংক্রিয়ভাবে কোড পড়ে বা স্ক্যান করে না। পরিশিষ্টের অডিটের জন্য Agent-কে নিজে সংশ্লিষ্ট অনুসন্ধান কমান্ড চালিয়ে ফলাফলের ভিত্তিতে সিদ্ধান্ত নিতে হবে।
ঐচ্ছিক Vantaloom-এর একই নামের প্লাগইনটি সংকুচিত নীতিমালা প্রতিটি ধাপের ডায়নামিক কনটেক্সটে রাখে এবং টুল ফলাফলের টেইলনোট ও lean_review টুল দেয়। প্লাগইনটি ধারাবাহিক স্মরণ করিয়ে দেয়, আর স্কিলটি সম্পূর্ণ মানদণ্ড সরবরাহ করে। প্লাগইন ইনস্টল না করলেও এই স্কিল স্বাধীনভাবে ব্যবহার করা যায়।
প্রকল্পের রিপোজিটরি GitHub-এর lean-mode-skill-এ দেখা যাবে; এটি MIT লাইসেন্সের অধীনে প্রকাশিত।
উপসংহার
lean-mode-এর মূল্য যান্ত্রিকভাবে কোড কমানোর মধ্যে নয়; বরং প্রতিটি যাচাই, ব্যতিক্রম পরিচালনা, অ্যাবস্ট্র্যাকশন, ফলব্যাক ও যাচাইকরণ কমান্ডের পেছনে যুক্তি নিশ্চিত করার মধ্যে। ইনস্টলের পর প্রকল্পের বাস্তব কমান্ড, অনুসন্ধান প্যাটার্ন ও ঝুঁকির ঘনত্ব অনুযায়ী কাস্টমাইজ করলে এটি কোডিং Agent-কে মূল কারণের দিকে বেশি মনোযোগী হতে এবং আরও ছোট, নির্ভরযোগ্য ইঞ্জিনিয়ারিং প্রতিক্রিয়া চক্র গড়ে তুলতে সাহায্য করতে পারে।