आप Claude Code से पूछते हैं कि उसने CLAUDE.md पढ़ी या नहीं। वह हाँ कहता है, फिर भी बताए गए टेस्ट छोड़ देता है। ऐसे में मॉडल तक पहुँचे ही नहीं निर्देशों और पहुँचने के बाद भी न माने गए निर्देशों को अलग करें। “पढ़ लिया” का जवाब इनमें से किसी स्थिति को साबित नहीं करता।

Cursor की .cursor/rules, GitHub Copilot की .github/copilot-instructions.md और Codex CLI की AGENTS.md के साथ भी यही बात है: फ़ाइल कहाँ से लोड होती है और कब लागू होती है, यह हर टूल में अलग है। फ़ाइल का लोड होना और मॉडल का उस निर्देश का पालन करना, ये अलग सवाल हैं।

सीधी बात यह है कि प्रक्रिया के तीन चरण हैं। पहले देखें कि फ़ाइल लोड हो रही है या नहीं। लोड होने के बाद भी जिस नियम का पालन न हो, उसे ऐसे वाक्य में दोबारा लिखें जिससे बाद में जाँचा जा सके कि पालन हुआ या नहीं। इसके बाद भी जिस प्रक्रिया को हर बार ज़रूर चलवाना है, उसे Hooks या CI में ले जाएँ। Claude Code के आधिकारिक दस्तावेज़ भी बताते हैं कि CLAUDE.md “लागू की जाने वाली सेटिंग नहीं, बल्कि संदर्भ” है, और Claude के निर्णय से स्वतंत्र रूप से किसी कार्रवाई को रोकना हो तो हुक इस्तेमाल करने की सलाह देते हैं।

यह लेख लोडिंग, संपीड़न के बाद वापसी और विरोधी निर्देशों सहित जाँचने योग्य पाँच बातें, कारण खोजने की प्रक्रिया और नियमों को दोबारा लिखने के उदाहरण क्रम से बताता है।

सारांश

नियम अनदेखे क्यों रह जाते हैं

— और जाँच की व्यवस्था कैसे बनाएँ

कारण
लोड होने की शर्तें
संपीड़न के बाद मूल CLAUDE.md लौटती है। केवल चैट में लिए फैसले अलग हैं
कारण
अस्पष्ट प्राथमिकताएँ
विरोधी निर्देशों का लेखक और लागू होने का दायरा जाँचें
उपाय
जाँचे जा सकने वाले वाक्य
“कब, क्या और कैसे जाँचें” तक लिखें, ताकि बाद में देखा जा सके कि पालन हुआ या नहीं
उपाय
जाँच की व्यवस्था बनाएँ
जाँची जा सकने वाली शर्तों के लिए Hooks और CI रखें। AI समीक्षा सहायता करती है

1. AI नियम क्यों नज़रअंदाज़ करता है: जाँचने योग्य पाँच बातें

1. फ़ाइल लंबी होने से नियम दब जाते हैं

Claude Code के आधिकारिक दस्तावेज़ हर CLAUDE.md फ़ाइल को 200 से कम पंक्तियों में रखने की सलाह देते हैं और कारण बताते हैं कि “लंबी फ़ाइलें ज़्यादा संदर्भ खर्च करती हैं और पालन घटाती हैं”। 200 पंक्तियाँ लोडिंग रुकने की जगह नहीं हैं; 4 MiB तक की CLAUDE.md पूरी लोड होती है (4 MiB से बड़ी फ़ाइल छोड़ दी जाती है)। लंबी फ़ाइल में समस्या यह नहीं होती कि बीच से आगे पढ़ा नहीं जाता, बल्कि यह कि पूरी पढ़े जाने के बाद भी अलग-अलग नियमों का पालन कम हो जाता है।

2. लंबे सेशन में Auto-compact

Claude Code का /compact बातचीत को संपीड़ित करता है, लेकिन इसके बाद प्रोजेक्ट की मूल डायरेक्टरी की CLAUDE.md डिस्क से दोबारा पढ़कर संदर्भ में जोड़ी जाती है। इसके विपरीत, उपडायरेक्टरी की CLAUDE.md और पाथ के अनुसार नियम संबंधित फ़ाइल पढ़ने पर फिर लोड होते हैं। आधिकारिक दस्तावेज़ों के अनुसार, संपीड़न के बाद गायब हुआ निर्देश इनमें से किसी एक जगह होता है: (1) वह केवल बातचीत में बताया गया था, (2) वह उपडायरेक्टरी की ऐसी CLAUDE.md में है जो अभी दोबारा लोड नहीं हुई, (3) वह ऐसे पाथ-आधारित नियम में है जिसकी लक्ष्य फ़ाइल अभी छुई नहीं गई। बातचीत में तय की गई बात बनाए रखनी हो, तो उसे CLAUDE.md में जोड़ें।

