Coding agents ஏன் உங்கள் கட்டளைகளைப் புறக்கணிக்கின்றன?

Coding agents உங்கள் அறிவுறுத்தல்களை ஏன் புறக்கணிக்கின்றன

Coding agents உங்கள் அறிவுறுத்தல்களை நான்கு காரணங்களுக்காகப் புறக்கணிக்கின்றன; நீங்கள் கனிவாகப் பேசியது ஒரு காரணமே அல்ல. அந்த விதி context window-ல் இல்லை என்பது முதல் காரணம். ஒரு செயலைச் சரிபார்க்க அந்த விதி மிகவும் தெளிவற்றதாக இருந்தது என்பது இரண்டாவது காரணம். context-ல் இருந்த வேறொன்று அதற்கு முரணாக இருந்தது, பெரும்பாலும் agent இப்பதான் படித்த code-ஆக அது இருக்கும் என்பது மூன்றாவது காரணம். அல்லது, அந்த விதி இன்னும் loaded நிலையில் இருந்தாலும், தற்போதைய உரையாடலுக்கு வெகு தொலைவில் இருப்பதால், அருகில் உள்ள தகவல்களை வைத்து agent செயல்படுகிறது என்பது நான்காவது காரணம்.

ஒவ்வொரு காரணத்திற்கும் தனித்தனி தீர்வுகள் உள்ளன, எனவே முதலில் எதனால் பிரச்சினை என்பதைப் பிரித்தறிவதே முதல் வேலை. பெரிய எழுத்துக்களும் (Capital letters) IMPORTANT என்ற வார்த்தையும் ஒரு நோயறிதல் அல்ல. கீழே உள்ள செயல்பாடுகள் Claude Code-ஐ உதாரணமாகக் கொண்டு விளக்கப்பட்டுள்ளன, ஏனெனில் ஆகஸ்ட் 2026 நிலவரப்படி அதன் loading மற்றும் compaction செயல்பாடுகள் விரிவாக ஆவணப்படுத்தப்பட்டுள்ளன. பிற கருவிகள் விவரங்களில் மாறுபடலாம், ஆனால் அடிப்படைச் செயல்பாடுகள் ஒரே மாதிரியானவை.

முதலில் இரண்டு கலைச்சொற்கள். context window என்பது ஒரு குறிப்பிட்ட turn-ல் model பார்க்கும் உரையின் தொகுப்பாகும்: system prompt, உங்கள் அறிவுறுத்தல் கோப்புகள், உரையாடல் மற்றும் agent படித்த ஒவ்வொரு கோப்பும் இதில் அடங்கும். harness என்பது model-ஐச் சுற்றியுள்ள நிரலாகும்; இது disk-லிருந்து கோப்புகளைப் படித்து அந்தத் தொகுப்பை உருவாக்கும் கருவியாகும். இந்தப் பதிவில் உள்ள பெரும்பாலான புகார்கள் உண்மையில் model-ஐப் பற்றியவை அல்ல, அவை harness-ஐப் பற்றிய புகார்களே.

உங்கள் அறிவுறுத்தல் கோப்பு ஒரு செய்தியே தவிர, அது ஒரு அமைப்பல்ல

ஒரு அறிவுறுத்தல் கோப்பு என்பது configuration அல்ல. runtime-ல் எதையும் வாசித்து CLAUDE.md-ஐ அது அமல்படுத்துவதில்லை. harness அந்த கோப்பை வட்டில் (disk) இருந்து வாசித்து, உரையில் ஒட்டுகிறது. Claude Code-ல் அந்த உள்ளடக்கம் system prompt-க்கு பிறகு ஒரு பயனர் செய்தியாக வழங்கப்படுகிறது. இதன் பொருள், நீங்கள் தட்டச்சு செய்த மற்ற அனைத்தையும் போலவே, உங்கள் விதிகளையும் அந்த மாதிரி (model) பார்க்கிறது.

இதன் விளைவாக ஒரு சங்கடமான சூழல் உருவாகிறது. உங்கள் விதிகள், அந்த விண்டோவில் உள்ள மற்ற அனைத்து உரைப்பகுதிகளுடனும் சமமான நிலையில் போட்டியிடுகின்றன. ஒரு விதி என்பது ஒரு கூற்று. அந்த agent இப்போது திறந்த கோப்பு என்பது ஒரு ஆதாரம். இவை இரண்டும் முரண்படும்போது, பெரும்பாலும் ஆதாரமே வெற்றி பெறுகிறது. எவ்வித பிழையும் (error) காட்டப்படாது, ஏனெனில் மாதிரியின் பார்வையில் அங்கு தவறாக எதுவும் நடக்கவில்லை.

அதிகாரப்பூர்வ ஆவணங்கள் இதைத் தெளிவாகக் கூறுகின்றன: அறிவுறுத்தல் கோப்புகள் சூழலாகவே (context) கருதப்படுகின்றன, அமல்படுத்தப்படும் configuration-ஆக அல்ல. மாதிரி என்ன முடிவெடுத்தாலும் ஒரு செயலைத் தடுக்க, உங்களுக்கு ஒரு hook தேவை, ஒரு வாக்கியம் அல்ல. அந்த வரிகளை நினைவில் கொள்ளுங்கள். இந்தப் பதிவின் இறுதியில் உள்ள பெரும்பாலான தீர்வுகள், ஒரு குறிப்பிட்ட சூழலுக்கு அந்த வரியைப் பயன்படுத்துவதே ஆகும்.

எந்த அறிவுறுத்தல் கோப்புகள் எப்போது ஏற்றப்படுகின்றன

