Claude Code স্টাইল গাইড প্রম্পটসমূহ ধারাবাহিক কোড রিভিউয়ের জন্য

কেন স্টাইল গাইড লঙ্ঘন দ্রুত ছড়ায়

স্টাইল গাইড লঙ্ঘন সাধারণত এক বড় ভুল হিসেবে প্রকাশ পায় না। এগুলো শুরু হয় ক্ষুদ্র “প্রায় ঠিক” সিদ্ধান্ত থেকে যা একটি পুল রিকোয়েস্টে নিরপরাধ মনে হয়, তারপর জমা হতে থাকে যতক্ষণ না কোডবেস অসমান ও পড়তে কঠিন হয়ে ওঠে।

স্টাইল ড্রিফ্ট সাধারণত এরকম হয়: একটি ফাইলে userID ব্যবহার করা হয়েছে, আর একটায় userId, আরেকটায় uid। একটা হ্যান্ডলার { error: "..." } রিটার্ন করে, অন্যটা থ্রো করে, আরেকটা লগ করে ও null রিটার্ন করে। প্রতিটি পরিবর্তন ছোট, কিন্তু একসাথে তারা এমন একটি রিপো তৈরি করে যেখানে প্যাটার্নগুলো আগে থেকে অপ্রেডিক্টেবল।

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

এজন্য লক্ষ্য হওয়া উচিত ধারাবাহিক কনভেনশন, ব্যক্তিগত পছন্দ নয়। প্রশ্ন হওয়া উচিত “আমি কি এই নামটি পছন্দ করি?” নয়—“এইটা কি আমাদের সম্মত নিয়মের সঙ্গে মিলে যাতে পরবর্তী ব্যক্তি চিন্তা না করে সেটি অনুসরণ করতে পারে?”

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

একটি বাস্তব উদাহরণ: একজন ডেভেলপার একটি নতুন API এন্ডপয়েন্ট যোগ করে এবং কেবল ডিবাগিং-র জন্য কাঁচা অনুরোধ বডি লগ করে। যদি সেটা মেইন শাখায় lande করে, পরের এন্ডপয়েন্টও কপি করবে, এবং শীঘ্রই সংবেদনশীল ডেটা লগে চলে আসবে। প্রথম PR-এ এটা ধরা সস্তা; পরে ছড়ালে ধরাটা ব্যথাদায়ক ও ঝুঁকিপূর্ণ।

আপনার স্টাইল গাইডকে স্পষ্ট, টেস্টযোগ্য নিয়মে পরিণত করুন

স্টাইল গাইড তখনই রিভিউতে কাজ করে যখন তা একটি চেকলিস্টের মতো পড়ে, পছন্দের সেট না হয়ে। প্রতিটি নির্দেশিকাকে এমন একটি নিয়ম হিসেবে লিখুন যা ডিফে পরীক্ষা করা যায়।

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

প্রতিটি নিয়মের তীব্রতা আগে থেকে ঠিক করুন:

• ম্যান্ডেটরি: ব্যর্থ হলে চেঞ্জ ব্লক করবে।
• রেকমেন্ডেড: যদি স্পষ্ট কারণ না থাকে তবে ঠিক করুন।
• ঐচ্ছিক: থাকা ভালো, কখনো ব্লক করে না।

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

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

উদাহরণ: যদি একটি PR কাঁচা ইউজার টোকেন লগ করে, রিভিউটি “logging: never log secrets” এর অধীনে ব্যর্থ হওয়া উচিত এবং পরিবর্তে একটি request ID লগ করার পরামর্শ দেয়া উচিত।

মতামত নয় — নিয়ম প্রয়োগ করবে এমন প্রম্পট স্ট্রাকচার

স্টাইল প্রম্পট ব্যর্থ হয় যখন তা পছন্দের মতো শোনায়। একটি ভালো রিভিউ প্রম্পটের মতো হওয়া উচিত একটি চুক্তির: স্পষ্ট অ-বার্ত্য, স্পষ্টভাবে নামকৃত ব্যতিক্রম, এবং একটি পূর্বানুমানযোগ্য আউটপুট।