3. विरोधी निर्देश और उनका दायरा

“कमिट से पहले टेस्ट करो” और “इस बार टेस्ट छोड़ दो” साथ मौजूद हों, तो कौन-सा लागू होगा, यह मॉडल के निर्णय पर छूट जाता है। Claude Code के आधिकारिक दस्तावेज़ बताते हैं कि दो नियम आपस में टकराएँ, तो Claude उनमें से कोई एक मनमाने ढंग से चुन सकता है। पूरे प्रोजेक्ट, व्यक्तिगत और डायरेक्टरी के निर्देशों की समय-समय पर तुलना करके विरोधाभास हटाएँ, और अपवाद की अनुमति देनी हो तो लिखें कि “किसके, किस तरह कहने पर”। कार्रवाई को ही रोकना हो, तो CLAUDE.md के बजाय परमिशन सेटिंग या Hooks इस्तेमाल करें। Claude से विरोधी या पुराने निर्देश खुद खोजवाने के लिए /doctor prompt-audit चलाएँ (यह कैसे काम करता है और इस साइट पर क्या मिला)।

4. अस्पष्ट या परस्पर विरोधी नियम

“विनम्रता से लिखो” या “उचित ढंग से संभालो” जैसे व्यक्तिनिष्ठ या अमूर्त निर्देशों का AI अपना अर्थ निकालता है, जो आपकी अपेक्षा से अलग हो सकता है। आवश्यकता को ऐसे रूप में लिखें जिससे पालन की जाँच हो सके: जैसे “तीन से अधिक पंक्तियाँ न लिखो” या “Slack API इस्तेमाल करते समय chat.postMessage इस्तेमाल करो” (दोबारा लिखने के उदाहरण खंड 3 में)।

5. बहुत बड़ी या बिखरी नियम फ़ाइलें

CLAUDE.md से SPEC.md का सामान्य लिंक देने पर लिंक की पूरी फ़ाइल शुरुआत में लोड हो ही जाए, यह ज़रूरी नहीं। Claude Code शुरुआत में @path इम्पोर्ट खोलता है, लेकिन उसकी सामग्री भी संदर्भ में जगह लेती है। व्यवस्था के लिए फ़ाइल बाँटना और उसे केवल ज़रूरत पर लोड करना अलग बातें हैं। दोहराए गए नियम आपस में टकराएँ, तो मूल प्रति और उनका दायरा स्पष्ट करें।

सबडायरेक्टरी में रखी CLAUDE.md और AGENTS.md कब पढ़ी जाती हैं (Claude Code और Codex में यह अलग है), और मोनोरेपो में अपने-आप होने वाली जाँचों से AI से नियम कैसे मनवाएँ, इसका विस्तार सबडायरेक्टरी की CLAUDE.md और AGENTS.md वाले लेख में है।

यहाँ तक बताई गई Claude Code की विशिष्टताएँ Claude Code के आधिकारिक मेमोरी दस्तावेज़ (21 सितंबर 2026 तक) पर आधारित हैं।

2. नियमों का पालन हो रहा है या नहीं, कैसे जाँचें

पहले मौजूदा स्थिति जाँचें। AI से ये सवाल पूछें और जवाबों को परखें:

सवालक्या जाँचें
“CLAUDE.md के सभी नियम बिंदुवार बताओ।”कोई नियम छूटा हो, तो /context से देखें कि वह फ़ाइल लोड हुई है या नहीं
“कोड लिखने से पहले बताओ कि CLAUDE.md के किन नियमों का पालन करोगे।”काम से पहले महत्त्वपूर्ण नियम याद दिलाता है। पालन हुआ या नहीं, यह काम के बाद के डिफ़ से देखें
“पिछले पाँच संवादों में CLAUDE.md का उल्लंघन करने वाले संभावित काम बताओ।”अपनी रिपोर्ट को केवल संकेत मानें; कमांड इतिहास, एग्ज़िट कोड और बनी फ़ाइलों से मिलाकर पक्का करें