Claude Code நீங்கள் அதைத் தொடங்கிய கோப்பகத்திலிருந்து (directory) கோப்பக மரத்தின் மேல்நோக்கிச் செல்கிறது. கோப்பக அமைப்பின் வேர் (root) முதல் உங்கள் பணி கோப்பகம் வரை உள்ள அனைத்து CLAUDE.md மற்றும் CLAUDE.local.md கோப்புகளும் தொடக்கத்தின்போது முழுமையாக ஏற்றப்படும். அவை அந்த வரிசையிலேயே இணைக்கப்படுகின்றன, எனவே நீங்கள் தொடங்கிய இடத்திற்கு மிக அருகில் உள்ள கோப்பு கடைசியாக வாசிக்கப்படும், மேலும் ஒரே கோப்பகத்திற்குள் .local கோப்பு முதன்மை கோப்பிற்குப் பிறகு சேர்க்கப்படும்.

உங்கள் பணி கோப்பகத்திற்கு கீழே உள்ள துணைக்கோப்பகங்களில் உள்ள கோப்புகள் வித்தியாசமாகச் செயல்படுகின்றன. அவை தொடக்கத்தின்போது ஏற்றப்படுவதில்லை. அந்த கோப்பகத்தில் உள்ள ஒரு கோப்பை ஏஜென்ட் வாசிக்கும்போது அவை ஏற்றப்படுகின்றன. .claude/rules/-ல் உள்ள path scoped விதிகள், paths: frontmatter புலத்தைக் கொண்டிருந்தால், அவையும் அதேபோல்தான் செயல்படுகின்றன: அவை ஒவ்வொரு முறையும் அல்லாமல், பொருத்தமான கோப்பு வாசிக்கப்படும்போது மட்டுமே சூழலுக்குள் (context) நுழைகின்றன.

இந்த ஒரு சிறிய வேறுபாடே பதிவாகும் தோல்விகளில் பெரும்பகுதிக்குக் காரணமாகிறது. நீங்கள் packages/api/CLAUDE.md-ல் ஒரு விதியைச் சேர்க்கிறீர்கள், API பற்றி ஒரு கேள்வியைக் கேட்கிறீர்கள், ஆனால் packages/api/-க்குக் கீழே உள்ள எந்தக் கோப்பையும் திறக்காமலேயே ஏஜென்ட் பதிலளிக்கிறது. அந்த விதி புறக்கணிக்கப்படவில்லை; அது அந்தச் சூழலில் இருக்கவே இல்லை. உங்கள் களஞ்சியம் (repository) monorepo-வில் உள்ள ஒவ்வொரு தொகுப்பு அறிவுறுத்தல் கோப்புகள் மூலம் வழிகாட்டுதலைப் பிரித்திருந்தால், ஒவ்வொரு முறையும் சரிபார்க்க வேண்டிய முதல் விஷயம் இதுதான்.

ஏற்றப்படும்போது ஏற்படும் மற்றொரு சிக்கல், "ஏஜென்ட் எனது அறிவுறுத்தல்களைப் புறக்கணித்தது" என்று கூறப்படும் புகார்களில் மிகவும் பொதுவானது: Claude Code CLAUDE.md-ஐ வாசிக்கும், AGENTS.md-ஐ அல்ல. AGENTS.md-ஐத் தரப்படுத்திய மற்றும் CLAUDE.md இல்லாத ஒரு களஞ்சியம் Claude Code-க்கு ஏற்றுவதற்கு எதையும் தருவதில்லை. இதற்கான ஆதரவு பாலம் (bridge) ஒரு CLAUDE.md ஆகும், அதன் முதல் வரி @AGENTS.md என்று இருக்க வேண்டும். இது தொடக்கத்தின்போது கோப்பை இறக்குமதி செய்யும், மேலும் கீழே Claude-க்கான குறிப்பிட்ட குறிப்புகளைச் சேர்க்கலாம். கூடுதலாகச் சேர்க்க எதுவும் இல்லாதபோது symlink-ம் வேலை செய்யும். அந்த கோப்பில் எதைச் சேர்க்க வேண்டும் என்பதைத் தீர்மானிப்பது ஒரு தனிப்பட்ட கேள்வி, அது மனித ஆவணங்களிலிருந்து ஏஜென்ட் அறிவுறுத்தல்களைப் பிரித்தல் பகுதியில் விவரிக்கப்பட்டுள்ளது.

கோப்பை மீண்டும் எழுதுவதற்கு முன் அது ஏற்றப்பட்டதை உறுதிப்படுத்தவும்

ஏஜென்ட் கோப்பைக் காண முடியும் என்பதற்கு ஆதாரம் கிடைக்கும் வரை அதன் உள்ளடக்கத்தை மாற்ற வேண்டாம். இதற்கு இரண்டு சோதனைகள் உள்ளன, எளிமையான சோதனையை முதலில் செய்யவும்.

Session-க்குள் /context கட்டளையை இயக்கவும். இது தற்போதைய விண்டோவை வகை வாரியாகப் பிரித்துக் காட்டும், மேலும் Memory files பட்டியலில் உண்மையில் ஏற்றப்பட்ட ஒவ்வொரு அறிவுறுத்தல் கோப்பின் பெயரும் இருக்கும். அந்தப் பட்டியலில் ஒரு கோப்பு இல்லை என்றால், அது உரையாடலில் இல்லை என்று பொருள்; எனவே அதற்குள் நீங்கள் எழுதும் எதற்கும் எந்தப் பயனும் இருக்காது. /memory கோப்பு இருப்பிடங்களைப் பட்டியலிட்டு அவற்றை எடிட் செய்யத் திறக்கும், இதில் இன்னும் உருவாக்கப்படாத கோப்புகளும் அடங்கும்.

