Monorepo में nested AGENTS.md का उपयोग कैसे करें

Monorepo में nested AGENTS.md का क्या अर्थ है

Monorepo में nested AGENTS.md का अर्थ है कि एक छोटी फाइल repository के root पर होती है और एक-एक फाइल प्रत्येक service directory के अंदर होती है। Root फाइल में वे कुछ नियम होते हैं जो हर जगह लागू होते हैं, साथ ही यह जानकारी भी होती है कि अन्य फाइलें कहाँ स्थित हैं। प्रत्येक service फाइल में केवल उस directory के लिए कमांड और नियम होते हैं। जब कोई agent services/worker/queue.py को edit करता है, तो वह root फाइल और उस विशिष्ट service की फाइल को पढ़ता है। इस प्रक्रिया में वह उस front end पर कोई context खर्च नहीं करता जिसे वह कभी touch नहीं करेगा।

इसमें कुछ भी install करने की आवश्यकता नहीं है। AGENTS.md एक convention है, और upstream project इसे स्पष्ट रूप से बताता है:

AGENTS.md केवल standard Markdown है। आप अपनी पसंद की किसी भी heading का उपयोग करें; agent केवल आपके द्वारा प्रदान किए गए text को parse करता है।

यही कारण है कि इस तकनीक को सही ढंग से सीखना उपयोगी है। इसका format आपके उपयोग के दौरान नहीं बदलेगा। जो चीज खराब हो सकती है वह है placement और maintenance, और ये दोनों आपकी जिम्मेदारी हैं।

एक बड़ी root AGENTS.md फाइल काम करना क्यों बंद कर देती है?

एक वेब ऐप, एक बैकग्राउंड वर्कर और एक Terraform डायरेक्टरी वाले रिपॉजिटरी की root में मौजूद 600-लाइन की एक अकेली AGENTS.md फाइल चार अलग-अलग तरीकों से विफल होती है।

यह पुरानी (stale) हो जाती है, क्योंकि इसका कोई मालिक नहीं होता। जो इंजीनियर apps/web में एक टेस्ट स्क्रिप्ट का नाम बदलता है, वह apps/web के अंतर्गत फाइलों को संपादित कर रहा होता है। root AGENTS.md उस diff में नहीं होती, इसलिए किसी भी reviewer को विसंगति (mismatch) दिखाई नहीं देती। छह सप्ताह बाद, फाइल एक ऐसे बिल्ड स्टेप का वर्णन कर रही होती है जो अब मौजूद ही नहीं है, और जिसने इसे तोड़ा था, वह उस बदलाव को भूल चुका होता है।

यह हर कार्य पर context की लागत बढ़ाती है। ये फाइलें सेशन की शुरुआत में ही लोड हो जाती हैं, इससे पहले कि एजेंट को पता चले कि आप क्या पूछने वाले हैं। Claude Code का डॉक्यूमेंटेशन इस पर एक संख्या निर्धारित करता है: "प्रति CLAUDE.md फाइल 200 लाइनों से कम का लक्ष्य रखें। लंबी फाइलें अधिक context का उपभोग करती हैं और निर्देशों का पालन कम कर देती हैं।" Codex निर्देश फाइलों को मर्ज करना तब बंद कर देता है जब उनका संयुक्त आकार 32 KiB तक पहुँच जाता है, जो कि डिफ़ॉल्ट project_doc_max_bytes है। चार सेवाओं का दस्तावेजीकरण करने वाली एक root फाइल हर एक कार्य के लिए उनमें से तीन पर वह बजट खर्च कर देती है।

