coding agents آپ کی ہدایات کیوں نظرانداز کرتے ہیں

آپ کے coding agents آپ کی ہدایات کو نظرانداز کیوں کرتے ہیں

coding agents آپ کی ہدایات کو 4 وجوہات کی بنا پر نظرانداز کرتے ہیں، اور ان میں سے کوئی وجہ یہ نہیں کہ آپ بہت مؤدب تھے۔ اصول کبھی context window میں شامل ہی نہیں ہوا۔ اصول اتنا مبہم تھا کہ اس کے مقابل کسی action کی جانچ نہیں کی جا سکتی تھی۔ context میں موجود کسی دوسری چیز نے اس کی تردید کی، عموماً اس code نے جسے agent نے ابھی پڑھا تھا۔ یا اصول ابھی بھی loaded ہے، لیکن موجودہ turn سے بہت پیچھے ہے، اور agent قریب موجود مواد کی بنیاد پر کام کر رہا ہے۔

ہر وجہ کا حل الگ ہے، اس لیے پہلا کام یہ ہے کہ ان وجوہات میں فرق کیا جائے۔ بڑے حروف اور IMPORTANT کا لفظ تشخیص نہیں ہوتے۔ ذیل میں mechanics کی وضاحت کے لیے Claude Code کو عملی مثال کے طور پر استعمال کیا گیا ہے، کیونکہ August 2026 تک اس کے loading اور compaction behaviour کی تفصیلی documentation دستیاب ہے۔ دیگر tools کی تفصیلات مختلف ہو سکتی ہیں، لیکن مجموعی طور پر ان کا behaviour یہی ہوتا ہے۔

پہلے 2 اصطلاحات سمجھ لیں۔ context window اس text block کو کہتے ہیں جسے model کسی مخصوص turn میں دیکھتا ہے: system prompt، آپ کی instruction files، conversation، اور ہر وہ file جسے agent نے پڑھا ہو۔ harness وہ program ہے جو model کے گرد کام کرتا ہے؛ یہی disk سے files پڑھ کر اس block کو assemble کرتا ہے۔ اس post کی تقریباً ہر شکایت دراصل model کے بجائے harness کے بارے میں شکایت ہے۔

آپ کی instruction file ایک پیغام ہے، setting نہیں

instruction file، configuration نہیں ہوتی۔ runtime میں کوئی چیز CLAUDE.md کو پڑھ کر اسے نافذ نہیں کرتی۔ harness ڈسک سے file پڑھتا ہے اور اس کا متن conversation میں شامل کر دیتا ہے۔ Claude Code میں یہ مواد system prompt کے بعد user message کے طور پر پہنچتا ہے۔ اس کا مطلب ہے کہ model آپ کے rules کو اسی طرح دیکھتا ہے جیسے آپ کا لکھا ہوا کوئی اور متن۔

اس کا ایک پریشان کن نتیجہ نکلتا ہے۔ آپ کے rules window میں موجود ہر دوسرے متن سے مقابلہ کرتے ہیں، اور سب کو یکساں اہمیت حاصل ہوتی ہے۔ rule ایک دعویٰ ہے۔ agent نے ابھی جو file کھولی ہے، وہ evidence ہے۔ جب دونوں میں اختلاف ہو تو اکثر evidence غالب آ جاتا ہے۔ کوئی error بھی ظاہر نہیں ہوتا، کیونکہ model کے نقطۂ نظر سے کچھ غلط نہیں ہوا۔

official documentation یہ بات واضح طور پر کہتی ہے: instruction files کو context سمجھا جاتا ہے، enforced configuration نہیں۔ کسی action کو model کے فیصلے سے قطع نظر روکنے کے لیے sentence نہیں، hook درکار ہوتا ہے۔ اس اصول کو یاد رکھیں۔ اس post کے آخر میں موجود زیادہ تر fixes اسی اصول کو مخصوص cases پر لاگو کرتے ہیں۔

کون سی ہدایاتی فائلیں لوڈ ہوتی ہیں، اور کب

