মোনোরেপোতে Claude Code: প্রসঙ্গ সীমিত করে নির্ভুল থাকা

কেন বড় মোনোরেপোতে Claude কম নির্ভুল হয়

বড় মোনোরেপোতে Claude Code অনিশ্চিত মনে হতে পারে একটাই সহজ কারণে: রিপোটা এমনভাবে বড় যে মডেল একবারে সবটুকু কাজের মেমরিতে রাখতে পারে না।

“কনটেক্সট” বলতে আমরা অর্থ করি সেই ফাইলগুলো, স্নিপেট, নোট এবং নির্দেশনা যা Claude-কে এই টাস্কের জন্য দেখানো হয়েছে—এবং এগুলোর থেকে যে অনুমান Claude করতে পারে। যখন গুরুত্বপূর্ণ বিস্তারিত অনুপস্থিত থাকে, Claude শূন্যস্থান ভরাট করে অনুমান নিয়ে। বড় রিপোতে এটি ঘন ঘন ঘটে।

তিনটি ব্যর্থতার ধরন বারবার দেখা যায়:

প্রথমত, মিস হওয়া ফাইল। একটি ফোল্ডারের মধ্যে যে পরিবর্তনটি নিরাপদ মনে হয়, সেটা প্রকৃতপক্ষে একটি শেয়ার্ড টাইপ, কনফিগ রুল, বা বিল্ড স্টেপের ওপর নির্ভর করতে পারে যা অন্য কোথাও সংজ্ঞায়িত। যদি সেই নির্ভরতাটি কনটেক্সটে না থাকে, Claude আত্মবিশ্বাসের সাথে ভুল জায়গায় এডিট করতে পারে বা ভুলভাবে থেমে যেতে পারে কারণ এটি বাস্তব উৎসমূল দেখতে পাচ্ছে না।

দ্বিতীয়ত, ভ্রান্ত সাদৃশ্য। মোনোরেপোতে প্রায়ই বহু প্যাকেজ থাকে যা দেখতে একদম মিলছে: দুইটি auth মডিউল, তিনটি API ক্লায়েন্ট, অথবা একাধিক React অ্যাপ যাদের ফোল্ডার স্ট্রাকচার মিলতেই পারে। Claude প্যাটার্নগুলো একটির সাথে অন্যটিতে মিশিয়ে দিতে পারে, ভুল প্যাকেজে হেল্পার আপডেট করতে পারে, অথবা “প্রায় ঠিক” মডিউল নাম থেকে ইম্পোর্ট করতে পারে।

তৃতীয়ত, সময়গত ভ্রান্তি। বড় কোডবেসগুলোতে সাধারণত একই কাজ করার পুরনো ও নতুন উপায় থাকতে পারে। যদি Claude কেবল পুরনো ফাইলগুলো দেখে, তাহলে এটি পুরনো প্যাটার্ন (অপ্রচলিত কনফিগ অপশন, লেগেসি API) অনুলিপি করে ফেলতে পারে, যদিও টিম ইতোমধ্যে এগুলো বাদ দিয়েছে।

একটি সাধারণ বাস্তব উদাহরণ: আপনি বিলিং UI-তে ছোট একটি পরিবর্তন চাইলে Claude একটি শেয়ার্ড payments কম্পোনেন্ট এডিট করে ফেলে যা অন্য অ্যাপগুলোও ব্যবহার করে—কারণ এটি অ্যাপ-নির্দিষ্ট র‍্যাপার যা পরিবর্তন করা উচিত তা কখনোই দেখেনি।

লক্ষ্য পুরো মোনোরেপো Claude-কে দেখানো নয়। লক্ষ্য হলো ছোট, ইচ্ছাকৃত ইনপুট দেওয়া যা প্রশ্নের উত্তর দেয়: আপনি যে প্যাকেজটি বদলাচ্ছেন, তার সরাসরি নির্ভরশীলতা, এবং টাইপ ও কনফিগের একটি বা দুইটি “সূত্রের সত্য”। এছাড়া “স্পর্শ করবেন না” ক্ষেত্রগুলো (অন্যান্য অ্যাপ, ইনফ্রা, জেনারেটেড কোড) উল্লেখ করুন এবং নিশ্চিত করুন কোন প্যাকেজ আচরণটির মালিক।