দুটো ছোট ব্লক দিয়ে শুরু করুন: কি অবশ্যই সত্য হতে হবে এবং কি বেঁচে নেয়া যেতে পারে। তারপর একটি সিদ্ধান্ত নিয়ম যোগ করুন: “যদি অনিশ্চিত হয়, Needs Clarification হিসেবে মার্ক করুন। অনুমান করবেন না।”

প্রমাণ জোর করুন। যখন টুল কোনো লঙ্ঘন ফ্ল্যাগ করে, তা করলে অবশ্যই সঠিক আইডেন্টিফায়ার ও ফাইল পাথ কোট করতে হবে—বেঠিক বর্ণনা নয়। এই একটাই শর্ত অনেক আগাম-মীমাংসা কমিয়ে দেয়।

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

Here’s a structure you can reuse:

Role: strict style guide reviewer.
Input: diff (or files changed) + style guide rules.
Non-negotiables: [list].
Allowed exceptions: [list].
Scope: ONLY comment on changed lines and directly impacted code paths. No unrelated refactors.
Evidence: Every finding MUST include (a) file path, (b) exact identifier(s), (c) short quote.
Output: structured compliance report with pass/fail per category + minimal fixes.

রিপোর্টে প্রতিবারই একই সেকশন রাখতে বলুন, এমনকি যদি কিছুতে “No issues found” হয়: Naming, Layering, Error handling, Logging।

যদি বলা হয় “service layer leaking DB details,” তাহলে সেটি অবশ্যই কিছু এইরকম কোট করতে হবে: internal/orders/service/order_service.go এবং নির্দিষ্ট কল যেমন db.QueryContext যাতে আপনি কোনো বিতর্ক ছাড়াই লিক ঠিক করতে পারেন।

ধাপে ধাপে: স্টাইল-চেক প্রম্পট ওয়ার্কফ্লো নির্মাণ করুন

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

একটি সহজ দুই-পাস ওয়ার্কফ্লো ব্যবহার করুন:

1. আপনার স্ট্যান্ডার্ডগুলো একটি কম্প্যাক্ট, নাম্বার্ড রুল লিস্ট হিসেবে পেস্ট করুন (10-25 লাইন)। প্রতিটি নিয়ম টেস্টযোগ্য রাখুন।
2. পরিবর্তনের প্রসঙ্গ যোগ করুন: ডিফ, টাচড ফাইলগুলো, এবং উদ্দেশ্য সম্পর্কে এক বাক্য।
3. প্রথমে একটি লঙ্ঘন রিপোর্ট চাহুন। ফাইল ও লাইন রেফারেন্স, সংক্ষিপ্ত কারণ, এবং নির্দিষ্ট নিয়ম নম্বর আবশ্যক করুন।
4. রিপোর্টের পরে কেবলমাত্র অনুগত হওয়ার জন্য সর্বনিম্ন প্যাচ চাহুন।
5. আপডেট করা কোডে একই প্রম্পট পুনরায় চালান যাতে নিশ্চিত হওয়া যায় কিছুই রয়ে যায়নি।

উদাহরণ: একটি PR একটি নতুন এন্ডপয়েন্ট যোগ করে। প্রথম পাসে রিপোর্ট জানায় হ্যান্ডলার সরাসরি PostgreSQL-এ কথা বলছে (layering), রিকোয়েস্ট স্ট্রাক্টে মিশ্র নামকরণ আছে (naming), এবং পূর্ণ ইমেইল লগ হচ্ছে (logging)। পাস 2-এ ছোট ছোট ফিক্স হয়: DB কল সার্ভিস বা রেপোজিটরিতে নিয়ে যাওয়া, স্ট্রাক্টের নাম ঠিক করা, এবং লগে ইমেইল মাস্ক করা। অন্য কিছু বদল করে না।

নামকরণ কনভেনশন: ক্ষুদ্র কিন্তু গুরুত্বপূর্ণ সমস্যাগুলো ধরতে প্রম্পট

নামকরণ সমস্যা ছোট মনে হলেও আসলে ব্যয় বৃদ্ধি করে: মানুষ ভুল বুঝে, সার্চ কঠিন হয়, এবং “প্রায় একই” নামগুলো বহুগুণ বাড়ে।

