सुसंगत कोड रिव्यू के लिए Claude Code स्टाइल गाइड प्रॉम्प्ट्स

क्यों स्टाइल गाइड उल्लंघन जल्दी फैलते हैं

स्टाइल गाइड के उल्लंघन शायद ही कभी एक बड़ी गलती के रूप में सामने आते हैं। वे छोटे-छोटे “काफी ठीक” विकल्पों के रूप में एक पुल रिक्वेस्ट में दिखते हैं, और फिर जमा होते जाते हैं जब तक कि कोडबेस असमान और पढ़ने में कठिन न लगने लगे।

स्टाइल ड्रिफ्ट अक्सर ऐसे दिखता है: एक फाइल userID का उपयोग करती है, दूसरी userId, तीसरी uid। एक हैंडलर { error: \"...\" } लौटाता है, दूसरा थ्रो करता है, तीसरा लॉग करके null लौटाता है। हर बदलाव छोटा है, पर मिलकर वे एक ऐसे रेपो बना देते हैं जहाँ पैटर्न अनुमानित नहीं रहते।

तेज़ इंटेरेशन और कई योगदानकर्ता इसे और खराब बनाते हैं। लोग जो वे देखते हैं उसे कॉपी करते हैं, खासकर समय की कमी में। अगर रेपो में हाल का कोड किसी शॉर्टकट का इस्तेमाल करता है, तो वही शॉर्टकट अगले बदलाव के लिए टेम्पलेट बन जाता है। कुछ हफ्तों में “डिफ़ॉल्ट स्टाइल” आपकी लिखी गाइड नहीं रहती—यह जो भी आख़िर में हुआ वही बन जाती है।

इसीलिए लक्ष्य होना चाहिए निरंतर कन्वेंशंस, व्यक्तिगत पसंद नहीं। सवाल यह नहीं होना चाहिए कि “क्या मुझे यह नाम पसंद है?” बल्कि होना चाहिए “क्या यह उन नियमों से मेल खाता जो हमने तय किए हैं ताकि अगला व्यक्ति बिना सोचे उसे फॉलो कर सके?”

उल्लंघनों को जल्दी पकड़ना मतलब बुरे पैटर्न को कॉपी-पेस्ट ईंधन बनने से रोकना। नए और संपादित कोड पर फोकस करें, किसी नई असंगति के पहले प्रकट होने को ठीक करें, और ऐसे मर्ज को ब्लॉक करें जो नए ड्रिफ्ट लाते हों। जब आप कोई समस्या फ्लैग करें, तो एक छोटा पसंदीदा उदाहरण जोड़ें जिसे लोग अगली बार नकल कर सकें।

एक वास्तविक उदाहरण: एक डेवलपर एक नया API एंडपॉइंट जोड़ता है और डिबग के लिए कच्चे रिक्वेस्ट बॉडी लॉग कर देता है। अगर वह उतर जाता है, तो अगला एंडपॉइंट उसे कॉपी कर लेगा, और जल्द ही संवेदनशील डेटा लॉग्स में आ जाएगा। पहले PR में पकड़ना सस्ता है। बाद में फैलने पर पकड़ना दर्दनाक और जोखिम भरा है।

अपनी स्टाइल गाइड को स्पष्ट, परीक्षण योग्य नियमों में बदलें

स्टाइल गाइड तभी काम करती है जब समीक्षा में वह चेकलिस्ट जैसा पढ़े, न कि प्राथमिकताओं का सेट। हर निर्देश को ऐसे नियम के रूप में लिखें जिसे diff पर चेक किया जा सके।

नियमों को चार बकेट्स में आयोजित करें ताकि वे नजरअंदाज न हों: नामकरण, लेयरिंग, त्रुटि हैंडलिंग, और लॉगिंग। हर बकेट के लिए दो बातें लिखें: क्या सत्य होना चाहिए और क्या वर्जित है।

हर नियम की ताकत पहले से तय करें:

• अनिवार्य: इसका पालन न होने पर चेंज ब्लॉक हो जाएगा।
• सिफारिशीकृत: इसे ठीक करें जब तक कि स्पष्ट कारण न हो।
• वैकल्पिक: अच्छा हो तो करें, पर कभी ब्लॉक नहीं करेगा।

स्कोप सेट करें ताकि रिव्यू अंतहीन रिफैक्टर में न बदल जाए। एक सरल नियम अच्छा काम करता है: “नया और संशोधित कोड अनुपालन कर सकता है; मौजूदा बिना छुआ कोड तब तक फिर से नहीं लिखा जाता जब तक वह फिक्स ब्लॉक न करे।” यदि आप क्लीनअप चाहते हैं, तो उसे एक अलग समयबद्ध टास्क बनाएं।

साथ ही रिव्यू से जो आउटपुट चाहिए वह परिभाषित करें ताकि उस पर कार्रवाई आसान हो: पास/फेल निर्णय, फाइल और लाइन रेफरेंस के साथ उल्लंघन सूची, सुझाए गए फिक्स जो ठोस एडिट के रूप में लिखे हों, और जब कुछ बग या लीक का कारण बन सकता हो तो एक संक्षिप्त रिस्क नोट।

उदाहरण: अगर एक PR कच्चे यूज़र टोकन को लॉग करता है, तो रिव्यू को “लॉगिंग: कभी सीक्रेट लॉग न करें” के तहत फेल होना चाहिए और सुझाव देना चाहिए कि लॉग में रिक्वेस्ट ID लॉग करें।

रायों के बजाय नियम लागू करने वाला प्रॉम्प्ट स्ट्रक्चर

स्टाइल प्रॉम्प्ट तब फेल होते हैं जब वे प्राथमिकताओं जैसा सुनाई देते हैं। एक अच्छा रिव्यू प्रॉम्प्ट एक कॉन्ट्रैक्ट जैसा पढ़ना चाहिए: स्पष्ट गैर-समझौते योग्य नियम, स्पष्ट अपवाद और अनुमानित आउटपुट।

दो छोटे ब्लॉक्स से शुरू करें: क्या सत्य होना आवश्यक है और किन मामलों में लचीलापन दिया जा सकता है। फिर एक डिसीजन नियम जोड़ें: “यदि स्पष्ट नहीं है, Needs Clarification मार्क करें। अनुमान न लगाएँ।”

सबूत की आवश्यकता लगाएँ। जब टूल उल्लंघन फ्लैग करे तो उसे सटीक आइडेंटिफायर और फ़ाइल पथ को उद्धृत करना अनिवार्य करें, न कि अस्पष्ट वर्णन। यह एकल बाध्यता बहुत से बैक-एंड-फोर्थ को दूर कर देती है।

स्कोप को तंग रखें: केवल बदली गई लाइनों और सीधे प्रभावित कोड पाथ्स पर टिप्पणी करें। यदि आप unrelated रिफैक्टर्स की अनुमति देते हैं, तो स्टाइल एन्फोर्समेंट “फाइल को फिर से लिखो” में बदल सकता है, और लोग फीडबैक पर भरोसा करना बंद कर देंगे।

यहाँ एक संरचना है जिसे आप बार-बार उपयोग कर सकते हैं:

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 DB डिटेल्स लीक कर रहा है,” तो उसे कुछ ऐसे उद्धरण के साथ आना चाहिए जैसे internal/orders/service/order_service.go और सटीक कॉल (उदाहरण के लिए db.QueryContext) ताकि आप बिना बहस के लीक को ठीक कर सकें।

चरण-दर-चरण: एक स्टाइल-चेक प्रॉम्प्ट वर्कफ़्लो बनाएं

एक स्टाइल गाइड तब टिकेगी जब प्रक्रिया दोहराने योग्य हो। लक्ष्य है कि मॉडल नियमों की जांच करे, स्वाद पर बहस न करे, और हर बार यही तरीका अपनाए।

एक सरल दो-पास वर्कफ़्लो का उपयोग करें:

1. अपने मानकों को कॉम्पैक्ट, नंबर वाले नियम सूची के रूप में पेस्ट करें (10–25 पंक्तियाँ)। हर नियम को परीक्षण योग्य रखें।
2. बदलाव का संदर्भ जोड़ें: diff, प्रभावित फ़ाइलें, और इरादे के बारे में एक वाक्य।
3. पहले उल्लंघन रिपोर्ट मांगें। फाइल और लाइन रेफरेंस, एक छोटा कारण, और सटीक नियम संख्या आवश्यक करें।
4. केवल रिपोर्ट के बाद, अनुपालन पाने के लिए सबसे छोटा पैच माँगें।
5. वही प्रॉम्प्ट अपडेटेड कोड पर फिर से चलाएँ ताकि पुष्टि हो जाए कि कुछ नहीं बचा।

उदाहरण: एक PR नया एंडपॉइंट जोड़ता है। पास 1 बताता है कि हैंडलर सीधे PostgreSQL से बात कर रहा है (लेयरिंग), रिक्वेस्ट स्ट्रक्ट्स में मिश्रित नामकरण है (नामकरण), और ईमेल पूरा लॉग हो रहा है (लॉगिंग)। पास 2 छोटे-छोटे फिक्स करता है: DB कॉल को सर्विस/रिपॉज़िटरी में ले जाना, स्ट्रक्ट का नाम बदलना, और लॉग में ईमेल को मास्क करना। और कुछ नहीं बदलता।

नामकरण कन्वेंशंस: छोटे मामलों को पकड़ने वाले प्रॉम्प्ट

नामकरण के मुद्दे मामूली लगते हैं, पर वास्तविक लागत पैदा करते हैं: लोग इरादा गलत पढ़ते हैं, सर्च मुश्किल हो जाता है, और "लगभग वही" नाम गुणा करते हैं।

रिव्यपर को परिवर्तन के पूरे दायरे में निम्न नामकरण नियम लागू करने कहें: फाइल नाम, एक्सपोर्टेड टाइप्स, फ़ंक्शन्स, वेरिएबल्स, कॉन्स्टेंट्स, और टेस्ट्स। केसिंग (camelCase, PascalCase, snake_case) के बारे में स्पष्ट रहें और एक एक्रोनिम नियम चुनें (उदाहरण APIClient बनाम ApiClient) और उसे हर जगह लागू करें।

साझा शब्दावली को भी मानकीकृत करें: एरर टाइप्स, लॉग फील्ड्स, और कॉन्फिग कीज़। अगर लॉग्स 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 से बात करता है, सर्विस बिजनेस नियम रखती है, रिपॉज़िटरी DB से बात करती है।

निर्देश दिशात्मक निर्भरताएँ लॉक करें। हैंडलर सर्विस को कॉल कर सकते हैं। सर्विस रिपॉज़िटरी को कॉल कर सकती है। रिपॉज़िटरी सर्विस या हैंडलर को नहीं कॉल करनी चाहिए। हैंडलर को डेटाबेस कोड, SQL हेल्पर, या ORM मॉडल्स इम्पोर्ट नहीं करने चाहिए। अगर आप साझा पैकेज (config, time, IDs) उपयोग करते हैं, तो उन्हें एप्लिकेशन लॉजिक से मुक्त रखें।

क्रॉस-कटिंग काम का घर पिन करें। वलिडेशन आमतौर पर बॉउंड्री पर रिक्वेस्ट शेप के लिए और सर्विस में बिजनेस नियमों के लिए रहता है। ऑथोराइज़ेशन अक्सर हैंडलर में शुरू होता है (पहचान, स्कोप्स), पर अंतिम निर्णय सर्विस को लागू करना चाहिए। मैपिंग लेयर किनारों पर होनी चाहिए: हैंडलर 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.

रिपोर्ट स्पष्ट बनाएं: फ़ाइल का नाम, वह लेयर जहां होना चाहिए, जो इम्पोर्ट या कॉल नियम तोड़ रही है, और पैटर्न को फैलने से रोकने के लिए न्यूनतम बदलाव क्या होगा।

त्रुटि हैंडलिंग कन्वेंशंस: दबाव में स्थिरता

अधिकांश स्टाइल बहस तब तेज हो जाती है जब कुछ प्रोडक्शन में टूटता है। एक स्पष्ट त्रुटि हैंडलिंग पॉलिसी सुधारों को शांत रखती है क्योंकि हर कोई जानता है कि “अच्छा” क्या है।

दर्शन लिखें और उसे लागू करें। उदाहरण के लिए: “कंटेक्स्ट जोड़ने के लिए त्रुटियों को रैप करें; केवल तब नया एरर बनाएं जब अर्थ बदल रहा हो या इसे यूज़र संदेश से मैप करना हो। सिस्टम बाउंडरी पर ही कच्चे एरर लौटाएँ।” यह एक वाक्य यादृच्छिक पैटर्न फैलने से रोकता है।

यूज़र-फेसिंग टेक्स्ट को आंतरिक विवरण से अलग रखें। यूज़र मैसेज छोटे और सुरक्षित होने चाहिए। आंतरिक एरर ऑपरेशन नाम और प्रमुख पहचानकर्ता शामिल कर सकते हैं, पर किसी भी तरह के सीक्रेट्स नहीं।

रिव्यू में कुछ बार-बार होने वाली असफलताओं की जाँच करें: गुप्त तरीके से छोड़ी गई त्रुटियाँ (लॉग तो होती है पर लौटाई नहीं जाती), अस्पष्ट रिटर्न्स (फेलियर के बाद nil वैल्यू और nil एरर), और यूज़र-फेसिंग मैसेज जो स्टैक ट्रेस, क्वेरी टेक्स्ट, टोकन या PII लीक कर रहे हों। यदि आप retries या timeouts सपोर्ट करते हैं, तो उन्हें स्पष्ट रूप से आवश्यक करें।

उदाहरण: एक चेकआउट कॉल टाइमआउट हो जाता है। यूज़र को दिखे: “Payment service is taking too long.” आंतरिक रूप से, टाइमआउट को रैप करें और op=checkout.charge और order ID शामिल करें ताकि यह searchable और actionable हो।

लॉगिंग कन्वेंशंस: पढ़ने योग्य, खोजने योग्य और सुरक्षित

लॉग तभी मदद करते हैं जब हर कोई उन्हें एक ही तरह लिखे। यदि हर डेवलपर अपनी शब्दावली, लेवल और फील्ड चुनता है, तो सर्च अटकलबाज़ी बन जाती है।

लॉग स्तरों को गैर-समझौते योग्य बनाएं: debug विकास विवरण के लिए, info सामान्य माइलस्टोन के लिए, warn अप्रत्याशित पर संभाले गए मामलों के लिए, और error जब यूज़र-फेसिंग एक्शन असफल हो या ध्यान चाहिए। “fatal” या “panic” को दुर्लभ रखें और स्पष्ट क्रैश पॉलिसी से जोड़ें।

स्ट्रक्चर्ड लॉग्स संपूर्ण वाक्यों से ज़्यादा महत्वपूर्ण हैं। स्थिर कुंजियों की आवश्यकता रखें ताकि डैशबोर्ड और अलर्ट टूटें नहीं। एक छोटा कोर सेट तय करें (उदाहरण: event, component, action, status, duration_ms) और उसे बनाए रखें।

संसेदनशील डेटा को कड़ी रोक की तरह ट्रीट करें। स्पष्ट रूप से बताएं कि क्या कभी लॉग नहीं करना चाहिए: पासवर्ड, ऑथ टोकन, पूरा क्रेडिट कार्ड, सीक्रेट्स और कच्चा व्यक्तिगत डेटा। उन चीज़ों पर भी ध्यान दें जो हानिरहित लगती हैं लेकिन नहीं हैं, जैसे पासवर्ड रीसेट लिंक, सत्र IDs, और पूरा रिक्वेस्ट बॉडी।

कोरलेशन IDs डिबगिंग को संभव बनाते हैं। हर रीक्वेस्ट के भीतर हर लॉग लाइन में 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), किसी भी एरर लॉग में जो यह नहीं बताता कि क्या फेल हुआ (ऑपरेशन, रिसोर्स, स्टेटस), किसी भी हाई-वॉल्यूम लॉग जो हर रिक्वेस्ट पर फायर होगा, और किसी भी संभावना कि फील्ड्स या मैसेज में सीक्रेट्स या व्यक्तिगत डेटा आ सकता है।