কাজটি সংজ্ঞায়িত করে শুরু করুন, রিপো নয়

নির্ভুলতা নির্ভর করে কত কোড আপনি পেস্ট করেন তার চেয়ে অনেক বেশি—কতটা স্পষ্টভাবে আপনি কাজটি বর্ণনা করেছেন তার ওপর।

আপনি যা চান সেটি দিয়ে শুরু করুন: একটি নির্দিষ্ট ফিক্স, রিফ্যাক্টর, বা উত্তর। “কোড সম্পর্কে প্রশ্ন” উচ্চ মাত্রায় রাখা যেতে পারে। “একটি পরিবর্তন করুন” অনুরোধের জন্য সীমানা, ইনপুট এবং সফলতার পরীক্ষা দরকার।

কিছু শেয়ার করার আগে এমন একটি বাক্য লিখুন যা এই বাক্যটি শেষ করে: “আপনি শেষ করলে, আমি সক্ষম হব…”。 উদাহরণ: “package X-এর ইউনিট টেস্টগুলো কোন ফেইল ছাড়াই চালাতে পারব” বা “endpoint Y-এর API রেসপন্সে নতুন ফিল্ডটি দেখতে পারব।” ওই বাক্যটা বড় রিপোতে উত্তরদানের নর্থ স্টার হিসেবে কাজ করবে।

পরিবর্তনের জন্য, সবচেয়ে ছোট সেট শেয়ার করুন যা পরিবর্তনটি সঠিক প্রমাণ করতে পারে: এন্ট্রি পয়েন্ট(গুলি), সংশ্লিষ্ট টাইপ/ইন্টারফেস বা স্কিমা, একটি ফেল করা টেস্ট বা রেপ্রো স্টেপ সহ প্রত্যাশিত ফল, এবং যে কোনো কনফিগ যা এই পথকে প্রভাবিত করে (রাউটিং, ফিচার ফ্ল্যাগ, বিল্ড বা লিন্ট রুল)। যদি সুবিধা হয়, প্যাকেজের একটি ছোট ফোল্ডার মানচিত্র যোগ করুন যাতে Claude বুঝতে পারে প্রতিটি ডিরেক্টরির উদ্দেশ্য কী।

স্পষ্টভাবে বলুন কি না দেখবে। যেমন: “জেনারেটেড ফাইল, ভেন্ডর ফোল্ডার, বিল্ড আউটপুট, স্ন্যাপশট, এবং লকফাইলগুলো এড়িয়ে চলুন যদি না আমি চাই।” এটি অপচয়ী সময় ও অপ্রয়োজনীয় এডিট প্রতিরোধ করে।

এছাড়া অনিশ্চয়তার জন্য প্রত্যাশাও সেট করুন। Claude-কে অনুমান ও অজানা জিনিসগুলো চিহ্নিত করতে বলুন পরিবর্তে অনুমান করে নেওয়ার। উদাহরণ: “যদি আপনি দেখতে না পান কোন ফাংশন কোথায় কল হচ্ছে, তা বলুন এবং ২টি উপায় প্রস্তাব করুন সেটি খুঁজে পেতে।”

স্পষ্ট সীমানা আঁকুন যা Claude পার হতে পারবে না

বড় মোনোরেপোতে accuracy তখনই কমে যখন মডেল “সহায়কভাবে” নিকটস্থ কোড টেনে আনতে শুরু করে যা টাস্কের অংশ নয়। সমাধান সরল: প্রশ্ন করার আগে ইন-স্কোপ এবং আউট-অফ-স্কোপ সংজ্ঞায়িত করুন।

