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

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

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

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

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

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

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

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

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

எந்த instruction கோப்புகள் எப்போது ஏற்றப்படுகின்றன

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-வில் உள்ள ஒவ்வொரு தொகுப்பிற்கான instruction கோப்புகள் என வழிகாட்டுதல்களைப் பிரித்திருந்தால், ஒவ்வொரு முறையும் முதலில் இதைத்தான் சரிபார்க்க வேண்டும்.

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

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

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

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

துல்லியமான பதிலைப் பெற, ஏற்றப்படும் கோப்புகளை log செய்யவும். ஒவ்வொரு முறை CLAUDE.md அல்லது ஒரு rules கோப்பு context-க்குள் நுழையும்போதும் 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 முழு பதிவையும் இணைக்கும். நீங்கள் பணிபுரியும் போது tail -f /tmp/instructions-loaded.log மூலம் இதைக் கவனிக்கவும். இந்த event-ன் exit status புறக்கணிக்கப்படும், எனவே hook-ஆல் கவனிக்க மட்டுமே முடியும், தடுக்க முடியாது. நீங்கள் எதிர்பார்க்கும் session-ல் உங்கள் nested கோப்பு அந்த log-ல் ஒருமுறை கூட வரவில்லை என்றால், மீண்டும் எழுதுவதை நிறுத்திவிடவும். கோப்பு வைக்கப்பட்ட இடத்தில் தான் பிரச்சினை உள்ளது.

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

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

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

சுருக்கம் (Compaction). Window நிரம்பும்போது, harness இதுவரை நடந்த உரையாடலைச் சுருக்கி, அந்தச் சுருக்கத்திலிருந்து தொடரும். சுருக்கத்தை உருவாக்குபவர் எதை முக்கியமாகக் கருதினாரோ அதுவே எஞ்சியிருக்கும்; நீங்கள் எதை முக்கியமாகக் கருதுகிறீர்களோ அது அல்ல. Claude Code ஒவ்வொரு mechanism-ன் முடிவுகளையும் ஆவணப்படுத்துகிறது, அவற்றுக்கிடையேயான வேறுபாடுகள் அதிகம். Project root CLAUDE.md மற்றும் scope செய்யப்படாத விதிகள், ஒரு சுருக்கத்திற்குப் பிறகு 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-வில் எவை இருக்க வேண்டும் என்பதை நிர்வகித்தல் பகுதி, /compact-ஐ ஒரு focus argument-உடனும், /clear-ஐ தொடர்பில்லாத பணிகளுக்கு இடையிலும் கையாள்கிறது. இவை இரண்டுமே, உங்கள் விதிகள் எவை என்பதைச் சுருக்கத்தை உருவாக்குபவர் எவ்வளவு அடிக்கடி தீர்மானிக்க வேண்டும் என்பதை மாற்றுகின்றன.

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

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

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

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

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

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

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

"சுத்தமான குறியீட்டை எழுதுங்கள்." "அதிகப்படியான பொறியியல் (over-engineer) செய்யாதீர்கள்." "எளிமையாக வைத்திருங்கள்." "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-ஐப் பயன்படுத்துங்கள்."

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

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

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

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

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

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

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 வரிசை, வரியின் நீளம், தடைசெய்யப்பட்ட 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) இயங்குவதற்கு முன்பே அதைத் தடுத்துவிடும். உங்கள் stderr உரை, தடுக்கும் செய்தியாக மாதிரிக்கு (model) அனுப்பப்படும். ${CLAUDE_PROJECT_DIR} என்பது project root-ஐக் குறிக்கும், எனவே முகவர் எந்த directory-ல் இருந்தாலும் இந்த hook சரியாகச் செயல்படும். முகவர் அந்த விதியை ஒப்புக்கொள்ளவோ, நினைவில் வைத்திருக்கவோ அல்லது context-ல் வைத்திருக்கவோ வேண்டிய அவசியமில்லை. அந்தத் திருத்தம் நடக்காது.

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

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

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

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

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

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

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

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

FAQ

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

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

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

ஏற்கனவே உரையாடலில் உள்ள நகலுக்கு மாற்றம் ஏற்படாது. உங்கள் working directory-க்கு மேலே உள்ள கோப்புகள் தொடக்கத்திலேயே முழுமையாக ஏற்றப்படும், எனவே ஏஜென்ட் வைத்திருக்கும் உரை (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-க்கு பிறகு வட்டில் இருந்து மீண்டும் உள்ளே செலுத்தப்படும். paths: frontmatter கொண்ட விதிகள் மற்றும் subdirectories-ல் உள்ள nested CLAUDE.md கோப்புகள், மீண்டும் ஒருமுறை கோப்பு படிக்கப்படும் வரை இழக்கப்படும். நீங்கள் chat-ல் தட்டச்சு செய்தவை, summariser அதைத் தக்கவைத்துக் கொண்டால் மட்டுமே நீடிக்கும். ஒரு விதி முழு அமர்விலும் நீடிக்க வேண்டும் என்றால், அதை paths: frontmatter இல்லாமல் project root கோப்பில் வைக்கவும்.

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

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