রিভিউয়ারকে অবশ্য enforce করতে বলুন নামকরণ নিয়মগুলো পুরো চেঞ্জে: ফাইল নাম, এক্সপোর্টেড টাইপ, ফাংশন, ভ্যারিয়েবল, কনস্ট্যান্ট ও টেস্ট। কেসিং স্পষ্টভাবে উল্লেখ করুন (camelCase, PascalCase, snake_case) এবং একটি একরকম একরনিম নিয়ম ঠিক করুন (উদাহরণ APIClient বনাম ApiClient)। তারপর সব জায়গায় তা বাধ্য করুন।

শেয়ারড ভোকাবুলারি স্ট্যান্ডার্ড করুন: error types, log fields, এবং config keys। যদি লগে request_id থাকে, এক ফাইলে reqId বা requestId অনুমোদন করবেন না।

একটি বাস্তবসম্মত রিভিউ ইনস্ট্রাকশন:

Check every new or renamed identifier. Enforce casing + acronym rules.
Flag vague names (data, info, handler), near-duplicates (userId vs userID), and names that contradict behavior.
Prefer domain language: business terms over generic tech words.

একটি সংক্ষিপ্ত রিপোর্ট চান: তিনটি সবচেয়ে বিভ্রান্তিকর নাম, যেকোন near-duplicates এবং কোনটিই রাখা উচিত, প্লাস লগ/কনফিগ/এরর নাম যা স্ট্যান্ডার্ডের সাথে মিলছে না।

লেয়ারিং নিয়ম: দায়িত্বগুলো মিশে না যাওয়া নিশ্চিত করুন

লেয়ারিং নিয়ম সাধারণ ভাষায় ভাল কাজ করে: হ্যান্ডলার HTTP কথা বলে, সার্ভিস বিজনেস রুল রাখে, রেপোজিটরি ডাটাবেসের সাথে কথা বলে।

নির্ভরতার দিক লক করুন। হ্যান্ডলার সার্ভিস কল করতে পারে। সার্ভিস রেপোজিটরি কল করতে পারে। রেপোজিটরি সার্ভিস বা হ্যান্ডলার কল করবে না। হ্যান্ডলার ডাটাবেস কোড, SQL হেল্পার, বা ORM মডেল ইমপোর্ট করা উচিত নয়। যদি শেয়ারড প্যাকেজ থাকে (config, time, IDs), সেগুলো অ্যাপ লজিক মুক্ত রাখুন।

ক্রস-কাটিং কাজগুলোকে একটি ঠিকানা দিন। ভ্যালিডেশন সাধারণত বাউন্ডারিতে থাকে অনুরোধের শেপের জন্য এবং সার্ভিসে বিজনেস রুলের জন্য। অথরাইজেশন সাধারণত হ্যান্ডলারে শুরু হয় (আইডেন্টিটি, স্কোপ), কিন্তু চূড়ান্ত সিদ্ধান্ত সার্ভিসকে Enforce করতে হবে। ম্যাপিং লেয়ারের প্রান্তে রাখুন: হ্যান্ডলার HTTP থেকে ডোমেইন ইনপুটে ম্যাপ করে; রেপোজিটরি DB রো থেকে ডোমেইন টাইপে ম্যাপ করে।

প্রম্পটে এটা দিন যাতে রিভিউগুলো কংক্রিট থাকে:

Check layering: handler -> service -> repository only.
Report any leaks:
- DB types/queries in handlers or services
- HTTP request/response types inside services or repositories
- repository returning DB models instead of domain objects
- auth/validation mixed into repository
For each leak, propose the smallest fix: move function, add interface, or rename package.

রিপোর্টটি স্পষ্ট করুন: ফাইল নাম, যে লেয়ারে থাকা উচিত, কোন ইমপোর্ট বা কল নিয়ম ভাঙছে, এবং pattern ছড়ানো প্রতিরোধে নূন্যতম পরিবর্তন।

ত্রুটি হ্যান্ডলিং কনভেনশন: চাপের মধ্যে ধারাবাহিকতা

অধিকাংশ স্টাইল বিতর্ক তখন জোরালো হয় যখন প্রোডাকশনে কিছু ভেঙে পড়ে। একটি স্পষ্ট ত্রুটি হ্যান্ডলিং পলিসি ফেল ঠিক রাখে কারণ সবাই জানে “ভাল” দেখতে কেমন।