निर्देश एक-दूसरे का विरोध करने लगते हैं। वेब डायरेक्टरी pnpm test चाहती है। वर्कर pytest -q चाहता है। एक ही फाइल में लिखे जाने पर, प्रत्येक नियम केवल कुछ समय के लिए ही सही होता है, इसलिए एजेंट को यह अनुमान लगाना पड़ता है कि कौन सा नियम लागू होता है। Claude Code के डॉक्स परिणाम का वर्णन करते हैं: "यदि दो नियम एक-दूसरे का विरोध करते हैं, तो Claude मनमाने ढंग से किसी एक को चुन सकता है।" प्रति-डायरेक्टरी फाइल अनुमान को खत्म कर देती है, क्योंकि context में दोनों में से केवल एक ही नियम मौजूद होता है। जब कोई नियम जिसे आपने स्पष्ट रूप से लिखा है, फिर भी अनदेखा कर दिया जाता है, तो निर्देश के लागू न होने के कारणों पर काम करना, शब्दों को चौथी बार फिर से लिखने से बेहतर होता है।

यह उन तथ्यों से भर जाती है जिन्हें एजेंट कोड से पढ़ सकता है। एक डायरेक्टरी ट्री, एक डिपेंडेंसी लिस्ट, प्रत्येक पैकेज क्या करता है इसका सारांश। Claude Code का /doctor चेक ठीक इसी को हटाने के लिए मौजूद है। यह "उन कंटेंट को काट देता है जिसे Claude कोडबेस से प्राप्त कर सकता है, जैसे कि डायरेक्टरी लेआउट, डिपेंडेंसी लिस्ट और आर्किटेक्चर ओवरव्यू" और केवल "कमियों (pitfalls), तर्क (rationale) और उन परंपराओं को रखता है जो टूल के डिफ़ॉल्ट से भिन्न हैं।" वह वाक्य सबसे अच्छा परीक्षण है जिसे मैं जानता हूँ कि क्या कोई लाइन वास्तव में फाइल में होनी चाहिए या नहीं।

क्या agent root file को पढ़ता है, या केवल सबसे निकट वाली को?

यहीं पर ज्यादातर लोग model के काम करने के तरीके को गलत समझते हैं, इसलिए इसे अपने शब्दों में बताने के बजाय upstream convention को उद्धृत करना बेहतर है:

प्रत्येक package के अंदर एक और AGENTS.md रखें। Agents स्वचालित रूप से directory tree में सबसे निकट वाली file को पढ़ते हैं, इसलिए सबसे करीबी file को प्राथमिकता मिलती है और प्रत्येक subproject अपनी विशिष्ट instructions दे सकता है।

और conflicts के मामले में:

edit की गई file के सबसे करीब वाली AGENTS.md प्रभावी होती है; user द्वारा chat में दिए गए स्पष्ट prompts हर चीज पर भारी पड़ते हैं।

"प्राथमिकता मिलती है" (takes precedence) का अर्थ बहुत से लोग यह निकालते हैं कि "root file को अनदेखा कर दिया जाता है"। ऐसा नहीं है। इस convention को लागू करने वाले tools में, repository root से लेकर working directory तक के path पर मौजूद हर file को पढ़ा जाता है और आपस में जोड़ दिया जाता है। सबसे निकट वाली file केवल तब प्रभावी होती है जब दो files एक ही विषय पर अलग-अलग निर्देश देती हैं।

Codex इस प्रक्रिया के बारे में स्पष्ट है: "Codex root से नीचे तक की files को जोड़ता है, और उन्हें खाली लाइनों के साथ मिलाता है। आपकी वर्तमान directory के करीब वाली files पहले के निर्देशों को override कर देती हैं।" Claude Code अपनी file के नाम के लिए इसी रास्ते का अनुसरण करता है। Working directory के ऊपर directory hierarchy में मौजूद files "launch के समय पूरी तरह से load हो जाती हैं", और "सभी खोजी गई files एक-दूसरे को override करने के बजाय context में जोड़ दी जाती हैं।" Working directory के नीचे की directories अलग तरह से व्यवहार करती हैं: Claude Code उन files को मांग पर load करता है, "जब Claude उन directories में files को पढ़ता है।"

इसके दो व्यावहारिक परिणाम होते हैं। Root file repository में हर session के लिए एक prefix होती है, इसलिए वहाँ लिखी प्रत्येक line को ऐसा मानें जिसके लिए आप सप्ताह में सौ बार भुगतान करते हैं। प्रति-directory वाली file की लागत तब शून्य होती है जब agent कहीं और काम कर रहा हो, जिसका अर्थ है कि वहाँ विस्तार से जानकारी देना सस्ता है और वहीं दी जानी चाहिए।

