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 संपादित करताना 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 वापरतात आणि instructions चे पालन कमी करतात." Codex च्या default project_doc_max_bytes नुसार, instruction files चा एकत्रित आकार 32 KiB झाल्यावर तो पुढील files merge करणे थांबवतो. चार services चे documentation असलेली root file प्रत्येक task साठी त्या budget मधील तीन चतुर्थांश भाग अनावश्यकपणे वापरते.

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

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

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

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

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

आणि conflicts बाबत:

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

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

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

यातून दोन व्यावहारिक निष्कर्ष निघतात. Root फाइल repository मधील प्रत्येक session साठी prefix असते. त्यामुळे तिची प्रत्येक ओळ आठवड्यात शंभर वेळा येणारा खर्च समजून लिहा. Per-directory फाइल agent दुसऱ्या ठिकाणी काम करत असताना load होत नाही. त्यामुळे तिथे तपशीलवार सूचना ठेवणे स्वस्त आणि योग्य ठरते.

ही वर्तणूक 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.

प्रत्येक directory मधील file मध्ये तपशील असतो. त्या 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.

Worker file ची रचनाही अशीच असते, पण त्यातील मजकूर वेगळा असतो: install command, pytest -q, consumer ने idempotent का राहिले पाहिजे याचे कारण आणि tests यशस्वी होण्यापूर्वी चालवावे लागणारे migration. Agent कडून होणारी हानी थांबवणारे नियम infra file मध्ये लिहा. 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 मधील विभागणी ही सीमा वाक्यागणिक स्पष्ट करते. तसेच code ची रचना अशी का आहे हे नोंदवणारी DESIGN.md ही तिसऱ्या file चे स्पष्टीकरण देते; त्या file मध्ये commands ऐवजी निर्णयांची कारणे नोंदवली जातात.

कोड बदलल्यावर फाइल कोण अपडेट करतो?

एक नियम ठेवा आणि तो root फाइलमध्ये लिहा: एखाद्या directory मधील कोड बदलणारी व्यक्ती त्याच commit मध्ये त्या directory मधील AGENTS.md देखील अपडेट करेल.

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

pull request वर तपासणी लावून या नियमाला आधार द्या. ही तपासणी बदललेल्या प्रत्येक फाइलच्या वरच्या स्तरांमध्ये असलेली सर्वात जवळची 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 यामुळे flag होतात, कारण दोन्हींमध्ये slash असतो आणि त्यापैकी कोणतेही disk वरील file नसते.

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

No such file or directory

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

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

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

Shared lines वर tool-specific lines जोडायच्या असतील, तर import form योग्य आहे. हे services/worker/CLAUDE.md मध्ये ठेवा:

@AGENTS.md

## Claude Code

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

Tool-specific काहीही जोडायचे नसेल, तर symlink form योग्य आहे.

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

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

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

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

AGENTS.md तुम्ही लिहिता, ते git मध्ये commit केले जाते, pull request मध्ये त्याचे पुनरावलोकन केले जाते आणि 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 मध्ये ठेवता येणार नाही. सत्रांदरम्यान agent memory कशी टिकते या विषयाच्या अर्ध्या भागाचे स्पष्टीकरण देते.

Skill ही तिसरी गोष्ट आहे. AGENTS.md प्रत्येक sessionमध्ये load होणारा context आहे; skill ही आवश्यकतेनुसार load होणारी procedure आहे. Claude Codeच्या documentation मध्ये वापरता येईल असा नियम दिला आहे: "If an entry is a multi-step procedure or only matters for one part of the codebase, move it to a skill or a path-scoped rule instead." या वाक्याचा दुसरा भाग 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 आवश्यक नसते. त्याऐवजी अधिक छोट्या files आवश्यक असतात. प्रत्येक fileने ती ज्या codeचे वर्णन करते त्याच्या शेजारी असावे आणि तो code शेवटचा बदलणाऱ्या व्यक्तीच्या मालकीचे असावे.

FAQ

nested AGENTS.md ही root फाइलची जागा घेते की त्यात भर घालते?

ती root फाइलमध्ये भर घालते. Upstream मध्ये "the closest one takes precedence" असे म्हटले आहे. याचा अर्थ conflict झाल्यावर काय होते, हे स्पष्ट होते; कोणत्या फाइल्स load केल्या जातात, हे नाही. Codex "concatenates files from the root down, joining them with blank lines", तर Claude Code working directory पासून वरच्या दिशेने जाताना सापडणाऱ्या प्रत्येक फाइलला concatenate करते; त्या एकमेकींना override करत नाहीत. दोन फाइल्समध्ये त्याच विषयाबाबत वेगवेगळ्या सूचना असतील, तेव्हाच जवळची फाइल लागू होते. सामायिक नियम root मध्ये एकदाच लिहा आणि प्रत्येक directory मध्ये त्यांची पुनरावृत्ती करू नका.

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

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

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

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

Claude Code AGENTS.md files वाचते का?

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

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

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