मोनोरेपोसाठी nested AGENTS.md रचना कशी करावी

मोनोरेपोमध्ये नेस्टेड AGENTS.md म्हणजे काय

मोनोरेपोमध्ये नेस्टेड AGENTS.md म्हणजे रिपॉझिटरीच्या root मध्ये एक छोटी फाइल आणि प्रत्येक service directory मध्ये आणखी एक फाइल असणे. root फाइलमध्ये सर्वत्र लागू होणारे मोजके नियम आणि इतर फाइल्स कुठे आहेत याचा नकाशा असतो. प्रत्येक service फाइलमध्ये फक्त त्या directory साठी लागू असलेल्या commands आणि conventions असतात. services/worker/queue.py संपादित करणारा agent आधी root फाइल आणि worker फाइल वाचतो. त्यामुळे तो कधीही न छेडल्या जाणाऱ्या front end संदर्भात context खर्च करत नाही.

काहीही install करण्याची गरज नाही. AGENTS.md ही एक convention आहे, असे upstream project स्पष्टपणे सांगतो:

AGENTS.md हे फक्त standard Markdown आहे. तुम्हाला हवे ते headings वापरा; agent तुम्ही दिलेला मजकूरच parse करतो.

म्हणूनच हे तंत्र व्यवस्थित शिकणे उपयुक्त ठरते. हा format तुमच्या वापरादरम्यान बदलणार नाही. अडचणी placement आणि maintenance मुळे निर्माण होतात, आणि त्या दोन्हींची जबाबदारी तुमची आहे.

एक मोठा root AGENTS.md काम करणे का थांबवतो?

वेब अॅप, background worker आणि Terraform directory असलेल्या repository च्या root मध्ये ठेवलेला एक 600-line AGENTS.md चार वेगवेगळ्या प्रकारे अपयशी ठरतो.

तो कालबाह्य होतो, कारण त्याची जबाबदारी कोणाकडेही नसते. apps/web मधील test script चे नाव बदलणारा engineer apps/web अंतर्गत असलेल्या files मध्ये बदल करतो. त्या diff मध्ये root AGENTS.md नसल्यामुळे कोणत्याही reviewer ला हा विसंवाद दिसत नाही. सहा आठवड्यांनंतर file मध्ये अस्तित्वात नसलेल्या build step चे वर्णन राहते आणि हा बदल करणाऱ्या व्यक्तीला तो बदल विसरलेला असतो.

प्रत्येक task साठी तो context खर्च करतो. Agent ला तुम्ही काय विचारणार आहात हे माहीत होण्यापूर्वी, session च्या सुरुवातीलाच या files load होतात. Claude Code च्या documentation मध्ये यासाठी स्पष्ट मर्यादा दिली आहे: "प्रत्येक CLAUDE.md file साठी 200 lines पेक्षा कमी ठेवण्याचे लक्ष्य ठेवा. मोठ्या files अधिक context वापरतात आणि सूचनांचे पालन कमी करतात." Codex च्या default project_doc_max_bytes नुसार, instruction files चा एकत्रित आकार 32 KiB झाल्यावर तो त्या merge करणे थांबवतो. चार services चे documentation असलेली root file प्रत्येक task साठी त्या budget मधील तीन-चतुर्थांश भाग अनावश्यकपणे वापरते.

सूचना एकमेकींशी विरोध करू लागतात. Web directory ला pnpm test हवे असते. Worker ला pytest -q हवे असते. या दोन्ही सूचना एकाच file मध्ये लिहिल्यावर प्रत्येक rule फक्त काही परिस्थितींमध्येच योग्य ठरतो. त्यामुळे कोणता rule लागू आहे याचा agent ला अंदाज घ्यावा लागतो. Claude Code च्या docs मध्ये याचा परिणाम स्पष्ट केला आहे: "दोन rules मध्ये विरोध असल्यास Claude त्यांपैकी एक rule मनमानीपणे निवडू शकतो." Per-directory file हा अंदाज दूर करते, कारण दोनपैकी फक्त एकच rule context मध्ये येतो.