उल्लंघन फैलने से पहले कैसे पकड़ें

स्टाइल ड्रिफ्ट को बिल्ड ब्रेक की तरह ट्रीट करें, सुझाव की तरह नहीं। एक सख्त गेट जोड़ें जो मर्ज से पहले चले और स्पष्ट पास या फेल लौटाए। यदि कोई अनिवार्य नियम टूटा है (नामकरण, लेयर बाउंडरी, लॉगिंग सुरक्षा, त्रुटि हैंडलिंग), तो वह फेल करे और सटीक फ़ाइल और रेखाएँ दिखाए।

गेट को छोटा रखें। एक व्यावहारिक ट्रिक: हर नियम के लिए YES/NO चेकलिस्ट की आवश्यकता रखें, और यदि कोई आइटम NO हो तो अनुमोदन मना कर दें।

एक PR-आकार की चेकलिस्ट जो अधिकांश समस्याओं को पकड़ लेगी:

• Naming: फ़ाइलें, टाइप्स और फ़ंक्शन्स के लिए स्वीकृत पैटर्न से मेल खाता है
• Layering: कोई डायरेक्ट कॉल नहीं जो लेयर्स को स्किप करे (उदाहरण के लिए हैंडलर से DB कॉल)
• Errors: कॉन्टेक्स्ट के साथ लौटाए गए, कुछ भी चुपके से छोड़ नहीं दिया गया
• Logging: स्थिर फील्ड्स, कोई सीक्रेट नहीं, और स्तर प्रभाव से मेल खाता है
• Tests/docs: व्यवहार या सार्वजनिक APIs बदलने पर अपडेट किए गए

