Claude Code দিয়ে Prompt-to-PR ওয়ার্কফ্লো: ছোট ডিফ

কেন Prompt-to-PR বড় এক-ধাপের প্রম্পটকে হারায়

বড় এক-ধাপের প্রম্পট প্রায়ই বড়, গন্ডগোল পরিবর্তনে নিয়ে যায়: অনেকগুলো ফাইল স্পর্শ করা, অপ্রাসঙ্গিক রিফ্যাক্টর, এবং এমন কোড যা আপনি সময় না পেলে বুঝে উঠতে পারেন না। আউটপুট প্রযুক্তিগতভাবে ঠিক থাকলেও রিভিউ ঝুঁকিপূর্ণ মনে হয় কারণ কী বদলেছে এবং কেন বদলেছে বোঝা কঠিন।

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

Prompt-to-PR একটি সহজ লুপ:

• একবারে একটি ছোট পরিবর্তন স্পষ্ট সীমা নিয়ে চাও।
• ডিফ চেক করে নিশ্চিত হও এটা উদ্দেশ্য মেলে।
• আপনার স্বাভাবিক চেক চালাও (টেস্ট, লিন্ট, বিল্ড)।
• কিছু ব্যর্থ হলে, সঠিক এরর ও প্রসঙ্গ নিয়ে পুনরায় প্রম্পট দাও।
• যতক্ষণ পর্যন্ত মর্জ-রেডি না হয় পুনরাবৃত্তি করো।

এই কেডেন্স ব্যর্থতাকে লুপের দ্রুত ফিডব্যাকে বদলে দেয়, শেষে চমক হয়ে আসে না। যদি আপনি Claude Code-কে একটি ভ্যালিডেশন রুল সমন্বয় করতে বলো, তা কেবল ঐ এক রুলেই সীমাবদ্ধ রাখো। যদি কোনো টেস্ট ব্যর্থ হয়, ফেলিং আউটপুট পেস্ট করে এমন সবচেয়ে ছোট ফিক্স চাও যা টেস্ট পাস করায়, পুরো মডিউল পুনর্লিখন নয়।

একটা জিনিস অপরিবর্তিত থাকে: চূড়ান্ত কোডের জন্য আপনি এখনো জবাবদিহি করবেন। মডেলকে স্থানীয় পেয়ার প্রোগ্রামারের মতো আচরণ করো যে দ্রুত টাইপ করে, কিন্তু অটোমেট নয়। আপনি নির্ধারণ করো কী যাবে, কী থাকবে না, এবং কখন PR ওপেন করা নিরাপদ।

আপনার রিপো ও লোকাল পেয়ারিং সেটআপ প্রস্তুত করুন

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

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

প্রথম প্রম্পটের আগে নির্ধারণ করুন কোন চেকগুলো কোথায় চলবে। যদি আপনি লোকালেই টেস্ট চালাতে পারেন, মিনিটের মধ্যে ফিডব্যাক পাবেন, যা ইটারেশন ছোট রাখে। যদি কিছু চেক শুধুমাত্র CI-তে চলে (কিছু লিন্ট নিয়ম, বড় স্যুট, বিল্ড স্টেপ), তখন সিদ্ধান্ত নিন কখন CI-র উপর নির্ভর করবেন যাতে প্রতিটি ছোট পরিবর্তনের পরে অপেক্ষা না করতে হয়।

একটি সহজ প্রি-ফ্লাইট:

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

কাজ করার সময় একটি ছোট স্ক্র্যাচপ্যাড খুলে রাখো। এমন সীমাবদ্ধতা লেখো যেমন "no API changes," "keep behavior backward compatible," "touch only X module," এবং আপনি যেসব সিদ্ধান্ত নেবেন। যখন কোনো টেস্ট ফেল করে, সঠিক ফেলিং মেসেজও সেখানে পেস্ট করো। সেই স্ক্র্যাচপ্যাড আপনার পরবর্তী প্রম্পটের সেরা ইনপুট হয়ে ওঠে এবং সেশন ভেসে যাওয়া বন্ধ করে।

এমন প্রম্পট লিখুন যা প্রাকৃতিকভাবে ছোট ডিফ দেয়

ছোট ডিফ কৌশলের সূচনা ইচ্ছাকৃতভাবে সংকীর্ণ প্রম্পট দিয়ে। মর্জযোগ্য কোডের দ্রুততম পথ হল এমন একটি পরিবর্তন যা আপনি এক মিনিটে পর্যালোচনা করতে পারেন—একটি রিফ্যাক্টর না যে আপনাকে এক ঘণ্টা বোঝাতে হবে।

