claude-md-for-agencies-2026.html
< BACK तीन स्टैक्ड आर्किटेक्चरल ड्राइंग शीट्स सूक्ष्म अंतरों के साथ, जो क्लायंट प्रोजेक्ट्स में लेयर्ड स्टैंडर्ड्स का सुझाव देते हैं

एजेंसियों के लिए CLAUDE.md: क्लायंट प्रोजेक्ट्स में AI कोडिंग स्टैंडर्ड्स स्केल करना

अधिकतर CLAUDE.md गाइडेंस सोलो डेवलपर्स के लिए लिखी जाती है जो एक बार में एक प्रोजेक्ट पर काम करते हैं। एजेंसी का काम अलग है: आपके पास क्लायंट प्रोजेक्ट्स का एक पोर्टफोलियो होता है, हर एक के अपने कन्वेंशन्स होते हैं, और एक ही इंजीनियर एक हफ्ते में उनमें से छह को छू सकता है। वह CLAUDE.md स्ट्रेटेजी जो सोलो डेव के लिए काम करती है एजेंसी स्केल पर विफल हो जाती है। यह वह वर्किंग अप्रोच है जिस पर हम Seahawk Media में 200+ सक्रिय क्लायंट रिपोजिटरीज़ में 18 महीनों की पुनरावृत्ति के बाद सेटल हुए हैं।

मुख्य बात: एजेंसी स्केल पर CLAUDE.md को तीन परतें चाहिए होती हैं — एजेंसी-व्यापी मानक, क्लाइंट ओवरराइड्स, और प्रति-एनगेजमेंट नोट्स — ताकि एक इंजीनियर छह रेपो में सही कॉन्टेक्स्ट के साथ काम कर सके।CLAUDE.md at agency scale needs three layers, agency-wide standards, client overrides, and per-engagement notes, so one engineer can move across six repos with the right context.

अगर आप एक एजेंसी चला रहे हैं जो रोज़मर्रा के आधार पर Claude Code का उपयोग करती है और पा रहे हैं कि इंजीनियर्स को प्रोजेक्ट्स में बिल्कुल अलग-अलग आउटपुट मिल रहे हैं, तो यह पोस्ट स्ट्रक्चरल फिक्स है।

सोलो-डेव CLAUDE.md सलाह एजेंसी स्केल पर क्यों टूटती है

स्टैंडर्ड CLAUDE.md सलाह है: इसे एक बार लिखो, अपने प्रोजेक्ट के लिए ऑप्टिमाइज़ करो, इसे 500 लाइन्स के अंदर रखो। यह तब काम करता है जब आपके पास एक प्रोजेक्ट हो। जब आपके पास 50 क्लायंट रिपोजिटरीज़ हों, तो तीन समस्याएं उभर जाती हैं। एक ही इंजीनियर को याद नहीं रह सकता कि कौन से कन्वेंशन्स किस क्लायंट पर लागू होते हैं। प्रोजेक्ट में नए इंजीनियर्स को पचास अलग-अलग CLAUDE.md फाइलें का सामना करना पड़ता है। CLAUDE.md कंटेंट ड्रिफ्ट करता है जैसे-जैसे इंजीनियर्स एक प्रोजेक्ट को अपडेट करते हैं और बाकी को भूल जाते हैं।

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

तीन-परत वाला CLAUDE.md मॉडल

परत 1: एजेंसी-व्यापी मानदंड

एक एकल CLAUDE.md टेम्पलेट हमारी एजेंसी के एक निजी GitHub रिपॉजिटरी में रहता है। इसमें शामिल है: जिन भाषाओं को हम शिप करते हैं उनके लिए कोड शैली, हमारे निषिद्ध पैटर्न, हमारी परीक्षण परंपराएं, हमारे सुरक्षा मानदंड, हमारा ब्रिटिश-वर्तनी संपादकीय नियम, हमारी डिप्लॉयमेंट डिफॉल्ट। यह फ़ाइल लगभग 400 लाइनों की है और साल में कुछ बार बदलती है।