আপনার রিপো কিভাবে সংগঠিত তার সঙ্গে মেলে এমন একটি সীমানা দিয়ে শুরু করুন: একটি প্যাকেজ, একটি সার্ভিস, একটি অ্যাপ বা একটি শেয়ার্ড লাইব্রেরি। যদি পরিবর্তনটি “চেকআউট UI আপডেট” হয়, সীমানাটা সম্ভবত একটি অ্যাপ প্যাকেজ, না যে জায়গায় “checkout” শব্দটি দেখা যায় সব জায়গা।

Claude-কে ধরে রাখতে সাহায্যকারী সিগন্যালগুলো:

• ফোল্ডার কনভেনশন (apps/, services/, packages/, libs/)
• প্যাকেজ ম্যানিফেস্ট (exports ও dependencies)
• পাবলিক এন্ট্রি পয়েন্ট (index ফাইল, exported components, handlers)
• টেস্ট (প্রায়ই প্রত্যাশিত সারফেস এরিয়া বের করে)

ফোল্ডার ভিতরে 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.”

কিভাবে দরকারী লোকাল সারাংশ লিখবেন

নির্ভুলতা বাড়ে যখন আপনি একটি ছোট, স্থিতিশীল মানচিত্র দেন যেটি আপনি বদলাতে চান। একটি “লোকাল সারাংশ” সেই মানচিত্র: দ্রুত পড়ার মতো সংক্ষিপ্ত, অনুমান বন্ধ করার জন্য যথেষ্ট নির্দিষ্ট।

প্রতিটি সারাংশ ১০–২০ লাইনের মধ্যে রাখুন। সেটি এমনভাবে লিখুন যেন একটি নতুন টিমমেটকে আপনি কোডটি সামলানোর জন্য দিচ্ছেন যাকে পুরো রিপোটা জানতে হবে না, কেবল ওই সীমানাটি জানলেই চলবে। সাধারণ ভাষা ও কোড থেকে আসল নামগুলো ব্যবহার করুন: ফোল্ডার, প্যাকেজ, এক্সপোর্টেড ফাংশন।

একটি দরকারী লোকাল সারাংশ পাঁচটি প্রশ্নের উত্তর দেয়:

• এই প্যাকেজ/সার্ভিস কী জন্য, এবং কী জন্য নয় (স্কোপ সীমা)
• কাজ কোথা থেকে শুরু হয় (প্রধান এন্ট্রি পয়েন্ট যেমন ফাইল, রুট, কমান্ড, বা কম্পোনেন্ট)
• বাইরের থেকে কী নিরাপদে কল করা যায় (পাবলিক API, এক্সপোর্টেড মডিউল, ইভেন্ট, এন্ডপয়েন্ট)
• এর উপর কী নির্ভর করে (ডাটাবেস, কিউ, ক্যাশ, কনফিগ, বাহ্যিক সেবা)
• এখানে কী নিয়মগুলো গুরুত্বপূর্ণ (নামকরণ, এরর স্টাইল, লগিং, টেস্ট কেমন লেখা হয়)

একটি “গটচা” লাইন যোগ করুন—যেখানে ব্যয়বহুল ভুল ঘটতে পারে: হিডেন ক্যাশিং, ফিচার ফ্ল্যাগ, মাইগ্রেশন ধাপ, এবং যেকোনো এমন জিনিস যা নীরবে ভাঙিয়ে দিতে পারে।

নিচে একটি কমপ্যাক্ট টেমপ্লেট আছে যা আপনি কপি করতে পারেন:

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-এর একটি সেকশন) রাখুন, রেপো রুটে একটি বিশাল ডক রাখার বদলে।

একটি সহজ, পুনরাবৃত্তিযোগ্য স্ট্রাকচার সাহায্য করে। সংক্ষিপ্ত রাখুন যাতে মানুষ এটিকে মেইনটেইন করে:

• এই ফোল্ডারটি কী (১–২ বাক্যে উদ্দেশ্য)
• পাবলিক সারফেস (প্রধান এন্ট্রি পয়েন্ট, এক্সপোর্টেড মডিউল বা API)
• মূল নির্ভরশীলতা (ইন্টার্নাল ও এক্সটার্নাল)
• সীমানা (কি ইম্পোর্ট বা পরিবর্তন করা উচিত না)
• কিভাবে টেস্ট করবেন (সর্বোত্তম লোকাল চেক)
• Last updated: 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 এগুলো উল্লেখ করবে)।
• Claude-কে বলুন কোন নির্দিষ্ট ফাইলগুলো চাই (সীমা ৩–৬)।
• কেবল সেই ফাইলগুলো দিন, তারপর ধাপে ধাপে বাড়ান।
• কোনো প্যাচ করার আগে একটি ছোট প্ল্যান দাবি করুন।

ধাপ ৩: স্পষ্টভাবে অনুমান ও ফাইল অনুরোধ বাধ্য করুন

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 হয়তো “অদ্ভুত” চেকটিকে সরিয়ে দিতে পারে যা শুধুমাত্র একটি ফ্ল্যাগ অন থাকলে প্রয়োজন, অথবা এমন কোড যোগ করতে পারে যা বিল্ড ধ্বংস করে।

ড্রিফটের লাল পতাকা:

• উত্তরটি “সাধারণ প্যাটার্ন” নিয়ে কথা বলছে কিন্তু আপনার আসল ফাইল নাম দিচ্ছে না
• এটি একটি নতুন শেয়ার্ড ইউটিলিটি প্রবর্তন করছে বিদ্যমানটি ব্যবহার না করে
• এটি প্যাকেজ বাউন্ডারি জুড়ে ইম্পোর্ট পরিবর্তন করছে
• এটি ফিচার ফ্ল্যাগ বা env-নির্ভর শাখা উপেক্ষা করছে
• এটি একটি কোর শেয়ার্ড প্যাকেজে ডিপেন্ডেন্সি যোগ করার পরামর্শ দিচ্ছে

ক্রস-প্যাকেজ ইম্পোর্টকে ডিফল্ট হিসেবে না নিয়ে একটি সিদ্ধান্ত হিসেবে বিবেচনা করুন। এলাকা সম্প্রসারণ না করা পর্যন্ত এডিট লোকাল রাখুন।

Claude-কে কিছু জিজ্ঞাসা করার আগে দ্রুত চেকলিস্ট

সঠিক এডিট পাওয়ার দ্রুত উপায় হলো সীমা দিয়ে শুরু করা, যোগের বদলে। একটি ভালো প্রম্পট একটু কঠোর মনে হওয়া উচিত: এটি Claude-কে কোথায় দেখতে হবে, কী উপেক্ষা করতে হবে, এবং “শেষ” মানে কী তা বলে।

কোড পেস্ট করার আগে একটি সংক্ষিপ্ত প্রেফেস লিখুন যা কাজটিকে রিপোর এক স্থানে পিন করে। প্যাকেজ, সঠিক ফোল্ডার এবং নির্দিষ্ট লক্ষ্য নামুন। তারপর একটি লোকাল সারাংশ (উদ্দেশ্য, মূল নির্ভরশীলতা, গুরুত্বপূর্ণ কনভেনশন) এবং সেই এন্ট্রি ফাইলটি অন্তর্ভুক্ত করুন যা পরিবর্তনকে অ্যাংকর করে।

চেকলিস্ট:

• Boundary: Work only in \u003cpackage\u003e/\u003cpath\u003e. Goal: \u003cone sentence\u003e. Ignore everything else unless asked.
• Context starter: Local summary: \u003c5-10 lines\u003e. Entry file: \u003cpath/to/file\u003e.
• Constraints: Allowed folders: \u003c...\u003e. Must not change: \u003cfolders/files or APIs\u003e. Keep behavior: \u003cwhat must stay true\u003e.
• File requests first: “Before proposing changes, list the minimum files you need to see (max 5) and why.”
• Output format: “Reply with a short plan first. After I confirm, give patch-style suggestions by file.”