மேலும் உறுதியான பதிலைப் பெற, ஏற்றப்பட்ட கோப்புகளைப் பதிவு செய்யவும் (log). ஒவ்வொரு முறை CLAUDE.md அல்லது விதிகள் கோப்பு (rules file) சூழலுக்குள் நுழையும்போதும் InstructionsLoaded hook event தூண்டப்படும். அதன் matcher அந்த ஏற்றம் ஏன் நடந்தது என்பதைக் கூறும்: session_start, nested_traversal, path_glob_match, include, அல்லது compact. இதை .claude/settings.json-ல் சேர்க்கவும்:

{
  "hooks": {
    "InstructionsLoaded": [
      {
        "matcher": "nested_traversal",
        "hooks": [
          {
            "type": "command",
            "command": "cat >> /tmp/instructions-loaded.log"
          }
        ]
      }
    ]
  }
}

இந்த hook அதன் payload-ஐ standard input வழியாக JSON வடிவில் பெறுகிறது, எனவே cat முழுப் பதிவையும் இணைக்கும் (append). நீங்கள் பணிபுரியும் போது tail -f /tmp/instructions-loaded.log மூலம் அதைக் கவனிக்கவும். இந்த event-ன் exit status புறக்கணிக்கப்படும், எனவே hook-ஆல் கவனிக்க மட்டுமே முடியும், தடுக்க முடியாது. நீங்கள் எதிர்பார்த்த session-ல் உங்கள் nested கோப்பு அந்த log-ல் ஒருமுறை கூடத் தோன்றவில்லை என்றால், மீண்டும் எழுதுவதை நிறுத்துங்கள். கோப்பு வைக்கப்பட்ட இடத்தில் தான் சிக்கல் உள்ளது.

நீண்ட session-ல் உங்கள் விதிகள் எவ்வாறு பாதிக்கப்படுகின்றன

இங்கு இரண்டு தனித்தனி விளைவுகள் ஏற்படுகின்றன, அவற்றுக்கு வெவ்வேறு தீர்வுகள் தேவை.

தொலைவு (Distance). முதல் turn-ல் கூறப்பட்ட ஒரு விதி, 90-வது turn-லும் context window-க்குள் இருக்கும். ஆனால், இப்போது நீங்கள் செய்து கொண்டிருக்கும் செயலுக்கு மிகவும் பொருத்தமான மற்றும் சமீபத்திய 90 turn-களின் உரையாடல்களுடன் அது போட்டியிட வேண்டியிருக்கும். இதை configuration மூலம் சரிசெய்ய முடியாது, ஆனால் அளவிட முடியும். ஒரு புதிய session-ல் அதே பணியைச் செய்து பாருங்கள். அங்கே விதி சரியாகச் செயல்பட்டு, நீண்ட session-ன் இறுதியில் தோல்வியடைந்தால், அதற்குத் தொலைவே காரணம்.

சுருக்கம் (Compaction). Window நிரம்பும்போது, harness இதுவரை நடந்த உரையாடலைச் சுருக்கி, அந்தச் சுருக்கத்திலிருந்து தொடரும். சுருக்கத்தை உருவாக்குபவர் எதை முக்கியமாகக் கருதினாரோ அதுவே எஞ்சியிருக்கும்; நீங்கள் எதை முக்கியமாகக் கருதுகிறீர்களோ அது அல்ல. Claude Code ஒவ்வொரு mechanism-ன் முடிவையும் ஆவணப்படுத்துகிறது, அவற்றுக்கிடையேயான வேறுபாடுகள் அதிகம். Project root CLAUDE.md மற்றும் scope இல்லாத விதிகள் compaction-க்கு பிறகு disk-லிருந்து மீண்டும் சேர்க்கப்படும். Auto memory disk-லிருந்து மீண்டும் சேர்க்கப்படும். paths: frontmatter கொண்ட விதிகள், தொடர்புடைய கோப்பு மீண்டும் வாசிக்கப்படும் வரை இழக்கப்படும். Subdirectory-களில் உள்ள nested CLAUDE.md கோப்புகள், அந்த subdirectory-ல் உள்ள ஒரு கோப்பு மீண்டும் வாசிக்கப்படும் வரை இழக்கப்படும்.

உங்கள் அறிவுறுத்தல்களை அந்த அட்டவணையின்படி வரிசைப்படுத்தினால், எவை எளிதில் பாதிக்கப்படக்கூடியவை என்பது தெளிவாகும். நீங்கள் chat-ல் மட்டும் தட்டச்சு செய்த விதி, session-ல் மிகவும் பலவீனமானது: சுருக்கத்தில் அது தற்செயலாக இருந்தால் மட்டுமே அது நீடிக்கும். packages/api/CLAUDE.md-ல் உள்ள விதி அடுத்த நிலையில் உள்ளது, ஏனெனில் அது ஒருமுறை ஏற்றப்பட்டு, சுருக்கப்பட்டு, அந்த directory-ல் அடுத்த முறை வாசிக்கும்போது மட்டுமே மீண்டும் வரும். Project root கோப்பில் உள்ள விதியே மிகவும் உறுதியானது, ஏனெனில் அது ஒவ்வொரு முறையும் disk-லிருந்து மீண்டும் வாசிக்கப்படுகிறது.

எனவே, ஒரு அறிவுறுத்தல் முழு session-க்கும் பொருந்த வேண்டும் என்றால், அது paths: frontmatter இல்லாமல் project root கோப்பில் இருக்க வேண்டும். மற்ற அனைத்தும் நீங்கள் திட்டமிட்டுச் செய்ய வேண்டிய சமரசங்கள். Context window-ல் எவை இருக்க வேண்டும் என்பதை நிர்வகித்தல் பகுதி, focus argument-உடன் /compact மற்றும் தொடர்பில்லாத பணிகளுக்கு இடையே /clear ஆகியவற்றைப் பற்றி விளக்குகிறது. இவை இரண்டுமே, உங்கள் விதிகள் எவை என்பதைச் சுருக்கத்தை உருவாக்குபவர் எவ்வளவு அடிக்கடி தீர்மானிக்கிறார் என்பதை மாற்றியமைக்கின்றன.