Claude Code اس ڈائریکٹری سے directory tree میں اوپر کی طرف جاتا ہے جہاں سے آپ نے اسے شروع کیا تھا۔ filesystem root سے working directory تک موجود ہر CLAUDE.md اور CLAUDE.local.md لانچ کے وقت مکمل طور پر لوڈ ہوتی ہے۔ انہیں اسی ترتیب سے یکجا کیا جاتا ہے، اس لیے آپ کے لانچ کرنے کی جگہ کے قریب ترین فائل آخر میں پڑھی جاتی ہے، اور ایک ہی ڈائریکٹری میں .local فائل کو main فائل کے بعد شامل کیا جاتا ہے۔

آپ کی working directory کے نیچے موجود subdirectories کی فائلیں مختلف انداز میں کام کرتی ہیں۔ وہ لانچ کے وقت لوڈ نہیں ہوتیں۔ جب agent اس ڈائریکٹری میں موجود کوئی فائل پڑھتا ہے، تب وہ لوڈ ہوتی ہیں۔ .claude/rules/ میں موجود path scoped rules بھی اسی طرح کام کرتے ہیں، اگر ان میں paths: frontmatter field موجود ہو: matching فائل پڑھے جانے پر یہ context میں شامل ہوتے ہیں، ہر turn پر نہیں۔

یہی فرق رپورٹ ہونے والی بہت سی failures کی وجہ واضح کرتا ہے۔ آپ packages/api/CLAUDE.md میں ایک rule رکھتے ہیں، API کے بارے میں سوال کرتے ہیں، اور agent packages/api/ کے اندر کوئی فائل کھولے بغیر جواب دے دیتا ہے۔ rule کو نظرانداز نہیں کیا گیا تھا۔ وہ context میں موجود ہی نہیں تھا۔ اگر آپ کا repository monorepo میں ہر package کے لیے الگ instruction files میں guidance تقسیم کرتا ہے، تو ہر بار سب سے پہلے یہی چیز چیک کریں۔

ایک اور loading trap ہے، اور یہ "agent نے میری instructions نظرانداز کر دیں" کی سب سے عام صورت ہے: Claude Code AGENTS.md نہیں بلکہ CLAUDE.md پڑھتا ہے۔ ایسا repository جو AGENTS.md کو standard بناتا ہے اور جس میں CLAUDE.md موجود نہیں، Claude Code کو load کرنے کے لیے کچھ بھی نہیں دیتا۔ معاون bridge ایک CLAUDE.md ہے جس کی پہلی line @AGENTS.md ہوتی ہے۔ یہ launch کے وقت فائل import کرتا ہے، جبکہ اس کے نیچے Claude سے متعلق اضافی notes شامل کی جا سکتی ہیں۔ اگر شامل کرنے کے لیے کوئی اضافی مواد نہ ہو تو symlink بھی کام کرتا ہے۔ ابتدا ہی میں یہ طے کرنا کہ اس فائل میں کیا شامل ہونا چاہیے، ایک الگ سوال ہے، جس کی وضاحت agent instructions کو انسانی documentation سے الگ کرنے میں کی گئی ہے۔

فائل کو دوبارہ لکھنے سے پہلے تصدیق کریں کہ وہ load ہو چکی ہے

الفاظ میں کوئی تبدیلی اس وقت تک نہ کریں جب تک آپ کے پاس یہ ثبوت نہ ہو کہ agent فائل دیکھ سکتا ہے۔ اس کے لیے دو checks ہیں، اور پہلے آسان check کو چلائیں۔

session کے اندر /context چلائیں۔ یہ موجودہ window کو category کے لحاظ سے دکھاتا ہے، اور Memory files کی فہرست میں ہر وہ instruction file درج ہوتی ہے جو حقیقتاً load ہوئی ہو۔ جو فائل اس فہرست میں موجود نہ ہو، وہ conversation میں شامل نہیں ہے؛ اس لیے اس کے اندر لکھی گئی کوئی بھی چیز مؤثر نہیں ہو سکتی۔ /memory فائلوں کے locations کی فہرست بناتا ہے اور انہیں editing کے لیے کھولتا ہے، ان فائلوں سمیت جو ابھی موجود نہیں ہیں۔