इस व्यवहार की पुष्टि अगस्त 2026 में Codex और Claude Code के documentation के आधार पर की गई थी। Tools इस convention को थोड़ा अलग तरीके से लागू करते हैं और वे बदलते भी रहते हैं, इसलिए आपकी टीम जो भी agent चलाती है, उसके लिए loading rules की पुष्टि कर लें।

तीन सेवाओं वाले रिपॉजिटरी के लिए एक कार्यशील लेआउट

repo/
  AGENTS.md                   rules true everywhere, plus the map
  apps/web/AGENTS.md          TypeScript client, Vite, Vitest
  services/worker/AGENTS.md   Python queue consumer, pytest
  infra/AGENTS.md             Terraform and the deploy scripts

रूट फ़ाइल को जानबूझकर संक्षिप्त रखा गया है। यह बताती है कि कहाँ देखना है, और इसमें केवल वही नियम हैं जो हर डायरेक्टरी पर लागू होते हैं।

# AGENTS.md

This is a monorepo. Each top-level directory ships its own AGENTS.md.
Read this file and the AGENTS.md nearest the code you are editing
before you change anything.

- `apps/web` browser client
- `services/worker` queue consumer
- `infra` Terraform and deploy scripts

## Rules for the whole repository

- The package manager is `pnpm`. `npm install` writes a second lockfile
  that CI ignores, so the install you tested is not the install that ships.
- Any `generated/` directory is build output. Edit the schema in
  `schemas/` and run `pnpm codegen` instead.
- `.env.local` holds real credentials. Do not read it and do not print it.
- If you change code in a directory, update that directory's AGENTS.md
  in the same commit.

प्रति-डायरेक्टरी फ़ाइल में विवरण होता है, और यह उतनी लंबी हो सकती है जितनी उस डायरेक्टरी के लिए आवश्यक हो।

# apps/web

Browser client. Vite and React, TypeScript with `strict` on.

## Commands

- `pnpm dev` serves on port 5173.
- `pnpm test` runs Vitest once and exits.
- `pnpm typecheck` runs `tsc --noEmit`.

## Conventions

- One component per file under `src/components/`.
- All HTTP goes through `src/api/client.ts`. Do not call `fetch` directly,
  because the client attaches the auth header and retries on 429.

## Traps

- `pnpm build` does not type check. Vite strips the types instead of
  checking them, so a broken type still produces a green build.
  Run `pnpm typecheck` as a separate step.

वर्कर फ़ाइल का आकार समान है लेकिन सामग्री अलग है: इंस्टॉल कमांड, pytest -q, वह कारण कि क्यों कंज्यूमर को आइडम्पोटेंट (idempotent) रहना चाहिए, और वह माइग्रेशन जिसे टेस्ट पास होने से पहले चलना आवश्यक है। इन्फ्रा फ़ाइल वह जगह है जहाँ आप वे नियम लिखते हैं जो किसी एजेंट को नुकसान पहुँचाने से रोकते हैं। कभी भी terraform apply न चलाएं। terraform plan चलाएं और वहीं रुक जाएं, और उस स्टेट बैकएंड का नाम दें जो पहले से कॉन्फ़िगर है ताकि एजेंट एक नया बैकएंड इनिशियलाइज़ करने का प्रयास न करे।

ध्यान दें कि इनमें से किसी भी फ़ाइल में क्या नहीं है: प्रत्येक सेवा किस उद्देश्य के लिए है, इसका विवरण। यह मनुष्यों के लिए है। अपस्ट्रीम भी यही रेखा खींचता है, यह कहते हुए कि "README.md फ़ाइलें मनुष्यों के लिए हैं: क्विक स्टार्ट, प्रोजेक्ट विवरण और योगदान दिशानिर्देश", जबकि AGENTS.md में "कोडिंग एजेंटों के लिए आवश्यक अतिरिक्त, कभी-कभी विस्तृत संदर्भ होता है: बिल्ड स्टेप्स, टेस्ट और कन्वेंशन।" AGENTS.md और मानव-केंद्रित README के बीच का विभाजन उस सीमा को वाक्य-दर-वाक्य स्पष्ट करता है, और एक DESIGN.md जो यह रिकॉर्ड करता है कि कोड को इस तरह क्यों बनाया गया है तीसरी फ़ाइल को कवर करता है, जो कमांड के बजाय निर्णयों की व्याख्या करती है।