प्रत्येक नया क्लायंट प्रोजेक्ट इस फ़ाइल को सिम्लिंक करके या कॉपी करके शुरू होता है। एजेंसी-व्यापी फ़ाइल में किए गए परिवर्तन त्रैमासिक समीक्षा चक्र पर प्रोजेक्ट में खींचे जाते हैं। इंजीनियर इन परंपराओं पर भरोसा कर सकते हैं कि वे समान हों चाहे वे कोई भी प्रोजेक्ट खोलें।

परत 2: क्लायंट-विशिष्ट CLAUDE.md

प्रत्येक क्लायंट रिपॉजिटरी के पास अपना CLAUDE.md है जो एजेंसी-व्यापी को आयात करता है और क्लायंट विशिष्ट जोड़ता है: उनका स्टैक, उनकी होस्टिंग, उनके प्लगइन, उनकी टीम परंपराएं, उनकी संपादकीय आवाज़, उनके निषिद्ध प्लगइन। यह फ़ाइल आमतौर पर 100 से 200 लाइनों की होती है और बदलती है जब क्लायंट एनगेजमेंट आकार बदलता है।

हम शीर्ष पर एक सरल इनक्लूड निर्देश का उपयोग करते हैं: "## Agency standards" एजेंसी-व्यापी फ़ाइल की लिंक के साथ, फिर "## Client-specific" ओवरराइड के साथ। Claude दोनों को पढ़ता है क्योंकि वे दोनों प्रोजेक्ट ट्री में हैं।

परत 3: प्रति-एनगेजमेंट नोट्स

विशिष्ट समय-सीमाबद्ध संदर्भ: मौजूदा स्प्रिंट लक्ष्य, सक्रिय खोज निष्कर्ष, हाल के निर्णय लॉग, खुले प्रश्न सूची। CLAUDE_NOTES.md या इसी तरह की फ़ाइल में रहता है, एनगेजमेंट के दौरान साप्ताहिक रूप से अपडेट होता है, एनगेजमेंट समापन पर संग्रहीत होता है।

यह वह जगह है जहाँ अधिकांश एजेंसियां CLAUDE.md स्वच्छता में विफल होती हैं। पहली दोनों परतें깔-सुथरी रहती हैं; तीसरी भटक जाती है और पुरानी हो जाती है। हम इसे शुक्रवार-दोपहर की समीक्षा चक्र के साथ हल करते हैं: प्रत्येक इंजीनियर अपने सक्रिय CLAUDE_NOTES.md की समीक्षा करता है और इसे या तो अपडेट करता है या संग्रहीत करता है।

वह निषिद्ध-पैटर्न सूची जो जटिलता में वृद्धि करती है

हमारी एजेंसी-व्यापी CLAUDE.md का सबसे अधिक प्रभाव वाला एक तत्व निषिद्ध-पैटर्न सूची है। बीस प्रविष्टियाँ, त्रैमासिक रूप से ताज़ी की जाती हैं। वर्तमान सूची के उदाहरण:

किसी भी भाषा में eval() का कभी उपयोग न करें जिसे हम शिप करते हैं।

WordPress में कभी query_posts() का उपयोग न करें (इसके बजाय WP_Query का उपयोग करें)।WordPress (use WP_Query instead).

TypeScript में किसी भी "// suppressed: <reason>" टिप्पणी के बिना कभी any का उपयोग न करें।

किसी भी संदर्भ में कभी document.write() का उपयोग न करें।

कभी भी secrets को git में कमिट न करें, कभी नहीं, कोई भी ब्रांच चाहे जो हो।

किसी भी क्लाइंट-सामना करने वाली कॉपी में कभी em-dashes का उपयोग न करें (AI-पहचान परिहार के लिए ऑपरेटर मानक)।

Supabase टेबल पर RLS को किसी बग को ठीक करने के लिए कभी अक्षम न करें।Supabase tables to fix a bug.

कभी भी main में सीधे push न करें (हमेशा PR करें)।

किसी मौजूदा फ़ाइल को संपादित करते समय कभी भी नई फ़ाइल न बनाएँ।

यह लिस्ट बढ़ती है क्योंकि हर बार जब कोई इंजीनियर इनमें से किसी भी नियम को तोड़ता है, हम नियम को जोड़ते हैं। Claude हर सेशन में वर्जित-पैटर्न लिस्ट को पढ़ता है और ऐसा कोड जेनरेट करने से मना कर देता है जो उन्हें violate करते हैं। bugs की वह श्रेणी जो हम पहले staging में भेजा करते थे, अब खत्म हो गई है।