زیادہ قابل اعتماد تصدیق کے لیے loads کو log کریں۔ InstructionsLoaded hook event ہر بار فعال ہوتا ہے جب کوئی CLAUDE.md یا rules file context میں شامل ہوتی ہے، اور اس کا matcher بتاتا ہے کہ load کیوں ہوا: 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 پورا record شامل کر دیتا ہے۔ کام کے دوران اسے tail -f /tmp/instructions-loaded.log کے ذریعے monitor کریں۔ اس event کا exit status نظرانداز کیا جاتا ہے، اس لیے hook صرف مشاہدہ کر سکتا ہے، load کو روک نہیں سکتا۔ اگر nested file اس session کے دوران log میں کبھی ظاہر نہ ہو جس میں آپ کو اس کے load ہونے کی توقع تھی، تو rewording روک دیں۔ مسئلہ file placement کا ہے۔

طویل session آپ کے rules کے ساتھ کیا کرتی ہے

یہاں دو الگ اثرات لاگو ہوتے ہیں، اور ان کے لیے مختلف اقدامات درکار ہیں۔

فاصلہ۔ turn 1 پر بیان کیا گیا rule، turn 90 پر بھی context window میں موجود ہوتا ہے، لیکن اب وہ حالیہ اور آپ کے موجودہ کام سے زیادہ متعلقہ 90 turns کے متن کا مقابلہ کر رہا ہوتا ہے۔ آپ اس اثر کو configuration کے ذریعے ختم نہیں کر سکتے، لیکن اس کی پیمائش کر سکتے ہیں۔ یہی task ایک نئی session میں چلائیں۔ اگر rule وہاں برقرار رہتا ہے اور طویل session میں کافی آگے جا کر ناکام ہو جاتا ہے، تو اس کی وجہ فاصلہ ہے۔

Compaction۔ جب window بھر جاتی ہے تو harness اب تک کی conversation کا خلاصہ بناتا ہے اور اسی summary سے کام جاری رکھتا ہے۔ جو کچھ باقی رہتا ہے، وہ summariser کے نزدیک اہم چیزیں ہوتی ہیں، اور یہ ضروری نہیں کہ آپ کے نزدیک بھی اہم ہوں۔ Claude Code ہر mechanism کے نتائج کی دستاویز فراہم کرتا ہے، اور ان میں نمایاں فرق ہے۔ Project root CLAUDE.md اور غیر scoped rules، compaction کے بعد disk سے دوبارہ inject کیے جاتے ہیں۔ Auto memory بھی disk سے دوبارہ inject ہوتی ہے۔ paths: frontmatter والے rules اس وقت تک ضائع رہتے ہیں جب تک matching file دوبارہ نہ پڑھی جائے۔ Subdirectories میں موجود nested CLAUDE.md files اس وقت تک ضائع رہتی ہیں جب تک اسی subdirectory کی کوئی file دوبارہ نہ پڑھی جائے۔

اپنی instructions کو اس table کے مطابق درجہ دیں، تو fragility کی ترتیب واضح ہو جاتی ہے۔ جو rule آپ نے صرف chat میں type کیا ہو، وہ session میں سب سے زیادہ fragile ہوتا ہے: وہ صرف اسی صورت برقرار رہتا ہے جب summary میں اتفاقاً شامل ہو جائے۔ packages/api/CLAUDE.md میں موجود rule اگلے درجے پر ہے، کیونکہ وہ ایک بار load ہوتا ہے، summary میں غائب ہو جاتا ہے، اور اسی directory میں اگلی read کے وقت واپس آتا ہے۔ Project root file میں موجود rule سب سے زیادہ durable ہوتا ہے، کیونکہ اسے ہر بار disk سے دوبارہ پڑھا جاتا ہے۔

اس لیے اگر کوئی instruction پوری session میں برقرار رہنی چاہیے تو اسے project root file میں، بغیر paths: frontmatter کے، رکھیں۔ باقی تمام اختیارات ایک tradeoff ہیں، جن کا فیصلہ آپ کو دانستہ طور پر کرنا چاہیے۔ context window میں برقرار رہنے والی چیزوں کا انتظام میں /compact کو focus argument کے ساتھ اور /clear کو غیر متعلقہ tasks کے درمیان بیان کیا گیا ہے۔ یہ دونوں چیزیں اس امر کو بدلتی ہیں کہ summariser کو آپ کے rules کے بارے میں فیصلہ کرنے کا موقع کتنی بار ملتا ہے۔