একটি ভাল প্রম্পটে এক লক্ষ্য, এক কোড এলাকা এবং এক প্রত্যাশিত ফল থাকা উচিত। যদি আপনি নির্দেশ করতে না পারেন কোথায় পরিবর্তন হওয়া উচিত (একটি ফাইল, ফোল্ডার, বা মডিউল), মডেল অনুমান করবে এবং ডিফ ছড়িয়ে পড়বে।

একটি প্রম্পটের আকৃতি যা পরিবর্তন টাইট রাখে:

• Goal: আপনি যে একমাত্র বিহেভিয়ার বদলাতে চান।
• Location: কোন ফাইল(গুলো) বা কম্পোনেন্ট স্পর্শ করবে।
• Constraints: কী বদলানো যাবে না।
• Acceptance: "ডান" হওয়ার মানদণ্ড কী।
• Diff size: কাজ করবে এমন সবচেয়ে ছোট পরিবর্তন স্পষ্টভাবে চাইতে বলুন।

সীমানা হলো গোপন অস্ত্র। "লগইন বাগ ঠিক করো" বলার বদলে বলুন কী অটল থাকতে হবে: "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-কে বলুন পরিবর্তনগুলো সাধারণ ভাষায় সারসংক্ষেপ করতে: স্পর্শকৃত ফাইলগুলো, বিহেভিয়ার পরিবর্তন, এবং যা না বদলানো হয়েছে। যদি এটি স্পষ্টভাবে ব্যাখ্যা না করতে পারে, ডিফ সম্ভবত অনেক বেশি করছে।

তারপর আপনি নিজে রিভিউ করুন। প্রথমে স্কিমিং করে স্কোপ দেখুন, পরে উদ্দেশ্যে পড়ুন। আপনি ড্রিফট খুঁজছেন: অপ্রাসঙ্গিক ফরম্যাটিং, অতিরিক্ত রিফ্যাক্টর, সিম্বল রিনেম, বা অনুরোধ করা না হওয়া পরিবর্তন।

একটি দ্রুত প্রি-চেক:

• পরিবর্তিত ফাইলগুলো আপনার অনুরোধের সাথে মিলছে কি?
• কোনো "ড্রাইভ-বাই" এডিট আছে কি (ব্ল্যাঙ্ক স্পেস, অপ্রাসঙ্গিক রিফ্যাক্টর)?
• কি এটি নতুন কোনো বিহেভিয়ার এনট্রোডিউস করে যা আপনি চাওনি?
• কোনো নতুন ডিপেন্ডেন্সি বা কনফিগ পরিবর্তন কি আছে যাকে বাস্তব কারণ থাকা দরকার?
• একজন রিভিউয়ার কি এটা পাঁচটা ফাইল না পড়েও বুঝতে পারবে?

ডিফ প্রত্যাশার থেকে বড় হলে, পরীক্ষা চালিয়ে সমস্যার সমাধান করার চেষ্টা করবেন না। রিভার্ট করে আবার ছোট ধাপের জন্য প্রম্পট দিন। উদাহরণ: "শুধু একটি ফেলিং টেস্ট যোগ করো যা বাগটি রিপ্রোডিউস করে। কোন রিফ্যাক্টর নয়." ছোট ডিফগুলো ব্যর্থতাগুলোকে সহজে ব্যাখ্যা যোগ্য রাখে এবং পরবর্তী প্রম্পটকে নির্দিষ্ট করে।

প্রতিটি ছোট পরিবর্তনের পরে চেক চালান

ছোট ডিফগুলো কেবল তখনই ফল দেয় যখন আপনি দ্রুত যাচাই করেন। লক্ষ্য হলো একটি টাইট লুপ: একটু বদলাও, একটু যাচাই করো, প্রসঙ্গ তাজা থাকায় ভুল দ্রুত ধরা পড়ে।

যে সবচেয়ে দ্রুত চেকটি বলে "এটা ভাঙল" সেটি দিয়ে শুরু করুন। আপনি যদি ফরম্যাটিং বা ইমপোর্ট বদলান, লিন্ট/ফরম্যাট আগে চালান। ব্যবসায়িক লজিক ছুঁয়েছেন বলে মনে হলে, সেই ফাইল বা প্যাকেজের টার্গেটেড ইউনিট টেস্ট চালান। টাইপ বা বিল্ড কনফিগে বদল করলে দ্রুত কম্পাইল চালান।