कोड बदलने पर फाइल को कौन अपडेट करता है?

एक नियम है, और यह root फाइल में जाता है: जो कोई भी किसी directory में कोड बदलता है, वह उसी commit में उस directory की AGENTS.md को अपडेट करता है।

यह एक तकनीकी कारण से काम करता है, न कि सांस्कृतिक कारण से। प्रति-directory फाइल उसी diff में होती है जिसमें कोड होता है, इसलिए pull request का reviewer दोनों को एक साथ देख लेता है। एक root फाइल सबकी होती है, जिसका अर्थ है कि वह किसी की नहीं है, और वह उस diff में कभी नहीं होती जिसे कोई पहले से पढ़ रहा है।

इस नियम को pull request पर एक जांच (check) के साथ लागू करें। यह प्रत्येक बदली गई फाइल के ऊपर निकटतम AGENTS.md को ढूंढता है, और फिर रिपोर्ट करता है कि उस फाइल को touch नहीं किया गया था।

#!/usr/bin/env bash
# Warn when code changed but the nearest AGENTS.md above it did not.
changed=$(git diff --name-only origin/main...HEAD)

nearest_doc() {
  d=$(dirname "$1")
  while [ "$d" != "." ]; do
    if [ -f "$d/AGENTS.md" ]; then echo "$d/AGENTS.md"; return; fi
    d=$(dirname "$d")
  done
  echo "AGENTS.md"
}

printf '%s\n' "$changed" | while read -r f; do
  [ -n "$f" ] || continue
  case "$f" in AGENTS.md|*/AGENTS.md) continue ;; esac
  doc=$(nearest_doc "$f")
  printf '%s\n' "$changed" | grep -Fqx "$doc" && continue
  echo "note: $f changed but $doc was not updated"
done

एक branch पर जिसने API client को फिर से तैयार किया लेकिन docs को नहीं छुआ, आउटपुट ऐसा दिखता है:

note: apps/web/src/api/client.ts changed but apps/web/AGENTS.md was not updated

इसे failure के बजाय एक warning बनाए रखें। एक सख्त gate लोगों को फाइल में एक खाली लाइन जोड़ने के लिए प्रेरित करता है ताकि CI green हो जाए, और एक ऐसी फाइल जिसे केवल robot को संतुष्ट करने के लिए edit किया गया हो, वह बिल्कुल भी फाइल न होने से कम मूल्यवान है। यह warning reviewer को पूछने के लिए एक सवाल देती है, और यही वह हिस्सा है जो वास्तव में काम करता है।

AGENTS.md पुराना हो गया है, यह कैसे पता करें?

आप आज दो जाँच कर सकते हैं, और एक लक्षण आपको session के दौरान दिखाई देगा।

प्रत्येक फ़ाइल की आयु की तुलना उस कोड की आयु से करें जिसका वह वर्णन करती है। %cs, YYYY-MM-DD के रूप में commit date प्रिंट करता है।

for f in $(git ls-files '*AGENTS.md'); do
  d=$(dirname "$f")
  printf '%s  doc:%s  code:%s\n' "$f" \
    "$(git log -1 --format=%cs -- "$f")" \
    "$(git log -1 --format=%cs -- "$d")"
done

apps/web/AGENTS.md          doc:2026-02-11  code:2026-08-07
services/worker/AGENTS.md   doc:2026-07-29  code:2026-08-09
infra/AGENTS.md             doc:2026-08-01  code:2026-08-01