اردگرد موجود code، rule سے زیادہ مؤثر کیوں ہوتا ہے

یہ وہ failure ہے جسے لوگ سب سے زیادہ بیان کرتے ہیں، لیکن سب سے کم diagnose کرتے ہیں۔ آپ کی file میں لکھا ہے کہ database access، repository layer کے ذریعے ہو۔ agent ایسا handler لکھ دیتا ہے جو ORM (object relational mapper) کو براہِ راست call کرتا ہے۔ آپ کو style کی بنیاد پر نظرانداز نہیں کیا گیا۔ شواہد نے آپ کی ہدایت کو مات دے دی۔

rule کسی ترجیح کو بیان کرتا ہے۔ code ایک ترجیح کا عملی نمونہ دکھاتا ہے۔ جب agent اس module کی تین files کھولتا ہے جس میں وہ ترمیم کرنے والا ہے، اور تینوں میں ORM کو براہِ راست call کیا گیا ہو، تو context میں ایک طرف ایک abstract جملہ ہوتا ہے، جبکہ دوسری طرف تین concrete، حالیہ اور task سے مطابقت رکھنے والی مثالیں ہوتی ہیں۔ مقامی pattern کو copy کرنا عموماً درست عمل ہوتا ہے۔ یہاں یہ صرف اس لیے غلط ہے کہ آپ ایک ایسی بات جانتے ہیں جو context نہیں جانتا: یہ files legacy ہیں۔

اس لیے rule میں یہ بات واضح طور پر لکھیں۔ جو rules اپنے خلاف موجود شواہد کا ذکر کرتے ہیں، وہ حقیقی repository میں بھی مؤثر رہتے ہیں۔ جو rules صرف ایک عمومی ترجیح بیان کرتے ہیں، وہ مؤثر نہیں رہتے۔

نیا database access app/repositories/ کے ذریعے ہو۔ app/legacy/ کے تحت موجود files اب بھی ORM کو براہِ راست call کرتی ہیں۔ یہ پرانا code ہے، pattern نہیں۔ اسے copy نہ کریں۔

اصل کام دوسرا جملہ کرتا ہے۔ یہ agent کو پہلے ہی بتا دیتا ہے کہ اسے کیا ملنے والا ہے اور اسے کیسے سمجھنا ہے۔ یہی اصلاح ہر اس rule پر لاگو ہوتی ہے جس کی repository کھلے طور پر مخالفت کرتی ہو: ایسا commit style جس پر آپ کی history عمل نہ کرتی ہو، ایسا test layout جسے آپ کی آدھی test suite نظرانداز کرتی ہو، یا ایسا import convention جو صرف نئے code میں موجود ہو۔ جہاں بھی code، file سے متفق نہ ہو، file میں اس اختلاف کو واضح کریں۔

ایک مبہم rule کی جانچ نہیں ہو سکتی، اس لیے اس پر عمل بھی نہیں کیا جا سکتا

"صاف code لکھیں۔" "ضرورت سے زیادہ engineering نہ کریں۔" "اسے سادہ رکھیں۔" "Migrations میں احتیاط کریں۔" ان میں سے کسی بھی بات کو agent یا آپ کسی مخصوص action کے خلاف test نہیں کر سکتے۔ جس agent کو ایسی rule دی جائے جسے وہ اپنے output کے خلاف check نہ کر سکے، وہ اندازہ لگا رہا ہے، اور آپ اس اندازے کی درجہ بندی احساس کی بنیاد پر کر رہے ہیں۔

یہ test اپنی file کی ہر line پر لاگو کریں۔ ایسی shell command لکھیں جو rule ٹوٹنے پر non-zero exit کرے۔ اگر آپ وہ command نہیں لکھ سکتے تو rule checkable نہیں ہے۔ ان جوڑوں کا موازنہ کریں:

• Checkable نہیں: "Functions چھوٹے رکھیں۔" Checkable: "60 lines سے طویل function کے اوپر ایک comment ہونا چاہیے جس میں بتایا گیا ہو کہ وہ طویل کیوں ہے۔"
• Checkable نہیں: "اپنی تبدیلیوں کو test کریں۔" Checkable: "Task کو مکمل کہنے سے پہلے npm test چلائیں اور failure count paste کریں۔"
• Checkable نہیں: "Files کو منظم رکھیں۔" Checkable: "HTTP handlers src/api/handlers/ میں ہونے چاہییں۔ اس directory میں کوئی اور چیز نہیں ہونی چاہیے۔"
• Checkable نہیں: "Code کو درست طور پر format کریں۔" Checkable: ".ts files میں 2 space indentation استعمال کریں۔"

"ضرورت سے زیادہ engineering نہ کریں" وہ rule ہے جسے لوگ سب سے پہلے ترک کر دیتے ہیں، کیونکہ اس کی اصلاح مختصر جملہ نہیں بلکہ طویل وضاحت ہوتی ہے: یہ واضح کرنا کہ کام کرنے والی سب سے چھوٹی تبدیلی سے حقیقی طور پر کیا مراد ہے agent کو ایسے criteria فراہم کرتا ہے جن کے مقابلے میں وہ اپنے diff کی خود جانچ کر سکتا ہے۔

Size کا مسئلہ بھی یہی ہے، صرف مختلف شکل میں۔ Claude Code کی guidance ہر instruction file کے لیے 200 lines سے کم رہنے کا ہدف دیتی ہے اور براہِ راست بیان کرتی ہے کہ طویل files adherence کم کرتی ہیں۔ 700 lines کی file زیادہ مضبوط instruction نہیں ہوتی۔ یہ claims کی 700 lines ہوتی ہیں، جن میں ایک دوسرے سے متصادم ہونے کے زیادہ امکانات ہوتے ہیں، اور ہر turn میں یہ آپ کے window میں شمار ہوتی ہیں، جو آپ کے token usage میں براہِ راست ظاہر ہوتا ہے۔ File کو اس طرح structure کرنا کہ ہر rule ایسے heading کے تحت ہو جسے reader scan کر سکے، ایسی instruction file لکھنے میں شامل ہے جس پر agent عمل کر سکے۔

دس منٹ میں اس کی تشخیص کیسے کریں

ان کمانڈز کو اسی ترتیب سے چلائیں۔ آخری مرحلے پر براہِ راست جانے سے عموماً rules کی ایک طویل فائل بن جاتی ہے جس میں سخت ہدایات ہوتی ہیں، لیکن مسئلہ پھر بھی حل نہیں ہوتا۔

1. تصدیق کریں کہ یہ load ہوئی ہے۔ /context چلائیں اور Memory files کی فہرست دیکھیں۔ اگر فائل موجود نہیں ہے تو location درست کریں اور رک جائیں۔ اس فہرست میں موجود کوئی اور مرحلہ ابھی لاگو نہیں ہوتا۔
2. نئے session میں دوبارہ پیدا کریں۔ نیا session شروع کریں اور سب سے چھوٹا task دیں جس سے rule لاگو ہونا چاہیے۔ اگر یہ مختصر session میں کام کرے لیکن طویل session میں ناکام ہو، تو مسئلہ distance یا compaction میں ہو سکتا ہے۔ اگر یہاں بھی ناکام ہو، تو مسئلہ خود rule میں ہے۔
3. متبادل ہدایات ہٹا دیں۔ اسی change کے لیے ایسی directory میں درخواست کریں جس کا موجودہ code پہلے ہی rule کی پیروی کرتا ہو۔ اگر compliance واپس آ جائے، تو اردگرد کا code آپ کے جملے پر غالب آ رہا تھا۔
4. تضاد تلاش کریں۔ ایک ہی behaviour کے بارے میں مختلف guidance دینے والی دو فائلیں documented failure ہیں۔ model کسی ایک کو بےترتیب منتخب کر سکتا ہے، اور یہ نہیں بتائے گا کہ اس نے ایسا کیا۔
5. اسے قابلِ جانچ بنائیں اور دوبارہ test کریں۔ rule کو concrete path اور condition کے ساتھ دوبارہ لکھیں۔ compliance میں نمایاں اضافہ اس بات کی علامت ہے کہ وجہ phrasing تھی۔