একটি ব্যবহারিক ক্রম:

• লিন্ট বা ফরম্যাট।
• আপনি যে এলাকায় বদলেছেন তার টার্গেটেড ইউনিট টেস্ট।
• সবকিছু মিলে যায় কিনা দেখতে বিল্ড বা টাইপচেক।
• বেসিক পাস করার পরে ধীর স্যুট (ইনটিগ্রেশন, ই2ই)।

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

স্কোপ টাইট রাখুন। যদি লিন্ট ব্যর্থ করে এবং টেস্টও ব্যর্থ করে, প্রথমে লিন্ট ঠিক করুন, পুনরায় চালান, তারপর টেস্ট ঠিক করুন। একই পাসে দ্রুত পরিচ্ছন্নতা ও ক্র্যাশ ফিক্স একসাথে মিশাবেন না।

চেক সবুজ না হওয়া পর্যন্ত ফেইল্যুর নিয়ে পুনরায় প্রম্পট করুন

চেক ফেল করলে, ফেলিয়ার আউটপুটকে আপনার পরবর্তী প্রম্পট হিসেবে ব্যবহার করুন। দ্রুত লুপ হচ্ছে: এরর পেস্ট করো, ডায়াগনসিস পাও, সর্বনিম্ন ফিক্স প্রয়োগ করো, পুনরায় চালাও।

ফেইল্যুরগুলি শব্দশুদ্ধভাবে পেস্ট করুন, কমান্ড ও পূর্ণ স্ট্যাক ট্রেসসহ। প্রথমে সবচেয়ে সম্ভাব্য কারণ চাও, অপশনগুলোর মেনু নয়। 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 দ্রুত মর্জ হয় যখন স্পষ্ট থাকে কী বদলেছে, কেন বদলেছে এবং কীভাবে পরীক্ষা করবেন। এই ওয়ার্কফ্লোতে PR একটি ছোট গল্পের মতো হওয়া উচিত: ছোট ধাপ, পরিষ্কার কারণ।

কমিটগুলোকে আপনার ইটারেশনগুলোর সাথে সারিবদ্ধ রাখুন। যদি আপনি একটি বিহেভিয়ার পরিবর্তনের জন্য একবার বলেছিলেন, সেটি এক কমিট রাখুন। যদি পরে ফেল করা টেস্ট ঠিক করেন, তা পরের কমিট রাখুন। রিভিউয়াররা পথটি ফলো করতে পারে এবং আপনি অপ্রয়োজনীয় পরিবর্তন ঢুকাননি তা বিশ্বাস করতে পারে।

ইচ্ছে থাকলে কমিট মেসেজগুলিকে উদ্দেশ্যের জন্য লিখুন, ফাইল নাম নয়। "Fix login redirect when session expires" ভাল — "Update auth middleware" নয়। যখন মেসেজ ব্যবহারকারীনির্মিত আউটকাম নাম করে, রিভিউয়াররা কম আন্দাজ করে।

একই কমিটে রিফ্যাক্টর ও বিহেভিয়ার পরিবর্তন মিশাবেন না। যদি আপনি ভ্যারিয়েবল রিনেম বা হেল্পার স্থানান্তর করতে চান, আলাদা করুন (বা আপাতত বর্জন করুন)। শব্দ ধীর করে এবং রিভিউ ধীর করে।

PR বর্ণনায় সংক্ষিপ্ত ও কনক্রিট থাকুন:

• কী বদলেছে (1–2 বাক্য)।
• কেন বদলেছে (বাগ বা রিকোয়্যারমেন্ট)।
• কীভাবে টেস্ট করবেন (নির্দিষ্ট ধাপ, কোনো ফ্ল্যাগ বা ডেটা প্রয়োজন কিনা)।
• আপনি কী পরিবর্তন করেননি (আশা স্থাপন করার জন্য)।
• কোনো ঝুঁকি বা রোলব্যাক নোট (ভুল হলে কী ভাঙতে পারে)।

উদাহরণ: একটি বিলিং পেজ ক্র্যাশ যা 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."
• লক্ষণের প্রতিফলন (অতিরিক্ত null চেক) ঠিক না করে মূল কারণ ঠিক না করা।
• কেবল লগের শেষ লাইন পেস্ট করা এবং প্রথম এরর লুকানো।
• চেক চালানোর আগে দ্রুত ডিফ স্ক্যান বাদ দেওয়া।
• নির্দিষ্ট কমান্ড ও আউটপুট না দিয়ে "এখনও ব্যর্থ" বলে পুনরায় প্রম্পট করা।

