05 जन॰ 2026·7 मिनट
Monorepos में Claude Code: संदर्भ सीमित करना और सटीक रहना
बड़े monorepo में Claude Code का संदर्भ अक्सर बिखर जाता है। सीमाएँ, लोकल सारांश और दोहराने योग्य वर्कफ़्लो से उत्तरों को सटीक रखें।
बड़े monorepo में Claude Code का संदर्भ अक्सर बिखर जाता है। सीमाएँ, लोकल सारांश और दोहराने योग्य वर्कफ़्लो से उत्तरों को सटीक रखें।
Claude Code बड़े monorepos में अनपेक्षित महसूस हो सकता है एक सरल कारण से: रिपो उस चीज़ से बड़ा होता है जिसे मॉडल एक बार में वर्किंग मेमोरी में रख सकता है।
“संदर्भ” उन फाइलों, स्निपेट्स, नोट्स, और निर्देशों का सेट है जो Claude को इस कार्य के लिए दिखाए गए हैं, साथ में वे बातें जो वह उनसे अनुमान लगा सकता है। जब महत्वपूर्ण विवरण गायब होते हैं, Claude खाली जगहों को अनुमानों से भर देता है। बड़े रिपो में यह अधिक बार होता है।
तीन बार-बार दिखने वाले फेल्योर मोड हैं:
पहला, मिस की हुई फाइलें। एक फ़ोल्डर में जो परिवर्तन सुरक्षित लगता है, वह किसी साझा type, config नियम, या बिल्ड स्टेप पर निर्भर हो सकता है जो कहीं और परिभाषित है। अगर वह निर्भरता संदर्भ में नहीं है, Claude आत्मविश्वास से गलत चीज़ edit कर सकता है या जल्दी रुक सकता है क्योंकि वह वास्तविक स्रोत-सत्य नहीं देख पा रहा।
दूसरा, गलत समानता। Monorepos में अक्सर कई पैकेज होते हैं जो एक जैसे दिखते हैं: दो auth मॉड्यूल, तीन API क्लाइंट, या कई React ऐप्स समान फ़ोल्डर संरचनाओं के साथ। Claude पैटर्न्स को मिला सकता है, किसी गलत पैकेज में हेल्पर अपडेट कर सकता है, या “लगभग सही” मॉड्यूल नाम से import कर सकता है।
तीसरा, समयीय विस्थापन। बड़े कोडबेस में आमतौर पर पुराने और नए तरीके दोनों होते हैं। अगर Claude केवल पुराने फाइलें देखता है, तो वह पुरानी पैटर्न्स (deprecated config options, legacy APIs) कॉपी कर सकता है जबकि टीम पहले ही आगे बढ़ चुकी है।
एक सामान्य वास्तविक उदाहरण: आप बिलिंग UI में एक छोटा परिवर्तन मांगते हैं, और Claude एक साझा payments कंपोनेंट को एडिट कर देता है जिसे अन्य ऐप्स उपयोग करते हैं क्योंकि उसने उस ऐप-विशेष wrapper को नहीं देखा जिसे बदलना चाहिए था।
लक्ष्य Claude को पूरा monorepo दिखाना नहीं है। लक्ष्य छोटे, जानबूझकर इनपुट देना है जो सवाल का उत्तर देने के लिए पर्याप्त हों: जिस पैकेज में आप बदलाव कर रहे हैं, उसके डायरेक्ट निर्भरताएँ, और एक-दो “स्रोत-सत्य” फाइलें types और config के लिए। साथ ही “छूना मत” क्षेत्रों को बताइए (अन्य ऐप्स, infra, generated code) और पुष्टि कीजिए कि कौन सा पैकेज उस व्यवहार का मालिक है।
सटीकता इस बात पर कम निर्भर करती है कि आप कितना कोड चिपकाते हैं और अधिक इस पर कि आप नौकरी को कितनी स्पष्टता से वर्णित करते हैं।
शुरुआत उस परिणाम से करें जो आप चाहते हैं: एक विशिष्ट फिक्स, refactor, या उत्तर। “कोड के बारे में प्रश्न” उच्च स्तर पर रह सकता है। “एक परिवर्तन करें” अनुरोध को सीमाएँ, इनपुट, और सफलता जाँच की ज़रूरत होती है।
किसी भी चीज़ को साझा करने से पहले, एक वाक्य लिखें जो इस वाक्यांश को पूरा करे: “जब आप कर लें, तो मैं सक्षम होना चाहिए…”。 उदाहरण: “package X के यूनिट टेस्ट्स बिना फेल के चलाने में सक्षम होना” या “endpoint Y के API response में नया फील्ड दिखना।” ये वाक्य रिपो बड़ा होने पर उत्तरदिशा बन जाती है।
बदलावों के लिए, सबसे छोटे आर्टिफैक्ट्स साझा करें जो परिवर्तन की सहीता साबित कर सकें: एंट्री पॉइंट(स), संबंधित types/interfaces या schema, एक फेल होता टेस्ट या repro स्टेप साथ अपेक्षित परिणाम, और कोई भी config जो इस पाथ को प्रभावित करता है (routing, feature flags, build या lint नियम)। अगर मदद मिले तो पैकेज का छोटा फ़ोल्डर मानचित्र जोड़ें ताकि Claude समझे कि प्रत्येक डायरेक्टरी किस लिए है।
यह स्पष्ट रूप से बताइए कि क्या न देखें। कहें: “Ignore generated files, vendor folders, build outputs, snapshots, and lockfiles unless I ask.” यह बेकार समय और उन जगहों में edits रोकता है जिन्हें आप समीक्षा नहीं करेंगे।
अनिश्चितता के लिए भी अपेक्षाएँ सेट करें। Claude से कहें कि वह अनुमान लगाने के बजाय मान्यताओं और अज्ञात बातों को फ्लैग करे। उदाहरण: “अगर आप नहीं देख पा रहे कि यह फंक्शन कहाँ कॉल होता है, तो बताइए और इसे खोजने के 2 तरीके सुझाइए।”
बड़े monorepo में, सटीकता तब घटती है जब मॉडल ‘मददगार’ तरीके से आसपास के कोड को खींचकर उस कार्य का हिस्सा बना लेता है। समाधान सीधा है: परिवर्तन मांगने से पहले क्या इन‑स्कोप है और क्या आउट‑ऑफ‑स्कोप है, यह परिभाषित करें।
रिपो के संगठन के अनुरूप एक सीमा से शुरू करें: एक पैकेज, एक सर्विस, एक ऐप, या एक साझा लाइब्रेरी। यदि परिवर्तन “checkout UI अपडेट करें” है, तो सीमा शायद एक ऐप पैकेज है, न कि हर जगह जहाँ “checkout” शब्द आता है।
वे संकेत जो Claude को वहीं रहने में मदद करते हैं उनमें फ़ोल्डर कन्वेंशंस (apps/, services/, packages/, libs/), पैकेज manifests (exports और dependencies), public entry points (index फाइलें, exported components, handlers), और टेस्ट्स शामिल हैं (वे अक्सर इरादा दिखाते हैं)। किसी फ़ोल्डर के अंदर का README तेज़ी से सीमा बताने वाला साधन हो सकता है।
सीमाएँ तब बेहतर काम करती हैं जब आप उनके बीच के पुलों को नाम दें। बताइए कि कौन‑से इंटरफेस Claude छू सकता है और बाकी सबको आउट‑ऑफ़‑लिमिट समझिए। सामान्य ब्रिज हैं HTTP API contracts, event topics और payloads, shared types, या कुछ exported functions का छोटा सेट।
जब भी परिवर्तन उनसे प्रभावित नहीं होना चाहिए, “do not touch” जोन्स भी नामित करें। सामान्य जोन हैं infrastructure और deployment configs, security और auth लॉजिक, billing और payments, data migrations और production schemas, और कई टीमों द्वारा उपयोग की जाने वाली shared libraries।
एक ठोस प्रांप्ट विवरण मदद करता है:
“Make changes only inside packages/cart/ and its tests. You may read shared types in packages/types/ but do not modify them. Do not edit infra, auth, or billing.”
जब आप उस क्षेत्र का छोटा, स्थिर मानचित्र देते हैं जिसे आप बदलवाना चाहते हैं, तो सटीकता सुधरती है। “लोकल सारांश” वही मानचित्र है: पढ़ने में तेज़, अनुमान करने से रोकने के लिए पर्याप्त विशिष्ट।
प्रत्येक सारांश को लगभग 10–20 पंक्तियों के भीतर रखें। इसे ऐसे लिखें जैसे आप कोड एक नए टीममेट के हाथ दे रहे हों जिसे केवल इस सीमा को छूना है, न कि पूरे रिपो को। सादा भाषा और कोड से वास्तविक नामों का उपयोग करें: फोल्डर, पैकेज, exported functions।
एक उपयोगी लोकल सारांश पाँच प्रश्नों का उत्तर देता है:
एक “gotchas” लाइन जोड़ें। यह वह जगह है जहाँ आप महंगी गलतियों को रोकते हैं: hidden caching, feature flags, migration steps, और ऐसी कोई भी चीज़ जो चुपचाप ब्रेक कर दे सकती है।
Here’s a compact template you can copy:
Local summary: <package/service name>
Purpose: <1 sentence>
Scope: <what to touch> | Not: <what not to change>
Entry points: <files/routes/commands>
Public surface: <exports/endpoints/events>
Data sources: <tables/collections/queues/caches>
Conventions: errors=<how>, logging=<how>, tests=<where/how>
Gotchas: <flags/caching/migrations/edge cases>
Example: अगर आप बिलिंग पैकेज एडिट कर रहे हैं, तो वह सटीक फंक्शन नोट करें जो इनवॉयस बनाता है, जिन टेबलों में वह लिखता है, और retryable errors के नियम। तब Claude उसी सीमा पर फोकस कर सकेगा बजाय इसके कि वह shared auth, config, या unrelated पैकेजों की ओर भटक जाए।
सबसे अच्छा सारांश वही है जो Claude को जब भी ज़रूरत हो दिखे। इसे उसी कोड के पास रखें ताकि देखना मुश्किल न हो और अपडेट करना आसान हो। उदाहरण के लिए, हर पैकेज, सर्विस, या ऐप डायरेक्टरी में छोटा SUMMARY.md (या README.md सेक्शन) रखें बजाय एक विशाल डॉक जो रूट पर हो।
सादा, दोहराने योग्य संरचना मदद करती है। इसे इतना छोटा रखें कि लोग इसे बनाए रखें:
YYYY-MM-DD - <what changed in one sentence>सारांश जेनरली predictable कारणों से स्टेल होते हैं। अपडेट को उसी तरह मानें जैसे आप type definition अपडेट करते हैं: काम पूरा करते समय इसका हिस्सा बनाएं, अलग टास्क न बनाएं।
जब भी कोई refactor संरचना या नाम बदलता है, कोई नया मॉड्यूल मुख्य तरीका बनता है, API/event/schema बदलता है (भले ही टेस्ट पास हों), सीमाएँ पैकेजों के बीच शिफ्ट हों, या कोई निर्भरता हटाई/बदली जाए—सारांश अपडेट करें।
एक व्यवहारिक आदत: जब आप कोई बदलाव merge करें, तो एक “Last updated” लाइन जोड़ें जो बताती हो क्या बदला। Koder.ai जैसे टूल कोड परिवर्तन में आपकी गति बढ़ा सकते हैं, पर सारांश ही भविष्य के परिवर्तनों को सटीक रखता है।
सटीकता अक्सर इस पर निर्भर करती है कि आप बातचीत की गति कैसे रखें। Claude को बड़े snapshot के आधार पर अनुमान लगाने नहीं दें; उसे छोटे टुकड़ों में संदर्भ अर्जित करने के लिए मजबूर करें।
किसी भी edit से पहले, Claude से पूछें कि वह जो देख रहा है उसका वर्णन करे और उसे क्या चाहिए। एक अच्छा नक्शा छोटा होता है: शामिल प्रमुख पैकेज, फ्लो का एंट्री पॉइंट, और जहाँ टेस्ट या types रहते हैं।
प्रांप्ट:
“Create a map of this change: packages involved, main flow, and likely touch points. Do not propose code yet.”
एक संकुचित स्लाइस चुनें: एक फीचर, एक पैकेज, एक user flow। सीमा स्पष्ट बताइए (उदा.: “Only change packages/billing-api. Do not touch shared-ui or infra.”)।
एक वर्कफ़्लो जो नियंत्रण में रखता है:
अगर Claude कुछ मिस कर रहा है तो उसे बताना चाहिए। उससे लिखवाएँ: (1) जो मान्यताएँ वह बना रहा है, (2) क्या उन्हें ग़लत साबित करेगा, और (3) अगली पुष्टि के लिए कौन‑सी फाइलें चाहिए।
उदाहरण: आपको Invoice response में एक फील्ड जोड़ना है। Claude handler, DTO/type definition, और एक टेस्ट मांगता है। आप केवल वही साझा करते हैं। अगर आप चैट-आधारित बिल्डर जैसे Koder.ai का उपयोग कर रहे हैं, तो वही नियम पलटता है: सबसे छोटे स्रोत फ़ाइलों का सेट दें, और तभी बढ़ाएँ जब वास्तव में ज़रूरत हो।
गलत edits के खिलाफ आपका सबसे अच्छा बचाव प्रांप्ट में एक छोटा “कॉन्ट्रैक्ट” लिखना है: क्या छूना है, आप सफलता कैसे आंकेंगे, और कौन‑से नियम मानने होंगे।
एक सीमा से शुरू करें जो पालन करना आसान हो और सत्यापित हो सके। स्पष्ट रूप से बताइए कहाँ edits की अनुमति है, और “do not touch” क्षेत्रों का नाम दें ताकि भटकाव की कोई गुंजाइश न रहे।
कॉन्ट्रैक्ट टेम्पलेट:
packages/payments/ के अंतर्गत फाइलें बदलें।packages/auth/, infra/, या किसी साझा config को edit न करें।फिर स्वीकार्यता जाँचें परिभाषित करें। इनके बिना Claude ऐसा कोड बना सकता है जो दिखने में सही लगे पर वास्तविक नियम तोड़ दे।
स्टाइल constraints भी महत्वपूर्ण हैं। Claude को बताइए कौन‑से पैटर्न अपनाने हैं और किन्हें टालना है, आपके कोडबेस के अनुसार। उदाहरण: “Use existing error helpers in this package; do not add new dependencies; keep function names consistent with camelCase; don’t introduce a new architecture layer.”
अंत में, किसी भी edit से पहले एक छोटा change plan माँगें:
“Before editing, list the 3-5 files you expect to touch and the exact behavior change. Wait for approval.”
उदाहरण:
“Fix rounding in invoice totals. Only edit packages/billing/src/ and tests under packages/billing/test/. Acceptance: pnpm -C packages/billing test and typecheck. Follow existing money utils; do not rewrite API types. Provide a 4-step plan first.”
Monorepo में सबसे तेज़ तरीका गलत edits पाने का है Claude को एक साथ बहुत ज्यादा देना। जब आप एक बड़ा कोड ढेर चिपकाते हैं, वह अक्सर सामान्य पैटर्न पर लौटता है बजाय आपके रिपो के विशिष्ट डिज़ाइन के पालन के।
एक और फंदा है उसे आर्किटेक्चर का अनुमान लगाने देना। अगर आप वास्तविक entry points नहीं दिखाते, तो वह पहले फाइल को चुन सकता है जो संभव दिखती है और लॉजिक वहां जोड़ देगा। व्यवहारिक रूप से, सटीकता कुछ “source of truth” फाइलों (entry modules, routers, service registries, package boundary docs) के छोटे सेट से आती है। अगर वे संदर्भ में नहीं हैं, मॉडल खाली जगह भर देता है।
नाम भी उसे भ्रमित कर सकते हैं। Monorepos में अक्सर ui, ui-kit, shared-ui जैसे पैकेज होते हैं या date.ts जैसी duplicate फाइलें कई जगह। अगर आप दोनों के स्निपेट्स मिलाते हैं, Claude एक फ़ाइल को पैच कर सकता है जबकि वह दूसरी के बारे में सोच रहा हो। उदाहरण: आप बटन स्टाइल बदलने को कहते हैं, वह packages/ui/Button.tsx एडिट कर देता है, पर ऐप packages/ui-kit/Button.tsx इम्पोर्ट करता है। diff ठीक दिखता है, पर प्रोडक्शन में कुछ नहीं बदलता।
Config भी एक मौन ड्रिफ्ट का स्रोत है। व्यवहार env vars, feature flags, build settings, या workspace tooling पर निर्भर कर सकता है। अगर आप इन्हें उल्लेख नहीं करते, Claude कोई “अजीब” चेक हटा सकता है जो केवल एक फ़्लैग पर मायने रखता है, या ऐसा कोड जोड़ सकता है जो build स्टेप तोड़ दे।
ड्रिफ्ट के रेड फ्लैग:
क्रॉस‑पैकेज imports को एक निर्णय मानें, डिफ़ॉल्ट नहीं। edits स्थानीय रखें जब तक आप जानबूझकर स्कोप बढ़ाना न चाहें।
सही edits पाने का सबसे तेज़ तरीका सीमा से शुरू करना है, मात्रा से नहीं। एक अच्छा प्रांप्ट थोड़ा सख्त लगे: यह Claude को बताता है कहाँ देखें, क्या Ignore करें, और “पूरा” होने का क्या अर्थ है।
कोड चिपकाने से पहले एक छोटा प्रेफ़ेस लिखें जो काम को रिपो में एक जगह पिन कर दे। पैकेज का नाम, सटीक फ़ोल्डर, और विशिष्ट लक्ष्य बताएं। फिर एक लोकल सारांश (उद्देश्य, प्रमुख निर्भरता, महत्वपूर्ण कन्वेंशन्स) और वह entry file शामिल करें जो परिवर्तन को एंकर करे।
चेकलिस्ट:
<package>/<path>. Goal: <one sentence>. Ignore everything else unless asked.<5-10 lines>. Entry file: <path/to/file>.<...>. Must not change: <folders/files or APIs>. Keep behavior: <what must stay true>.अगर Claude आपके boundary के बाहर बदलाव प्रस्तावित करता है, तो इसे एक संकेत समझें: या तो प्रांप्ट को सख्त करें, या जानबूझकर सीमा बढ़ाएँ और इसे फिर स्पष्ट रूप से बताइए।
मान लीजिए आपके monorepo में apps/web-store (एक React ऐप) और packages/ui-kit (shared buttons, inputs, और styles) हैं। आप एक छोटा फीचर चाहते हैं: cart पेज में “Save for later” बटन जोड़ना, जो ui-kit से नया SaveIcon उपयोग करे। और कुछ भी बदलना नहीं चाहिए।
बदलाव मांगने से पहले, दो लोकल सारांश बनाइए जो सीमाओं की तरह काम करें। उन्हें छोटा, विशिष्ट, और महत्वपूर्ण बातों के बारे में रायवाला रखें।
# apps/web-store/LOCAL_SUMMARY.md
Purpose: Customer shopping UI.
Entry points: src/routes.tsx, src/pages/cart/CartPage.tsx
Cart rules: cart state lives in src/cart/useCart.ts
Do not touch: checkout flow (src/pages/checkout), payments, auth.
Tests: npm test -w apps/web-store
# packages/ui-kit/LOCAL_SUMMARY.md
Purpose: shared UI components.
Exports: src/index.ts
Icons: src/icons/*, add new icons by exporting from index.
Do not touch: theming tokens, build config.
Tests: npm test -w packages/ui-kit
फिर लूप तंग रखें:
CartPage and ui-kit icons. No checkout/auth edits.”CartPage, useCart, ui-kit icons, ui-kit index)।परिवर्तन के बाद, इसे डॉक्यूमेंट करें ताकि भविष्य का संदर्भ छोटा रहे:
अगर यह एक व्यक्ति के लिए अच्छा काम कर रहा है पर बाकी टीम के लिए नहीं, तो गायब हिस्सा आमतौर पर दोहराव है। “अच्छी संदर्भ हाइजीन” को डिफ़ॉल्ट बनाइए, व्यक्तिगत आदत नहीं।
एक प्रांप्ट सांचे को सेव करें जिसे हर कोई कॉपी करके भर सके। इसे छोटा पर सख्त रखें। इसमें लक्ष्य ("पूरा" क्या दिखता है), अनुमति स्कोप, कठोर सीमाएँ (और क्यों), एक लोकल सारांश, और आउटपुट कॉन्ट्रैक्ट (पहले योजना, फिर diff‑style edits और टेस्ट) शामिल करें।
बड़े मासिक रिव्यू छोड़ दें जिन्हें कोई नहीं करता। सारांश अपडेट को सामान्य काम के साथ जोड़ दें: जब कोई परिवर्तन व्यवहार, निर्भरता, या APIs बदलता है, उसी PR में लोकल सारांश अपडेट करें।
एक सरल नियम: अगर कोई teammate पूछेगा “यह कहाँ रहता है?” या “इस पर कौन निर्भर करता है?”, तो सारांश अब आउटडेटेड है।
अगर आप चैट‑फर्स्ट वर्कफ़्लो पसंद करते हैं, तो Koder.ai इस तरह के इटरेशन को सुरक्षित बनाने में मदद कर सकता है। Planning mode आपको स्कोप और सीमाओं पर पहले सहमति करने में मदद करता है, और snapshots/rollback से आप परिवर्तनों को आज़मा कर जल्दी लौट सकते हैं जब अनुमान गलत निकले।
Claude उस वास्तविक स्रोत-सत्य को "नहीं देख पाने" पर कम सटीक हो जाता है.
बड़े monorepo में, मॉडल अक्सर किसी निर्भरता फ़ाइल को मिस कर देता है, दो मिलते-जुलते पैकेजों को भुला देता है, या संदर्भ में जो पुराना पैटर्न है वही कॉपी कर लेता है।
पूरा रिपोज़िटरी देने की कोशिश न करें। उस सबसे छोटे सेट से शुरू करें जो परिवर्तन की सहीता साबित कर सके.
एक अच्छा डिफ़ॉल्ट:
वह शेयर करें जो व्यवहार को एंकर करता है, नाम से जुड़ी हर चीज नहीं.
एक व्यावहारिक सेट:
अपने रिपॉज़िटरी के संगठन के अनुरूप एक boundary चुनें: एक package, app, या service.
फिर इसे स्पष्ट रूप से बताइए, और क्या आउट-ऑफ़-स्कोप है उसे भी शामिल करें. उदाहरण constraints:
packages/cart/ and its tests.”क्योंकि monorepos में अक्सर look-alike modules होते हैं (ui, ui-kit, shared-ui) और duplicated helpers (date.ts कई जगह).
Claude सही आइडिया को गलत पैकेज पर लागू कर सकता है, या “लगभग सही” मॉड्यूल नाम से import कर सकता है। इससे रोकने के लिए उस सटीक पैकेज और entry points का नाम बताएं जो आप चाहते हैं।
एक local summary वह छोटा नक्शा है जिसे आप बदलना चाहते हैं, आम तौर पर 10–20 पंक्तियाँ.
शामिल करें:
इसे उसी कोड के बगल में रखें ताकि इसे ढूँढना और अपडेट करना आसान हो.
एक सरल डिफ़ॉल्ट:
SUMMARY.md या package README.md में छोटा सेक्शनClaude को शुरू से कहें कि अनुमान लगाने की बजाय वह assumptions और unknowns को फ्लैग करे.
एक उपयोगी नियम:
एक तंग लूप का उपयोग करें जो संदर्भ को छोटे‑छोटे हिस्सों में कमाए जाने के लिए मजबूर करे:
अपने प्रांप्ट में एक छोटा “अनुबंध” लिखें और उसे लागू करने योग्य बनाएं:
यह समीक्षा को आसान बनाता है और अनजाने में cross-package edits को घटाता है।