कोड की तारीख से छह महीने पुरानी दस्तावेज़ की तारीख यह साबित नहीं करती कि फ़ाइल गलत है। यह केवल आपको यह बताती है कि पहले कौन सी फ़ाइल पढ़नी है, और एक सेकंड में होने वाली जाँच से आपको बस इतना ही चाहिए।

उन paths को खोजें जो अब मौजूद नहीं हैं। दस्तावेज़ एक बहुत ही विशिष्ट तरीके से खराब होते हैं: वे ऐसे कोड का वर्णन करना जारी रखते हैं जिसे हटा दिया गया है। इन फ़ाइलों में प्रत्येक path backticks में लिखा होता है, इसलिए उन्हें निकालना और टेस्ट करना आसान है।

grep -o '`[^`]*`' apps/web/AGENTS.md | tr -d '`' | grep '/' | while read -r p; do
  [ -e "$p" ] || [ -e "apps/web/$p" ] || echo "missing: $p"
done

इसे CI में डालने के बजाय output को पढ़ें। यह src/**/*.ts जैसे globs और आपके द्वारा उद्धृत किसी भी URL को भी चिह्नित करता है, क्योंकि दोनों में स्लैश होता है और कोई भी डिस्क पर फ़ाइल नहीं है।

session में लक्षण। एजेंट फ़ाइल पढ़ता है, और फ़ाइल के निर्देशानुसार src/api/client.ts को खोलने का प्रयास करता है, और टूल यह return करता है:

No such file or directory

इसलिए यह उचित कार्य करता है और अपना स्वयं का fetch wrapper लिखता है। यही एक पुरानी फ़ाइल की वास्तविक कीमत है। एजेंट आपके दस्तावेज़ों को अनदेखा नहीं करता है। यह दस्तावेज़ों का पालन करता है, एक ऐसे path पर पहुँचता है जिसे तीन महीने पहले हटा दिया गया था, और उस कोड को फिर से बनाता है जो आपके पास पहले से है। Ponytail, जो एजेंट को सबसे छोटे कार्यशील बदलाव तक सीमित रखता है, जैसी skill उस पुनर्निर्माण की प्रवृत्ति को दुर्लभ बनाती है, लेकिन यह उस helper को नहीं ढूँढ सकती जिसे आपकी फ़ाइल ने गलत जगह पर इंगित किया है।

क्या Claude Code AGENTS.md फाइलों को पढ़ता है?

नहीं, और यह स्पष्ट रूप से कहना आवश्यक है क्योंकि नेस्टेड लेआउट इसी पर निर्भर करता है। अगस्त 2026 तक के दस्तावेज़ों के अनुसार: "Claude Code CLAUDE.md को पढ़ता है, AGENTS.md को नहीं।" यह पैटर्न अभी भी काम करता है, बस आपको प्रत्येक AGENTS.md के बगल में एक CLAUDE.md की आवश्यकता होती है।

जब आप साझा लाइनों के ऊपर टूल-विशिष्ट लाइनें चाहते हैं, तो import फॉर्म सही रहता है। इसे services/worker/CLAUDE.md में रखें:

@AGENTS.md

## Claude Code

Use plan mode for changes under `services/worker/migrations/`.

जब जोड़ने के लिए कुछ भी टूल-विशिष्ट न हो, तो symlink फॉर्म सही रहता है।

git ls-files '*AGENTS.md' | while read -r f; do
  ln -s AGENTS.md "$(dirname "$f")/CLAUDE.md"
done
ls -l apps/web/CLAUDE.md

ln सफल होने पर कुछ भी प्रिंट नहीं करता है, इसलिए लिस्टिंग की जाँच करें: apps/web/CLAUDE.md -> AGENTS.md। फिर एक सत्र (session) शुरू करें और /context चलाएँ, जहाँ लोड की गई फाइलें Memory files के अंतर्गत दिखाई देंगी। Windows पर symlink के लिए Administrator अधिकारों या Developer Mode की आवश्यकता होती है, इसलिए वहाँ @AGENTS.md import का उपयोग करें।