CLAUDE.md से क्या बाहर रखें

पाँच चीजें जो हम explicitly agency CLAUDE.md फ़ाइलों में नहीं रखते हैं:

प्रोजेक्ट स्टेटस अपडेट। ये पुरानी पड़ जाती हैं; ये Linear या Notion में जाती हैं।

लंबा architectural rationale। design docs में होता है; CLAUDE.md को उनका reference देना चाहिए, उन्हें duplicate नहीं करना चाहिए।

क्लाइंट-साइड secrets, credentials, या कोई भी sensitive चीज़। यहाँ तक कि private CLAUDE.md फ़ाइलें भी बहुत लीक होने योग्य हैं।

किसी भी इंजीनियर की व्यक्तिगत preferences। standards agency-wide होने चाहिए; इंजीनियर-specific preferences उनकी अपनी .claude/settings.json में जाती हैं।

मार्केटिंग कॉपी या sales language। CLAUDE.md engineering context है; इसे ऐसा दिखना चाहिए जैसे किसी senior engineer ने इसे दूसरे engineers के लिए लिखा हो।

CLAUDE.md hiring equation को कैसे बदलता है

एक सीनियर इंजीनियर जो हर विजिट पर हर प्रोजेक्ट को दोबारा सीखे बिना अपने पूरे क्लाइंट पोर्टफोलियो में डिलीवर कर सके, वह नाटकीय रूप से ज्यादा मूल्यवान है जो नहीं कर सकता। तीन-लेयर CLAUDE.md सिस्टम वही है जो यह संभव बनाता है। नए इंजीनियरों के लिए ऑनबोर्डिंग समय मोटे तौर पर 2 सप्ताह की प्रोजेक्ट-स्पेसिफिक रैम्प से गिरकर 3 दिन हो गया क्योंकि कन्वेंशन कोडिफाइड हैं, न कि सांस्कृतिक।

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

निचली पंक्ति

एजेंसी-स्केल CLAUDE.md एक लेयर्ड सिस्टम है: एजेंसी-व्यापी स्टैंडर्ड्स आधार के रूप में, क्लाइंट-स्पेसिफिक ओवरराइड्स बीच में, प्रति-एनगेजमेंट नोट्स सबसे ऊपर। फॉरबिडन-पैटर्न लिस्ट सबसे ज्यादा लीवरेज वाला सेक्शन है। प्रति-एनगेजमेंट लेयर में स्टेल कॉन्टेंट से बचने के लिए फ्राइडे-रिव्यू कैडेंस का इस्तेमाल करें।

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

अक्सर पूछे जाने वाले सवाल

CLAUDE.md फ़ाइल क्या है?

CLAUDE.md एक प्रोजेक्ट फ़ाइल है जो Claude Code को आपके standards, stack और conventions बताती है ताकि इसका output आपके codebase में fit हो जाए। agency scale पर, एक flat file काफ़ी नहीं होती, इसलिए यह कई client repos में एक three-layer model use करती है।

आप CLAUDE.md को कई client projects में कैसे scale करते हैं?

एक three-layer model से: agency-wide standards जो everywhere apply हों, client-specific overrides हर account के लिए, और एक given project के लिए per-engagement notes। एक ही engineer एक हफ़्ते में छह client repos में move कर सकता है और हर जगह सही context रख सकता है बिना इसे rewrite किए।

CLAUDE.md में क्या नहीं जाना चाहिए?

Secrets, कोई भी चीज़ जो constantly बदलती है, और noise जो important rules को dilute कर दे। इसे durable standards और conventions तक सीमित रखें। एक overstuffed CLAUDE.md को ignore किया जाता है; एक tight, layered वाली जो forbidden patterns को clearly state करे, वही actually output को change करती है।

क्या CLAUDE.md hiring को change करती है?

यह onboarding cost को कम करती है। जब standards एक layered CLAUDE.md में रहते हैं, तो एक नया engineer agency के conventions को tool के through inherit कर लेता है, बजाय महीनों के tribal knowledge के। यह hiring को house style memorise करने से हटा कर judgment की ओर shift करती है।

< BACK