जब टूल फिक्स सुझाए, तो उससे हर टच किए गए नियम के लिए एक छोटा अनुपालन स्निपेट माँगें। इससे अस्पष्ट फीडबैक जैसे “स्पष्टता के लिए नाम बदलें” रोकता है।

प्रॉम्प्ट से स्टाइल लागू करते समय सामान्य जाल

स्टाइल गाइड फेल होने का सबसे तेज़ तरीका है व्याख्या की गुंजाइश छोड़ना। यदि दो रिव्यूवर एक ही नियम पढ़कर अलग निष्कर्ष पर पहुँच सकते हैं, तो टूल स्वाद लागू करेगा, मानक नहीं।

नामकरण एक सामान्य उदाहरण है। “साफ़ नामों का उपयोग करें” परीक्षण योग्य नहीं है। इसे इस तरह कस लें: “फ़ंक्शन्स क्रियाएँ हों (उदाहरण createInvoice), बूलियन is/has/can से शुरू हों, एक्सपोर्टेड टाइप्स PascalCase हों।”

एक और जाल सब कुछ एक साथ माँगना है। जब एक प्रॉम्प्ट नामकरण, लेयरिंग, त्रुटियाँ, लॉगिंग, टेस्ट्स और प्रदर्शन सब कवर करने की कोशिश करता है, तो फीडबैक उथला होता है। जब विस्तृत आवश्यकता हो तो फोकस्ड पास में विभाजित करें, या गेट प्रॉम्प्ट को अनिवार्य नियमों तक सीमित रखें।