इसके साथ एक समस्या जुड़ी है। /compact के बाद, रूट फाइल को डिस्क से दोबारा पढ़ा जाता है, लेकिन सबडायरेक्ट्रीज में मौजूद नेस्टेड फाइलें दोबारा इंजेक्ट नहीं होती हैं। वे अगली बार तब वापस आती हैं जब एजेंट उस डायरेक्ट्री में कोई फाइल पढ़ता है। यदि कोई प्रति-डायरेक्ट्री नियम लंबे सत्र के बीच में काम करना बंद कर देता है, तो आमतौर पर यही कारण होता है, और उस डायरेक्ट्री में किसी भी फाइल को touch करने से वह वापस सक्रिय हो जाता है।

यह agent memory या skill से किस प्रकार भिन्न है?

ये तंत्र देखने में समान लगते हैं, लेकिन इनके विफल होने के तरीके पूरी तरह अलग हैं। इसलिए यह स्पष्ट होना आवश्यक है कि आप किस तंत्र का उपयोग करना चाहते हैं।

AGENTS.md आपके द्वारा लिखा जाता है, git में commit किया जाता है, pull request में review किया जाता है, और यह उन सभी के लिए समान होता है जो repository को clone करते हैं। Agent memory को agent द्वारा लिखा जाता है, repository के बाहर store किया जाता है, और यह एक मशीन तक सीमित होता है। Claude Code का documentation भी यही अंतर स्पष्ट करता है: CLAUDE.md में आपके द्वारा लिखे गए "निर्देश और नियम" (Instructions and rules) होते हैं, auto memory में Claude द्वारा सीखे गए "पैटर्न और सीख" (Learnings and patterns) होते हैं, और memory directory को मशीनों के बीच साझा नहीं किया जाता है। इसकी जाँच सरल है। यदि कोई तथ्य किसी सहकर्मी के लिए fresh clone पर भी सत्य होना चाहिए, तो वह memory में नहीं रह सकता। How agent memory persists between sessions इस विषय के उस पहलू को कवर करता है।

Skill तीसरी चीज है। AGENTS.md वह context है जो हर session में load होता है; skill वह प्रक्रिया है जो आवश्यकता पड़ने पर load होती है। Claude Code का documentation एक उपयोगी नियम बताता है: "यदि कोई entry बहु-चरणीय प्रक्रिया (multi-step procedure) है या केवल codebase के एक हिस्से के लिए मायने रखती है, तो उसे skill या path-scoped rule में ले जाएँ।" उस वाक्य का दूसरा भाग वही है जिसे nested AGENTS.md हल करता है। पहला भाग agent skills के लिए है, और जब एक ही प्रक्रिया की आवश्यकता एक से अधिक repository में हो, तो share the skill across repos का उपयोग करें, बजाय इसके कि एक ही पैराग्राफ को दस अलग-अलग AGENTS.md फाइलों में copy-paste करें।

Upstream का कहना है कि "इस लेख को लिखते समय मुख्य OpenAI repo में 88 AGENTS.md फाइलें थीं"। यह संख्या ही अपने आप में पूरा तर्क है। एक बड़ी repository को एक बड़ी फाइल की आवश्यकता नहीं होती है। इसे और अधिक छोटी फाइलों की आवश्यकता होती है, जिनमें से प्रत्येक उस code के बगल में स्थित हो जिसका वह वर्णन करती है, और प्रत्येक का स्वामित्व उस व्यक्ति के पास हो जिसने अंतिम बार उस code में बदलाव किया है।

FAQ

क्या nested AGENTS.md root file की जगह लेता है या उसमें जुड़ता है?

यह उसमें जुड़ता है। Upstream का कहना है कि "सबसे नज़दीकी फाइल प्रभावी होती है", जो यह बताती है कि conflict होने पर क्या होगा, न कि यह कि क्या लोड होगा। Codex "root से नीचे की ओर फाइलों को जोड़ता है और उन्हें खाली लाइनों से अलग करता है", और Claude Code वर्किंग डायरेक्टरी से ऊपर की ओर जाते हुए मिलने वाली हर फाइल को जोड़ता है, न कि उन्हें ओवरराइड करता है। सबसे नज़दीकी फाइल केवल तब प्रभावी होती है जब दो फाइलें एक ही विषय पर अलग-अलग निर्देश देती हैं। साझा नियमों को एक बार root पर लिखें और उन्हें हर डायरेक्टरी में न दोहराएं।