“पढ़ लिया” या “समझ गया” वाला जवाब न लोडिंग का प्रमाण है, न लागू करने का। प्रमाण हैं लोडिंग का प्रदर्शन और काम के बाद बनी फ़ाइलें।

कारण पहचानने के चार चरण

  1. प्रवेश-बिंदु देखें। Claude Code में /context के Memory files में देखें कि संबंधित CLAUDE.md और नियम सूची में हैं या नहीं। न हों, तो फ़ाइल की जगह और बाहर रखने की सेटिंग (claudeMdExcludes) जाँचें। AGENTS.md सीधे लोड करवाई गई हो, तो वह AGENTS.md इस सूची में नहीं दिखती। डिफ़ॉल्ट सेटिंग में, शुरुआत पर दिखने वाली no CLAUDE.md found; AGENTS.md loaded: … पंक्ति आई है या नहीं, यह देखें (CLAUDE.md से इम्पोर्ट की गई AGENTS.md सूची में दिखती है)।
  2. नियम लागू होने की शर्त पूरी करें। पाथ के अनुसार नियमों के लिए एजेंट से मेल खाती फ़ाइल पढ़वाएँ। संपीड़न के बाद वह फ़ाइल अभी नहीं पढ़ी गई, तो वह नियम दोबारा लोड नहीं हुआ है। कब क्या लोड हुआ, इसका रिकॉर्ड रखना हो, तो InstructionsLoaded हुक से CLAUDE.md और नियमों की लोडिंग लॉग में दर्ज कर सकते हैं (सीधे लोड हुई AGENTS.md पर यह नहीं चलता)।
  3. छोटा, हानिरहित काम आज़माएँ। अस्थायी नमूने पर “बदलने से पहले फ़ाइल का नाम बताओ” और “बाद में टेस्ट कमांड तथा एग्ज़िट कोड बताओ” जैसे नियम लगाकर संपादन कराएँ। परीक्षण के लिए उत्पादन का डेटा मिटाना या प्रकाशन न चुनें। गुप्त परीक्षण-शब्द से परखना हो, तो वह शब्द केवल निर्देश फ़ाइल में लिखें, सवाल में शामिल न करें।
  4. परिणाम स्वतंत्र रूप से सत्यापित करें। डिफ़ में अनपेक्षित बदलाव देखें, बताए गए टेस्ट वास्तव में चले या नहीं और पर्याप्त मदें जाँची गईं या नहीं, यह जाँचें। परीक्षण के समय की सेटिंग, टूल का संस्करण और लक्ष्य फ़ाइलें दर्ज करें, और इनमें से कुछ भी बदले तो फिर से आज़माएँ।

मसलन, “कमिट से पहले टेस्ट करो” वाला निर्देश लोड हुआ, फिर भी टेस्ट नहीं चले, तो फ़ाइल की जगह बदलने से समस्या हल नहीं होगी। सुधारना है नियम लिखने का तरीका (अगले खंड के उदाहरण) और जाँच की व्यवस्था। मर्ज से पहले CI जाँच अनिवार्य करने से AI की अपनी रिपोर्ट से अलग प्रमाण भी मिलता है।

संबंधित CLAUDE.md लोडिंग के प्रदर्शन में न दिखे, तो शब्दों पर और ज़ोर देने से पहले शुरुआत की डायरेक्टरी और सेटिंग ठीक करें। लोडिंग की पुष्टि के बाद भी उल्लंघन रहें, तो निर्देश कितने ठोस हैं और जाँच कैसे होती है, यह देखें। इस क्रम से हर असफलता को “AI भूल गया” मानने से बचते हैं।

3. पाँच मिनट में आज़माने योग्य सुधार

1. हमेशा ज़रूरी नियम और ज़रूरत पर पढ़े जाने वाले विवरण अलग रखें

Claude Code की 200 से कम पंक्तियों वाली आधिकारिक सलाह से शुरू करें, लेकिन पंक्तियाँ गिनने के बजाय दोहराव और अनावश्यक व्याख्या घटाएँ। उदाहरण:

  • अनिवार्य नियम (10–20 पंक्तियाँ) → CLAUDE.md की शुरुआत में
  • सेवा का विस्तृत विनिर्देश → अलग SPEC-xxx.md फ़ाइलों में
  • इतिहास और पृष्ठभूमि → docs/ डायरेक्टरी में

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