দর্শন লিখে রাখুন এবং তা Enforce করুন। উদাহরণ: “Wrap errors to add context; create a new error only when changing meaning or mapping to a user message. Return raw errors only at the system boundary.” এই এক বাক্যই এলোমেলো প্যাটার্ন ছড়ানো বন্ধ করে।

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

রিভিউতে কয়েকটি ঘাটতি খুঁজে বের করুন: swallowed errors (লগ কিন্তু রিটার্ন না করা), ambiguous returns (ফেইল হলেও nil value ও nil error), এবং ইউজার-মুখী মেসেজে স্ট্যাক ট্রেস, প্রশ্নটেক্সট, টোকেন বা PII লিক করা। যদি আপনি রিটারাই বা টাইমআউট সাপোর্ট করেন, সেগুলো স্পষ্ট করা বাধ্যতামূলক করুন।

উদাহরণ: চেকআউট কল টাইমআউট হয়। ইউজার দেখে “Payment service is taking too long.” অভ্যন্তরীণভাবে টাইমআউটকে র‍্যাপ করে op=checkout.charge এবং অর্ডার আইডি যোগ করুন যাতে খোঁজা ও কার্যকরী হয়।

লগিং কনভেনশন: পাঠযোগ্য, সার্চেবল, ও নিরাপদ

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

লগ লেভেলগুলো অ-আলোচ্যযোগ্য করুন: debug ডেভেলপমেন্ট ডিটেইলের জন্য, info সাধারণ মাইলস্টোনের জন্য, warn অপ্রত্যাশিত কিন্তু হ্যান্ডলড অবস্থার জন্য, এবং error যখন ইউজার-মুখী কাজ ব্যর্থ বা মনোযোগ প্রয়োজন। “fatal” বা “panic” বিরল রাখা এবং স্পষ্ট ক্র্যাশ পলিসি সংযুক্ত করুন।

স্ট্রাকচার্ড লগ অপরিপক্ক বাক্যের চেয়ে বেশি গুরুত্বপূর্ণ। স্থিতিশীল কী নামগুলি বাধ্যতামূলক করুন যাতে ড্যাশবোর্ড ও অ্যালার্ট ভাঙ্গে না। একটি ছোট কোর সেট নির্ধারণ করুন (উদাহরণ event, component, action, status, duration_ms) এবং তা ধারাবাহিক রাখুন।

সংবেদনশীল ডেটাকে কঠোরভাবে বারণ করুন। যা কখনোই লগে আসবে না তা স্পষ্ট করুন: passwords, auth tokens, পুরো ক্রেডিট কার্ড, সিক্রেটস, এবং কাঁচা ব্যক্তিগত ডেটা। এমন কিছু চিহ্নিত করুন যা ক্ষুদ্র মনে হলেও বিপজ্জনক, যেমন পাসওয়ার্ড রিসেট লিঙ্ক, সেশন আইডি, এবং পুরো অনুরোধ বডি।

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

পুনরায় ব্যবহার করার যোগ্য প্রম্পট ব্লক:

Review the changes for logging conventions:
- Check level usage (debug/info/warn/error). Flag any level that does not match impact.
- Verify structured fields: require stable keys and avoid free-form context in the message.
- Confirm correlation identifiers: request_id on all request-bound logs; user_id only when allowed.
- Flag any sensitive data risk (tokens, secrets, personal data, request/response bodies).
- Identify noisy logs (in loops, per-item logs, repeated success messages) and missing context.
Return: (1) violations with file/line, (2) suggested rewrite examples, (3) what to add or remove.

মার্জ করার আগে একটি দ্রুত “সেফটি পাস” করুন: যেকোন নতুন লগ যা request_id ছাড়া, যেকোন নতুন কী যা বিদ্যমান নাম বদলে দেয় (userId বনাম user_id), যেকোন error লগ যা কী ভুল হয়েছে তা ছাড়া, উচ্চ-ভলিউম লগ যা প্রতিটি অনুরোধে চলবে, এবং যেকোন ক্ষেত্র বা মেসেজে সিক্রেট বা PII আসার সম্ভাবনা।

কিভাবে লঙ্ঘন ছড়ানোর আগেই ধরা যাবে

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

গেটটা সংক্ষিপ্ত রাখুন। একটি ব্যবহারযোগ্য ট্রিক হলো প্রতিটি নিয়মের জন্য হ্যাঁ/না চেকলিস্ট দাবি করা, এবং যেকোন আইটেম না হলে অনুমোদন প্রত্যাখ্যান করা।