যদি 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

তারপর লুপটি টাইট রাখুন:

1. Map: “This change is limited to CartPage and ui-kit icons. No checkout/auth edits.”
2. Assumptions: অনুমানগুলোর একটি তালিকা দরকার এবং অনুমোদনের জন্য অপেক্ষা করুন।
3. File requests: কেবল সেই কয়েকটি ফাইল অনুমোদন করুন যেগুলো সত্যিই দরকার (CartPage, useCart, ui-kit icons, ui-kit index)।
4. Plan: নিশ্চিত করুন এটি সীমার সাথে মেলে।
5. Edits: সবচেয়ে ছোট diff করুন, তারপর আপডেটেড টেস্ট চাইুন।

পরিবর্তনের পরে, ডকুমেন্ট করুন যাতে ভবিষ্যৎ কনটেক্সট ছোট থাকে:

• দুটো লোকাল সারাংশে নতুন এক্সপোর্ট এবং স্পষ্টভাবে কোন ফাইল টাচ হয়েছে তা আপডেট করুন।
• কার্ট পেইজে একটি সংক্ষিপ্ত কমেন্ট হেডার যোগ করুন: বাটনটি কী করে এবং স্টেট কোথায় হ্যান্ডেল হয়।
• পাস করা টেস্ট কমান্ডগুলো নথিভুক্ত করুন (এবং কোন স্ন্যাপশট আপডেট হয়েছে তা)।

পরবর্তী ধাপ: এটাকে আপনার টিমের জন্য পুনরাবৃত্তিযোগ্য করুন

যদি এটা একজনের জন্য ভাল কাজ করে কিন্তু টিমের বাকি লোকদের জন্য না করে, বেশিরভাগ ক্ষেত্রে অভাবটি পুনরাবৃত্তিত্ব। “ভাল কনটেক্সট হাইজিন” ডিফল্ট করা দরকার, ব্যক্তিগত অভ্যাস নয়।

আপনার শ্রেষ্ঠ প্রম্পটগুলো টিম টেমপ্লেটে পরিণত করুন

একটি প্রম্পট স্কেলেটন সংরক্ষণ করুন যা সবাই কপি করে পূরণ করতে পারে। সংক্ষিপ্ত কিন্তু কঠোর রাখুন। এতে থাকবে লক্ষ্য (“শেষ হলে কী দেখতে হবে”), অনুমোদিত স্কোপ, হাইর্ড বাউন্ডারি (কেন), একটি লোকাল সারাংশ, এবং আউটপুট চুক্তি (প্রথমে প্ল্যান, তারপর ফাইলভিত্তিক ডিফ এবং টেস্ট)।

হালকাভাবে কড়া কডিং ক্যালেন্ডার সহ সারাংশ রাখুন

মাসিক বড় রিভিউগুলো এড়িয়ে যান যা কেউ করে না। সারাংশ আপডেটকে স্বাভাবিক কাজের সঙ্গে যুক্ত করুন: যখন কোনো পরিবর্তন আচরণ, নির্ভরশীলতা, বা API বদলে, একই PR-এ লোকাল সারাংশ আপডেট করুন।

একটি সহজ নিয়ম: যদি একজন টিমমেট জিজ্ঞেস করবে “এটি কোথায় থাকে?” বা “কার উপর নির্ভরশীল?”, সারাংশ এখন অপ্রচলিত।

চ্যাট-ফার্স্ট ওয়ার্কফ্লোর প্রিফার করলে, Koder.ai আপনাকে এই ধরণের ইটারেশন নিরাপদে করতে সাহায্য করতে পারে। Planning mode আপনাকে স্কোপ ও সীমানায় সম্মতি করতে দেয় আগে থেকেই, এবং স্ন্যাপশট ও রোলব্যাক আপনাকে অনুমান ভুল হলে দ্রুত ফিরে যেতে দেয়।