Agent code मधून वाचू शकणाऱ्या facts ने ती भरून जाते. Directory tree, dependency list आणि प्रत्येक package काय करते याचा summary यामध्ये येतो. Claude Code ची /doctor check नेमकी हीच माहिती काढून टाकण्यासाठी आहे. ती "directory layouts, dependency lists आणि architecture overviews यांसारखी Claude codebase मधून स्वतः मिळवू शकणारी content काढून टाकते" आणि "pitfalls, rationale आणि tool defaults पेक्षा वेगळ्या conventions" ठेवते. एखादी line या file मध्ये असावी की नाही हे तपासण्यासाठी मला यापेक्षा चांगली कसोटी माहीत नाही.

एजंट root फाइल वाचतो का, की फक्त सर्वात जवळची फाइल?

बहुतेक लोकांना मॉडेलच्या वर्तनाबद्दल याच ठिकाणी चुकीची समजूत असते. त्यामुळे upstream convention चे स्वैर पुनर्कथन करण्याऐवजी ते थेट उद्धृत करणे योग्य ठरेल:

प्रत्येक package मध्ये आणखी एक AGENTS.md ठेवा. एजंट directory tree मधील सर्वात जवळची फाइल आपोआप वाचतात. त्यामुळे सर्वात जवळच्या फाइलला प्राधान्य मिळते आणि प्रत्येक subproject मध्ये त्याला अनुरूप सूचना ठेवता येतात.

आणि conflict असल्यास:

संपादित केलेल्या फाइलच्या सर्वात जवळची AGENTS.md लागू होते; explicit user chat prompts सर्व सूचनांवर प्राधान्य मिळवतात.

"Takes precedence" याचा अर्थ root फाइलकडे दुर्लक्ष केले जाते, असा अनेकांना होतो. तसे नाही. ही convention लागू करणाऱ्या tools मध्ये repository root पासून working directory पर्यंतच्या path वरील प्रत्येक फाइल वाचली जाते आणि त्या एकत्र जोडल्या जातात. दोन फाइल्समध्ये त्याच विषयाबद्दल वेगवेगळ्या सूचना असतील, तेव्हाच सर्वात जवळची फाइल प्राधान्य घेते.

Codex ही प्रक्रिया स्पष्टपणे सांगते: "Codex root पासून खालपर्यंतच्या फाइल्स blank lines ने जोडून concatenate करते. तुमच्या current directory च्या जवळच्या फाइल्स आधीच्या मार्गदर्शनावर override करतात." Claude Code स्वतःच्या file name साठी हाच path तपासते. Working directory च्या वरील directory hierarchy मधील फाइल्स "launch वेळी पूर्णपणे load केल्या जातात", आणि "सापडलेल्या सर्व फाइल्स एकमेकांवर override न करता context मध्ये concatenate केल्या जातात." Working directory च्या खालील directories वेगळ्या प्रकारे हाताळल्या जातात: Claude Code त्या directories मधील फाइल्स "Claude त्या directories मधील फाइल्स वाचते तेव्हा" गरजेनुसार load करते.

यातून दोन व्यावहारिक निष्कर्ष निघतात. Repository मधील प्रत्येक session मध्ये root फाइल prefix म्हणून समाविष्ट होते. त्यामुळे तिच्या प्रत्येक ओळीचा खर्च आठवड्यात शंभर वेळा होतो, असे समजून ती लिहा. Agent दुसरीकडे काम करत असताना per-directory फाइलचा कोणताही खर्च होत नाही. त्यामुळे तपशील तिथे ठेवणे स्वस्त आणि योग्य ठरते.