root AGENTS.md कितना बड़ा होना चाहिए?

इतना छोटा कि आपको उस रिपॉजिटरी में किए जाने वाले हर अनुरोध (request) के ऊपर इसे पेस्ट करने में कोई आपत्ति न हो, क्योंकि वास्तव में यही होता है। Claude Code का डॉक्यूमेंटेशन प्रति फाइल 200 लाइनों से कम रखने का सुझाव देता है और चेतावनी देता है कि लंबी फाइलें "अनुपालन (adherence) को कम करती हैं"। Codex डिफ़ॉल्ट रूप से 32 KiB पर निर्देश फाइलों को मर्ज करना बंद कर देता है। यदि आपकी root फाइल चार सेवाओं का डॉक्यूमेंटेशन करती है, तो किसी एक कार्य के लिए इसका अधिकांश हिस्सा अनावश्यक है। विवरण को प्रति-डायरेक्टरी फाइलों में ले जाएं और पीछे एक मैप छोड़ दें।

मैं इन फाइलों को पुराना (stale) होने से कैसे रोकूं?

root फाइल में एक नियम रखें: जो कोई भी किसी डायरेक्टरी में कोड बदलता है, वह उसी कमिट में उस डायरेक्टरी की AGENTS.md को अपडेट करेगा। फाइल को कोड के बगल में रखने से ही यह नियम प्रभावी होता है, क्योंकि बदलाव उसी पुल रिक्वेस्ट डिफ (pull request diff) में दिखाई देता है जिसे एक इंसान पहले से पढ़ रहा है। एक CI चेतावनी जोड़ें जो प्रत्येक बदले हुए पाथ को उसके ऊपर की सबसे नज़दीकी AGENTS.md से मैप करे, और समय-समय पर प्रत्येक फाइल पर git log -1 --format=%cs की तुलना उसी कमांड से करें जो उस डायरेक्टरी पर चलाई गई है जिसका वह डॉक्यूमेंटेशन करती है।

क्या Claude Code AGENTS.md फाइलों को पढ़ता है?

नहीं। अगस्त 2026 तक के डॉक्यूमेंटेशन के अनुसार "Claude Code CLAUDE.md को पढ़ता है, AGENTS.md को नहीं।" उसी डायरेक्टरी में एक CLAUDE.md बनाएं जिसकी पहली लाइन पर @AGENTS.md हो, जो साझा फाइल को लोड करता है और आपको उसके नीचे Claude-विशिष्ट निर्देश जोड़ने की अनुमति देता है। जब कुछ अतिरिक्त न जोड़ना हो, तो ln -s AGENTS.md CLAUDE.md से बनाया गया symlink काम करता है, हालांकि Windows पर इसके लिए Administrator अधिकार या Developer Mode की आवश्यकता होती है। सत्र में /context चलाएं और पुष्टि करें कि फाइल Memory files के अंतर्गत दिखाई देती है।

मैं वह नियम कहाँ रखूं जो केवल कभी-कभी मायने रखता है?

AGENTS.md में नहीं। वह फाइल हर सत्र में लोड होती है, इसलिए उसकी हर लाइन आपके द्वारा टाइप किए गए वास्तविक अनुरोध के साथ ध्यान खींचने के लिए प्रतिस्पर्धा करती है। कई चरणों वाली प्रक्रिया जिसकी कभी-कभी आवश्यकता होती है, वह एक skill में होनी चाहिए, जो मांग पर लोड होती है। एक नियम जो एक डायरेक्टरी पर लागू होता है, वह उस डायरेक्टरी की AGENTS.md में होना चाहिए। कोई तथ्य जिसे एजेंट सीधे कोड से पढ़ सकता है, जैसे कि डायरेक्टरी ट्री या डिपेंडेंसी लिस्ट, उसे कहीं भी रखने की आवश्यकता नहीं है।