একটি PR-মাপের চেকলিস্ট যা বেশিরভাগ সমস্যা ধরে:

• Naming: ফাইল, টাইপ, ও ফাংশনের জন্য অনুমোদিত প্যাটার্ন মেনে চলে
• Layering: সরাসরি লেয়ার স্কিপ করে কল নেই (উদাহরণ হ্যান্ডলার DB কল করছে না)
• Errors: প্রাসঙ্গিক কনটেক্সটসহ রিটার্ন করা হচ্ছে, কিছু মুদ্রায় বাদ পড়ছে না
• Logging: ধারাবাহিক ফিল্ড, সিক্রেট নেই, এবং লেভেল প্রভাবের সঙ্গে মানানসই
• Tests/docs: পাবলিক API বা আচরণ বদলালে আপডেট হয়েছে

যখন টুল ফিক্স প্রস্তাব করে, প্রতিটি স্পর্শকৃত নিয়মের জন্য একটি ছোট compliant স্নিপেট বাধ্যতামূলক করুন। এটা অস্পষ্ট মতামত যেমন “বুঝতে স্পষ্ট করার জন্য নাম পরিবর্তন করুন” প্রতিরোধ করে।

প্রম্পট ব্যবহার করে স্টাইল এনফোর্স করার সাধারণ ফাঁদ

স্টাইল গাইড ব্যর্থ হওয়ার সবচেয়ে দ্রুত পথ হলো ব্যাখ্যার সুযোগ রেখে দেয়া। যদি দুই রিভিউয়ার একই নিয়ম পড়ে ভিন্ন সিদ্ধান্তে পৌঁছাতে পারে, টুল স্বাদ প্রয়োগ করবে, মানদণ্ড নয়।

নামকরণ একটি সাধারণ উদাহরণ। “নির্মল নাম ব্যবহার করুন” টেস্টযোগ্য নয়। এটিকে দৃঢ় করুন এমনভাবে যা যাচাই করা যায়: “ফাংশনগুলো ক্রিয়াপদ (e.g., createInvoice), বুলিয়ানগুলো is/has/can দিয়ে শুরু, এক্সপোর্টেড টাইপগুলো PascalCase।”

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

সবচেয়ে সাধারণ কারণগুলো যা enforcement drift ঘটায়:

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

আপনি যদি প্রম্পটগুলোকে টেস্ট হিসেবে বিবেচনা করেন, আপনি predictable enforcement পাবেন। প্রম্পটগুলোকে পরামর্শ হিসেবে দেখলে, লঙ্ঘন ধীরে ধীরে ছড়ায়।

দ্রুত চেকলিস্ট যা আপনি প্রত্যেক চেঞ্জে চালাতে পারেন

ডিফের উপর একটি দ্রুত পাস চালান (পুরো রিপো না) এবং নিশ্চিত করুন:

• Naming: নতুন আইডেন্টিফায়ার আপনার প্যাটার্ন মেনে চলছে (কেস, প্রিফিক্স, সাফল্য)। এক ধারণা একভাবে সব ফাইলে নামকরণ করা।
• Layering: নির্ভরতা কেবল অনুমোদিত দিকেই যাচ্ছে। নিম্ন স্তর কখনো উচ্চ স্তর ইমপোর্ট করবে না।
• Errors: কন্টেক্সটসহ রিটার্ন করা হয়েছে। কিছু মুদ্রায় উপেক্ষিত হচ্ছেনা।
• Logging: সঠিক লেভেল, স্থিতিশীল ফিল্ড, এবং কোন সিক্রেট বা ব্যক্তিগত ডেটা নেই।
• Final pass: রিভিউয়ার স্পষ্টভাবে বলে: “no mandatory violations found”, অথবা মর্জের আগে ঠিক করতে হবে এমন লঙ্ঘনগুলোর তালিকা।

প্রতি চেঞ্জে একটি ছোট প্রম্পট টেমপ্লেট রাখুন এবং সেটা পেস্ট করুন:

Review ONLY the changed code against our rules for naming, layering, errors, and logging.
List mandatory violations first (with file + line if available). Then list optional suggestions.
End with either: “no mandatory violations found” or “mandatory violations found”.