हे वर्तन August 2026 मध्ये Codex आणि Claude Code च्या documentation विरुद्ध तपासले गेले. Tools ही convention थोडी वेगवेगळ्या प्रकारे implement करतात आणि त्यांच्यात बदलही होतात. त्यामुळे तुमची team ज्या agent चा वापर करते, त्याच्या loading rules ची खात्री करा.

तीन सेवांसह repository ची कार्यरत रचना

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

Root file मुद्दाम लहान ठेवलेली आहे. ती कुठे पाहायचे ते सांगते आणि प्रत्येक directory मध्ये लागू असलेले नियमच त्यात असतात.

# 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 file मध्ये असतो. Directory च्या गरजेनुसार ही file कितीही मोठी असू शकते.

# 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.

Worker file ची रचना याच प्रकारची असते, पण त्यातील मजकूर वेगळा असतो: install command, pytest -q, consumer idempotent का राहिला पाहिजे याचे कारण आणि tests यशस्वी होण्यापूर्वी चालवायचे migration. Infra file मध्ये agent कडून होणारे नुकसान रोखणारे नियम लिहिले जातात. terraform apply कधीही चालवू नका. terraform plan चालवून तेथेच थांबा. आधीच configured असलेला state backend नमूद करा, म्हणजे agent नवीन backend initialise करण्याचा प्रयत्न करणार नाही.

या files पैकी कोणत्याही file मध्ये प्रत्येक service कशासाठी आहे याचे वर्णन नाही, हे लक्षात घ्या. ते humans साठी असते. Upstream मध्येही हीच विभागणी केली आहे: "README.md files are for humans: quick starts, project descriptions, and contribution guidelines", तर AGENTS.md मध्ये "the extra, sometimes detailed context coding agents need: build steps, tests, and conventions." असे नमूद केले आहे. AGENTS.md आणि humans साठी असलेल्या README मधील विभागणी या सीमारेषेचे sentence by sentence स्पष्टीकरण देते. तसेच code ची रचना अशी का आहे हे नोंदवणारी DESIGN.md commands ऐवजी निर्णय स्पष्ट करणाऱ्या तिसऱ्या file चे वर्णन करते.

कोडमध्ये बदल झाल्यावर फाइल कोण अद्ययावत करतो?

एक नियम root फाइलमध्ये लिहा: एखाद्या directory मधील code मध्ये बदल करणाऱ्या व्यक्तीने त्याच commit मध्ये त्या directory मधील AGENTS.md देखील अद्ययावत करावे.

हा नियम सांस्कृतिक कारणामुळे नव्हे, तर यांत्रिक कारणामुळे कार्य करतो. Per-directory फाइल code सोबतच त्याच diff मध्ये असते. त्यामुळे pull request चे reviewer दोन्ही बदल एकाच वेळी पाहतो. Root फाइल सर्वांची असते. त्यामुळे ती प्रत्यक्षात कोणाचीच राहत नाही. तसेच, कोणी आधीपासून पाहत असलेल्या diff मध्ये ती कधीच समाविष्ट नसते.

Pull request वरील check ने या नियमाला समर्थन द्या. तो प्रत्येक बदललेल्या फाइलच्या वरच्या स्तरावरील सर्वांत जवळची AGENTS.md शोधतो. ती 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

Docs मध्ये बदल न करता API client पुन्हा तयार केलेल्या branch वर output असा दिसतो:

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

याला failure ऐवजी warning ठेवा. कठोर gate ठेवल्यास CI हिरवा दिसावा म्हणून लोक फाइलमध्ये रिकामी ओळ घालतील. Robot चे समाधान करण्यासाठी संपादित केलेली फाइल ही फाइल नसण्यापेक्षाही कमी उपयुक्त असते. Warning मुळे reviewer ला प्रश्न विचारता येतो. प्रत्यक्षात कार्य करणारा भाग हाच आहे.

कालबाह्य झालेली AGENTS.md फाइल कशी ओळखावी?