ஏன் சுற்றியுள்ள குறியீடு விதியை விட மேலோங்குகிறது

மக்கள் அடிக்கடி விவரிக்கும் மற்றும் குறைவாகவே கண்டறியும் தோல்வி இதுவாகும். தரவுத்தள அணுகல் repository layer வழியாகச் செல்ல வேண்டும் என்று உங்கள் கோப்பு கூறுகிறது. ஆனால், முகவர் (agent) நேரடியாக ORM-ஐ (object relational mapper) அழைக்கும் ஒரு handler-ஐ எழுதுகிறார். உங்கள் பாணி (style) நிராகரிக்கப்படவில்லை. ஆதாரங்களின் அடிப்படையில் அது புறக்கணிக்கப்பட்டது.

ஒரு விதி விருப்பத்தை மட்டுமே விவரிக்கிறது. குறியீடு ஒரு நடைமுறையை நிரூபிக்கிறது. முகவர் திருத்தப்போகும் தொகுப்பில் உள்ள மூன்று கோப்புகளைத் திறக்கும்போது, அவை அனைத்தும் நேரடியாக ORM-ஐ அழைத்தால், சூழலில் ஒரு பக்கம் சுருக்கமான விதியும், மறுபக்கம் மூன்று உறுதியான, சமீபத்திய, பணிக்கு ஏற்ற உதாரணங்களும் இருக்கும். உள்ளூர் அமைப்பைப் பின்பற்றுவது பொதுவாகச் சரியான செயலாகும். ஆனால், சூழலுக்குத் தெரியாத ஒரு விஷயம் உங்களுக்குத் தெரியும் என்பதால், இங்கே அது தவறாகிறது: அந்த கோப்புகள் பழையவை (legacy).

எனவே, அதை விதியிலேயே எழுதுங்கள். தங்களுக்கு எதிரான ஆதாரங்களைச் சுட்டிக்காட்டும் விதிகள் மட்டுமே உண்மையான repository-ல் நிலைத்து நிற்கும். வெறும் விருப்பத்தை மட்டும் கூறும் விதிகள் நிலைக்காது.

புதிய தரவுத்தள அணுகல் app/repositories/ வழியாகச் செல்ல வேண்டும். app/legacy/-க்குக் கீழ் உள்ள கோப்புகள் இன்னும் நேரடியாக ORM-ஐ அழைக்கின்றன. அது பழைய குறியீடு, தற்போதைய நடைமுறை அல்ல. அதைப் பின்பற்ற வேண்டாம்.

இரண்டாவது வாக்கியம் முக்கியப் பணியைச் செய்கிறது. முகவர் எதைக் கண்டறியப் போகிறார் என்பதையும், அதைக் கண்டறிவதற்கு முன்பே அதை எப்படிப் புரிந்துகொள்ள வேண்டும் என்பதையும் அது கூறுகிறது. உங்கள் repository-ல் உள்ள குறியீடு விதிகளுக்கு முரணாக இருக்கும் எந்தவொரு இடத்திலும் இதே திருத்தத்தைப் பயன்படுத்தலாம்: உங்கள் வரலாறு பின்பற்றாத ஒரு commit பாணி, உங்கள் தொகுப்பில் பாதி புறக்கணிக்கும் ஒரு test அமைப்பு, புதிய குறியீட்டில் மட்டுமே கடைபிடிக்கப்படும் ஒரு import மரபு. குறியீடு கோப்புடன் முரண்படும் இடங்களில், அந்த முரண்பாட்டை கோப்பிலேயே குறிப்பிடுங்கள்.

தெளிவற்ற விதியைச் சரிபார்க்க முடியாது, எனவே அதைப் பின்பற்றவும் முடியாது

"சுத்தமான குறியீட்டை எழுதுங்கள்." "அதிகப்படியான பொறியியல் வேண்டாம்." "எளிமையாக வைத்திருங்கள்." "migration-களை கவனமாகக் கையாளுங்கள்." இவை எதையுமே ஒரு குறிப்பிட்ட செயலுக்கு எதிராக, முகவர் (agent) மூலமாகவோ அல்லது உங்கள் மூலமாகவோ சோதிக்க முடியாது. ஒரு விதியைச் சரிபார்க்க முடியாதபோது, முகவர் யூகிக்கிறார்; நீங்களும் அந்த யூகத்தை உங்கள் உணர்வின் அடிப்படையில் மதிப்பிடுகிறீர்கள்.

உங்கள் கோப்பில் உள்ள ஒவ்வொரு வரிக்கும் இந்தச் சோதனையைப் பயன்படுத்துங்கள். விதி மீறப்படும்போது non-zero exit status-ஐத் தரும் shell command-ஐ எழுதுங்கள். உங்களால் அந்த command-ஐ எழுத முடியாவிட்டால், அந்த விதியைச் சரிபார்க்க முடியாது என்று அர்த்தம். இந்த இணைகளை ஒப்பிட்டுப் பாருங்கள்:

