০৫ জানু, ২০২৬·6 মিনিট
মোনোরেপোতে Claude Code: প্রসঙ্গ সীমিত করে নির্ভুল থাকা
বৃহৎ মোনোরেপোতে Claude Code বিভ্রান্ত হতে পারে। সঠিক উত্তর রাখতে সীমানা নির্ধারণ, লোকাল সারাংশ এবং পুনরাবৃত্তিযোগ্য ওয়ার্কফ্লো শিখুন।
বৃহৎ মোনোরেপোতে Claude Code বিভ্রান্ত হতে পারে। সঠিক উত্তর রাখতে সীমানা নির্ধারণ, লোকাল সারাংশ এবং পুনরাবৃত্তিযোগ্য ওয়ার্কফ্লো শিখুন।
বড় মোনোরেপোতে Claude Code অনিশ্চিত মনে হতে পারে একটাই সহজ কারণে: রিপোটা এমনভাবে বড় যে মডেল একবারে সবটুকু কাজের মেমরিতে রাখতে পারে না।
“কনটেক্সট” বলতে আমরা অর্থ করি সেই ফাইলগুলো, স্নিপেট, নোট এবং নির্দেশনা যা Claude-কে এই টাস্কের জন্য দেখানো হয়েছে—এবং এগুলোর থেকে যে অনুমান Claude করতে পারে। যখন গুরুত্বপূর্ণ বিস্তারিত অনুপস্থিত থাকে, Claude শূন্যস্থান ভরাট করে অনুমান নিয়ে। বড় রিপোতে এটি ঘন ঘন ঘটে।
তিনটি ব্যর্থতার ধরন বারবার দেখা যায়:
প্রথমত, মিস হওয়া ফাইল। একটি ফোল্ডারের মধ্যে যে পরিবর্তনটি নিরাপদ মনে হয়, সেটা প্রকৃতপক্ষে একটি শেয়ার্ড টাইপ, কনফিগ রুল, বা বিল্ড স্টেপের ওপর নির্ভর করতে পারে যা অন্য কোথাও সংজ্ঞায়িত। যদি সেই নির্ভরতাটি কনটেক্সটে না থাকে, Claude আত্মবিশ্বাসের সাথে ভুল জায়গায় এডিট করতে পারে বা ভুলভাবে থেমে যেতে পারে কারণ এটি বাস্তব উৎসমূল দেখতে পাচ্ছে না।
দ্বিতীয়ত, ভ্রান্ত সাদৃশ্য। মোনোরেপোতে প্রায়ই বহু প্যাকেজ থাকে যা দেখতে একদম মিলছে: দুইটি auth মডিউল, তিনটি API ক্লায়েন্ট, অথবা একাধিক React অ্যাপ যাদের ফোল্ডার স্ট্রাকচার মিলতেই পারে। Claude প্যাটার্নগুলো একটির সাথে অন্যটিতে মিশিয়ে দিতে পারে, ভুল প্যাকেজে হেল্পার আপডেট করতে পারে, অথবা “প্রায় ঠিক” মডিউল নাম থেকে ইম্পোর্ট করতে পারে।
তৃতীয়ত, সময়গত ভ্রান্তি। বড় কোডবেসগুলোতে সাধারণত একই কাজ করার পুরনো ও নতুন উপায় থাকতে পারে। যদি Claude কেবল পুরনো ফাইলগুলো দেখে, তাহলে এটি পুরনো প্যাটার্ন (অপ্রচলিত কনফিগ অপশন, লেগেসি API) অনুলিপি করে ফেলতে পারে, যদিও টিম ইতোমধ্যে এগুলো বাদ দিয়েছে।
একটি সাধারণ বাস্তব উদাহরণ: আপনি বিলিং UI-তে ছোট একটি পরিবর্তন চাইলে Claude একটি শেয়ার্ড payments কম্পোনেন্ট এডিট করে ফেলে যা অন্য অ্যাপগুলোও ব্যবহার করে—কারণ এটি অ্যাপ-নির্দিষ্ট র্যাপার যা পরিবর্তন করা উচিত তা কখনোই দেখেনি।
লক্ষ্য পুরো মোনোরেপো Claude-কে দেখানো নয়। লক্ষ্য হলো ছোট, ইচ্ছাকৃত ইনপুট দেওয়া যা প্রশ্নের উত্তর দেয়: আপনি যে প্যাকেজটি বদলাচ্ছেন, তার সরাসরি নির্ভরশীলতা, এবং টাইপ ও কনফিগের একটি বা দুইটি “সূত্রের সত্য”। এছাড়া “স্পর্শ করবেন না” ক্ষেত্রগুলো (অন্যান্য অ্যাপ, ইনফ্রা, জেনারেটেড কোড) উল্লেখ করুন এবং নিশ্চিত করুন কোন প্যাকেজ আচরণটির মালিক।
নির্ভুলতা নির্ভর করে কত কোড আপনি পেস্ট করেন তার চেয়ে অনেক বেশি—কতটা স্পষ্টভাবে আপনি কাজটি বর্ণনা করেছেন তার ওপর।
আপনি যা চান সেটি দিয়ে শুরু করুন: একটি নির্দিষ্ট ফিক্স, রিফ্যাক্টর, বা উত্তর। “কোড সম্পর্কে প্রশ্ন” উচ্চ মাত্রায় রাখা যেতে পারে। “একটি পরিবর্তন করুন” অনুরোধের জন্য সীমানা, ইনপুট এবং সফলতার পরীক্ষা দরকার।
কিছু শেয়ার করার আগে এমন একটি বাক্য লিখুন যা এই বাক্যটি শেষ করে: “আপনি শেষ করলে, আমি সক্ষম হব…”。 উদাহরণ: “package X-এর ইউনিট টেস্টগুলো কোন ফেইল ছাড়াই চালাতে পারব” বা “endpoint Y-এর API রেসপন্সে নতুন ফিল্ডটি দেখতে পারব।” ওই বাক্যটা বড় রিপোতে উত্তরদানের নর্থ স্টার হিসেবে কাজ করবে।
পরিবর্তনের জন্য, সবচেয়ে ছোট সেট শেয়ার করুন যা পরিবর্তনটি সঠিক প্রমাণ করতে পারে: এন্ট্রি পয়েন্ট(গুলি), সংশ্লিষ্ট টাইপ/ইন্টারফেস বা স্কিমা, একটি ফেল করা টেস্ট বা রেপ্রো স্টেপ সহ প্রত্যাশিত ফল, এবং যে কোনো কনফিগ যা এই পথকে প্রভাবিত করে (রাউটিং, ফিচার ফ্ল্যাগ, বিল্ড বা লিন্ট রুল)। যদি সুবিধা হয়, প্যাকেজের একটি ছোট ফোল্ডার মানচিত্র যোগ করুন যাতে Claude বুঝতে পারে প্রতিটি ডিরেক্টরির উদ্দেশ্য কী।
স্পষ্টভাবে বলুন কি না দেখবে। যেমন: “জেনারেটেড ফাইল, ভেন্ডর ফোল্ডার, বিল্ড আউটপুট, স্ন্যাপশট, এবং লকফাইলগুলো এড়িয়ে চলুন যদি না আমি চাই।” এটি অপচয়ী সময় ও অপ্রয়োজনীয় এডিট প্রতিরোধ করে।
এছাড়া অনিশ্চয়তার জন্য প্রত্যাশাও সেট করুন। Claude-কে অনুমান ও অজানা জিনিসগুলো চিহ্নিত করতে বলুন পরিবর্তে অনুমান করে নেওয়ার। উদাহরণ: “যদি আপনি দেখতে না পান কোন ফাংশন কোথায় কল হচ্ছে, তা বলুন এবং ২টি উপায় প্রস্তাব করুন সেটি খুঁজে পেতে।”
বড় মোনোরেপোতে accuracy তখনই কমে যখন মডেল “সহায়কভাবে” নিকটস্থ কোড টেনে আনতে শুরু করে যা টাস্কের অংশ নয়। সমাধান সরল: প্রশ্ন করার আগে ইন-স্কোপ এবং আউট-অফ-স্কোপ সংজ্ঞায়িত করুন।
আপনার রিপো কিভাবে সংগঠিত তার সঙ্গে মেলে এমন একটি সীমানা দিয়ে শুরু করুন: একটি প্যাকেজ, একটি সার্ভিস, একটি অ্যাপ বা একটি শেয়ার্ড লাইব্রেরি। যদি পরিবর্তনটি “চেকআউট UI আপডেট” হয়, সীমানাটা সম্ভবত একটি অ্যাপ প্যাকেজ, না যে জায়গায় “checkout” শব্দটি দেখা যায় সব জায়গা।
Claude-কে ধরে রাখতে সাহায্যকারী সিগন্যালগুলো:
apps/, services/, packages/, libs/)ফোল্ডার ভিতরে README দ্রুত সীমানা নির্দেশক হিসেবে কাজ করতে পারে।
সীমানাগুলো তখনই ভাল কাজ করে যখন আপনি সেগুলির মধ্যে সেতুসমূহ নাম দেন। স্পষ্টভাবে উল্লেখ করুন কোন ইন্টারফেসগুলো Claude স্পর্শ করতে পারে এবং বাকিগুলো অফ-লিমিট ধরা হবে। সাধারণ সেতু হল HTTP API কনট্রাক্ট, ইভেন্ট টপিক ও পেইলোড, শেয়ার্ড টাইপ, বা একটি সীমিত সেট এক্সপোর্টেড ফাংশন।
ওই একইভাবে “স্পর্শ করবেন না” জোনগুলিও নাম করুন যখন পরিবর্তনগুলো সেখানে প্রভাব ফেলবে না। সাধারণ ক্ষেত্রগুলো: ইনফ্রাস্ট্রাকচার ও ডেপ্লয়মেন্ট কনফিগ, সিকিউরিটি ও অথ লজিক, বিলিং ও পেমেন্টস, ডেটা মাইগ্রেশন এবং প্রোডাকশন স্কিমা, এবং বহু টিম দ্বারা ব্যবহৃত শেয়ার্ড লাইব্রেরি।
একটি কনক্রিট প্রম্পট ডিটেইল সাহায্য করে:
“Make changes only inside packages/cart/ and its tests. You may read shared types in packages/types/ but do not modify them. Do not edit infra, auth, or billing.”
নির্ভুলতা বাড়ে যখন আপনি একটি ছোট, স্থিতিশীল মানচিত্র দেন যেটি আপনি বদলাতে চান। একটি “লোকাল সারাংশ” সেই মানচিত্র: দ্রুত পড়ার মতো সংক্ষিপ্ত, অনুমান বন্ধ করার জন্য যথেষ্ট নির্দিষ্ট।
প্রতিটি সারাংশ ১০–২০ লাইনের মধ্যে রাখুন। সেটি এমনভাবে লিখুন যেন একটি নতুন টিমমেটকে আপনি কোডটি সামলানোর জন্য দিচ্ছেন যাকে পুরো রিপোটা জানতে হবে না, কেবল ওই সীমানাটি জানলেই চলবে। সাধারণ ভাষা ও কোড থেকে আসল নামগুলো ব্যবহার করুন: ফোল্ডার, প্যাকেজ, এক্সপোর্টেড ফাংশন।
একটি দরকারী লোকাল সারাংশ পাঁচটি প্রশ্নের উত্তর দেয়:
একটি “গটচা” লাইন যোগ করুন—যেখানে ব্যয়বহুল ভুল ঘটতে পারে: হিডেন ক্যাশিং, ফিচার ফ্ল্যাগ, মাইগ্রেশন ধাপ, এবং যেকোনো এমন জিনিস যা নীরবে ভাঙিয়ে দিতে পারে।
নিচে একটি কমপ্যাক্ট টেমপ্লেট আছে যা আপনি কপি করতে পারেন:
Local summary: \u003cpackage/service name\u003e
Purpose: \u003c1 sentence\u003e
Scope: \u003cwhat to touch\u003e | Not: \u003cwhat not to change\u003e
Entry points: \u003cfiles/routes/commands\u003e
Public surface: \u003cexports/endpoints/events\u003e
Data sources: \u003ctables/collections/queues/caches\u003e
Conventions: errors=\u003chow\u003e, logging=\u003chow\u003e, tests=\u003cwhere/how\u003e
Gotchas: \u003cflags/caching/migrations/edge cases\u003e
উদাহরণ: যদি আপনি একটি বিলিং প্যাকেজ সম্পাদনা করেন, তাহলে সঠিকভাবে নোট করুন কোন ফাংশন ইনভয়েস তৈরি করে, কোন টেবিলগুলোতে লেখা হয়, এবং retry-যোগ্য এররগুলোর নিয়ম কী। তারপর Claude সেই সীমার উপর ফোকাস করতে পারবে, শেয়ার্ড অথ, কনফিগ বা সম্পর্কহীন প্যাকেজে বিচরণ না করে।
বেস্ট সারাংশ হলো যা Claude দেখতে পায় যখন তাকে প্রয়োজন। কোডের পাশে রাখুন যেন ওটা উপেক্ষা করা কঠিন এবং আপডেট করা সহজ। উদাহরণস্বরূপ, প্রতিটি প্যাকেজ/সার্ভিস/অ্যাপ ডিরেক্টরির মাঝেই একটি ছোট SUMMARY.md (বা README.md-এর একটি সেকশন) রাখুন, রেপো রুটে একটি বিশাল ডক রাখার বদলে।
একটি সহজ, পুনরাবৃত্তিযোগ্য স্ট্রাকচার সাহায্য করে। সংক্ষিপ্ত রাখুন যাতে মানুষ এটিকে মেইনটেইন করে:
YYYY-MM-DD - \u003cwhat changed in one sentence\u003eসারাংশগুলো স্টেল হয়ে যায় স্বাভাবিক কারণগুলোতে: রিফ্যাক্টর করলে স্ট্রাকচার বা নাম বদলে যায়, একটি নতুন মডিউল প্রধান উপায় হয়ে ওঠে, API/ইভেন্ট/স্কিমা বদলে যায়—even যদি টেস্ট পাস করে—সীমা প্যাকেজের মধ্যে পরিবর্তন হয়, বা নির্ভরশীলতা সরানো/বদলানো হয়।
প্র্যাকটিক্যাল হ্যাবিট: যখন আপনি একটি পরিবর্তন মিশান, একটি “Last updated” লাইন যোগ করুন যা কী পরিবর্তিত হয়েছে সংক্ষেপে বলে। Koder.ai-এর মতো টুলগুলো কোড পরিবর্তনে দ্রুততা আনতে সাহায্য করতে পারে, কিন্তু সারাংশই ভবিষ্যৎ পরিবর্তনগুলোকে নির্ভুল রাখে।
নির্ভুলতা প্রায়ই নির্ভর করে আপনি কথোপকথনের গতি কিভাবে রাখেন তার ওপর। Claude-কে এক বড় স্ন্যাপশট থেকেই অনুমান করতে দেবেন না; বরং ছোট টুকরো করে কনটেক্সট অর্জন করান।
কোনও এডিটের আগে Claude-কে যা দেখা যাচ্ছে এবং যা দরকার তা বর্ণনা করতে বলুন। একটি ভালো মানচিত্রটি সংক্ষিপ্ত: কী কী প্যাকেজ জড়িত, ফ্লোরির এন্ট্রি পয়েন্ট, এবং কোথায় টেস্ট বা টাইপস থাকে।
প্রম্পট:
“Create a map of this change: packages involved, main flow, and likely touch points. Do not propose code yet.”
একটি সংকীর্ণ অংশ নির্বাচন করুন: একটি ফিচার, একটি প্যাকেজ, একটি ইউজার ফ্লো। সীমা স্পষ্টভাবে বলুন (উদাহরণ: “Only change packages/billing-api. Do not touch shared-ui or infra.”)।
একটি ওয়ার্কফ্লো যা আপনাকে নিয়ন্ত্রণে রাখে:
Claude যদি কিছু মিস করে, সেটা জানাতে হবে। তাকে লিখে দিতে বলুন: (1) সে যে অনুমানগুলো করছে, (2) কী falsify করবে সেগুলো, এবং (3) পরবর্তী কোন ফাইলগুলো দরকার তা নিশ্চিত করতে।
উদাহরণ: আপনাকে একটি Invoice রেসপন্সে একটি ফিল্ড যোগ করতে হবে। Claude হ্যান্ডলার, DTO/টাইপ ডেফিনিশন, এবং একটি টেস্ট অনুরোধ করে। আপনি কেবল সেইগুলোই শেয়ার করবেন। যদি আপনি চ্যাট-ভিত্তিক বিল্ডার ব্যবহার করেন যেমন Koder.ai, একই নিয়ম প্রযোজ্য: সবচেয়ে ছোট সেট সোর্স ফাইল দিন, তারপর প্রকৃত প্রয়োজন হলে বাড়ান।
ভুল এডিট প্রতিরোধ করার আপনার সেরা প্রতিরক্ষা হলো প্রম্পটের মধ্যে একটি ছোট “চুক্তি”: Claude কী স্পর্শ করতে পারবে, কীভাবে আপনি সাফল্য বিচার করবেন, এবং কোন নিয়মগুলো মানতে হবে।
সহজভাবে মানার মতো একটি সীমানা দিয়ে শুরু করুন। স্পষ্টভাবে বলুন কোথায় এডিট অনুমোদিত, এবং কোনগুলো “স্পর্শ করবেন না” যাতে বিচরণ করার ইচ্ছা না তৈরি হয়।
চুক্তি টেমপ্লেট:
packages/payments/ এর ফাইলগুলো পরিবর্তন।packages/auth/, infra/, বা কোনো শেয়ার্ড কনফিগ এডিট করবেন না।তারপর গ্রহণযোগ্যতা চেকগুলো নির্ধারণ করুন। এগুলো ব্যতীত Claude এমন কোড তৈরি করতে পারে যা দেখতে ঠিক লাগে কিন্তু রিপোর বাস্তব নিয়ম ভেঙে দেয়।
স্টাইল কনস্ট্রেইন্টও গুরুত্বপূর্ণ। Claude-কে বলুন কোন প্যাটার্ন মেনে চলতে হবে এবং কী এড়াতে হবে, আপনার কোডবেস যা করে তার উপর ভিত্তি করে। উদাহরণ: “এই প্যাকেজে বিদ্যমান error helper ব্যবহার করুন; নতুন ডিপেন্ডেন্সি যোগ করবেন না; function নামগুলো camelCase রাখুন; নতুন আর্কিটেকচার লেয়ার না যোগ করুন।”
অবশেষে, কোনো এডিটের আগে একটি ছোট চেঞ্জ প্ল্যান বাধ্য করুন:
“Before editing, list the 3-5 files you expect to touch and the exact behavior change. Wait for approval.”
উদাহরণ:
“Fix rounding in invoice totals. Only edit packages/billing/src/ and tests under packages/billing/test/. Acceptance: pnpm -C packages/billing test and typecheck. Follow existing money utils; do not rewrite API types. Provide a 4-step plan first.”
মোনোরেপোতে দ্রুত ভুল এডিট পাওয়ার দ্রুততম উপায় হলো Claude-কে একসাথে অনেক কিছুরও বেশি দেখানো। যখন আপনি একটি বড় কোডের প্যাকেট পেস্ট করেন, এটি প্রায়ই জেনেরিক প্যাটার্নগুলোর দিকে ফিরে যায় বদলে আপনার রিপো ইতিমধ্যেই যেভাবে ডিজাইন করা আছে তার অনুসরণ করার।
আরেকটি ফাঁদ হলো আর্কিটেকচারের অনুমান করতে দেওয়া। যদি আপনি প্রকৃত এন্ট্রি পয়েন্ট না দেখান, তাহলে Claude প্রথম উপযুক্ত দেখানো ফাইলটিকে বেছে নিয়ে সেখানে লজিক যোগ করতে পারে। বাস্তবে নির্ভুলতা আসে ছোট সেট “সূত্রের সত্য” ফাইল থেকে (এন্ট্রি মডিউল, রাউটার, সার্ভিস রেজিস্ট্রি, প্যাকেজ বাউন্ডারি ডক)। এইগুলো কনটেক্সটে না থাকলে মডেল ফাঁকগুলো পূরণ করে।
নামও বিভ্রান্তিকর হতে পারে। মোনোরেপোতে প্রায়ই ui, ui-kit, shared-ui মতো প্যাকেজ থাকে, বা একই নামের হেলপার যেমন date.ts বিভিন্ন জায়গায়। যদি আপনি দুটো জায়গার স্নিপেট মিশিয়ে দেন, Claude একটি ফাইল প্যাচ করলেও অন্যটার সম্পর্কে ভাবতে পারে। উদাহরণ: আপনি একটি বাটনের স্টাইল বদলাতে বলেন, এটি packages/ui/Button.tsx এ পরিবর্তন করে ফেলে, কিন্তু অ্যাপটি packages/ui-kit/Button.tsx ইম্পোর্ট করছে। ডিফ দেখতে ঠিক লাগে, কিন্তু প্রোডাকশনে কিছু পরিবর্তন হয় না।
কনফিগ আরেকটি নীরব ড্রিফট উৎস। আচরণ env vars, ফিচার ফ্ল্যাগ, বিল্ড সেটিংস, বা ওয়ার্কস্পেস টুলিং-এর ওপর নির্ভর করতে পারে। আপনি যদি এগুলো উল্লেখ না করেন, Claude হয়তো “অদ্ভুত” চেকটিকে সরিয়ে দিতে পারে যা শুধুমাত্র একটি ফ্ল্যাগ অন থাকলে প্রয়োজন, অথবা এমন কোড যোগ করতে পারে যা বিল্ড ধ্বংস করে।
ড্রিফটের লাল পতাকা:
ক্রস-প্যাকেজ ইম্পোর্টকে ডিফল্ট হিসেবে না নিয়ে একটি সিদ্ধান্ত হিসেবে বিবেচনা করুন। এলাকা সম্প্রসারণ না করা পর্যন্ত এডিট লোকাল রাখুন।
সঠিক এডিট পাওয়ার দ্রুত উপায় হলো সীমা দিয়ে শুরু করা, যোগের বদলে। একটি ভালো প্রম্পট একটু কঠোর মনে হওয়া উচিত: এটি Claude-কে কোথায় দেখতে হবে, কী উপেক্ষা করতে হবে, এবং “শেষ” মানে কী তা বলে।
কোড পেস্ট করার আগে একটি সংক্ষিপ্ত প্রেফেস লিখুন যা কাজটিকে রিপোর এক স্থানে পিন করে। প্যাকেজ, সঠিক ফোল্ডার এবং নির্দিষ্ট লক্ষ্য নামুন। তারপর একটি লোকাল সারাংশ (উদ্দেশ্য, মূল নির্ভরশীলতা, গুরুত্বপূর্ণ কনভেনশন) এবং সেই এন্ট্রি ফাইলটি অন্তর্ভুক্ত করুন যা পরিবর্তনকে অ্যাংকর করে।
চেকলিস্ট:
\u003cpackage\u003e/\u003cpath\u003e. Goal: \u003cone sentence\u003e. Ignore everything else unless asked.\u003c5-10 lines\u003e. Entry file: \u003cpath/to/file\u003e.\u003c...\u003e. Must not change: \u003cfolders/files or APIs\u003e. Keep behavior: \u003cwhat must stay true\u003e.যদি Claude আপনার সীমানার বাইরে পরিবর্তন প্রস্তাব করে, এটাকে একটি সংকেত হিসাবে নিন: বা প্রম্পট আরও কঠোর করুন, বা সচেতনভাবে সীমানা বাড়িয়ে আবার স্পষ্টভাবে বলুন।
ধরা যাক আপনার মোনোরেপোতে apps/web-store (একটি React অ্যাপ) এবং packages/ui-kit (শেয়ার্ড বাটন, ইনপুট ও স্টাইল) আছে। আপনি একটি ছোট ফিচার চান: কার্ট পেজে “Save for later” বাটন যোগ করুন, ui-kit থেকে নতুন SaveIcon ব্যবহার করে। অন্য কিছু পরিবর্তন করা চলবে না।
পরিবর্তন চাইবার আগে দুইটি লোকাল সারাংশ তৈরি করুন যেগুলো সীমানা হিসেবে কাজ করবে। সংক্ষিপ্ত, স্পেসিফিক এবং ব্যাপারগুলোকে গুরুত্ব দেয় এমন রাখুন।
# apps/web-store/LOCAL_SUMMARY.md
Purpose: Customer shopping UI.
Entry points: src/routes.tsx, src/pages/cart/CartPage.tsx
Cart rules: cart state lives in src/cart/useCart.ts
Do not touch: checkout flow (src/pages/checkout), payments, auth.
Tests: npm test -w apps/web-store
# packages/ui-kit/LOCAL_SUMMARY.md
Purpose: shared UI components.
Exports: src/index.ts
Icons: src/icons/*, add new icons by exporting from index.
Do not touch: theming tokens, build config.
Tests: npm test -w packages/ui-kit
তারপর লুপটি টাইট রাখুন:
CartPage and ui-kit icons. No checkout/auth edits.”CartPage, useCart, ui-kit icons, ui-kit index)।পরিবর্তনের পরে, ডকুমেন্ট করুন যাতে ভবিষ্যৎ কনটেক্সট ছোট থাকে:
যদি এটা একজনের জন্য ভাল কাজ করে কিন্তু টিমের বাকি লোকদের জন্য না করে, বেশিরভাগ ক্ষেত্রে অভাবটি পুনরাবৃত্তিত্ব। “ভাল কনটেক্সট হাইজিন” ডিফল্ট করা দরকার, ব্যক্তিগত অভ্যাস নয়।
একটি প্রম্পট স্কেলেটন সংরক্ষণ করুন যা সবাই কপি করে পূরণ করতে পারে। সংক্ষিপ্ত কিন্তু কঠোর রাখুন। এতে থাকবে লক্ষ্য (“শেষ হলে কী দেখতে হবে”), অনুমোদিত স্কোপ, হাইর্ড বাউন্ডারি (কেন), একটি লোকাল সারাংশ, এবং আউটপুট চুক্তি (প্রথমে প্ল্যান, তারপর ফাইলভিত্তিক ডিফ এবং টেস্ট)।
মাসিক বড় রিভিউগুলো এড়িয়ে যান যা কেউ করে না। সারাংশ আপডেটকে স্বাভাবিক কাজের সঙ্গে যুক্ত করুন: যখন কোনো পরিবর্তন আচরণ, নির্ভরশীলতা, বা API বদলে, একই PR-এ লোকাল সারাংশ আপডেট করুন।
একটি সহজ নিয়ম: যদি একজন টিমমেট জিজ্ঞেস করবে “এটি কোথায় থাকে?” বা “কার উপর নির্ভরশীল?”, সারাংশ এখন অপ্রচলিত।
চ্যাট-ফার্স্ট ওয়ার্কফ্লোর প্রিফার করলে, Koder.ai আপনাকে এই ধরণের ইটারেশন নিরাপদে করতে সাহায্য করতে পারে। Planning mode আপনাকে স্কোপ ও সীমানায় সম্মতি করতে দেয় আগে থেকেই, এবং স্ন্যাপশট ও রোলব্যাক আপনাকে অনুমান ভুল হলে দ্রুত ফিরে যেতে দেয়।
Claude তখন কম নির্ভুল হয় যখন এটি প্রকৃত সত্যের উৎস "দেখতে" পারে না।
বৃহৎ মোনোরেপোতে মডেল প্রায়ই একটি নির্ভরশীল ফাইল মিস করে, দুইটি মিলানো প্যাকেজকে ভূলভাবে মিশিয়ে ফেলে, বা কনটেক্সটে পুরনো প্যাটার্ন থাকলে সেটি কপি করে — কারণ তা ছিলেই দেখা।
সম্পূর্ণ রিপো দেখানোর চেষ্টা করবেন না। পরিবর্তনটি সঠিক কিনা প্রমাণ করার জন্য সবচেয়ে ছোট সেট দিয়ে শুরু করুন।
একটি ভালো ডিফল্ট হলো:
যে ফাইলগুলো আঙ্গুরচাষ নয়, বরং আচরণটি কনক্রিটলি ঝুলছে সেগুলো শেয়ার করুন।
একটি ব্যবহারিক সেট:
আপনার রিপো কীভাবে সংগঠিত তাতে মিল রেখে একটি সীমানা বেছে নিন: একটি প্যাকেজ, অ্যাপ বা সার্ভিস।
তারপর এটি স্পষ্টভাবে বলুন, আর কী অতিরিক্ত বাইরে থাকবে তা উল্লেখ করুন। উদাহরণস্বরূপ:
packages/cart/ এবং তার টেস্টগুলো পরিবর্তন করুন।”কারণ মোনোরেপোতে একইরকম নামের বা স্ট্রাকচারের একাধিক প্যাকেজ থাকতে পারে (ui, ui-kit, shared-ui) এবং ডুপ্লিকেট হেলপার্স।
Claude সঠিক ধারণা নিয়ে ভূল প্যাকেজেই পরিবর্তন করতে পারে, বা “প্রায় ঠিক” মডিউল নাম থেকে ইম্পোর্ট করতে পারে। সঠিক প্যাকেজ ও এন্ট্রি পয়েন্টের নাম দিয়ে এটার প্রতিরোধ করুন।
লোকাল সারাংশ হলো আপনি যেই নির্দিষ্ট এলাকাটি পরিবর্তন করতে চান তার সংক্ষিপ্ত মানচিত্র — সাধারণত ১০–২০ লাইন।
এতে থাকা উচিত:
যে কোডের পাশে সারাংশ আছে সেটারই কাছে রাখুন যাতে খুঁজে সহজ হয় এবং আপডেট করতেও সহজ হয়।
সহজ ডিফল্ট:
SUMMARY.md বা README সেকশনClaude-কে আগে বলুন যে অনুমান করে না, বরং অনিশ্চয়তা ও অনুমানগুলো ফ্ল্যাগ করবে।
উপকারী নিয়ম:
একটি টাইট লুপ ব্যবহার করুন যাতে কনটেক্সট ছোট ছোট অংশে অর্জিত হয়:
প্রম্পটে একটি ছোট “চুক্তি” লিখে দিন এবং সেটাকে বাধ্যতামূলক করুন:
এতে রিভিউ করা সহজ হয় এবং অনিচ্ছাকৃত ক্রস-প্যাকেজ পরিবর্তন কমে যায়।