Step 4 کے لیے ایک command کافی ہے۔ موضوع کے بارے میں ہر instruction source میں grep کریں، صرف اس فائل میں نہیں جسے آپ edit کر رہے تھے:

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

دو فائلوں میں مختلف ہدایات ملنا ہی آپ کا bug ہے۔ ایک فائل delete کریں۔ انہیں زیادہ سخت wording کے ذریعے ترجیح دینے کی کوشش نہ کریں، کیونکہ اس کے لیے کوئی ranking engine موجود نہیں ہے۔

نفاذ کے لحاظ سے اصلاحات

ذیل کا ہر قدم اس سے اوپر والے قدم کے مقابلے میں زیادہ مؤثر ہے اور اسے ترتیب دینے میں زیادہ لاگت آتی ہے۔ جب کسی rule کو دوبارہ لکھنا آسان ہو تو اوپر سے شروع کریں۔ جیسے ہی کوئی rule اتنا اہم ہو جائے کہ کبھی کبھار ہونے والی خلاف ورزیاں قابل قبول نہ رہیں، نیچے والے قدم پر جائیں۔

1. Rule کو واضح بنائیں۔ کسی path، command یا condition کا نام دیں۔ وہ متبادل evidence بھی شامل کریں جو agent کو repository میں ملے گا، جیسا کہ پہلے دکھایا گیا ہے۔ اس کی کوئی لاگت نہیں آتی اور یہ حیرت انگیز تعداد میں مسائل حل کرتا ہے۔
2. Rule کو اس چیز کے قریب لے جائیں جس پر یہ لاگو ہوتا ہے۔ مثلاً nested CLAUDE.md، .claude/rules/ میں path-scoped rule، یا خود file کے شروع میں comment۔ اس طرح rule اسی read میں آتا ہے جس میں متعلقہ code پڑھا جاتا ہے۔ اس tradeoff کو قبول کریں: اس طریقے سے load ہونے والی چیز اگلی compaction پر context سے نکل جاتی ہے اور اگلی matching read پر واپس آتی ہے۔
3. Enforcement کو hook میں منتقل کریں۔ Prose درخواست کرتی ہے۔ Hook فیصلہ کرتا ہے۔ Hooks مقررہ lifecycle events پر code کے طور پر چلتے ہیں اور model کے نتیجے سے قطع نظر لاگو ہوتے ہیں۔
4. Rule کسی deterministic tool کے حوالے کریں اور prose حذف کر دیں۔ Formatting، import order، line length، ممنوع imports اور commit message کی ساخت۔ ruff format، prettier --write، eslint، یا pre-commit hook۔ Formatter ہر بار درست ہوتا ہے اور کوئی token استعمال نہیں کرتا۔ جملہ زیادہ تر اوقات درست ہوتا ہے، لیکن ہر turn پر tokens استعمال کرتا ہے۔

Step 3 مکمل طور پر

فرض کریں کہ agent کو migration files میں کبھی ترمیم نہیں کرنی چاہیے۔ اسے .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 شروع کریں اور agent سے migrations/ کے اندر کسی file میں ترمیم کرنے کو کہیں۔ ترمیم مسترد ہو جائے گی اور آپ کا message وجہ کے طور پر واپس آئے گا۔ PreToolUse پر exit status 2 tool call کو چلنے سے پہلے روک دیتا ہے، اور آپ کا stderr متن model کو blocking message کے طور پر دیا جاتا ہے۔ ${CLAUDE_PROJECT_DIR} project root تک resolve ہوتا ہے، اس لیے hook اس directory سے قطع نظر کام کرتا ہے جس میں agent موجود ہو۔ Agent کو rule سے اتفاق کرنے، اسے یاد رکھنے یا اسے اب بھی context میں رکھنے کی ضرورت نہیں ہوتی۔ ترمیم نہیں ہوتی۔

منطق کے بغیر flat prohibition کے لیے، آپ کی settings میں permissions.deny یہی کام کسی script کو maintain کیے بغیر کرتا ہے، اور permission modes طے کرتے ہیں کہ آپ سے پوچھے بغیر کیا چلایا جائے۔ اگر کسی instruction کا system prompt level پر رہنا واقعی ضروری ہو، user message میں نہیں، تو --append-system-prompt اسے وہاں رکھتا ہے۔ تاہم اسے ہر invocation پر pass کرنا ضروری ہے، اس لیے یہ interactive کام کے مقابلے میں scripts کے لیے زیادہ موزوں ہے۔