• சரிபார்க்க முடியாதது: "functions-ஐச் சிறியதாக வைத்திருங்கள்." சரிபார்க்கக்கூடியது: "60 வரிகளுக்கு மேல் உள்ள function-க்கு மேலே, அதற்கான காரணத்தை விளக்கும் comment இருக்க வேண்டும்."
• சரிபார்க்க முடியாதது: "மாற்றங்களைச் சோதியுங்கள்." சரிபார்க்கக்கூடியது: "npm test-ஐ இயக்கி, ஒரு பணியை முடித்ததாகக் குறிக்கும் முன் தோல்வி அடைந்த எண்ணிக்கையை (failure count) பதிவிடுங்கள்."
• சரிபார்க்க முடியாதது: "கோப்புகளை ஒழுங்கமைத்து வைத்திருங்கள்." சரிபார்க்கக்கூடியது: "HTTP handlers src/api/handlers/-ல் இருக்க வேண்டும். அந்த directory-ல் வேறு எதுவும் இருக்கக்கூடாது."
• சரிபார்க்க முடியாதது: "குறியீட்டைச் சரியாக வடிவமைக்கவும்." சரிபார்க்கக்கூடியது: ".ts கோப்புகளில் 2 space indentation-ஐப் பயன்படுத்துங்கள்."

அளவு என்பது வேறு வடிவில் வரும் அதே சிக்கல்தான். Claude Code-ன் வழிகாட்டுதல், ஒரு instruction கோப்பிற்கு 200 வரிகளுக்குக் குறைவாக இருக்க வேண்டும் என்று பரிந்துரைக்கிறது; நீண்ட கோப்புகள் விதிகளின் பின்பற்றுதலைக் குறைக்கும் என்று நேரடியாகக் குறிப்பிடுகிறது. 700 வரிகள் கொண்ட கோப்பு என்பது உறுதியான அறிவுறுத்தல் அல்ல. அது 700 வரிகள் கொண்ட கூற்றுகள்; இதில் ஒன்றுக்கொன்று முரண்பட அதிக வாய்ப்புகள் உள்ளன. மேலும், ஒவ்வொரு முறையும் இது உங்கள் window-ல் கணக்கிடப்படுகிறது, இது உங்கள் token பயன்பாட்டில் நேரடியாகத் தெரியும். ஒவ்வொரு விதியும் ஒரு தலைப்பின் கீழ் இருக்குமாறு கோப்பை வடிவமைப்பது, வாசகர் எளிதாகப் பார்க்க உதவும்; இது முகவர் செயல்படக்கூடிய வகையில் instruction கோப்பை எழுதுதல் என்பதில் விவரிக்கப்பட்டுள்ளது.

பத்து நிமிடங்களில் கண்டறிவது எப்படி

இவற்றை வரிசைப்படி இயக்கவும். கடைசி படிக்குத் தாவுவதுதான், வேலை செய்யாத விதிகளின் நீண்ட பட்டியலை உருவாக்குவதற்கு வழிவகுக்கும்.

1. கோப்பு ஏற்றப்பட்டதை உறுதிப்படுத்தவும். /context-ஐ இயக்கி, Memory கோப்புகளின் பட்டியலைப் படிக்கவும். கோப்பு அங்கு இல்லை என்றால், அதன் இருப்பிடத்தைச் சரிசெய்து நிறுத்தவும். இந்தப் பட்டியலில் உள்ள மற்றவை இப்போதைக்கு பொருந்தாது.
2. புதிய அமர்வில் மீண்டும் நிகழ்த்தவும். புதிய அமர்வைத் தொடங்கி, விதியைத் தூண்டும் மிகச்சிறிய பணியைச் செய்யவும். நீண்ட அமர்வில் தோல்வியடைந்து, இதில் சரியாக இருந்தால், அது தூரம் அல்லது சுருக்கம் (compaction) தொடர்பான சிக்கல். இதிலும் தோல்வியடைந்தால், விதியே சிக்கலாக உள்ளது என்று பொருள்.
3. போட்டியிடும் விதிகளை நீக்கவும். ஏற்கனவே விதியைப் பின்பற்றும் குறியீடு உள்ள ஒரு கோப்பகத்தில் அதே மாற்றத்தைக் கோரவும். இணக்கம் (compliance) திரும்பக் கிடைத்தால், சுற்றியுள்ள குறியீடு உங்கள் விதியை மீறியுள்ளது என்று பொருள்.
4. முரண்பாட்டைத் தேடவும். ஒரே செயலுக்கு இரண்டு கோப்புகள் வெவ்வேறு வழிகாட்டுதல்களை வழங்குவது ஆவணப்படுத்தப்பட்ட தோல்வியாகும்: மாதிரி (model) ஏதேனும் ஒன்றை தன்னிச்சையாகத் தேர்வு செய்யலாம், அது குறித்து உங்களுக்குத் தெரிவிக்காது.
5. சரிபார்க்கக்கூடியதாக மாற்றி மீண்டும் சோதிக்கவும். ஒரு குறிப்பிட்ட பாதை மற்றும் நிபந்தனையுடன் விதியை மீண்டும் எழுதவும். இணக்கத்தில் பெரிய முன்னேற்றம் ஏற்பட்டால், உங்கள் வாக்கிய அமைப்பே சிக்கலாக இருந்துள்ளது என்று பொருள்.

படி 4 ஒரு கட்டளை மட்டுமே. நீங்கள் திருத்திய கோப்பை மட்டும் பார்க்காமல், அந்தத் தலைப்பு தொடர்பான அனைத்து அறிவுறுத்தல் மூலங்களையும் Grep செய்யவும்:

grep -rni "migration" --include="CLAUDE.md" --include="CLAUDE.local.md" .
grep -rni "migration" .claude/rules/ ~/.claude/CLAUDE.md ~/.claude/rules/ 2>/dev/null

இரண்டு கோப்புகளில் வெவ்வேறு தகவல்கள் இருப்பதுதான் உங்கள் பிழை. ஒன்றைத் நீக்கவும். வலுவான சொற்களைப் பயன்படுத்தி அவற்றை வரிசைப்படுத்த முயற்சிக்காதீர்கள், ஏனெனில் வரிசைப்படுத்தும் இயந்திரம் (ranking engine) எதுவும் இல்லை.