आज तुम्ही दोन तपासण्या करू शकता. सत्राच्या आत दिसणारे एक लक्षणही आहे.

प्रत्येक फाइलचे वय ती ज्या code चे वर्णन करते त्याच्या वयाशी तुलना करा. %cs commit date YYYY-MM-DD म्हणून दाखवते.

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 सहा महिने मागे आहे, यावरून फाइल चुकीची आहे असे सिद्ध होत नाही. मात्र कोणती फाइल आधी वाचावी हे कळते. एका सेकंदात होणाऱ्या तपासणीतून तुम्हाला एवढेच हवे असते.

आता अस्तित्वात नसलेले paths शोधा. Documentation खराब होण्याचा एक ठरावीक प्रकार आहे: deleted झालेले code ती अजूनही वर्णन करते. या फाइलमधील प्रत्येक 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

Output वाचा. ही तपासणी CI मध्ये जोडू नका. src/**/*.ts सारखे globs आणि तुम्ही उद्धृत केलेली कोणतीही URL हीदेखील ती दर्शवते, कारण दोन्हींमध्ये slash असतो आणि disk वर त्यापैकी कोणतीही file नसते.

सत्रातील लक्षण. Agent फाइल वाचते, फाइलने सांगितल्यामुळे src/api/client.ts उघडण्याचा प्रयत्न करते आणि tool पुढील प्रतिसाद देते:

No such file or directory

म्हणून ते योग्यच पाऊल उचलते आणि स्वतःचा fetch wrapper लिहिते. ही कालबाह्य फाइलची खरी किंमत आहे. Agent तुमच्या documentation कडे दुर्लक्ष करत नाही. ते documentation चे पालन करते, तीन महिन्यांपूर्वी deleted झालेल्या path वर पोहोचते आणि तुमच्याकडे आधीपासून असलेला code पुन्हा तयार करते. काम करणाऱ्या सर्वात लहान बदलापुरते agent ला मर्यादित ठेवणारे Ponytail यांसारखे skill ही पुन्हा तयार करण्याची प्रवृत्ती कमी करते. पण तुमच्या फाइलने चुकीच्या ठिकाणी निर्देश केलेला helper ते शोधू शकत नाही.

Claude Code AGENTS.md फाइल्स वाचते का?

नाही. हे स्पष्टपणे सांगणे महत्त्वाचे आहे, कारण nested मांडणी यावर अवलंबून आहे. August 2026 पर्यंतच्या दस्तऐवजीकरणानुसार: "Claude Code CLAUDE.md वाचते, AGENTS.md नाही." ही पद्धत तरीही कार्य करते; प्रत्येक AGENTS.md च्या बाजूला CLAUDE.md ठेवावे लागते.

सामायिक ओळींसोबत tool-specific ओळी जोडायच्या असतील, तर import पद्धत योग्य आहे. हे services/worker/CLAUDE.md मध्ये ठेवा:

@AGENTS.md

## Claude Code

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

जोडण्यासाठी tool-specific काहीही नसल्यास 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 काहीही दाखवत नाही. त्यामुळे listing तपासा: apps/web/CLAUDE.md -> AGENTS.md. त्यानंतर session सुरू करा आणि /context चालवा. लोड झालेल्या फाइल्स Memory files अंतर्गत दिसतील. Windows वर symlink तयार करण्यासाठी Administrator अधिकार किंवा Developer Mode आवश्यक असतो. त्यामुळे तेथे @AGENTS.md import वापरा.

यासोबत आणखी एक महत्त्वाची बाब आहे. /compact नंतर root फाइल disk वरून पुन्हा वाचली जाते; परंतु subdirectories मधील nested फाइल्स पुन्हा inject केल्या जात नाहीत. Agent त्या directory मधील एखादी फाइल पुढच्या वेळी वाचतो तेव्हा त्या पुन्हा लोड होतात. दीर्घ session मध्ये per-directory नियम अर्ध्यावर लागू होणे थांबले असे वाटल्यास, सामान्यतः हेच कारण असते. Directory मधील कोणतीही फाइल touch केल्यावर ते नियम पुन्हा लागू होतात.