جس چیز کی ہدایت دے کر اصلاح نہیں کی جا سکتی

واضح کریں کہ اس معاملے کا کون سا حصہ آپ کی ذمہ داری ہے۔ جگہ، عبارت، فائلوں کے درمیان تضادات، اور فائل کا سائز مصنف کے مسائل ہیں، اور ان کے حل بھی مصنف کو کرنے چاہییں۔ باقی حصہ model کا رویہ ہے، اور بہتر الفاظ اسے ختم نہیں کریں گے۔

اتفاق compliance نہیں ہے۔ کوئی agent کسی rule کو تسلیم کرے گا، اسے درست طور پر دہرا دے گا، اور دو tool calls کے بعد اسی rule کی خلاف ورزی کرے گا۔ تسلیم کرنے میں کوئی لاگت نہیں آتی اور اس سے کسی نتیجے کی پیش گوئی نہیں ہوتی۔ اسے اصلاح نہ سمجھیں اور نہ ہی test شمار کریں۔

کچھ عادات مستقل رہتی ہیں۔ Comments شامل کرنا، defensive error handling شامل کرنا، اختتامی summary لکھنا، اور اگلا واضح command چلانا۔ ایسے rule کے تحت بھی یہ عادات واپس آتی ہیں جو انہیں منع کرتا ہو؛ شرح کم ہوتی ہے، صفر نہیں۔ آپ اپنی شرح ناپ سکتے ہیں: یہی task نئی sessions میں 10 مرتبہ چلائیں اور خلاف ورزیوں کی تعداد گنیں۔ جہاں یہ تعداد صفر ہونی چاہیے، وہاں rule کو prompt سے نکالنا ہوگا۔

آپ کی اپنی session ایک مثال بن جاتی ہے۔ اگر agent نے turn 12 پر rule توڑا اور آپ نے اسے نظرانداز کر دیا، تو وہ خلاف ورزی context میں demonstration کے طور پر شامل ہو جاتی ہے، اور rule کے مقابلے میں کہیں زیادہ تازہ ہوتی ہے۔ خلاف ورزی نظر آتے ہی اسے درست کریں۔ درست نہ کی گئی خلاف ورزی session کے باقی حصے کو یہی طرز سکھاتی ہے۔

Instruction file security boundary نہیں ہوتی۔ یہ رویے کی سمت متعین کرتی ہے، اسے enforce نہیں کرتی۔ ایسی چیزیں جن میں غلطی مہنگی پڑ سکتی ہے، مثلاً credentials یا destructive commands، permissions یا hook کے دائرے میں ہونی چاہییں۔ agent سے secrets دور رکھنا data کے لیے بھی یہی اصول لاگو کرتا ہے: agent کو کسی file کو نہ پڑھنے کی ہدایت نہ دیں، بلکہ اس file کو پڑھنے کے قابل ہی نہ بنائیں۔

مختصر بات یہ ہے: ثابت کریں کہ file load ہو گئی ہے، rule کو قابلِ جانچ بنائیں، اسے اس چیز کے قریب رکھیں جس پر وہ لاگو ہوتا ہے، اور جب miss rate پھر بھی اہم ہو تو اسے prose سے باہر لے جائیں۔ جس rule کو agent نظرانداز نہیں کر سکتا، وہ ایسا rule ہے جو agent سے کبھی مانگا ہی نہیں گیا۔

FAQ

Claude Code میری CLAUDE.md کو نظرانداز کیوں کرتا ہے؟