தீர்வுகளின் வரிசைமுறை, அதன் தாக்கம் மற்றும் முக்கியத்துவத்தின் அடிப்படையில்

கீழே உள்ள ஒவ்வொரு படியும் அதற்கு முந்தைய படியை விட அதிக தாக்கத்தை ஏற்படுத்துகிறது, அதே சமயம் அதை அமைப்பதற்கான செலவும் அதிகம். ஒரு விதியை மாற்றி அமைப்பது எளிது என்றால், மேலிருந்து தொடங்கவும். ஒரு விதி மிக முக்கியமானது மற்றும் அதில் தவறு நடப்பதை அனுமதிக்க முடியாது என்றால், அடுத்தடுத்த நிலைகளுக்குச் செல்லவும்.

1. விதியைத் தெளிவாக வரையறுக்கவும். ஒரு path, command அல்லது நிபந்தனையைக் குறிப்பிடவும். முன்னரே காட்டியபடி, repository-ல் முகவர் (agent) கண்டறியக்கூடிய எதிர்-ஆதாரங்களைச் சேர்க்கவும். இது இலவசமானது மற்றும் பெரும்பாலான சிக்கல்களைத் தீர்க்கும்.
2. விதியை அது கட்டுப்படுத்தும் இடத்திற்கு அருகிலேயே வைக்கவும். ஒரு nested CLAUDE.md, .claude/rules/-ல் உள்ள path scoped விதி, அல்லது கோப்பின் மேலேயே ஒரு comment-ஐச் சேர்க்கவும். இதனால், குறியீட்டைப் படிக்கும்போதே அந்த விதியும் கவனத்திற்கு வரும். இதில் உள்ள சமரசத்தை ஏற்கவும்: இவ்வாறு ஏற்றப்படும் எந்தவொரு விதியும் அடுத்த compaction-ன் போது நீக்கப்பட்டு, மீண்டும் பொருந்தும் போது ஏற்றப்படும்.
3. விதிமுறையை ஒரு hook-க்குள் கொண்டு வரவும். உரை (prose) கோரிக்கை மட்டுமே விடுக்கிறது. ஆனால், ஒரு hook முடிவெடுக்கிறது. Hooks என்பது நிலையான lifecycle நிகழ்வுகளின் போது குறியீடாக இயங்குபவை; இவை model-ன் முடிவுகளைச் சாராமல் செயல்படும்.
4. விதியை ஒரு deterministic கருவியிடம் ஒப்படைத்துவிட்டு, உரை விளக்கத்தை நீக்கவும். Formatting, import order, line length, தடைசெய்யப்பட்ட imports, commit message வடிவம் போன்றவை. ruff format, prettier --write, eslint, ஒரு pre-commit hook. Formatter எப்போதும் சரியாகச் செயல்படும் மற்றும் tokens-ஐச் செலவிடாது. ஆனால், வாக்கியங்கள் எப்போதும் சரியாக இருப்பதில்லை மற்றும் ஒவ்வொரு முறையும் tokens-ஐச் செலவிடும்.

படி 3-ன் முழு விளக்கம். migration கோப்புகளை முகவர் (agent) திருத்தக்கூடாது என்று வைத்துக்கொள்வோம். இதை .claude/settings.json-ல் சேர்க்கவும்:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/guard-migrations.sh"
          }
        ]
      }
    ]
  }
}

மேலும் இதை .claude/hooks/guard-migrations.sh-ல் சேர்க்கவும்:

#!/usr/bin/env bash
set -euo pipefail

path=$(jq -r '.tool_input.file_path // empty')

