विषय-सूची
आप Claude Code से पूछते हैं कि उसने CLAUDE.md पढ़ी या नहीं। वह हाँ कहता है, फिर भी बताए गए टेस्ट छोड़ देता है। ऐसे में मॉडल तक पहुँचे ही नहीं निर्देशों और पहुँचने के बाद भी न माने गए निर्देशों को अलग करें। “पढ़ लिया” का जवाब इनमें से किसी स्थिति को साबित नहीं करता।
Cursor की .cursor/rules, GitHub Copilot की .github/copilot-instructions.md और Codex CLI की AGENTS.md के लिए भी जाँचना होगा कि फ़ाइल कहाँ से लोड होती है और कब लागू होती है। टूल निर्देश कैसे लोड करता है और मॉडल उनका पालन करता है या नहीं, ये अलग सवाल हैं।
यह लेख लोडिंग, संपीड़न के बाद वापसी और विरोधी निर्देशों सहित जाँचने योग्य पाँच बातें, कारण खोजने का क्रम और व्यावहारिक सुधार समझाता है। केवल छोटा लिखने से पालन की गारंटी नहीं मिलती। यांत्रिक रूप से जाँची जा सकने वाली शर्तें Hooks या CI में रखें, और मानवीय निर्णय वाले सवाल समीक्षा में रखें।
नियम अनदेखे क्यों रह जाते हैं
— और जाँच की व्यवस्था कैसे बनाएँ
1. AI नियम क्यों नज़रअंदाज़ करता है: जाँचने योग्य पाँच बातें
1. लंबाई की सलाह को लोडिंग की सीमा समझना
लंबे निर्देश संदर्भ में जगह लेते हैं और महत्त्वपूर्ण शर्तें ढूँढ़ना मुश्किल बनाते हैं। Claude Code के दस्तावेज़ हर CLAUDE.md फ़ाइल को 200 से कम पंक्तियों में रखने की सलाह देते हैं, लेकिन इसका मतलब यह नहीं कि 200वीं पंक्ति पर लोडिंग रुक जाती है। लोडिंग की सीमा और लोड हुए निर्देशों का पालन अलग बातें हैं। दस्तावेज़ “150 पंक्तियों पर पालन निश्चित है” या “200 से ऊपर बीच का हिस्सा गायब होता है” जैसी सीमाएँ नहीं बताते।
2. लंबे सेशन में Auto-compact
Claude Code का /compact बातचीत को संपीड़ित करता है, लेकिन इसके बाद प्रोजेक्ट की मूल डायरेक्टरी की CLAUDE.md डिस्क से दोबारा पढ़कर संदर्भ में जोड़ी जाती है। इसके विपरीत, उपडायरेक्टरी की CLAUDE.md और पाथ के अनुसार नियम संबंधित फ़ाइल पढ़ने पर फिर लोड होते हैं। केवल चैट में हुए फैसले, अभी दोबारा लोड न हुए भीतर की डायरेक्टरी के निर्देश, और लोड होकर भी न माने गए निर्देश अलग रखें।
3. विरोधी निर्देश और उनका दायरा
“कमिट से पहले टेस्ट करो” और “इस बार टेस्ट छोड़ दो” साथ मौजूद हों, तो एजेंट को तय करना होगा कि कौन-सा निर्देश लागू है। सिर्फ़ समयक्रम प्राथमिकता नहीं बताता: नया निर्देश अपने आप ऊँची प्राथमिकता का नहीं हो जाता। पूरे प्रोजेक्ट, व्यक्तिगत और डायरेक्टरी के निर्देशों की तुलना करें तथा बताएँ कि अपवाद की अनुमति कौन दे सकता है। CLAUDE.md में मनाही लिखने से अपने आप उस कार्रवाई की परमिशन नहीं हटती।
4. अस्पष्ट या परस्पर विरोधी नियम
“विनम्रता से लिखो” या “उचित ढंग से संभालो” जैसे व्यक्तिनिष्ठ या अमूर्त निर्देशों का AI अपना अर्थ निकालता है, जो आपकी अपेक्षा से अलग हो सकता है। आवश्यकता को जाँचने योग्य बनाएँ: जैसे “तीन से अधिक पंक्तियाँ न लिखो” या “Slack API इस्तेमाल करते समय chat.postMessage इस्तेमाल करो”।
5. बहुत बड़ी या बिखरी नियम फ़ाइलें
CLAUDE.md से SPEC.md का सामान्य लिंक देने पर लिंक की पूरी फ़ाइल शुरुआत में लोड हो ही जाए, यह ज़रूरी नहीं। Claude Code शुरुआत में @path इम्पोर्ट खोलता है, लेकिन उसकी सामग्री भी संदर्भ में जगह लेती है। व्यवस्था के लिए फ़ाइल बाँटना और उसे केवल ज़रूरत पर लोड करना अलग बातें हैं। दोहराए गए नियम आपस में टकराएँ, तो मूल प्रति और उनका दायरा स्पष्ट करें।
ये भेद Claude Code के आधिकारिक मेमोरी दस्तावेज़ पर आधारित हैं, जिनका मूल पाठ 21 सितंबर 2026 को जाँचा गया। कारण गलत न समझें: लंबाई की सलाह और संपीड़न के बाद क्या वापस आता है, इनकी व्याख्या अलग पढ़ें।
2. नियमों का पालन हो रहा है या नहीं, कैसे जाँचें
पहले मौजूदा स्थिति जाँचें। AI से ये सवाल पूछें और जवाबों को परखें:
| सवाल | क्या जाँचें |
|---|---|
| “CLAUDE.md के सभी नियम बिंदुवार बताओ।” | सूची में नियम छूट सकते हैं। फ़ाइल लोड होने का प्रदर्शन और वास्तविक बदलाव अलग जाँचें |
| “कोड लिखने से पहले बताओ कि CLAUDE.md के किन नियमों का पालन करोगे।” | इससे महत्त्वपूर्ण शर्तें पहले देख सकते हैं। घोषणा होना या न होना, नियम लागू होने का प्रमाण नहीं |
| “पिछले पाँच संवादों में CLAUDE.md का उल्लंघन करने वाले संभावित काम बताओ।” | इसे स्वयं समीक्षा की शुरुआत मानें। कमांड इतिहास, एग्ज़िट कोड और बनी फ़ाइलों से मिलाएँ |
AI “पढ़ लिया” या “समझ गया” कहे, तब भी निर्देशों को लागू करना अलग सवाल है। लोडिंग के प्रमाण और काम के परिणाम, दोनों जाँचें।
कारण पहचानने के चार चरण
- प्रवेश-बिंदु जाँचें। Claude Code में
/contextके Memory files देखकर CLAUDE.md और नियमों की लोडिंग जाँचें। फ़ाइल सही डायरेक्टरी में है और सेटिंग ने उसे बाहर नहीं किया है, यह भी देखें। सीधे लोड हुई AGENTS.md अपवाद है जो इस सूची में न दिख सकती है; केवल सूची में न होना, उसे न पढ़े जाने का प्रमाण नहीं है। - नियम लागू होने की शर्त पूरी करें। पाथ के अनुसार नियमों के लिए एजेंट से मेल खाती फ़ाइल पढ़वाएँ। संपीड़न के बाद वह फ़ाइल नहीं पढ़ी गई हो, तो नियम अभी दोबारा लोड नहीं हुए होंगे। शुरुआत के निर्देश और किसी खास काम के लिए लोड हुए निर्देश अलग दर्ज करें।
- छोटा, हानिरहित काम आज़माएँ। अस्थायी नमूने पर “बदलने से पहले फ़ाइल का नाम बताओ” और “बाद में टेस्ट कमांड तथा एग्ज़िट कोड बताओ” जैसे नियम लगाकर संपादन कराएँ। परीक्षण के लिए उत्पादन का डेटा मिटाना या प्रकाशन न चुनें। गोपनीय परीक्षण-वाक्य सवाल में ही दे देंगे, तो एजेंट निर्देश फ़ाइल पढ़े बिना उत्तर दे सकता है; उससे लोडिंग नहीं जँचती।
- परिणाम स्वतंत्र रूप से सत्यापित करें। डिफ़ में अनपेक्षित बदलाव देखें, बताए गए टेस्ट वास्तव में चले या नहीं और पर्याप्त मदें जाँची गईं या नहीं, यह जाँचें। एक सफल परीक्षण भविष्य की हर कार्रवाई की गारंटी नहीं है। बदली सेटिंग, टूल का संस्करण और लक्ष्य फ़ाइलें दर्ज करें, फिर परिस्थितियाँ बदलने पर दोबारा जाँचें।
मसलन, एजेंट ने “कमिट से पहले टेस्ट करो” लोड किया, लेकिन टेस्ट नहीं चलाए, तो केवल फ़ाइल की जगह बदलना कारण नहीं सुलझाएगा। कौन-से टेस्ट चलाने हैं यह बताएँ, और उनके परिणाम के बिना कमिट वाला चरण पूरा न मानें। मर्ज से पहले CI जाँच अनिवार्य करने से AI की अपनी रिपोर्ट से अलग प्रमाण भी मिलता है।
संबंधित CLAUDE.md लोडिंग के प्रदर्शन में न दिखे, तो शब्दों पर और ज़ोर देने से पहले शुरुआत की डायरेक्टरी और सेटिंग ठीक करें। लोडिंग की पुष्टि के बाद भी उल्लंघन रहें, तो निर्देश कितने ठोस हैं और जाँच कैसे होती है, यह देखें। इस क्रम से हर असफलता को “AI भूल गया” मानने से बचते हैं।
3. पाँच मिनट में आज़माने योग्य सुधार
1. हमेशा ज़रूरी नियम और ज़रूरत पर पढ़े जाने वाले विवरण अलग रखें
Claude Code की 200 से कम पंक्तियों वाली आधिकारिक सलाह से शुरू करें, लेकिन पंक्तियाँ गिनने के बजाय दोहराव और अनावश्यक व्याख्या घटाएँ। उदाहरण:
- अनिवार्य नियम (10–20 पंक्तियाँ) → CLAUDE.md की शुरुआत में
- सेवा का विस्तृत विनिर्देश → अलग SPEC-xxx.md फ़ाइलों में
- इतिहास और पृष्ठभूमि → docs/ डायरेक्टरी में
विवरण दूसरी फ़ाइल में रखने के बाद प्रवेश-बिंदु फ़ाइल में बताएँ कि किस तरह के काम से पहले क्या पढ़ना है। हर सेशन की सारी सामग्री इम्पोर्ट करते हैं, तो फ़ाइल बाँटने से शुरुआती संदर्भ नहीं घटता। शर्तों के अनुसार निर्देश केवल ज़रूरत पर लोड करने के लिए पाथ-आधारित नियम या Skills इस्तेमाल करें।
2. प्राथमिकता बताने वाले संकेत जोड़ें
महत्त्व बताने वाले संकेत इंसान और AI को मंशा समझने में मदद करते हैं। संकेत अपने आप काम लागू नहीं करवाते। उदाहरण के लिए:
- CRITICAL: उल्लंघन से उत्पादन में हादसा हो सकता है
- MUST: हमेशा आवश्यक
- SHOULD: सामान्यतः अपेक्षित
- NICE TO HAVE: समय मिले तो वैकल्पिक
“CRITICAL: उत्पादन डेटाबेस को नुकसान पहुँचाने वाली क्वेरी के लिए पहले मंज़ूरी चाहिए” से कार्रवाई और मंज़ूरी की शर्त स्पष्ट होती है। बिना अनुमति की कार्रवाई वास्तव में रोकने के लिए परमिशन सेटिंग या काम से पहले की जाँच भी चाहिए।
3. चैट में नियम याद दिलाएँ
सेशन की शुरुआत में जोड़ें: “काम शुरू करने से पहले तीन सबसे महत्त्वपूर्ण नियम बताओ।” इससे समझ जाँचने का अवसर मिलता है, लेकिन टेस्ट चलने की गारंटी नहीं मिलती। बाद में परिणाम भी जाँचें।
4. योजना में सत्यापन की शर्तें शामिल करें
अपने 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 एजेंट के लिए नियम बनाने के सुझाव
टूल की विशिष्ट शर्तों के लिए Cursor नियम दस्तावेज़, GitHub Copilot के कस्टम निर्देश और OpenAI की AGENTS.md मार्गदर्शिका देखें। Copilot के पाथ-आधारित निर्देश *.instructions.md इस्तेमाल करते हैं; हर सुविधा का समर्थन जाँचें। Codex की 32 KiB सीमा डिफ़ॉल्ट संयुक्त बाइट सीमा है, अक्षर या पंक्तियों की संख्या नहीं।
साझा सिद्धांत है “संक्षिप्त, ठोस और स्पष्ट प्राथमिकता वाले निर्देश”। फ़ाइल का नाम और जगह टूल के अनुसार बदलते हैं, लेकिन लिखने के सिद्धांत समान हैं।
6. नियम बनाते समय होने वाली तीन गलतियाँ
1. “कृपया अच्छे तरीके अपनाएँ”
सिर्फ़ यह अनुरोध “अच्छे तरीके” परिभाषित नहीं करता। प्रोजेक्ट में अपनाए तरीके और उनका सत्यापन बताएँ। “उचित टेस्ट करो” के लिए आवश्यक टेस्ट कमांड और उनके असफल होने पर रुकने वाला कार्य-चरण बताएँ।
2. कई फ़ाइलों में एक ही नियम दोहराना
कमिट के एक ही नियम CLAUDE.md, SPEC.md और README.md में हों, तो अपडेट के बाद तीनों प्रतियाँ अलग हो सकती हैं। एक मूल प्रति चुनें और दूसरी फ़ाइलों से उसका लिंक दें।
3. हर जगह “हर हाल में ज़रूरी” लिखना
हर शर्त पर एक जितना ज़ोर देने से प्राथमिकताएँ समझाना कठिन हो जाता है। “CRITICAL” सच में गंभीर परिणाम वाली शर्तों के लिए रखें और बाकी सामान्य भाषा में लिखें। याद रखें कि बहुत अधिक ज़ोर देने से उसका महत्त्व घटता है।
सारांश
नियम न माने जाएँ, तो इस क्रम में जाँचें: लोडिंग की शर्तें → दायरा → विरोधी निर्देश → काम के परिणाम। मूल CLAUDE.md संपीड़न के बाद वापस जुड़ता है, इसलिए केवल संपीड़न को कारण न मानें। संक्षिप्त भाषा, महत्त्व के संकेत और AI समीक्षा सहायक हैं। विश्वसनीय ढंग से जाँची जा सकने वाली शर्तें Hooks या CI में रखें, और अनुमत कार्रवाइयाँ परमिशन सेटिंग से तय करें।
काम पूरा होने का प्रमाण आवश्यक दायरे को जाँचने वाले परिणामों और बनी फ़ाइलों से मिलता है, “पढ़ लिया” के जवाब से नहीं।
अक्सर पूछे जाने वाले सवाल
सवाल 1. CLAUDE.md की सही लंबाई क्या है?
आधिकारिक सलाह है प्रति फ़ाइल 200 से कम पंक्तियाँ। यह न लोडिंग रुकने की सीमा है, न पालन की गारंटी। हर बार ज़रूरी नियम रखें और विवरण अलग करते समय उन्हें पढ़ने की स्पष्ट शर्तें दें। पूरा विवरण वापस इम्पोर्ट करने से शुरुआती संदर्भ नहीं घटता।
सवाल 2. Cursor की .cursorrules इस्तेमाल करें या .cursor/rules/*.mdc?
नया सेटअप हो, तो .cursor/rules/*.mdc इस्तेमाल करें। हर फ़ाइल में एक नियम रखें और glob पैटर्न से उसका दायरा बताएँ। पुरानी .cursorrules एक ही फ़ाइल है जिसे संभालना कठिन हो सकता है।
सवाल 3. क्या लंबे नियमों से सख्ती बढ़ती है?
केवल लंबाई बढ़ाने से नियम सख्त नहीं होते। ज़रूरी शर्तें या उदाहरण मदद कर सकते हैं, लेकिन दोहराव और विरोधाभास न जोड़ें। जाँचें कि क्या लोड होता है और किन शर्तों का वास्तव में सत्यापन हो सकता है।
सवाल 4. एक प्रोजेक्ट में Claude Code और Cursor जैसे कई AI टूल हों तो क्या करें?
साझा नियमों की एक मूल प्रति रखें, और हर टूल के प्रवेश-बिंदु तथा सेटिंग अलग रखें। Codex और Cursor AGENTS.md का समर्थन करते हैं। Claude Code में लोड होने वाली CLAUDE.md से @AGENTS.md इम्पोर्ट करना भी विकल्प है। लेकिन फ़ाइल खोजने का दायरा और बाहर रखने की सेटिंग अलग हैं। प्रोजेक्ट में साझा फ़ाइल रख देने से यह सिद्ध नहीं होता कि हर टूल को वह मिल गई।
सवाल 5. AI कहे “पढ़ लिया”, फिर भी क्या फ़ाइल अनपढ़ी हो सकती है?
सिर्फ़ जवाब से न यह साबित होता है कि फ़ाइल पढ़ी नहीं गई, न यह कि पढ़ी गई। इस लेख के जाँच-चरणों से लोडिंग का प्रदर्शन जाँचें और डिफ़, टेस्ट परिणाम तथा कमांड इतिहास से मिलाएँ।