हे agent memory किंवा skillपेक्षा वेगळे कसे आहे?

या यंत्रणा वरवर सारख्या दिसतात; परंतु त्या पूर्णपणे वेगवेगळ्या प्रकारे अपयशी ठरतात. त्यामुळे तुम्ही नेमकी कोणती यंत्रणा वापरत आहात हे स्पष्टपणे ठरवणे महत्त्वाचे आहे.

AGENTS.md तुम्ही लिहिता, git मध्ये commit करता, pull request मध्ये त्याचा review होतो आणि repository clone करणाऱ्या प्रत्येकासाठी तो समान असतो. Agent memory agent लिहितो, repository बाहेर साठवली जाते आणि एका मशीनपुरती मर्यादित असते. Claude Code च्या documentation मध्येही हाच फरक स्पष्ट केला आहे: CLAUDE.md मध्ये तुम्ही लिहिलेल्या "Instructions and rules" असतात, auto memory मध्ये Claude लिहित असलेले "Learnings and patterns" असतात आणि memory directory वेगवेगळ्या मशीनमध्ये share होत नाही. याची सोपी चाचणी अशी आहे: एखादी बाब fresh clone करणाऱ्या सहकाऱ्यासाठीही खरी असणे आवश्यक असेल, तर ती memory मध्ये ठेवता येत नाही. sessions दरम्यान agent memory कशी टिकते या विषयाच्या त्या भागाचे स्पष्टीकरण देते.

Skill ही तिसरी गोष्ट आहे. AGENTS.md प्रत्येक session मध्ये load होणारा context आहे; skill ही गरज असेल तेव्हा load होणारी procedure आहे. Claude Code documentation मध्ये यासाठी उपयुक्त नियम दिला आहे: "जर एखादी entry multi-step procedure असेल किंवा codebase च्या केवळ एका भागासाठी महत्त्वाची असेल, तर ती skill किंवा path-scoped rule मध्ये हलवा." या वाक्याचा दुसरा भाग nested AGENTS.md ने नेमका सोडवला जातो. पहिला भाग agent skills साठी आहे. तीच procedure एकापेक्षा अधिक repository मध्ये आवश्यक असेल, तर तीच paragraphs दहा वेगवेगळ्या AGENTS.md files मध्ये paste करण्याऐवजी repos मध्ये skill share करा.

Upstream नुसार, "at time of writing the main OpenAI repo has 88 AGENTS.md files". हा आकडा संपूर्ण मुद्दा स्पष्ट करतो. मोठ्या repository ला अधिक मोठी file आवश्यक नसते. त्याऐवजी code चे वर्णन करणाऱ्या अधिक लहान files आवश्यक असतात. प्रत्येक file तिने वर्णन केलेल्या code च्या जवळ असावी आणि तो code शेवटचा बदलणाऱ्या व्यक्तीच्या मालकीची असावी.

FAQ

नेस्टेड AGENTS.md मूळ फाइलची जागा घेते की तिच्यात भर घालते?

ती मूळ फाइलमध्ये भर घालते. Upstream मध्ये "सर्वांत जवळची फाइल प्राधान्य घेते" असे म्हटले आहे. याचा अर्थ संघर्ष झाल्यावर काय होते, असा आहे; कोणत्या फाइल्स लोड केल्या जातात, असा नाही. Codex "मूळापासून खाली येताना फाइल्स जोडतो आणि त्यांना रिकाम्या ओळींनी एकत्र करतो". Claude Code देखील त्या फाइल्स override करण्याऐवजी working directory पासून वरच्या दिशेने जाताना सापडणारी प्रत्येक फाइल जोडतो. दोन फाइल्समध्ये एकाच विषयाबाबत वेगवेगळ्या सूचना असतील, तेव्हाच सर्वांत जवळची फाइल लागू होते. सामायिक नियम एकदाच root मध्ये लिहा आणि ते प्रत्येक directory मध्ये पुन्हा लिहू नका.