نظرانداز کیے جانے کا نتیجہ اخذ کرنے سے پہلے تصدیق کریں کہ فائل load ہوئی تھی۔ /context چلائیں اور Memory files کی فہرست دیکھیں؛ جس فائل کا نام وہاں موجود نہ ہو، وہ conversation میں شامل نہیں ہے۔ Instruction files، system prompt کے بعد user message کے طور پر بھیجی جاتی ہیں اور enforced configuration کے بجائے context سمجھی جاتی ہیں، اس لیے مکمل compliance کی سخت ضمانت نہیں ہوتی۔ زیادہ تر حقیقی صورتیں چار میں سے ایک ہوتی ہیں: فائل ایسی subdirectory میں ہے جہاں سے agent نے کبھی نہیں پڑھا، دو فائلیں ایک دوسرے سے متصادم ہیں اور model نے من مانی طور پر ایک کو منتخب کر لیا، rule اتنا مبہم ہے کہ اسے کسی action کے خلاف چیک نہیں کیا جا سکتا، یا اردگرد کا code اس rule کے برعکس عمل دکھاتا ہے۔

session کے دوران instruction file میں ترمیم کرنے سے کیا کچھ تبدیل ہوتا ہے؟

conversation میں پہلے سے موجود copy کے لیے نہیں۔ آپ کی working directory سے اوپر موجود فائلیں launch کے وقت مکمل طور پر load ہوتی ہیں، اس لیے model کے پاس موجود متن launch کے وقت والا متن ہوتا ہے۔ ترمیم شامل کرنے کے لیے نئی session شروع کریں، یا agent سے کہیں کہ وہ اپنے معمول کے file tools کے ذریعے فائل پڑھے؛ اس طرح موجودہ version ایک fresh message کے طور پر conversation میں شامل ہو جائے گا۔ compaction کے بعد project root file کو disk سے دوبارہ پڑھا جاتا ہے، اس لیے اس وقت نیا version بھی شامل ہو جاتا ہے۔

جب root CLAUDE.md اور nested file میں اختلاف ہو تو کون سی فائل مؤثر ہوتی ہے؟

قابلِ اعتماد طور پر کوئی بھی نہیں۔ Discovered files کو ایک دوسرے کو override کرنے کے بجائے context میں concatenate کیا جاتا ہے۔ انہیں filesystem root سے working directory تک ترتیب دیا جاتا ہے، اس لیے قریب ترین فائل صرف آخر میں پڑھی جاتی ہے۔ Contradictions حل کرنے والا کوئی precedence engine موجود نہیں، اور Claude Code کی documentation کے مطابق متضاد rules من مانی طور پر resolve ہو سکتے ہیں۔ Nested files کو ایسی additions کے طور پر لکھیں جن میں وہ path درج ہو جس پر وہ لاگو ہوتی ہیں، اور contradiction کو فوقیت دینے کی کوشش کے بجائے اسے حذف کریں۔

کیا میری instructions /compact کے بعد برقرار رہتی ہیں؟

یہ اس بات پر منحصر ہے کہ وہ کیسے load ہوئی تھیں۔ Project root CLAUDE.md، unscoped rules اور auto memory، compaction کے بعد disk سے دوبارہ inject کیے جاتے ہیں۔ paths: frontmatter والی rules اور subdirectories میں موجود nested CLAUDE.md files اس وقت تک ضائع رہتی ہیں جب تک matching file دوبارہ نہ پڑھی جائے۔ جو کچھ آپ نے صرف chat میں type کیا ہو، وہ صرف اسی صورت میں برقرار رہتا ہے جب summariser نے اسے محفوظ رکھا ہو۔ اگر کوئی rule پوری session کے دوران لاگو رہنا ضروری ہے تو اسے project root file میں، paths: frontmatter کے بغیر، رکھیں۔

rule کو prose کے بجائے hook کب بنانا چاہیے؟

جب check deterministic ہو اور miss ہونے کی لاگت ایک چھوٹی script لکھنے کی لاگت سے زیادہ ہو۔ File path restrictions، commit سے پہلے required commands، اور forbidden tool calls اس معیار پر پورے اترتے ہیں۔ PreToolUse hook جو status 2 کے ساتھ exit ہو، tool call کو براہِ راست block کرتا ہے اور آپ کا stderr متن model کو وجہ کے طور پر واپس دیتا ہے۔ اس طرح rule اس بات سے متاثر نہیں ہوتا کہ وہ context میں موجود ہے یا نہیں۔ Formatter یا linter جس چیز کا فیصلہ کر سکتا ہو، اس کی ذمہ داری اسی tool کو دیں اور اسے instruction file سے مکمل طور پر حذف کریں۔