2. नियमों को “पालन जाँचे जा सकने वाले वाक्यों” में दोबारा लिखें

लोड होने के बाद भी जिस नियम का पालन न हो, उसमें पहले देखें कि “क्या करने पर पालन माना जाएगा” लिखा है या नहीं। Claude Code के आधिकारिक दस्तावेज़ भी निर्देशों को इतना ठोस लिखने की सलाह देते हैं कि उनकी जाँच हो सके, और उदाहरण देते हैं कि “बदलाव टेस्ट करो” के बजाय “कमिट से पहले npm test चलाओ” लिखें। इसे एक कदम आगे बढ़ाकर विफलता पर व्यवहार और अपवाद की शर्तें भी लिखें, तो रूप कुछ ऐसा होगा:

पहलेदोबारा लिखने के बादबाद में क्या परखा जा सकता है
टेस्ट करके कमिट करोकमिट से पहले npm test चलाओ और जाँचो कि एग्ज़िट कोड 0 है। विफल हो तो कमिट न करो और विफल टेस्ट का नाम बताओ। टेस्ट केवल तब छोड़ो जब उपयोगकर्ता स्पष्ट रूप से कहेचलाई गई कमांड, एग्ज़िट कोड और टेस्ट छोड़ने का कारण
कोड का फ़ॉर्मैट ठीक रखोइंडेंटेशन 2 स्पेसडिफ़ देखकर उल्लंघन पता चलता है
फ़ाइलें व्यवस्थित रखोAPI हैंडलर src/api/handlers/ में रखोनई फ़ाइल कहाँ रखी गई, इससे जाँचा जा सकता है
समझने में आसान कमिट संदेश लिखोपहली पंक्ति feat: fix: docs: में से किसी एक से शुरू करो और 50 अक्षरों के भीतर रखोकमिट इतिहास में हर कमिट को अलग-अलग परखा जा सकता है

दोबारा लिखे वाक्यों में डिफ़, कमांड इतिहास और एग्ज़िट कोड देखकर तय किया जा सकता है कि पालन हुआ या नहीं। जो नियम इस तरह परखे जा सकते हैं, वे बाद में Hooks या CI में ले जाते समय सीधे जाँच की शर्त बन जाते हैं (खंड 4)।

3. प्राथमिकता बताने वाले संकेत जोड़ें

महत्त्व बताने वाले संकेत इंसान और AI को मंशा समझने में मदद करते हैं। संकेत अपने आप काम लागू नहीं करवाते। उदाहरण के लिए:

  • CRITICAL: उल्लंघन से उत्पादन में हादसा हो सकता है
  • MUST: हमेशा आवश्यक
  • SHOULD: सामान्यतः अपेक्षित
  • NICE TO HAVE: समय मिले तो वैकल्पिक

“CRITICAL: उत्पादन डेटाबेस को नुकसान पहुँचाने वाली क्वेरी के लिए पहले मंज़ूरी चाहिए” से कार्रवाई और मंज़ूरी की शर्त स्पष्ट होती है। बिना अनुमति की कार्रवाई वास्तव में रोकने के लिए परमिशन सेटिंग या काम से पहले की जाँच भी चाहिए।

4. चैट में नियम याद दिलाएँ

सेशन की शुरुआत में जोड़ें: “काम शुरू करने से पहले तीन सबसे महत्त्वपूर्ण नियम बताओ।” घोषणा से नियम याद आते हैं; पालन हुआ या नहीं, यह काम के बाद के परिणाम से देखें।

5. योजना में पूरा होने की शर्तें शामिल करें

अपने AI एजेंट की कार्य-सूची में “नियम जाँचो” जोड़ें और हर चरण पूरा होने की शर्त दिखाएँ। केवल “टेस्ट किया” के बजाय कमांड, एग्ज़िट कोड और अनजाँचा दायरा माँगें। प्रमाण वाला हिस्सा खाली हो और फिर भी पूर्णता का निशान लगा हो, तो उसे पूरा न मानें।

4. लंबे समय के उपाय: Hooks, समीक्षा और Skills