case "$path" in
  */migrations/*)
    echo "Files under migrations/ are written by hand. Stop and ask first." >&2
    exit 2
    ;;
esac

exit 0

chmod +x .claude/hooks/guard-migrations.sh-ஐ இயக்கவும், பின்னர் புதிய session-ஐத் தொடங்கி migrations/-ன் கீழ் உள்ள கோப்பைத் திருத்தும்படி முகவரிடம் கேட்கவும். அந்தத் திருத்தம் நிராகரிக்கப்படும் மற்றும் உங்கள் செய்தி அதற்கான காரணமாகத் திரும்ப வரும். PreToolUse-ல் உள்ள exit status 2, tool call இயங்குவதற்கு முன்பே அதைத் தடுத்துவிடும், மேலும் உங்கள் stderr உரை, தடுக்கும் செய்தியாக model-க்கு அனுப்பப்படும். ${CLAUDE_PROJECT_DIR} என்பது project root-ஐக் குறிக்கும், எனவே முகவர் எந்த directory-ல் இருந்தாலும் இந்த hook வேலை செய்யும். முகவர் அந்த விதியை ஒப்புக்கொள்ளவோ, நினைவில் வைத்திருக்கவோ அல்லது context-ல் வைத்திருக்கவோ வேண்டிய அவசியமில்லை. திருத்தம் நடக்காது.

எந்தவிதமான தர்க்கமும் இல்லாத நேரடித் தடையை உருவாக்க, உங்கள் settings-ல் உள்ள permissions.deny அதே வேலையைச் செய்யும், இதற்கு எந்த script-ஐயும் பராமரிக்க வேண்டியதில்லை. மேலும் permission modes உங்களிடம் கேட்காமலேயே எதை இயக்க வேண்டும் என்பதைத் தீர்மானிக்கும். ஒரு அறிவுறுத்தல் பயனர் செய்தியில் இல்லாமல், system prompt மட்டத்திலேயே இருக்க வேண்டும் என்றால், --append-system-prompt அதை அங்கு வைக்கும். இருப்பினும், ஒவ்வொரு முறையும் அதை அனுப்ப வேண்டியிருக்கும், இது interactive பணிகளை விட script-களுக்கு மிகவும் பொருத்தமானது.

நீங்கள் கட்டளையிட முடியாதவை

இதில் எந்தப் பகுதி உங்களது பொறுப்பு என்பதில் தெளிவாக இருங்கள். கோப்புகளின் இருப்பிடம், சொற்றொடர் அமைப்பு, கோப்புகளுக்கு இடையிலான முரண்பாடுகள் மற்றும் கோப்பின் அளவு ஆகியவை ஆசிரியரின் சிக்கல்கள், அவற்றை ஆசிரியரே சரிசெய்ய வேண்டும். மீதமுள்ளவை AI மாதிரியின் செயல்பாடுகள்; சிறந்த சொற்களைப் பயன்படுத்துவதால் அவை நீங்காது.

ஒப்புதல் என்பது இணக்கம் அல்ல. ஒரு ஏஜென்ட் ஒரு விதியை ஒப்புக்கொள்ளும், அதை உங்களிடம் சரியாகத் திரும்பக் கூறும், ஆனால் இரண்டு tool calls-க்கு பிறகு அதை மீறும். அந்த ஒப்புதலுக்கு எந்த மதிப்பும் இல்லை, அது எதையும் முன்கூட்டியே தீர்மானிக்காது. அதை ஒரு தீர்வாகக் கருதாதீர்கள், அதை ஒரு சோதனையாகவும் எண்ணாதீர்கள்.

சில பழக்கங்கள் மாறாதவை. கருத்துகளைச் (comments) சேர்ப்பது, தற்காப்பு பிழை கையாளுதலை (defensive error handling) சேர்ப்பது, நிறைவுச் சுருக்கத்தை எழுதுவது, அடுத்த கட்டமாகச் செய்ய வேண்டிய வெளிப்படையான கட்டளையை இயக்குவது போன்றவை இதில் அடங்கும். ஒரு விதி இவற்றைத் தடை செய்தாலும், அவை மீண்டும் நிகழலாம்; பூஜ்ஜியத்திற்குப் பதிலாக குறைந்த விகிதத்தில் நிகழும். உங்கள் சொந்த விகிதத்தை நீங்கள் அளவிடலாம்: ஒரே பணியைப் புதிய அமர்வுகளில் பத்து முறை இயக்கி, எத்தனை முறை விதிகள் மீறப்படுகின்றன என்று எண்ணுங்கள். அந்த எண்ணிக்கை பூஜ்ஜியமாக இருக்க வேண்டிய இடத்தில், அந்த விதியை prompt-லிருந்து நீக்கிவிட வேண்டும்.

உங்கள் சொந்த அமர்வே ஒரு உதாரணமாகிறது. 12-வது சுற்றில் ஏஜென்ட் விதியை மீறியபோது நீங்கள் அதைத் தட்டிக்கேட்கவில்லை என்றால், அந்த மீறல் ஒரு முன்னுதாரணமாக context-ல் பதிந்துவிடும்; அது விதியை விட மிக சமீபத்தியது. ஒரு மீறலைக் கண்டவுடன் அதைச் சரிசெய்யுங்கள். சரிசெய்யப்படாத ஒரு மீறல், அந்த அமர்வின் எஞ்சிய பகுதிக்குத் தவறான வழிகாட்டுதலை வழங்கும்.

ஒரு instruction கோப்பு என்பது பாதுகாப்பு எல்லை (security boundary) அல்ல. இது செயல்பாட்டை வடிவமைக்கிறதே தவிர, அதை அமல்படுத்துவதில்லை. தவறு நடந்தால் அதிக விலை கொடுக்க வேண்டிய விஷயங்கள், நற்சான்றிதழ்கள் (credentials) அல்லது அழிவுகரமான கட்டளைகள் போன்றவை permissions அல்லது hook-களின் கீழ் வர வேண்டும். ரகசியங்களை ஏஜென்ட்டின் அணுகலுக்கு அப்பால் வைத்திருத்தல் என்பது தரவுகளுக்கும் இதே கொள்கையைப் பயன்படுத்துகிறது: ஒரு கோப்பை வாசிக்க வேண்டாம் என்று ஏஜென்டிடம் கேட்பதற்குப் பதிலாக, அந்தக் கோப்பை வாசிக்க முடியாதபடி அமைப்பதே சிறந்தது.

சுருக்கமாகச் சொன்னால்: கோப்பு ஏற்றப்பட்டதை உறுதிப்படுத்துங்கள், விதியைச் சரிபார்க்கக்கூடியதாக மாற்றுங்கள், அதை அது நிர்வகிக்கும் விஷயத்திற்கு அருகிலேயே வையுங்கள். தவறு நடக்கும் விகிதம் இன்னும் முக்கியமானது என்றால், அதை உரை வடிவில் (prose) வைக்காதீர்கள். ஒரு ஏஜென்ட் புறக்கணிக்க முடியாத விதி என்பது, ஏஜென்டிடம் கேட்கப்படாத விதியே ஆகும்.

FAQ

Claude Code ஏன் எனது CLAUDE.md கோப்பைப் புறக்கணிக்கிறது?

அது புறக்கணிக்கப்பட்டதா என்று முடிவு செய்வதற்கு முன், அது ஏற்றப்பட்டதா என்பதைச் சரிபார்க்கவும். /context கட்டளையை இயக்கி, Memory files பட்டியலைப் பார்க்கவும்; அதில் இடம்பெறாத கோப்பு உரையாடலில் இல்லை என்று பொருள். அறிவுறுத்தல் கோப்புகள் (instruction files) system prompt-க்கு பிறகு user message-ஆக அனுப்பப்படுகின்றன. இவை கட்டாயப்படுத்தப்பட்ட configuration-ஆக இல்லாமல், context-ஆகவே கருதப்படுகின்றன, எனவே இவை கண்டிப்பாகப் பின்பற்றப்படும் என்பதற்கு உத்தரவாதம் இல்லை. பெரும்பாலான சிக்கல்கள் பின்வரும் நான்கு காரணங்களில் ஒன்றாகவே இருக்கும்: கோப்பு முகவர் (agent) படிக்காத ஒரு subdirectory-ல் இருக்கலாம், இரண்டு கோப்புகள் முரண்பட்டு ஏதேனும் ஒன்றை மாதிரி (model) தன்னிச்சையாகத் தேர்ந்தெடுத்திருக்கலாம், விதி மிகவும் தெளிவற்றதாக இருக்கலாம், அல்லது சுற்றியுள்ள குறியீடு (code) விதியிற்கு நேர்மாறான செயல்பாட்டைக் கொண்டிருக்கலாம்.

அமர்வின் நடுவில் அறிவுறுத்தல் கோப்பைத் திருத்தினால் மாற்றம் ஏற்படுமா?

உரையாடலில் ஏற்கனவே உள்ள நகலுக்கு மாற்றம் ஏற்படாது. உங்கள் working directory-க்கு மேலே உள்ள கோப்புகள் தொடக்கத்திலேயே முழுமையாக ஏற்றப்படும், எனவே மாதிரி (model) வைத்திருக்கும் உரை (text) தொடக்க நேரத்தில் இருந்த உரையாகவே இருக்கும். திருத்தத்தைப் பெற, புதிய அமர்வைத் தொடங்கவும் அல்லது சாதாரண file tools மூலம் கோப்பைப் படிக்குமாறு முகவரிடம் கேட்கவும்; இது தற்போதைய பதிப்பை ஒரு புதிய செய்தியாக உரையாடலில் சேர்க்கும். Compaction-க்கு பிறகு, project root கோப்பு வட்டில் (disk) இருந்து மீண்டும் படிக்கப்படும், எனவே அந்த நேரத்தில் புதிய பதிப்பு வந்து சேரும்.

root CLAUDE.md மற்றும் nested CLAUDE.md முரண்படும்போது எந்தக் கோப்பு எடுத்துக்கொள்ளப்படும்?

எதுவும் உறுதியாகச் சொல்ல முடியாது. கண்டறியப்பட்ட கோப்புகள் ஒன்றையொன்று மேலெழுதாமல் (override), ஒன்றன் பின் ஒன்றாக இணைக்கப்படுகின்றன (concatenate). இவை filesystem root-லிருந்து உங்கள் working directory வரை வரிசைப்படுத்தப்படுகின்றன, எனவே மிக அருகிலுள்ள கோப்பு கடைசியாகப் படிக்கப்படுகிறது. முரண்பாடுகளைத் தீர்க்கும் முன்னுரிமை அமைப்பு (precedence engine) எதுவும் இல்லை, மேலும் முரண்பாடான விதிகள் தன்னிச்சையாகத் தீர்க்கப்படலாம் என்று Claude Code ஆவணங்கள் கூறுகின்றன. Nested கோப்புகளை அவை நிர்வகிக்கும் பாதையைக் குறிப்பிடும் கூடுதல் விதிகளாக எழுதவும்; முன்னுரிமை பெற முயற்சிப்பதற்குப் பதிலாக முரண்பாட்டை நீக்கிவிடவும்.

/compact கட்டளைக்குப் பிறகு எனது அறிவுறுத்தல்கள் நீடிக்கின்றனவா?

அவை எவ்வாறு ஏற்றப்பட்டன என்பதைப் பொறுத்தது. Project root CLAUDE.md, unscoped விதிகள் மற்றும் auto memory ஆகியவை compaction-க்கு பிறகு வட்டில் (disk) இருந்து மீண்டும் செலுத்தப்படுகின்றன. paths: frontmatter கொண்ட விதிகள் மற்றும் subdirectories-ல் உள்ள nested CLAUDE.md கோப்புகள், மீண்டும் படிக்கப்படும் வரை இழக்கப்படும். நீங்கள் chat-ல் தட்டச்சு செய்தவை, summariser அதைத் தக்கவைத்திருந்தால் மட்டுமே நீடிக்கும். ஒரு விதி முழு அமர்விலும் நீடிக்க வேண்டுமெனில், அதை paths: frontmatter இல்லாமல் project root கோப்பில் வைக்கவும்.

ஒரு விதியை எப்போது உரைக்கு (prose) பதிலாக hook-ஆக மாற்ற வேண்டும்?

சரிபார்ப்பு தீர்மானிக்கக்கூடியதாக (deterministic) இருக்கும்போதும், தவறவிடுதலின் விலை ஒரு சிறிய script-ஐ எழுதுவதை விட அதிகமாக இருக்கும்போதும் hook-ஐப் பயன்படுத்தவும். கோப்புப் பாதை கட்டுப்பாடுகள் (file path restrictions), commit-க்கு முந்தைய கட்டாயக் கட்டளைகள் மற்றும் தடைசெய்யப்பட்ட tool calls ஆகியவை இதற்குப் பொருந்தும். Status 2-உடன் வெளியேறும் ஒரு PreToolUse hook, tool call-ஐத் தடுத்து, உங்கள் stderr உரையை அதற்கான காரணமாக மாதிரிக்குத் திருப்பி அனுப்பும். எனவே, விதி context-ல் இருந்தாலும் இல்லாவிட்டாலும் இது செயல்படும். Formatter அல்லது linter மூலம் தீர்மானிக்கக்கூடிய எதையும் அந்த tool-களிடமே விட்டுவிட்டு, அறிவுறுத்தல் கோப்பிலிருந்து முழுமையாக நீக்கிவிடவும்.