একটি বাস্তব উদাহরণ: টেস্ট ফেল করে "expected 400, got 500." যদি আপনি শুধু স্ট্যাক ট্রেসের টেইল পেস্ট করেন, প্রায়ই সাধারণ try/catch পরামর্শ পাবেন। যদি পুরো টেস্ট আউটপুট দেয়া হয়, রিয়েল ইস্যুটি দেখা যেতে পারে: একটি অনুপস্থিত ভ্যালিডেশন ব্রাঞ্চ। সেটি একটি ছোট, ফোকাসড ডিফ নিয়ে আসে।

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

উদাহরণ: কয়েকটি লুপে মার্জযোগ্য PR-এ বাগ ফিক্স

একজন ব্যবহারকারী রিপোর্ট করে: "The settings page sometimes resets to defaults after you save." আপনি main টানা, টেস্ট চালান, এবং একটি ফেল দেখে ফেলেন। অথবা টেস্ট নেই, শুধু একটি স্পষ্ট রিপ্রো আছে।

এটাকে একটি লুপ হিসেবে আচরণ করো: এক ছোট অনুরোধ, এক ছোট ডিফ, তারপর চেক।

প্রথমে Claude Code-কে সবচেয়ে ছোট দরকারি প্রসঙ্গ দিন: ফেলিং টেস্ট আউটপুট (বা রিপ্রো স্টেপস), সন্দেহভাজন ফাইল পাথ, এবং লক্ষ্য ("save করার পর সেটিংস রিসেট বন্ধ রাখো")। ডায়াগনসিস ও একটি মিনিমাল প্যাচ চাইুন, রিফ্যাক্টর নয়।

তারপর সংক্ষিপ্ত লুপে কাজ করুন:

1. লুপ ১ (মিনিমাল প্যাচ): সবচেয়ে ছোট পরিবর্তন প্রয়োগ করুন যা সম্ভবত বাগটা ঠিক করে। টাইট রাখুন: একটি গার্ড কন্ডিশন, অনুপস্থিত নাল চেক, ভুল ডিফল্ট ভ্যালু, বা ভুল ডিপেন্ডেন্সি তালিকা।

ডিফ রিভিউ করে চেক চালান।

2. লুপ ২ (নির্দিষ্ট ফেলব্যাক): যদি টেস্ট ফেল করে, সঠিক ফেলিং আউটপুট Claude Code-কে কপি করে দিন। ফাইল নাম, লাইন নম্বর, এবং assertion মেসেজ যোগ করুন। জিজ্ঞেস করুন: "What's the smallest change to fix this failure without widening scope?"

চেক পাস করে কিন্তু আপনি রিগ্রেশন ভয় পেলে কভারেজ যোগ করুন।

3. লুপ ৩ (টেস্ট বা টেস্ট সমন্বয়): একটি টেস্ট যোগ করুন যা প্যাচ না থাকলে ফেল করে এবং প্যাচ থাকলে পাস করে। বাগফোকাসড রাখুন। চেক আবার চালান।

শেষে একটি ছোট PR বর্ণনা দিন: বাগটা কী ছিল, কেন হয়েছিল, এবং কী পরিবর্তন করা হয়েছে। রিভিউয়ার নোট যোগ করুন যেমন "touches only X file" বা "added one test for the reset case" যাতে রিভিউ নিরাপদ মনে হয়।

PR ওপেন করার ঠিক আগে দ্রুত চেকলিস্ট

PR ওপেন করার ঠিক আগে একটি চূড়ান্ত পরীক্ষা চালান যেন কাজটি পর্যালোচনা ও মার্জ করা সহজ হয়:

• ডিফ মূল উদ্দেশ্যের সাথে মেলে এবং কয়েক মিনিটে বোঝার মতো ছোট।
• প্রাসঙ্গিক চেকগুলো (টেস্ট, লিন্ট, টাইপচেক, বিল্ড) চালানো হয়েছে এবং পাস করেছে। আপনার টিম CI ব্যবহার করলে নিশ্চিত করুন CI-তে একই সেট চলবে।
• কাজটির পাশে নিরাপত্তা জাল আছে: সম্ভব হলে বাগ বা ফিচারের জন্য একটি টেস্ট, অথবা টেস্ট না থাকলে একটি স্পষ্ট কারণ।
• 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 আসে যা সেরা অর্থে ‘বোরিং’।