जिन शर्तों का मूल्यांकन हो सकता है उन्हें स्क्रिप्ट में रखें, और कार्रवाई की परमिशन सेटिंग से नियंत्रित करें। Hooks, CI, AI समीक्षा और Skills के उद्देश्य अलग हैं। सबको “स्वचालित पालन” कहने से उनके बाहर का अनजाँचा दायरा छिप जाता है।

1. Claude Code Hooks से जाँच लागू करें

Claude Code की Hooks सुविधा खास टूल कॉल से पहले या बाद में स्क्रिप्ट चला सकती है। इससे ऐसी व्यवस्था बन सकती है जहाँ AI नियम भूल भी जाए, तो सिस्टम कार्रवाई रोक दे।

उदाहरण के लिए, PreToolUse हुक यह कर सकता है:

  • खतरनाक कमांड (rm -rf, git push --force) को Bash टूल चलने से पहले पहचानकर अस्वीकार करना
  • लक्ष्य फ़ाइल की परमिशन या लॉक स्थिति को Edit टूल चलने से पहले जाँचना
  • कमिट से पहले प्रोजेक्ट के टेस्ट चलाना और असफल होने पर कमिट रोकना

जब PreToolUse हुक को कार्रवाई रोकनी हो, तो उससे एग्ज़िट कोड 2 या उचित अस्वीकृति JSON लौटवाएँ। असफल टेस्ट केवल सामान्य टेक्स्ट आउटपुट के साथ 1 लौटाता है, तो वह न रोकने वाली त्रुटि है और कार्रवाई जारी रहती है। PostToolUse बाद में चलता है, इसलिए पहले पूरी हो चुकी कार्रवाई को वापस करने की व्यवस्था नहीं है।

हुक केवल वही रोक सकता है जिसका उसकी स्क्रिप्ट तय इवेंट पर मूल्यांकन करती है। केवल Edit पर निगरानी रखने से शेल के ज़रिए लिखी फ़ाइलें शामिल नहीं होतीं। खतरनाक स्ट्रिंग का साधारण मिलान भी संपूर्ण जाँच नहीं है। Hooks के साथ परमिशन, सैंडबॉक्स और CI रखें तथा पास होने वाले और अस्वीकार होने वाले, दोनों तरह के इनपुट जाँचें।

2. सबएजेंट से ज़िम्मेदारियाँ बाँटें

Claude Agent SDK या Cursor की सबएजेंट सुविधा से नियमों की जाँच के लिए अलग एजेंट बनाएँ। मुख्य एजेंट के कोड की दूसरे एजेंट से समीक्षा कराने पर दूसरे दृष्टिकोण से चूकें मिल सकती हैं। फिर भी दोनों एजेंट एक ही गलती कर सकते हैं या एक ही समस्या छोड़ सकते हैं।

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

3. दोहराई जाने वाली प्रक्रिया Skills से चलाएँ

Claude Code में दोहराई जाने वाली प्रक्रिया .claude/skills/precommit/SKILL.md में रखकर अपने /precommit से बुला सकते हैं। यह स्वयं बनाने का उदाहरण है, अंतर्निहित कमांड नहीं। पुराने .claude/commands/ की फ़ाइलें भी काम करती हैं, लेकिन वर्तमान दस्तावेज़ उन्हें Skills में शामिल करते हैं। प्रक्रिया बुलाना और हर जाँच पास होना अलग बातें हैं, इसलिए अंत में परिणाम देखें।

फ़ाइल की जगह और बुलाने का तरीका आधिकारिक Skills दस्तावेज़ में दिया गया है। स्किल में प्रक्रिया और पास होने की शर्तें रखें, तथा चरण चलने के प्रमाण माँगें।

4. स्वचालित स्क्रिप्ट से उल्लंघन पहचानें

प्रतिबंधित पैटर्न पहचानने के लिए CI या pre-commit हुक में grep इस्तेमाल करें। उदाहरण:

  • उत्पादन कोड में बचा console.log
  • कोड में सीधे लिखी API कुंजियाँ
  • फ़ाइल की शुरुआत में कॉपीराइट टिप्पणी का अभाव

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

5. हर टूल के लिए उपयोगी तरीके

प्रमुख AI एजेंट के लिए नियम बनाने के सुझाव