वे समस्याएँ जो अक्सर प्रवर्तन को ड्रीफ्ट कराती हैं:

• अस्पष्ट नियम: “साफ़” और “सुसंगत” को मापनीय भाषा से बदलें।
• स्टाइल फिक्स और रीडिज़ाइन मिलाना: प्रॉम्प्ट को नया आर्किटेक्चर प्रस्तावित करने न दें।
• उद्धृत सबूत का अभाव: हर टिप्पणी के लिए सटीक आइडेंटिफायर या स्निपेट उद्धृत करना अनिवार्य करें।
• मौन अपवाद: यदि आप अपवाद की अनुमति देते हैं, तो एक छोटा नोट आवश्यक करें कि क्यों और कब यह हटाया जाना चाहिए।

यदि आप प्रॉम्प्ट्स को टेस्ट की तरह ट्रीट करेंगे, तो आपको अनुमानित प्रवर्तन मिलेगा। अगर आप उन्हें सलाह मानेंगे, तो उल्लंघन चुपके से आ कर बढ़ जाएंगे।

हर परिवर्तन पर चलाने के लिए त्वरित चेकलिस्ट

Diff (पूरा रेपो नहीं) पर एक त्वरित पास चलाएँ और पुष्टि करें:

• Naming: नए आइडेंटिफायर्स आपके पैटर्न का पालन करते हैं (केस, प्रीफिक्स, सफिक्स)। एक अवधारणा का नाम एक ही तरीके से across फाइल्स होना चाहिए।
• Layering: निर्भरताएँ केवल अनुमत दिशा में जाती हैं। लोअर लेयर्स कभी हाईअर नहीं इम्पोर्ट करतीं।
• Errors: फेलियर संदर्भ के साथ लौटे जाते हैं। कुछ भी चुपके से अनदेखा न हो।
• Logging: सही स्तर, स्थिर फील्ड्स, और कोई सीक्रेट या व्यक्तिगत डेटा नहीं।
• Final pass: रिव्यवर स्पष्ट रूप से कहे: “कोई अनिवार्य उल्लंघन नहीं मिला” या उन उल्लंघनों की सूची दे जो मर्ज से पहले ठीक होने चाहिए।

