১৭ ডিসে, ২০২৫·6 মিনিট
Claude Code দিয়ে Prompt-to-PR ওয়ার্কফ্লো: ছোট ডিফ
Claude Code-এর সাথে লোকালভাবে Prompt-to-PR ওয়ার্কফ্লো ব্যবহার করুন: ছোট প্রম্পট লিখুন, ছোট ডিফ পাঠান, চেক চালান, ব্যর্থ হলে পুনরায় প্রম্পট দিন এবং মার্জ-রেডি PR পৌঁছান।
Claude Code-এর সাথে লোকালভাবে Prompt-to-PR ওয়ার্কফ্লো ব্যবহার করুন: ছোট প্রম্পট লিখুন, ছোট ডিফ পাঠান, চেক চালান, ব্যর্থ হলে পুনরায় প্রম্পট দিন এবং মার্জ-রেডি PR পৌঁছান।
বড় এক-ধাপের প্রম্পট প্রায়ই বড়, গন্ডগোল পরিবর্তনে নিয়ে যায়: অনেকগুলো ফাইল স্পর্শ করা, অপ্রাসঙ্গিক রিফ্যাক্টর, এবং এমন কোড যা আপনি সময় না পেলে বুঝে উঠতে পারেন না। আউটপুট প্রযুক্তিগতভাবে ঠিক থাকলেও রিভিউ ঝুঁকিপূর্ণ মনে হয় কারণ কী বদলেছে এবং কেন বদলেছে বোঝা কঠিন।
ছোট ডিফ তা প্রতিরোধ করে। যখন প্রতিটি পরিবর্তন সীমিত ও ফোকাসড থাকে, আপনি কয়েক মিনিটে সেটা পড়ে নিতে পারেন, ভুল ধরা পড়ে দ্রুত, এবং অনিচ্ছাকৃতভাবে অন্য অংশ ভেঙে ফেলার সম্ভাবনা কমে যায়। রিভিউয়াররা ছোট PR-গুলোকে বেশি বিশ্বাস করেন, তাই মর্জ দ্রুত হয় এবং কম কমেন্ট লাগে।
Prompt-to-PR একটি সহজ লুপ:
এই কেডেন্স ব্যর্থতাকে লুপের দ্রুত ফিডব্যাকে বদলে দেয়, শেষে চমক হয়ে আসে না। যদি আপনি Claude Code-কে একটি ভ্যালিডেশন রুল সমন্বয় করতে বলো, তা কেবল ঐ এক রুলেই সীমাবদ্ধ রাখো। যদি কোনো টেস্ট ব্যর্থ হয়, ফেলিং আউটপুট পেস্ট করে এমন সবচেয়ে ছোট ফিক্স চাও যা টেস্ট পাস করায়, পুরো মডিউল পুনর্লিখন নয়।
একটা জিনিস অপরিবর্তিত থাকে: চূড়ান্ত কোডের জন্য আপনি এখনো জবাবদিহি করবেন। মডেলকে স্থানীয় পেয়ার প্রোগ্রামারের মতো আচরণ করো যে দ্রুত টাইপ করে, কিন্তু অটোমেট নয়। আপনি নির্ধারণ করো কী যাবে, কী থাকবে না, এবং কখন PR ওপেন করা নিরাপদ।
নিরপেক্ষ বেসলাইন থেকে শুরু করো। আপনার ব্রাঞ্চ পেছনে থাকলে বা টেস্ট ইতিমধ্যেই ফেল করছে, প্রত্যেক পরামর্শ অনুমানভিত্তিক হয়ে যায়। লেটেস্ট পরিবর্তনগুলি পুল করো, টিমের পছন্দমতো রিবেস বা মার্জ করো, এবং যে বর্তমান স্টেটটি সুস্থ আছে তা নিশ্চিত করো তারপরই কিছু চাও।
একটি “লোকাল পেয়ার প্রোগ্রামার” সেটআপ মানে Claude Code আপনার রিপোর ফাইলগুলো এডিট করবে আর আপনি লক্ষ্য, গার্ডরেইল এবং প্রতিটি ডিফের নিয়ন্ত্রণ রাখবে। মডেল আপনার কোডবেস জানে না যতক্ষণ না আপনি দেখান, তাই ফাইল, সীমাবদ্ধতা এবং প্রত্যাশিত আচরণ স্পষ্ট করে বলুন।
প্রথম প্রম্পটের আগে নির্ধারণ করুন কোন চেকগুলো কোথায় চলবে। যদি আপনি লোকালেই টেস্ট চালাতে পারেন, মিনিটের মধ্যে ফিডব্যাক পাবেন, যা ইটারেশন ছোট রাখে। যদি কিছু চেক শুধুমাত্র CI-তে চলে (কিছু লিন্ট নিয়ম, বড় স্যুট, বিল্ড স্টেপ), তখন সিদ্ধান্ত নিন কখন CI-র উপর নির্ভর করবেন যাতে প্রতিটি ছোট পরিবর্তনের পরে অপেক্ষা না করতে হয়।
একটি সহজ প্রি-ফ্লাইট:
কাজ করার সময় একটি ছোট স্ক্র্যাচপ্যাড খুলে রাখো। এমন সীমাবদ্ধতা লেখো যেমন "no API changes," "keep behavior backward compatible," "touch only X module," এবং আপনি যেসব সিদ্ধান্ত নেবেন। যখন কোনো টেস্ট ফেল করে, সঠিক ফেলিং মেসেজও সেখানে পেস্ট করো। সেই স্ক্র্যাচপ্যাড আপনার পরবর্তী প্রম্পটের সেরা ইনপুট হয়ে ওঠে এবং সেশন ভেসে যাওয়া বন্ধ করে।
ছোট ডিফ কৌশলের সূচনা ইচ্ছাকৃতভাবে সংকীর্ণ প্রম্পট দিয়ে। মর্জযোগ্য কোডের দ্রুততম পথ হল এমন একটি পরিবর্তন যা আপনি এক মিনিটে পর্যালোচনা করতে পারেন—একটি রিফ্যাক্টর না যে আপনাকে এক ঘণ্টা বোঝাতে হবে।
একটি ভাল প্রম্পটে এক লক্ষ্য, এক কোড এলাকা এবং এক প্রত্যাশিত ফল থাকা উচিত। যদি আপনি নির্দেশ করতে না পারেন কোথায় পরিবর্তন হওয়া উচিত (একটি ফাইল, ফোল্ডার, বা মডিউল), মডেল অনুমান করবে এবং ডিফ ছড়িয়ে পড়বে।
একটি প্রম্পটের আকৃতি যা পরিবর্তন টাইট রাখে:
সীমানা হলো গোপন অস্ত্র। "লগইন বাগ ঠিক করো" বলার বদলে বলুন কী অটল থাকতে হবে: "Don't change the API shape," "Don't rename public functions," "No formatting-only edits," "Avoid new dependencies." এতে আপনার পেয়ার প্রোগ্রামারকে কোথায় চালাকী করা যাবে না বলা হয়।
যদি কাজটি এখনও অস্পষ্ট মনে হয়, কোডের আগে একটি পরিকল্পনা চাও। একটি সংক্ষিপ্ত পরিকল্পনা কাজটিকে ধাপে ভাগ করে এবং আপনাকে প্রথম ছোট সর্ট পদক্ষেপ অনুমোদন করার সুযোগ দেয়।
Goal: Fix the null crash when rendering the profile header.
Location: src/components/ProfileHeader.tsx only.
Constraints: Do not change styling, props, or any exported types.
Expected outcome: If user.name is missing, show "Anonymous" and no crash.
Diff constraint: Minimal diff. No refactors. No unrelated formatting.
If unclear: First reply with a 3-step plan, then wait for approval.
যদি আপনি টিমে কাজ করেন, রিভিউ সীমাবদ্ধতাও যোগ করুন: "Keep it under ~30 lines changed" বা "One file only unless absolutely necessary." এটি ডিফকে স্ক্যান করা সহজ করে এবং যখন কিছু ব্যর্থ হয় তখন পরবর্তী প্রম্পট আরও তীক্ষ্ণ হয়।
প্রতিটি লুপকে এক ছোট, টেস্টেবল পরিবর্তনের উপর ফোকাস রাখুন। যদি আপনি এক বাক্যে লক্ষ্য বর্ণনা করতে পারেন এবং কোন ফাইলগুলো পরিবর্তিত হবে তা পূর্বাভাস করতে পারেন, তাহলে সেটি সঠিক আকার।
ভাল ইউনিটের উদাহরণ: একটি বাগ শুধুমাত্র একটি পথ সংশোধন করা (রিপ্রো ও গার্ডসহ), একটি নির্দিষ্ট টেস্ট সমন্বয় করা, বিহেভিয়ার-সংরক্ষণকারী রিফ্যাক্টর (রিনেম, ফাংশন এক্সট্রাক্ট, ডুপ্লিকেশন অপসারণ), বা একটি ত্রুটি বার্তা/ভ্যালিডেশন রুল উন্নত করা।
প্রতিটি লুপের জন্য সময় নির্ধারণ করুন। সাধারণত ১০–২০ মিনিট যথেষ্ট স্পষ্ট প্রম্পট লিখতে, ডিফ প্রয়োগ করতে এবং দ্রুত চেক চালাতে। যদি ২০ মিনিটের পরে আপনি এখনও অন্বেষণে থাকেন, ইউনিটটি ছোট করুন বা শুধুমাত্র তদন্ত (নোট, লগিং, ফেলিং টেস্ট) করুন এবং সেখানে থেমে যান।
শুরু করার আগে “ডান” কী তা সংজ্ঞায়িত করুন:
যখন স্কোপ বড় হতে শুরু করে, আগেই থেমে যান। যদি আপনি নিজে বলতে শুরু করেন "এখানেই থাকলে…" আপনি সদ্য যে পরবর্তী ইটারেশন খুঁজে পেয়েছেন। এটাকে ফলো-আপ হিসেবে ক্যাপচার করুন, বর্তমান ছোট ডিফ কমিট করুন, এবং এগিয়ে যান।
টেস্ট বা বিল্ড চালানোর আগে, রিভিউয়ারের মতো ডিফটি পড়ুন। এখানেই ওয়ার্কফ্লো পরিষ্কার থাকে নাকি ধীরে ধীরে "কেন ওই ফাইলটা স্পর্শ করল?" এলাকায় চলে যায় তা নির্ধারিত হয়।
প্রথমে Claude Code-কে বলুন পরিবর্তনগুলো সাধারণ ভাষায় সারসংক্ষেপ করতে: স্পর্শকৃত ফাইলগুলো, বিহেভিয়ার পরিবর্তন, এবং যা না বদলানো হয়েছে। যদি এটি স্পষ্টভাবে ব্যাখ্যা না করতে পারে, ডিফ সম্ভবত অনেক বেশি করছে।
তারপর আপনি নিজে রিভিউ করুন। প্রথমে স্কিমিং করে স্কোপ দেখুন, পরে উদ্দেশ্যে পড়ুন। আপনি ড্রিফট খুঁজছেন: অপ্রাসঙ্গিক ফরম্যাটিং, অতিরিক্ত রিফ্যাক্টর, সিম্বল রিনেম, বা অনুরোধ করা না হওয়া পরিবর্তন।
একটি দ্রুত প্রি-চেক:
ডিফ প্রত্যাশার থেকে বড় হলে, পরীক্ষা চালিয়ে সমস্যার সমাধান করার চেষ্টা করবেন না। রিভার্ট করে আবার ছোট ধাপের জন্য প্রম্পট দিন। উদাহরণ: "শুধু একটি ফেলিং টেস্ট যোগ করো যা বাগটি রিপ্রোডিউস করে। কোন রিফ্যাক্টর নয়." ছোট ডিফগুলো ব্যর্থতাগুলোকে সহজে ব্যাখ্যা যোগ্য রাখে এবং পরবর্তী প্রম্পটকে নির্দিষ্ট করে।
ছোট ডিফগুলো কেবল তখনই ফল দেয় যখন আপনি দ্রুত যাচাই করেন। লক্ষ্য হলো একটি টাইট লুপ: একটু বদলাও, একটু যাচাই করো, প্রসঙ্গ তাজা থাকায় ভুল দ্রুত ধরা পড়ে।
যে সবচেয়ে দ্রুত চেকটি বলে "এটা ভাঙল" সেটি দিয়ে শুরু করুন। আপনি যদি ফরম্যাটিং বা ইমপোর্ট বদলান, লিন্ট/ফরম্যাট আগে চালান। ব্যবসায়িক লজিক ছুঁয়েছেন বলে মনে হলে, সেই ফাইল বা প্যাকেজের টার্গেটেড ইউনিট টেস্ট চালান। টাইপ বা বিল্ড কনফিগে বদল করলে দ্রুত কম্পাইল চালান।
একটি ব্যবহারিক ক্রম:
কিছু ব্যর্থ হলে, কিছু ঠিক করার আগে দুইটি জিনিস ক্যাপচার করুন: চালানো নির্দিষ্ট কমান্ড এবং পূর্ণ এরর আউটপুট (ঠিক যেমনটি)। ঐ রেকর্ড পরবর্তী প্রম্পটকে নির্দিষ্ট করে এবং “এটা এখনও ব্যর্থ” লুপ ঠেকায়।
স্কোপ টাইট রাখুন। যদি লিন্ট ব্যর্থ করে এবং টেস্টও ব্যর্থ করে, প্রথমে লিন্ট ঠিক করুন, পুনরায় চালান, তারপর টেস্ট ঠিক করুন। একই পাসে দ্রুত পরিচ্ছন্নতা ও ক্র্যাশ ফিক্স একসাথে মিশাবেন না।
চেক ফেল করলে, ফেলিয়ার আউটপুটকে আপনার পরবর্তী প্রম্পট হিসেবে ব্যবহার করুন। দ্রুত লুপ হচ্ছে: এরর পেস্ট করো, ডায়াগনসিস পাও, সর্বনিম্ন ফিক্স প্রয়োগ করো, পুনরায় চালাও।
ফেইল্যুরগুলি শব্দশুদ্ধভাবে পেস্ট করুন, কমান্ড ও পূর্ণ স্ট্যাক ট্রেসসহ। প্রথমে সবচেয়ে সম্ভাব্য কারণ চাও, অপশনগুলোর মেনু নয়। Claude Code সঠিক লাইন নম্বর ও মেসেজ পেয়ে ভালো করে মামলা নির্ণয় করে।
আপনি ইতিমধ্যেই কী চেষ্টা করেছেন এক বাক্যে যোগ করুন যাতে এটি আপনাকে আবার একই পথে না পাঠায়। গুরুত্বপূর্ণ সীমাবদ্ধতাগুলো পুনরায় বলুন ("Don't change public APIs," "Keep current behavior, just fix the crash")। তারপর এমন সবচেয়ে ছোট প্যাচ চাও যা চেক পাস করায়।
যদি প্রস্তাবিত ফিক্স বিহেভিয়ার বদলে দেয়, সেই নতুন বিহেভিয়ার প্রমাণ করে এমন একটি টেস্ট চাইুন। যদি একটি হ্যান্ডলার এখন 400 ফেরত দেয় 500 এর বদলে, একটি ফোকাসড টেস্ট চাইুন যা পুরোনো কোডে ফেল করে এবং ফিক্সের পরে পাস করে। এটি কাজটিকে সততা দেয় এবং PR-কে বিশ্বাসযোগ্য করে তোলে।
চেক সবুজ এবং ডিফ এখনও একটাই আইডিয়া মনে হলে থামুন। যদি মডেল অপ্রাসঙ্গিক কোড উন্নত করতে শুরু করে, পুনরায় প্রম্পট দিন: "Only address the failing test. No cleanup."
একটি PR দ্রুত মর্জ হয় যখন স্পষ্ট থাকে কী বদলেছে, কেন বদলেছে এবং কীভাবে পরীক্ষা করবেন। এই ওয়ার্কফ্লোতে PR একটি ছোট গল্পের মতো হওয়া উচিত: ছোট ধাপ, পরিষ্কার কারণ।
কমিটগুলোকে আপনার ইটারেশনগুলোর সাথে সারিবদ্ধ রাখুন। যদি আপনি একটি বিহেভিয়ার পরিবর্তনের জন্য একবার বলেছিলেন, সেটি এক কমিট রাখুন। যদি পরে ফেল করা টেস্ট ঠিক করেন, তা পরের কমিট রাখুন। রিভিউয়াররা পথটি ফলো করতে পারে এবং আপনি অপ্রয়োজনীয় পরিবর্তন ঢুকাননি তা বিশ্বাস করতে পারে।
ইচ্ছে থাকলে কমিট মেসেজগুলিকে উদ্দেশ্যের জন্য লিখুন, ফাইল নাম নয়। "Fix login redirect when session expires" ভাল — "Update auth middleware" নয়। যখন মেসেজ ব্যবহারকারীনির্মিত আউটকাম নাম করে, রিভিউয়াররা কম আন্দাজ করে।
একই কমিটে রিফ্যাক্টর ও বিহেভিয়ার পরিবর্তন মিশাবেন না। যদি আপনি ভ্যারিয়েবল রিনেম বা হেল্পার স্থানান্তর করতে চান, আলাদা করুন (বা আপাতত বর্জন করুন)। শব্দ ধীর করে এবং রিভিউ ধীর করে।
PR বর্ণনায় সংক্ষিপ্ত ও কনক্রিট থাকুন:
উদাহরণ: একটি বিলিং পেজ ক্র্যাশ যা null customer রেকর্ডের কারণে। কমিট ১ একটি গার্ড ও ক্লিয়ার এরর স্টেট যোগ করে। কমিট ২ null কেসের জন্য একটি টেস্ট যোগ করে। PR বর্ণনা বলে: "Open Billing, load a customer with no profile, confirm the page shows the new empty state." এধরনের PR দ্রুত অনুমোদন পাওয়ার প্রবণতা রাখে।
এই কেডেন্স ভেঙে যায় যখন স্কোপ চাপে চাপে বাড়ে। একটি প্রম্পট যা শুরু হয়েছিল "এই ফেলিং টেস্ট ঠিক করো" হঠাৎ করে "মডিউল জুড়ে এরর হ্যান্ডলিং উন্নত করো" এ পরিণত হয়, এবং আচমকা আপনি একটি বড় ডিফ রিভিউ করছেন যার উদ্দেশ্য অস্পষ্ট। এটিকে টাইট রাখুন: এক লক্ষ্য, এক পরিবর্তন সেট, এক সেট চেক।
আরও একটি ধীরকরণ হলো সুন্দর দেখাতে পারে এমন রিফ্যাক্টরগুলো গ্রহণ করা শুধু কারণ তা সুন্দর। রিনেম, ফাইল মুভ, স্টাইল পরিবর্তন রিভিউয়ে শব্দ বাড়ায় এবং প্রকৃত বিহেভিয়ার পরিবর্তন খুঁজে পেতেই সমস্যা তৈরি করে।
সাধারণ জাল:
"while it is here.""এখনও ব্যর্থ" বলে পুনরায় প্রম্পট করা।একটি বাস্তব উদাহরণ: টেস্ট ফেল করে "expected 400, got 500." যদি আপনি শুধু স্ট্যাক ট্রেসের টেইল পেস্ট করেন, প্রায়ই সাধারণ try/catch পরামর্শ পাবেন। যদি পুরো টেস্ট আউটপুট দেয়া হয়, রিয়েল ইস্যুটি দেখা যেতে পারে: একটি অনুপস্থিত ভ্যালিডেশন ব্রাঞ্চ। সেটি একটি ছোট, ফোকাসড ডিফ নিয়ে আসে।
কমিট করার আগে, ডিফটি রিভিউয়ারের মতো পড়ুন। প্রশ্ন করো: প্রতিটি লাইন কি অনুরোধ সার্ভ করে, এবং আমি কি এটাকে এক বাক্যে ব্যাখ্যা করতে পারি? যদি না, অতিরিক্ত পরিবর্তনগুলো revert করে আবার সংকীর্ণ অনুরোধ দিয়ে প্রম্পট করো।
একজন ব্যবহারকারী রিপোর্ট করে: "The settings page sometimes resets to defaults after you save." আপনি main টানা, টেস্ট চালান, এবং একটি ফেল দেখে ফেলেন। অথবা টেস্ট নেই, শুধু একটি স্পষ্ট রিপ্রো আছে।
এটাকে একটি লুপ হিসেবে আচরণ করো: এক ছোট অনুরোধ, এক ছোট ডিফ, তারপর চেক।
প্রথমে Claude Code-কে সবচেয়ে ছোট দরকারি প্রসঙ্গ দিন: ফেলিং টেস্ট আউটপুট (বা রিপ্রো স্টেপস), সন্দেহভাজন ফাইল পাথ, এবং লক্ষ্য ("save করার পর সেটিংস রিসেট বন্ধ রাখো")। ডায়াগনসিস ও একটি মিনিমাল প্যাচ চাইুন, রিফ্যাক্টর নয়।
তারপর সংক্ষিপ্ত লুপে কাজ করুন:
ডিফ রিভিউ করে চেক চালান।
"What's the smallest change to fix this failure without widening scope?"চেক পাস করে কিন্তু আপনি রিগ্রেশন ভয় পেলে কভারেজ যোগ করুন।
শেষে একটি ছোট PR বর্ণনা দিন: বাগটা কী ছিল, কেন হয়েছিল, এবং কী পরিবর্তন করা হয়েছে। রিভিউয়ার নোট যোগ করুন যেমন "touches only X file" বা "added one test for the reset case" যাতে রিভিউ নিরাপদ মনে হয়।
PR ওপেন করার ঠিক আগে একটি চূড়ান্ত পরীক্ষা চালান যেন কাজটি পর্যালোচনা ও মার্জ করা সহজ হয়:
উদাহরণ: আপনি একটি লগইন বাগ ঠিক করেছেন কিন্তু একই সাথে ২০টি ফাইল রিফরম্যাট করেছেন—ঐ ফরম্যাটিং কমিটটি ফিরিয়ে নিন। রিভিউয়ারকে লগইন ফিক্সেই ফোকাস রাখতে দিন।
যদি কোনো আইটেম ফেল করে, আরেকটা ছোট লুপ চালান: একটি সংক্ষিপ্ত ডিফ করুন, চেক পুনরায় চালান, এবং PR নোট আপডেট করুন। সেই শেষ লুপ ঘন্টাখানেকের ব্যাক-এন্ড-বচচা কমাতে পারে।
অভ্যাসিকতা একটি ভালো সেশনকে নির্ভরযোগ্য ওয়ার্কফ্লোতে পরিণত করে। একটি ডিফল্ট লুপ বেছে নিন এবং প্রতিবার একইভাবে চালান। এক সপ্তাহের মধ্যে আপনি দেখতে পাবেন আপনার প্রম্পটগুলো সংক্ষিপ্ত হচ্ছে এবং ডিফগুলো পর্যালোচনা সহজ হচ্ছে।
একটি সরল রুটিন:
একটি ব্যক্তিগত প্রম্পট টেমপ্লেট আপনাকে শৃঙ্খলায় রাখে: "Change only what's needed. Touch at most 2 files. Keep public behavior the same unless I say otherwise. Tell me the command to run and what success looks like."
আপনি যদি Koder.ai-এর ভিতরে নির্মাণ করেন, একই লুপ চ্যাট ইন্টারফেসে ব্যবহার করতে পারবেন। Planning mode ছোট মার্জেবল স্লাইস স্কোপ করতে ভাল—ইনপুট, আউটপুট এবং গ্রহণযোগ্যতা চেক নির্ধারণ করুন—এবং স্ন্যাপশট/রোলব্যাক দ্রুত পুনরুদ্ধারে সাহায্য করে।
পরিবর্তন স্থিতিশীল হলে সোর্স কোড এক্সপোর্ট করে আপনার স্বাভাবিক লোকাল টুলিং, CI, এবং টিম রিভিউ চালান। পৃথিবীতে যাচাই করতে ডিপ্লয় করুন যখন পুরো ফ্লো এন্ড-টু-এন্ড পরীক্ষা করা জরুরী।
লুপটিকে আপনার ডিফল্ট বানান। ছোট প্রম্পট, ছোট ডিফ, ঘন চেক এবং দ্রুত সংশোধন মিলিয়ে এমন PR আসে যা সেরা অর্থে ‘বোরিং’।
ডিফের আকার: এক বাক্যে ব্যাখ্যা করা যায় এমন এক ছোট, পর্যালোণাযোগ্য পরিবর্তন লক্ষ্য করুন।
একটি ব্যবহারিক নিয়ম হল: আপনি পূর্বাভাস করতে পারবেন কোন ফাইল(গুলো) পরিবর্তিত হবে, এবং একটি দ্রুত চেক (টার্গেটেড টেস্ট, লিন্ট, বা দ্রুত রান) দিয়ে এটি যাচাই করতে পারবেন। যদি না পারেন, কাজটি এখনও বেশি — এটিকে আলাদা লুপে ভাগ করুন: “রিপ্রো টেস্ট যোগ করুন” এবং “বাগ ঠিক করুন”।
হ্যাঁ — লক্ষ্য অস্পষ্ট হলে প্রথমে ছোট একটি প্ল্যান চাও।
সহজ একটি গেট ব্যবহার করো:
এতে মডেল অনুমান করে অপ্রয়োজনীয় ফাইল ছুঁতে দেয় না।
আপনার প্রম্পটে অবশ্যই নিচের বিষয়গুলো রাখুন:
যদি মডেল আপনি চাওয়ার চেয়ে বেশি ফাইল স্পর্শ করে, সঙ্গে থেকে স্কোপ কমিয়ে দিন।
প্রায়োগিক পদক্ষেপ:
X ফাইলকে স্পর্শ করো। কোন রিফ্যাক্টরিং নয়। কোন অপ্রাসঙ্গিক ফরম্যাটিং নয়।”বিস্তৃত ডিফকে “টেস্ট করে বের করে নেওয়ার” চেষ্টা সাধারণত ছোট করে নতুন করে করার চেয়ে বেশি সময় নেয়।
প্রথমে ডিফ পড়ে নিন, তারপর চেক চালান।
সরল একটি অর্ডার:
ফেইল্যুর কোডব্লক কপি করে সবচেয়ে ছোট ফিক্স চাও।
সম্বল করুন:
“এখনও ব্যর্থ” বলে মাত্রা ছেড়ে দেওয়ার চেয়ে নির্দিষ্ট আউটপুট দেওয়াই দ্রুত নির্দিষ্ট প্যাচ এনে দেয়।
মডেলকে একটি দ্রুত টাইপিং সঙ্গী হিসেবে ভাবুন, অটোপাইলট হিসেবে নয়।
আপনি দায়িত্বশীল:
ভাল অভ্যাস: সংক্ষিপ্ত প্লেইন-ল্যাঙ্গুয়েজ সারসংক্ষেপ দাবি করুন: কী বদলেছে, কী বদলায়নি, এবং কেন।
বাই ডিফল্ট আলাদা রাখুন।
রিফ্যাক্টর ও বিহেভিয়ার পরিবর্তন একসাথে মিশালে রিভিউ-তে শব্দবৃদ্ধি হয় এবং উদ্দেশ্য যাচাই কঠিন করে।
সংক্ষিপ্ত এবং কনক্রিট রাখুন:
যদি আপনার PR ‘একটি ধারনা, একটি চেক দিয়ে প্রমাণিত’ের মতো পড়ে, সেটি দ্রুত মার্জ হয়।
Koder.ai একই শৃঙ্খল বজায় রাখতে কিছু সহায়ক ফিচার দেয়:
এগুলো ইটারেশনগুলো ছোট ও উল্টনযোগ্য রাখে, তারপর আপনার স্ট্যান্ডার্ড রিভিউ প্রক্রিয়ায় মার্জ করুন।
এই কাঠামো স্বাভাবিকভাবে স্কোপ সীমাবদ্ধ করে এবং রিভিউ দ্রুত করে।
এটি লুপটিকে টাইট রাখে এবং ব্যর্থতাগুলো বোঝা সহজ করে।