Claude Code
Anthropic
सेटिंग फ़ाइलें
CLAUDE.md + ~/.claude/CLAUDE.md
लंबाई और लोडिंग
आधिकारिक सलाह: 200 से कम पंक्तियाँ। फ़ाइल जितनी लंबी, पालन उतना कम
जाँच के उपाय
Hooks / subagents / Skills
Cursor
Anysphere
सेटिंग फ़ाइलें
.cursor/rules/*.mdc
लंबाई और लोडिंग
आधिकारिक सलाह: 500 से कम पंक्तियाँ। उद्देश्य के अनुसार बाँटें
जाँच के उपाय
glob से दायरा / @-mention से संदर्भ
GitHub Copilot
GitHub
सेटिंग फ़ाइलें
.github/copilot-instructions.md
लंबाई और लोडिंग
छोटे, अपने आप में पूरे निर्देश। इस्तेमाल की सुविधा में समर्थन जाँचें
जाँच के उपाय
.github/instructions/*.instructions.md में फ़ाइल के अनुसार नियम
Codex CLI
OpenAI
सेटिंग फ़ाइलें
AGENTS.md
लंबाई और लोडिंग
डिफ़ॉल्ट संयुक्त लोडिंग सीमा: 32 KiB, पंक्तियों की संख्या नहीं
जाँच के उपाय
मंज़ूरी के मोड / सैंडबॉक्स की पाबंदियाँ

टूल की विशिष्ट शर्तों के लिए Cursor नियम दस्तावेज़, GitHub Copilot के कस्टम निर्देश और OpenAI की AGENTS.md मार्गदर्शिका देखें। Copilot के पाथ-आधारित निर्देश *.instructions.md इस्तेमाल करते हैं; उन्हें कौन-सी सुविधा पढ़ती है, यह सुविधा के अनुसार अलग है। Codex की 32 KiB सीमा डिफ़ॉल्ट संयुक्त बाइट सीमा है, अक्षर या पंक्तियों की संख्या नहीं।

साझा सिद्धांत है “संक्षिप्त, ठोस और स्पष्ट प्राथमिकता वाले निर्देश”। फ़ाइल का नाम और जगह टूल के अनुसार बदलते हैं, लेकिन लिखने के सिद्धांत समान हैं।

6. नियम बनाते समय होने वाली तीन गलतियाँ

1. “कृपया अच्छे तरीके अपनाएँ”

सिर्फ़ यह अनुरोध “अच्छे तरीके” परिभाषित नहीं करता। प्रोजेक्ट में अपनाए तरीके और उनका सत्यापन बताएँ। “उचित टेस्ट करो” के लिए आवश्यक टेस्ट कमांड और उनके असफल होने पर रुकने वाला कार्य-चरण बताएँ (खंड 3 के दोबारा लिखने के उदाहरण)।

2. कई फ़ाइलों में एक ही नियम दोहराना

कमिट के एक ही नियम CLAUDE.md, SPEC.md और README.md में हों, तो अपडेट के बाद तीनों प्रतियाँ अलग हो सकती हैं। एक मूल प्रति चुनें और दूसरी फ़ाइलों से उसका लिंक दें।

3. हर जगह “हर हाल में ज़रूरी” लिखना

हर शर्त पर एक जितना ज़ोर देने से प्राथमिकताएँ समझाना कठिन हो जाता है। “CRITICAL” सच में गंभीर परिणाम वाली शर्तों के लिए रखें और बाकी सामान्य भाषा में लिखें। याद रखें कि बहुत अधिक ज़ोर देने से उसका महत्त्व घटता है।

सारांश

नियम न माने जाएँ, तो इस क्रम में जाँचें: लोडिंग की शर्तें → दायरा → विरोधी निर्देश → काम के परिणाम। मूल CLAUDE.md संपीड़न के बाद भी वापस जुड़ती है, इसलिए संपीड़न के बाद गायब हुआ निर्देश या तो केवल बातचीत में बताया गया था, या अभी दोबारा लोड न हुई भीतर की CLAUDE.md या पाथ-आधारित नियम में है।

  • लोड नहीं हो रहा: फ़ाइल की जगह, बाहर रखने की सेटिंग और AGENTS.md के लोड होने की शर्तें ठीक करें
  • लोड हो रहा है, फिर भी पालन नहीं: नियम को ऐसे वाक्य में दोबारा लिखें जिससे बाद में पालन जाँचा जा सके
  • हर बार ज़रूर चलवाना है: Hooks या CI से जाँचें, और अनुमत कार्रवाइयाँ परमिशन सेटिंग से तय करें

काम पूरा होने का प्रमाण “पढ़ लिया” का जवाब नहीं, बल्कि काम के परिणाम और बनी फ़ाइलें हैं।

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

सवाल 1. CLAUDE.md की सही लंबाई क्या है?

आधिकारिक सलाह है प्रति फ़ाइल 200 से कम पंक्तियाँ, और बताया गया है कि फ़ाइल जितनी लंबी होगी, उतना ज़्यादा संदर्भ खर्च होगा और पालन घटेगा। 200 पंक्तियों से ऊपर जाने पर भी लोडिंग बीच में नहीं रुकती (4 MiB तक पूरी फ़ाइल लोड होती है)। हर बार ज़रूरी नियम ही रखें, और केवल खास फ़ाइलों पर लागू होने वाले नियम पाथ-आधारित नियमों में ले जाएँ। @path इम्पोर्ट से अलग की गई फ़ाइलें भी शुरुआत में लोड होती हैं, इसलिए संदर्भ की मात्रा नहीं घटती।

सवाल 2. Cursor की .cursorrules इस्तेमाल करें या .cursor/rules/*.mdc?

नया सेटअप हो, तो .cursor/rules/*.mdc इस्तेमाल करें। हर फ़ाइल में एक नियम रखें और glob पैटर्न से उसका दायरा बताएँ। पुरानी .cursorrules एक ही फ़ाइल है जिसे संभालना कठिन हो सकता है।

सवाल 3. क्या लंबे नियमों से सख्ती बढ़ती है?

केवल लंबाई बढ़ाने से नियम सख्त नहीं होते। आधिकारिक दस्तावेज़ भी बताते हैं कि लंबी फ़ाइलें पालन घटाती हैं। कुछ जोड़ना हो, तो जाँची जा सकने वाली शर्तें और ठोस उदाहरण जोड़ें, और दोहराव तथा विरोधाभास हटाएँ।

सवाल 4. एक प्रोजेक्ट में Claude Code और Cursor जैसे कई AI टूल हों तो क्या करें?

साझा नियमों की मूल प्रति AGENTS.md में रखें, और हर टूल की विशिष्ट सेटिंग उसके अपने प्रवेश-बिंदु में अलग रखें। Codex और Cursor AGENTS.md का समर्थन करते हैं। Claude Code भी v2.1.277 से, यदि कार्य डायरेक्टरी और उसके ऊपर की डायरेक्टरियों में CLAUDE.md, .claude/CLAUDE.md या CLAUDE.local.md में से कोई न हो, तो AGENTS.md सीधे लोड करता है। इनमें से कोई एक भी हो, तो डिफ़ॉल्ट रूप से केवल वही पढ़ी जाती है; व्यक्तिगत CLAUDE.local.md रख देने भर से भी AGENTS.md पढ़ी जाना बंद हो जाती है। जिस प्रोजेक्ट में CLAUDE.md भी इस्तेमाल होती है, उसमें CLAUDE.md में @AGENTS.md की एक पंक्ति लिखकर उसे इम्पोर्ट करें (/config में Project instructions को claude-md-and-agents-md करके दोनों पढ़वाने का तरीका भी है)। Amazon Bedrock जैसे बाहरी प्रदाता से या टेलीमेट्री बंद करके चलाए गए सेशन, इंस्टॉल या अपडेट के ठीक बाद के पहले सेशन, और disableAllHooks आदि से हुक बंद किए गए परिवेश में सीधी लोडिंग काम नहीं करती, इसलिए वहाँ इम्पोर्ट इस्तेमाल करें। फ़ाइल किस रास्ते से पढ़ी जा रही है, यह खंड 2 के चरण 1 से पहचाना जा सकता है।

सवाल 5. AI कहे “पढ़ लिया”, फिर भी क्या फ़ाइल अनपढ़ी हो सकती है?

जवाब न यह साबित करता है कि फ़ाइल पढ़ी गई, न यह कि नहीं पढ़ी गई। खंड 2 के जाँच-चरणों से लोडिंग का प्रदर्शन देखें और डिफ़, टेस्ट परिणाम तथा कमांड इतिहास से मिलाएँ।