हर बदलाव के साथ एक छोटा प्रॉम्प्ट टेम्पलेट रखें और उसे चिपकाएँ:

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 लौटाना, और ऐसे noisy लॉग्स जैसे 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, न कि पूरा invoice) होते हैं।

अगले कदम: रूटीन बनाएं बिना गति धीमी किए

एक टीम-स्वीकृत प्रॉम्प्ट चुनें और उसे साझा टूल की तरह ट्रीट करें। पहले उन चीज़ों से शुरू करें जो समीक्षा में आपको सबसे ज़्यादा परेशान करती हैं (नामकरण ड्रिफ्ट, लेयर्स का लीक, असंगत एरर, असुरक्षित लॉग्स)। प्रॉम्प्ट को तभी अपडेट करें जब आप असली कोड में कोई वास्तविक उल्लंघन देखें।

प्रॉम्प्ट के शीर्ष पर एक छोटा नियम ब्लॉक रखें और हर रिव्यू में उसे बिना बदले पेस्ट करें। अगर हर कोई हर बार नियम संपादित करेगा, तो आपके पास मानक नहीं होगा—आपके पास बहस होगी।

एक सरल तालमेल मदद करता है: सप्ताह की टॉप स्टाइल मिसेज़ को एक व्यक्ति इकट्ठा करे, और आप बस एक स्पष्ट नियम या एक बेहतर उदाहरण जोड़ें।

यदि आप चैट-ड्रिवन बिल्ड फ्लो जैसे Koder.ai (koder.ai) में काम करते हैं, तो उसी गेट चेक्स को बदलावों के दौरान चलाना उपयोगी होता है, न कि सिर्फ अंत में। प्लानिंग, स्नैपशॉट, और रोलबैक जैसी सुविधाएँ स्टाइल फिक्स को छोटे और उलटने योग्य रखने में मदद कर सकती हैं।