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

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

Monorepo में nested AGENTS.md का अर्थ है कि एक छोटी फाइल repository के root पर होती है और एक-एक फाइल प्रत्येक service directory के अंदर होती है। Root फाइल में वे कुछ नियम होते हैं जो हर जगह लागू होते हैं, साथ ही यह जानकारी भी होती है कि अन्य फाइलें कहाँ स्थित हैं। प्रत्येक service फाइल में केवल उस directory के लिए commands और conventions होते हैं। जब कोई 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 डायरेक्टरी वाले रिपॉजिटरी के रूट पर स्थित 600-लाइन का एक AGENTS.md चार अलग-अलग तरीकों से विफल हो जाता है।

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

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

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

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

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

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

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

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

संपादित 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 होती है, इसलिए वहाँ की प्रत्येक लाइन को ऐसी लाइन मानें जिसके लिए आप सप्ताह में सौ बार भुगतान करते हैं। जब agent कहीं और काम कर रहा हो तो प्रति-directory file की कोई लागत नहीं होती, जिसका अर्थ है कि वहाँ विवरण देना सस्ता है और वहीं देना उचित है।

इस व्यवहार की अगस्त 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.

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

# 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 फाइल में जाता है: जो कोई भी किसी डायरेक्टरी में कोड बदलता है, वह उसी कमिट में उस डायरेक्टरी की AGENTS.md को अपडेट करता है।

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

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

#!/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

एक ऐसी ब्रांच पर जिसने API client को फिर से तैयार किया लेकिन डॉक्स को टच नहीं किया, आउटपुट ऐसा दिखता है:

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

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

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

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

प्रत्येक file की आयु की तुलना उस code की आयु से करें जिसका वह वर्णन करती है। %cs commit date को YYYY-MM-DD के रूप में print करता है।

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

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

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

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 को भी flag करता है, क्योंकि दोनों में slash होता है और उनमें से कोई भी disk पर file नहीं है।

Session में दिखने वाला लक्षण। Agent file को पढ़ता है, src/api/client.ts को खोलने की कोशिश करता है क्योंकि file ने उसे ऐसा करने के लिए कहा था, और tool यह return करता है:

No such file or directory

इसलिए वह उचित कदम उठाता है और अपना खुद का fetch wrapper लिख देता है। यही एक पुरानी file की वास्तविक कीमत है। Agent आपकी documentation को ignore नहीं करता है। वह documentation का पालन करता है, एक ऐसे path पर पहुँचता है जिसे तीन महीने पहले delete कर दिया गया था, और उस code को फिर से बनाता है जो आपके पास पहले से मौजूद है। Ponytail, जो agent को सबसे छोटे काम करने वाले बदलाव तक सीमित रखता है, जैसी skill उस rebuilding की प्रवृत्ति को दुर्लभ बना देती है, लेकिन यह उस helper को नहीं ढूँढ सकती जिसकी ओर आपकी file ने गलत स्थान पर इशारा किया है।

क्या 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। फिर एक सेशन शुरू करें और /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 के docs एक उपयोगी नियम देते हैं: "यदि कोई entry बहु-चरणीय प्रक्रिया है या केवल 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 रूट फाइल की जगह लेता है या उसमें जुड़ता है?

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

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

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

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

रूट फाइल में एक नियम रखें: जो कोई भी किसी डायरेक्टरी में कोड बदलता है, वह उसी कमिट में उस डायरेक्टरी की 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 पर इसके लिए एडमिनिस्ट्रेटर अधिकार या डेवलपर मोड की आवश्यकता होती है। सत्र में /context चलाएं और पुष्टि करें कि फाइल Memory files के अंतर्गत दिखाई देती है।

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

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