root AGENTS.md फाइल किती मोठी असावी?

तुम्ही त्या repository मध्ये केलेल्या प्रत्येक request वर ती फाइल जोडली गेली तरी तुम्हाला अडचण वाटणार नाही, इतकी ती लहान असावी. कारण प्रत्यक्षात तसेच होते. Claude Code च्या documentation मध्ये प्रत्येक फाइल 200 lines पेक्षा कमी ठेवण्याचे लक्ष्य सुचवले आहे आणि मोठ्या फाइल्स "पालनाची पातळी कमी करतात" असा इशारा दिला आहे. Codex संयुक्त instruction files चे merging default ने 32 KiB वर थांबवतो. तुमची root फाइल चार services चे documentation ठेवत असेल, तर कोणत्याही एका task साठी तिचा बहुतांश भाग अनावश्यक असतो. तपशील per-directory files मध्ये हलवा आणि मागे एक नकाशा ठेवा.

या फाइल्स कालबाह्य होऊ नयेत यासाठी काय करावे?

root फाइलमध्ये एक नियम ठेवा: एखाद्या directory मधील code बदलणाऱ्या व्यक्तीने त्याच commit मध्ये त्या directory ची AGENTS.md देखील अद्ययावत करावी. फाइल code च्या शेजारी ठेवल्यामुळे हा नियम प्रत्यक्षात पाळला जातो, कारण बदल त्याच pull request diff मध्ये येतो आणि तो diff मानव आधीच पाहत असतो. बदललेल्या प्रत्येक path ला त्याच्या वरच्या स्तरावरील सर्वांत जवळच्या AGENTS.md शी जोडणारा CI warning जोडा. तसेच वेळोवेळी प्रत्येक फाइलमधील git log -1 --format=%cs ची तुलना ती फाइल ज्या directory चे documentation करते, त्या directory वर चालवलेल्या त्याच command शी करा.

Claude Code AGENTS.md फाइल्स वाचतो का?

नाही. August 2026 पर्यंतच्या documentation मध्ये "Claude Code CLAUDE.md वाचतो, AGENTS.md नाही" असे नमूद केले आहे. त्याच directory मध्ये CLAUDE.md तयार करा आणि पहिल्या line वर @AGENTS.md ठेवा. यामुळे shared file लोड होते आणि त्याखाली Claude-specific instructions जोडता येतात. काहीही अतिरिक्त जोडायचे नसल्यास ln -s AGENTS.md CLAUDE.md ने तयार केलेला symlink कार्य करतो. मात्र Windows वर त्यासाठी Administrator rights किंवा Developer Mode आवश्यक आहे. एखाद्या session मध्ये /context चालवा आणि Memory files अंतर्गत ती फाइल दिसत असल्याची खात्री करा.

एखादा नियम फक्त काही वेळाच लागू होत असेल, तर तो कुठे ठेवावा?

AGENTS.md मध्ये ठेवू नका. ही फाइल प्रत्येक session मध्ये लोड होते. त्यामुळे तिच्यातील प्रत्येक line तुम्ही प्रत्यक्षात लिहिलेल्या request चे लक्ष वेधून घेण्यासाठी स्पर्धा करते. अधूनमधून आवश्यक असलेली, अनेक steps असलेली procedure skill मध्ये ठेवावी. ती मागणीनुसार लोड होते. एका directory ला लागू होणारा नियम त्या directory च्या AGENTS.md मध्ये ठेवावा. directory tree किंवा dependency list यांसारखी agent थेट code मधून वाचू शकत असलेली माहिती कोणत्याही ठिकाणी ठेवण्याची गरज नाही.