উদাহরণ: একটি হ্যান্ডলারে procUsr() নামে নতুন ফাংশন যা সরাসরি PostgreSQL-এ লেখে তা নামকরণ ও লেয়ারের কারণে ব্যর্থ হওয়া উচিত, এমনকি ফিচার কাজ করলেও। এখানে ধরলে কপি-পেস্ট ছড়ানো প্রতিরোধ হয়।

উদাহরণ: প্রথম ধাপে ইস্যুগুলো ধরতে পারে এমন একটি বাস্তবসম্মত রিভিউ

একজন সহকর্মী একটি নতুন এন্ডপয়েন্ট যোগ করে: POST /v1/invoices/{id}/send. এটি একটি হ্যান্ডলার, একটি সার্ভিস, এবং স্টোরেজ স্পর্শ করে।

প্রথম পাসে আপনি রিপোর্ট চান, রিরাইট নয়:

Pass 1 (report only)
You are a strict style checker. Read the patch.
Rules: naming must match our guide, handlers call services only, services call storage only, no SQL in handlers,
errors must be wrapped with context, logs must be structured and not leak PII.
Output: a numbered list of violations with file:line, rule name, and one-sentence impact. Do not propose fixes.
If a rule might be intentionally broken, ask one clarification question.

সাধারণ ফলাফল: SendInvoiceNow() বনাম SendInvoice নামের অসামঞ্জস্য, হ্যান্ডলার সরাসরি db.QueryRow কল করছে, কনটেক্সট ছাড়া err রিটার্ন করা হচ্ছে, এবং log.Printf("sending invoice %v", invoice) মত শব্দগুলো যে পুরো অবজেক্ট ডাম্প করে—এসব।

দ্বিতীয় পাসে ন্যূনতম, নিরাপদ পরিবর্তন চাওয়া হয়:

Pass 2 (minimal fix suggestions)
Using the violations list, propose the smallest code edits to comply.
Constraints: keep behavior the same, no refactors beyond what is needed, show suggested function names and where code should move.
For each fix, include 1-2 lines of example code.

যদি কোনো নিয়ম ভাঙা অনুমোদিত করা হয়, তা আগেই বলুন: “Exceptions are permitted only if you add a short comment explaining why, and you add a follow-up task to remove the exception.”

ফিক্সের পরে হ্যান্ডলার পাতলা অ্যাডাপটার হয়, সার্ভিস ওয়ার্কফ্লো নিয়ন্ত্রণ করে, স্টোরেজ কোয়েরি স্বত্বে থাকে, এররগুলো fmt.Errorf("send invoice: %w", err) হয়ে যায়, এবং লগগুলো নিরাপদ ফিল্ড (invoice ID, পুরো ইনভয়েস নয়) সহ পরিষ্কার এক লাইনে থাকে।

পরবর্তী পদক্ষেপ: ধীর করে না করে নিয়মিত করুন

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

প্রম্পটের শুরুতে একটি ছোট রুল ব্লক রাখুন এবং প্রতিটি রিভিউতে অপরিবর্তিতভাবে পেস্ট করুন। যদি সবাই প্রতিবারই নিয়ম সম্পাদনা করে, আপনার কাছে একটি স্ট্যান্ডার্ড থাকবে না—আপনার কাছে বিতর্ক থাকবে।

একটি সহজ কেডেন্স সাহায্য করে: একজন ব্যক্তি সপ্তাহের শীর্ষ স্টাইল মিসগুলো সংগ্রহ করে, এবং আপনি ঠিক একটি পরিষ্কার নিয়ম বা একটি উন্নত উদাহরণ যোগ করেন।

আপনি যদি Koder.ai (koder.ai) মত চ্যাট-চালিত বিল্ড ফ্লোতে কাজ করেন, তখন গেট চেকগুলো পরিবর্তনের সময়েই চালানো মূল্যবান, কেবল শেষে নয়। প্ল্যানিং, স্ন্যাপশট, ও রোলব্যাকের মতো ফিচারগুলো স্টাইল ফিক্সগুলিকে ছোট ও পূর্বাবস্থায় ফিরিয়ে আনার যোগ্য রাখে আগে আপনি সোর্স কোড এক্সপোর্ট করেন।