Forward Implementation First কী করে
Forward Implementation First হলো এমন একটি এজেন্ট স্কিল, যা কোডিং এজেন্টদের পাইপলাইনের হিসাবরক্ষণে আটকে পড়া ঠেকানোর জন্য তৈরি। এটি অনুরোধ করা পণ্য তৈরি করা, প্রভাবিত আচরণ যাচাই করা এবং সামনে এগিয়ে যাওয়ার দিকে মনোযোগ রাখে; বারবার হ্যাশ, রসিদ, লক, ড্যাশবোর্ড বা অগ্রগতি চিহ্ন মেরামত করার দিকে নয়।
প্রকল্পটি মূলত YAML frontmatter-সহ প্রায় 150 লাইনের একটি Markdown স্কিল নিয়ে গঠিত। এটি Agent Skills convention অনুসরণ করে এবং মডেল, টুল ও ডোমেইন-নিরপেক্ষ।
দীর্ঘস্থায়ী ওয়ার্কফ্লোতে এই স্কিলটি বিশেষভাবে কার্যকর, যেখানে একটি orchestrator ক্রমবদ্ধ ধাপগুলোর মেটাডেটা সংরক্ষণ করে। সেই মেটাডেটা পুরোনো হয়ে গেলে, কোনো এজেন্ট অসামঞ্জস্যকে আগে সঠিক থাকা আউটপুট ভুল হওয়ার প্রমাণ হিসেবে ধরে নিতে পারে। Forward Implementation First এমন একটি সিদ্ধান্তের নিয়ম দেয়, যা প্রকৃত সঠিকতা-সংক্রান্ত কাজকে প্রশাসনিক রক্ষণাবেক্ষণ থেকে আলাদা করে।
মূল শ্রেণিবিন্যাস
কোনো পদক্ষেপ নেওয়ার আগে এজেন্ট সেটিকে তিনটি শ্রেণির একটিতে ভাগ করে।
- Semantic implementation: কোনো producer, consumer, adapter, runtime path, schema, fixture বা চূড়ান্ত আউটপুট তৈরি বা সংযুক্ত করার কাজ।
- Focused validation: পরিবর্তিত dependency cone পরীক্ষা করা; এর মধ্যে আচরণ, schema, গণনা, ক্রমবদ্ধ নমুনা, সংরক্ষণ, সামঞ্জস্য, অসম্পূর্ণভাবে কেটে না যাওয়া এবং পরিমাপ করা সময় বা মেমরি অন্তর্ভুক্ত।
- Administrative bookkeeping: হ্যাশ, লক, রসিদ, ড্যাশবোর্ড, certification marker, অগ্রগতি-সংক্রান্ত মেটাডেটা বা শুধু উপস্থিতি-নির্ভর রেকর্ড তৈরি বা মেরামতের কাজ।
কার্যপদ্ধতির নিয়মটি সহজ: semantic implementation এবং focused validation সম্পন্ন করুন। ব্যবহারকারী স্পষ্টভাবে অনুরোধ না করলে বা artifact-টি পণ্যের অংশ না হলে administrative bookkeeping এড়িয়ে চলুন। শুধু হিসাবরক্ষণ-নির্ভর কোনো dependency যদি সঠিকতা রক্ষা না করেই উৎপাদনশীল কাজে বাধা দেয়, তাহলে সেই dependency সরিয়ে দিন।
পাইপলাইনের হিসাবরক্ষণ কেন সমস্যা হয়ে দাঁড়ায়
এমন একটি পাইপলাইন বিবেচনা করুন, যেখানে stage 40 stage 41-এর জন্য একটি ফাইল তৈরি করে। Orchestrator একটি completion marker এবং input hash-সহ একটি JSON রেকর্ডও লেখে। কোনো producer পরিবর্তিত হলে হ্যাশ আর না মিলতে পারে, যদিও বিদ্যমান stage output সঠিকই থাকে।
স্পষ্ট নীতি না থাকলে, কোনো এজেন্ট আগের অনেকগুলো stage বাতিল করতে পারে, stage 41 ম্যানুয়ালি চালাতে অস্বীকৃতি জানাতে পারে, সম্পর্কহীন marker পুনরায় তৈরি করতে পারে এবং মেরামত করা মেটাডেটাকে অগ্রগতি হিসেবে জানাতে পারে। প্রতিটি স্থানীয় সিদ্ধান্ত সতর্ক মনে হতে পারে, কিন্তু সম্মিলিত ফলাফল অনুরোধ করা আউটপুট উন্নত না করেই সময় নষ্ট করে।
প্রশাসনিক মেটাডেটা কোনো আউটপুট সঠিক হওয়ার প্রমাণের বিকল্প নয়।
এই স্কিলটি এজেন্টদের মেটাডেটার উপস্থিতি বা হালনাগাদ অবস্থাকে প্রমাণ হিসেবে না ধরে পরিণতি যাচাই করতে বাধ্য করে এই ব্যর্থতা প্রতিরোধ করে।
স্কিলটি যা শিথিল করে না
Forward Implementation First সঠিকতা উপেক্ষা করার কোনো নির্দেশ নয়। এটি অপসারণযোগ্য orchestration record-কে integrity mechanism এবং পণ্যকে সত্যিই সুরক্ষিত রাখা প্রমাণ থেকে আলাদা করে।
- পণ্যের integrity অপরিহার্য। ব্যবহারকারীর দ্বারা যাচাই করা checksum, প্রয়োজনীয় signature এবং output contract-এ সংজ্ঞায়িত hash হলো পণ্যের বৈশিষ্ট্য, কাগজপত্র নয়।
- Input এবং revision identity অপরিহার্য। কোনো এজেন্টকে জানতে হবে সে কোন version বা target পরিবর্তন করছে।
- ফলাফল-কেন্দ্রিক test অপরিহার্য। Benchmark, reproduction, test এবং end-to-end run এখনও অপরিহার্য প্রমাণ সরবরাহ করে।
- Coverage আর consequence এক নয়। কোনো path চালানো মানেই সেই path সঠিক উত্তর তৈরি করেছে, তা প্রমাণিত হয় না।
Command, input, result এবং যাচাই করা expectation-সহ একটি execution record প্রকৃত প্রমাণ হতে পারে। এটি না থাকলে, এজেন্ট সেই record যে দাবির সমর্থন করত তা করতে পারে না। তবে এর অনুপস্থিতি পাইপলাইনের আগের সম্পর্কহীন stage-গুলোকে স্বয়ংক্রিয়ভাবে অবৈধ করে না।
ইনস্টলেশন
শনাক্ত করা Agent Skill Directory-তে ইনস্টল করুন
Repository clone করে অন্তর্ভুক্ত installation script চালান:
git clone https://github.com/Vuk97/forward-implementation-first
cd forward-implementation-first
./install.shস্ক্রিপ্টটি শনাক্ত করা প্রতিটি সমর্থিত agent skill directory-তে SKILL.md কপি করে। নথিভুক্ত destination-গুলো হলো:
- Claude Code:
~/.claude/skills/forward-implementation-first/ - Codex:
~/.codex/skills/forward-implementation-first/ - Shared convention:
~/.agents/skills/forward-implementation-first/
একটি প্রকল্পের জন্য ইনস্টল করুন
প্রকল্প-নির্দিষ্ট আচরণের জন্য skill directory-টি repository-র .claude/skills/ বা .agents/skills/-এ কপি করুন। এতে নীতিটি প্রতিটি workspace-এ ইনস্টল না হয়ে ওই প্রকল্পের সঙ্গে যুক্ত থাকে।
ইনস্টলেশনের পর agent পুনরায় চালু করুন। বিদ্যমান session-গুলো স্বয়ংক্রিয়ভাবে skill পুনরায় লোড করে না।
একটি skill হলো একটি পরামর্শ, এবং এটি লোড করা হবে কি না মডেল তা নির্ধারণ করে। আপনার agent যদি always-on rule বা hook সমর্থন করে, তাহলে মূল সিদ্ধান্তের নিয়মটিও সেখানে রাখুন।
মৌলিক ব্যবহার
ধাপ 1: পরবর্তী পণ্য-প্রাসঙ্গিক পদক্ষেপ শনাক্ত করুন
বর্তমান pipeline cursor বা পরবর্তী অসম্পূর্ণ dependency থেকে শুরু করুন। প্রস্তাবিত পদক্ষেপটি implementation পরিবর্তন করে, পরিবর্তিত কোনো consequence যাচাই করে, নাকি শুধু orchestration metadata মেরামত করে, তা নির্ধারণ করুন।
Proposed action: Connect stage 41 to the output produced by stage 40.
Classification: Semantic implementation.
Decision: Perform the action.ধাপ 2: পরিবর্তিত Dependency Cone যাচাই করুন
বাস্তবায়নের পরে, যে ক্ষুদ্রতম অঞ্চলে প্রভাব পড়তে পারে সেটি পরীক্ষা করুন। উপযুক্ত যাচাইয়ের মধ্যে স্কিমা, সারি বা আইটেমের সংখ্যা, ক্রমবদ্ধ নমুনা, সংরক্ষণ ধর্ম, সামঞ্জস্য, ছাঁটাই শনাক্তকরণ, এন্ড-টু-এন্ড আচরণ এবং পরিমাপ করা রিসোর্স ব্যবহারের পরীক্ষা অন্তর্ভুক্ত থাকতে পারে।
প্রস্তাবিত পদক্ষেপ: এর উৎপাদক পরিবর্তনের পর ৪১ নম্বর ধাপের স্কিমা, আউটপুট সংখ্যা, ক্রমবদ্ধ নমুনা
এবং অপূর্ণ ছাঁটাই না থাকার বিষয়টি যাচাই করুন।
শ্রেণিবিন্যাস: কেন্দ্রীভূত যাচাই।
সিদ্ধান্ত: যাচাইগুলো সম্পন্ন করুন এবং প্রমাণ নথিভুক্ত করুন।ধাপ ৩: ডিফল্ট লক্ষ্য হিসেবে হিসাবরক্ষণ প্রত্যাখ্যান করুন
একমাত্র প্রস্তাবিত পদক্ষেপ যদি পুরোনো রসিদ বা সম্পন্নতার চিহ্ন পুনরায় তৈরি করা হয়, তাহলে সেটি এড়িয়ে যান—যদি না ব্যবহারকারী ওই আর্টিফ্যাক্টটি চান বা সেটি নিজেই সরবরাহযোগ্য অংশ হয়।
প্রস্তাবিত পদক্ষেপ: অপরিবর্তিত ১২ থেকে ৪০ নম্বর ধাপের সম্পন্নতার রসিদ পুনর্নির্মাণ করুন।
শ্রেণিবিন্যাস: প্রশাসনিক হিসাবরক্ষণ।
সিদ্ধান্ত: স্পষ্টভাবে অনুরোধ করা না হলে বা পণ্যের প্রয়োজনে না হলে এড়িয়ে যান।ধাপ ৪: শুধুমাত্র প্রশাসনিক গেট সরিয়ে ফেলুন
যদি কোনো পুরোনো চিহ্ন পরবর্তী বৈধ ধাপটি চালাতে বাধা দেয়, কিন্তু সঠিকতা সুরক্ষিত না করে, তাহলে ধাপটি ম্যানুয়ালি চালান, এর আউটপুট যাচাই করুন, তা প্রকাশ করুন এবং কার্সর থেকে চালিয়ে যান। এরপর শুধুমাত্র প্রশাসনিক এই নির্ভরতা সরিয়ে ফেলুন, যাতে একই বাধা আবার না ঘটে।
ফরোয়ার্ড কার্সর নিয়ম প্রয়োগ করুন
কোনো সম্পন্ন ধাপ পুনরায় চালানো বা রোলব্যাক করা উচিত কেবল তখনই, যখন এর কোনো বাস্তব কারণ থাকে। স্কিলটি নিম্নলিখিত কারণগুলো স্বীকার করে:
- ধাপের ইনপুটের অর্থ পরিবর্তিত হয়েছে।
- লক্ষ্য বা পিন করা রিভিশন পরিবর্তিত হয়েছে।
- আউটপুটটি বিকৃত, অপূর্ণ, সংরক্ষণধর্ম-বিরোধী, অসামঞ্জস্যপূর্ণ বা এর ভোক্তার সঙ্গে অসামঞ্জস্যপূর্ণ।
- পর্যবেক্ষিত কোনো রান আগের স্থির ফলাফলকে ভুল প্রমাণ করেছে।
- পরিবর্তিত উৎপাদকের ঘোষিত নির্ভরতা-পরিসরের মধ্যে ধাপটি অন্তর্ভুক্ত।
অনুপস্থিত বা পুরোনো মেটাডেটা একাই যথেষ্ট কারণ নয়। সম্পূর্ণ ইতিহাস পুনরায় শুরু না করে সবচেয়ে ছোট প্রভাবিত নির্ভরতা-পরিসর পুনরায় চালান।
পুনরুদ্ধার সিদ্ধান্তের উদাহরণ
পর্যবেক্ষণ: ৪০ নম্বর ধাপের রসিদ হ্যাশটি পুরোনো।
আউটপুট পরীক্ষা: ৪০ নম্বর ধাপের আর্টিফ্যাক্টটি সঠিকভাবে গঠিত এবং ৪১ নম্বর ধাপের সঙ্গে সামঞ্জস্যপূর্ণ।
নির্ভরতা পরীক্ষা: পরিবর্তিত উৎপাদকটি ৪০ নম্বর ধাপের অর্থকে প্রভাবিত করে না।
পদক্ষেপ: ৪০ নম্বর ধাপ পুনরায় চালাবেন না। ৪১ নম্বর ধাপে এগিয়ে যান এবং এর ফলাফল যাচাই করুন।যদি যাচাইয়ে বিকৃত বা অসামঞ্জস্যপূর্ণ আউটপুট পাওয়া যায়, তাহলে পুনরায় চালানো যুক্তিসঙ্গত, কারণ কারণটি প্রশাসনিক নয়, অর্থগত।
পরস্পরবিরোধী সত্য তৈরি না করে ওয়ার্কার পুল ব্যবহার করুন
স্কিলটি সমান্তরাল কাজের জন্যও একটি সুশৃঙ্খল পদ্ধতি নির্ধারণ করে।
- একসঙ্গে কেবল একটি ভারী প্রক্রিয়া চালান, যেমন কম্পাইলার, সম্পূর্ণ টেস্ট স্যুট, বড় ডেটা কাজ, বেঞ্চমার্ক বা দীর্ঘ স্ক্যান।
- পরস্পর-অতিক্রম না করা ফাইলগুলোতে হালকা কাজের জন্য সমান্তরাল লেন ব্যবহার করুন।
Nসংখ্যক ওয়ার্কার ব্যবহারের অনুমোদন থাকলে, সম্পূর্ণ একটি তরঙ্গ শেষ হওয়ার অপেক্ষা না করে লেনগুলো কাজ শেষ করার সঙ্গে সঙ্গে পুনরায় পূরণ করুন।- প্রতিটি ওয়ার্কারকে ব্যস্ত রাখার জন্য কম-মূল্যের কাজ উদ্ভাবন করবেন না।
- ভারী এক্সিকিউশন, প্রকাশনা, কার্সর সরানো এবং চূড়ান্ত সিদ্ধান্তগুলো রুট লেনে রাখুন।
- সমান্তরাল ওয়ার্কারদের প্রস্তুতি ও পরিদর্শনের কাজ করতে দিন, তবে তাদের আউটপুট ব্যবহারের আগে যাচাই করুন।
- প্রতিটি লেনের জন্য অপেক্ষা করে অগ্রগতি থামাবেন না। কোনো লেনের নির্ভরতা পৌঁছে গেলে তার ফলাফল গ্রহণ করুন।
এই কাঠামো একাধিক ওয়ার্কারকে পরস্পরবিরোধী সত্যের উৎসে পরিণত না করে কার্যকর সমান্তরাল কাজের সুযোগ দেয়।
উন্নত পরামর্শ
সিদ্ধান্তের নিয়ম সবসময় সক্রিয় কনফিগারেশনে স্থানান্তর করুন
কোনো মডেল কোনো স্কিল লোড না করার সিদ্ধান্ত নিতে পারে। তাই স্থায়ী নিয়ম বা হুক থাকা পরিবেশে কেন্দ্রীয় নীতিটি সেখানেও পুনরায় উল্লেখ করা উচিত: প্রতিটি পদক্ষেপ শ্রেণিবদ্ধ করুন, বাস্তবায়ন ও কেন্দ্রীভূত যাচাই সম্পন্ন করুন এবং অনুরোধ করা না হলে বা পণ্যের সঙ্গে সম্পর্কিত না হলে প্রশাসনিক কাজ এড়িয়ে চলুন।
পণ্যের অখণ্ডতা স্পষ্টভাবে নির্ধারণ করুন
কোন হ্যাশ, স্বাক্ষর, ম্যানিফেস্ট বা অডিট রেকর্ড আউটপুট চুক্তির অংশ, তা নথিভুক্ত করুন। এতে একজন এজেন্ট প্রকৃত বৈশিষ্ট্য ভুলভাবে বাদ দেওয়া থেকে বিরত থাকবে, আবার ব্যবহারযোগ্য নয় এমন অর্কেস্ট্রেশন চিহ্ন উপেক্ষা করতে পারবে।
নির্ভরতা-পরিসর ঘোষণা করুন
সম্ভব হলে উৎপাদক ও ভোক্তার সম্পর্ক স্পষ্টভাবে প্রকাশ করুন। একটি পরিষ্কার নির্ভরতা-পরিসর এজেন্টকে কেবল প্রভাবিত ধাপগুলো পুনরায় চালাতে সাহায্য করে এবং অনিশ্চতার কারণে বিস্তৃত অবৈধকরণ এড়ায়।
শুধু উপস্থিতি নয়, প্রমাণ নথিভুক্ত করুন
যে রেকর্ডে কমান্ড, ইনপুট, ফলাফল এবং প্রত্যাশিত শর্ত উল্লেখ থাকে, সেগুলো অগ্রাধিকার দিন। শুধু উপস্থিতির চিহ্ন বলে যে কিছু চালানো হয়েছে; প্রমাণসমৃদ্ধ রেকর্ড কাজটি সফল হয়েছে কি না তা প্রতিষ্ঠায় সহায়তা করে।
প্রস্তুতি ও কর্তৃত্ব আলাদা রাখুন
ফাইল পরিদর্শন, প্যাচ প্রস্তুত বা তথ্য সংগ্রহের জন্য সমান্তরাল ওয়ার্কার ব্যবহার করুন, কিন্তু এক্সিকিউশনের কর্তৃত্ব ও সিদ্ধান্ত রুট লেনের জন্য সংরক্ষণ করুন। ওয়ার্কারের আউটপুট মার্জ বা প্রকাশের আগে যাচাই করুন।
কখন স্কিলটি ব্যবহার করবেন
Forward Implementation First নিম্নলিখিত ক্ষেত্রে উপযোগী:
- ক্রমবদ্ধ ধাপ ও সংরক্ষিত কার্সরযুক্ত পাইপলাইন।
- পরবর্তী ধাপগুলোতে ব্যবহৃত জেনারেটেড আর্টিফ্যাক্ট।
- অর্কেস্ট্রেটর-উৎপাদিত ম্যানিফেস্ট, লকফাইল বা রসিদযুক্ত ওয়ার্কফ্লো।
- নিরবচ্ছিন্ন মানব তত্ত্বাবধান ছাড়াই চলমান রান।
- একাধিক এজেন্ট বা সেশনে ব্যবহৃত রিপোজিটরি।
- ETL পাইপলাইন, ধাপে ধাপে ডেটা প্রক্রিয়াকরণ, বড় কোড মাইগ্রেশন, বিল্ড ও রিলিজ ওয়ার্কফ্লো, ডকুমেন্টেশন জেনারেশন, ব্যাচ বিশ্লেষণ এবং বহুদিনের রোডম্যাপ।
একবারে সম্পন্ন হওয়া কাজ, সংক্ষিপ্ত ইন্টার্যাক্টিভ সেশন বা যেখানে অডিট ট্রেইল নিজেই সরবরাহযোগ্য অংশ, সেখানে এটি এড়িয়ে যান। ব্যবহারকারী বা পর্যালোচকদের রসিদ ব্যবহার করার কথা থাকলে, সেই রেকর্ডগুলো প্রশাসনিক অতিরিক্ত কাজ নয়, পণ্যের অংশ।
উপসংহার
Forward Implementation First কোডিং এজেন্টদের একটি সীমিত কিন্তু ব্যবহারিক শৃঙ্খলা দেয়: পণ্য তৈরি করুন, প্রভাবিত আচরণ যাচাই করুন এবং পাইপলাইনের কাগজপত্রকে সঠিকতার সমতুল্য মনে করবেন না। এর ফরোয়ার্ড কার্সর নিয়ম অপ্রয়োজনীয় পুনঃসম্পাদনা সীমিত করে, আর এর ওয়ার্কার পুল নির্দেশনা নিরাপদ সমান্তরাল কাজকে সমর্থন করে। স্কিলটি ইনস্টল করুন, এজেন্ট পুনরায় চালু করুন এবং যখন সুবিধাটি উপলভ্য থাকে, সর্বদা-সক্রিয় কনফিগারেশনের মাধ্যমে এর সিদ্ধান্তের নিয়ম আরও দৃঢ় করুন।