doxతో AGENTS.mdని ఆటోమేటిక్‌గా తాజాగా ఉంచడం

మూడు వారాల తర్వాత మీ AGENTS.md ఎందుకు తప్పుగా మారుతుంది

AGENTS.md ఫైల్‌కు కోడ్‌తో ఎలాంటి అనుసంధానం లేకపోవడం వల్ల అది కాలక్రమేణా పాతబడుతుంది. రిపాజిటరీ ఒక నిర్దిష్ట స్థితిలో ఉన్న రోజున దాన్ని చేతితో ఒకసారి రాస్తారు. తరువాత test runner మారుతుంది, package పేరు మారుతుంది, service తొలగించబడుతుంది. అయినా ఆ ఫైల్ మాత్రం జూన్ నెల పరిస్థితినే వివరిస్తుంది. ఏ build step కూడా దాన్ని చదవదు కాబట్టి ఏదీ విఫలం కాదు.

Agent దాన్ని చదివి నిజమని నమ్ముతుంది. మీకు ఖర్చు కలిగించేది ఇదే. AGENTS.md లేని రిపాజిటరీలో coding agent పని ప్రారంభించే ముందు పరిసరాలను పరిశీలిస్తుంది. తప్పుగా ఉన్న AGENTS.md ఉన్న రిపాజిటరీలో అది పరిశీలించడం ఆపేస్తుంది, ఎందుకంటే దాని వద్ద ఇప్పటికే సమాధానం ఉందని భావిస్తుంది. మీ ఫైల్‌లో పేర్కొన్న command ను అది అమలు చేస్తుంది, shell Missing script: "test" కు సమాధానం ఇస్తుంది. ఇప్పుడు agent ఊహించడం ప్రారంభిస్తుంది. మీరు documentation లో హామీ ఇచ్చిన script ను చేర్చడానికి అది తరచుగా package.json ను సవరిస్తుంది. పాతబడిన ఫైల్ నిశ్శబ్దంగా విఫలం కాలేదు. మీరు కోరని edit కు అది కారణమైంది.

దానికి dox ఒక పరిష్కారం. ఇది agent కోసం రాసిన నియమాల సమాహారం. పనిని పూర్తిచేయడంలో documentation ను నవీకరించడాన్ని కూడా భాగంగా చేస్తుంది. అందువల్ల ఆ documentation ను తప్పుగా మార్చిన code తో పాటు, అదే commit లో ఫైల్ కూడా మారుతుంది.

dox అంటే ఏమిటి, ఏమి కాదు

dox ఒకే Markdown ఫైల్. Repository agent0ai/dox, ఇది MIT లైసెన్స్‌లో ఉంది. 11 August 2026 నాటికి మొత్తం project ఒక 3906-byte AGENTS.md, ఒక README, ఒక LICENSE మరియు రెండు images‌తో కూడి ఉంది. Install చేయడానికి package లేదు. Runtime కూడా లేదు.

ఇది ముఖ్యమైన విషయం. ఎందుకంటే generator అనే పదం మీ code‌ను parse చేసే program‌ను సూచిస్తుంది. మీ code‌ను ఏదీ parse చేయదు. dox అనేది మీ coding agent చదివే contract. మీ agent generator. dox దానికి docs ఎప్పుడు చదవాలి, వాటిని ఎప్పుడు తిరిగి రాయాలి, ప్రతి document ఏ రూపంలో ఉండాలి అనే instruction set‌ను అందిస్తుంది.

ఈ file‌లో పది sections ఉన్నాయి. వాటిలో రెండు sections ప్రధాన పనిని చేస్తాయి. "Read Before Editing" section agent‌కు repository root నుంచి అది మార్చబోయే ప్రతి path వరకు వెళ్లి, ప్రతి మార్గంలో ఉన్న ప్రతి AGENTS.md‌ను ప్రస్తుత session‌లో తప్పనిసరిగా చదవాలని చెబుతుంది. Memoryపై ఆధారపడకూడదు. "Update After Editing" section ప్రకారం ప్రతి meaningful change‌కు DOX pass అవసరం. అంటే task పూర్తయిందిగా పరిగణించే ముందు documentation update step‌ను అమలు చేయాలి. Purpose, structure, workflow, permissions లేదా user preferences మారితే, ఈ pass అత్యంత సమీప owning document‌ను update చేస్తుంది.

మిగిలినది document రూపానికి సంబంధించినది. Child AGENTS.md‌కు default section order ఉంటుంది: Purpose, Ownership, Local Contracts, Work Guidance, Verification, మరియు Child DOX Index. Root file‌లో project-wide rulesతో పాటు top-level Child DOX Index ఉంటుంది. Agent child documents‌ను ఈ index ద్వారా కనుగొంటుంది. "Closeout" అనేది task చివర agent అమలు చేసే checklist. ఇందులో మార్చిన paths‌ను chain‌తో మళ్లీ తనిఖీ చేయడం, అత్యంత సమీప owning docs‌ను update చేయడం, ప్రభావితమైన ప్రతి index‌ను refresh చేయడం, contradictions‌ను తొలగించడం, ఉన్న verification‌ను అమలు చేయడం, అలాగే ఉద్దేశపూర్వకంగా మార్చకుండా వదిలిన docs ఏవో నివేదించడం ఉంటాయి.

main కి కాకుండా ఒక commit కు pin చేయండి

రిజిటరీలో tags లేదా releases లేవు. అందువల్ల pin చేయడానికి version number లేదు. బదులుగా commit ను pin చేయండి. ప్రస్తుత AGENTS.md commit f34ec7ad1055d3393887e5a2670e8cb7320c9165 వద్ద ఉంది. ఇది 1 August 2026 తేదీకి సంబంధించినది.

mkdir -p .agent
curl -fsSL -o .agent/dox-f34ec7a.md \
  https://raw.githubusercontent.com/agent0ai/dox/f34ec7ad1055d3393887e5a2670e8cb7320c9165/AGENTS.md
wc -c .agent/dox-f34ec7a.md

wc -c, 3906 ను print చేయాలి. వేరే number వస్తే, ఈ guide వివరించే file ను మీరు fetch చేయలేదని అర్థం. కాబట్టి దానిని నమ్మే ముందు చదవండి. Commit hash తప్పుగా టైప్ చేస్తే, -f curl ను curl: (22) The requested URL returned error: 404 తో ఆపి ఎలాంటి content ను write చేయదు. తరువాత wc -c, 0 ను print చేస్తుంది. File అసంపూర్ణంగా ఉండటం కంటే file లేకపోవడమే మంచిది. లేకపోతే agent సగం contract ను మాత్రమే అనుసరించి, అది అసంపూర్ణమని తెలుసుకోదు.

cp .agent/dox-f34ec7a.md AGENTS.md
git add AGENTS.md .agent/dox-f34ec7a.md
git commit -m "Add DOX rules (agent0ai/dox @ f34ec7a)"

ఈ cp ఇంకా AGENTS.md లేని repository కోసం ఉద్దేశించబడింది. మీ వద్ద ఇప్పటికే ఒకటి ఉంటే, దానిని overwrite చేయవద్దు. మీ existing content పైన dox sections ను ఉంచండి. మీ స్వంత rules ను వాటి కింద ఉంచండి. తరువాత మొత్తం ఫలితాన్ని మొదటి నుంచి చివరి వరకు ఒకసారి చదవండి. పరస్పరం విరుద్ధమైన రెండు documents ఉంటే, agent చివరిగా చదివిన line ను అనుసరించవచ్చు.

తరువాత repository లోపల మీ agent ను మొదటి pass కోసం అడగండి. README లో ఖచ్చితమైన wording ఉంది:

Initialize DOX tree for this project now.

ఇది child AGENTS.md files మరియు వాటిని సూచించే indexes ను సృష్టిస్తుంది. ఇది చేసిన పనిని నమ్మే ముందు పరిశీలించండి:

git status --short
find . -name AGENTS.md -not -path './.git/*' | sort

ఆ find output లోని ప్రతి file, దాని పైన ఎక్కడో ఉన్న Child DOX Index లో కనిపించాలి. ఏ index ప్రస్తావించని child document ను agent మిస్ చేయవచ్చు. ఎందుకంటే అది నడుస్తున్న path పై నేరుగా లేని documents ను కనుగొనడానికి index ను ఉపయోగిస్తుంది.

dox ఏమి చూడగలదు, ఏమి తెలుసుకోలదు

మీ tree ను రూపొందించే agent repository ను చదువుతుంది. అందువల్ల repository లో ఉన్న ఏదైనా inventory లోకి వెళ్లవచ్చు: directory layout, package manifests మరియు lockfiles, package.json లేదా Makefile లేదా pyproject.toml లోని scripts, CI workflow files, Dockerfiles, entry points, అలాగే మీ వద్ద ఉంటే CODEOWNERS. వీటి ఆధారంగా రూపొందించిన inventory నిజంగా self-maintaining గా ఉంటుంది. ఒక package స్థానం మారితే, తదుపరి pass దాన్ని వివరించే line ను కూడా మార్చుతుంది.

క్రిందివన్నీ మీరు స్వయంగా పేర్కొనాలి, ఎందుకంటే అవి repository లో ఉండవు:

• ఒక rule ఎందుకు ఉందో. దాన్ని అవసరం లేని complexity గా భావించి agent తొలగించకుండా ఆపేది ఇదే
• పనిచేస్తున్న రెండు paths లో ఏది supported path, ఏది తొలగించడానికి వేచి ఉన్న path అనేది
• repository వెలుపల ఉన్న ఏదైనా విషయం, ఉదాహరణకు staging environment లేదా ఒక dependency ను రెండు versions వెనుక pin చేయడానికి కారణం
• వచ్చే వారం మీరు చేయాలని అనుకుంటున్న పని. current గా ఉన్న file కు useful గా ఉన్న file కు మధ్య ఇదే తేడా

dox కు తన గురించి ఈ విషయం తెలుసు. Project యొక్క ప్రస్తుత standards లేదా user instructions ను Work Guidance ప్రతిబింబించాలి అని దాని స్వంత rules చెబుతున్నాయి. అవి ఇంకా లేకపోతే ఆ section ను ఖాళీగా ఉంచాలి. Verification ఇప్పటికే ఉన్న check ను ప్రతిబింబించాలి. అందువల్ల repository లో test framework లేకపోతే, అది ఏర్పడే వరకు ఆ section ఖాళీగానే ఉంటుంది. ఒక standard ను కల్పించే generated file, ఖాళీ section కంటే చెత్తది. ఎందుకంటే అప్పుడు agent ఆ కల్పిత standard ను అమలు చేయడం ప్రారంభిస్తుంది.

రూపొందించిన inventoryలో చేతితో రాసిన ఉద్దేశాన్ని కలపవద్దు

Generated docs పై నమ్మకం కోల్పోయేలా చేసే failure ఇదే. Jobs queue single consumer గానే ఉండాలని వివరిస్తూ మీరు ఒక paragraph రాస్తారు. మూడు వారాల తరువాత ఒక pass ఆ fileను మళ్లీ రాస్తుంది. మీ paragraph కనుమరుగవుతుంది. అది ఎక్కువగా file names ను క్రమం మార్చే 40 lines diff లో దాగి ఉంటుంది. ఎవరూ దాన్ని గుర్తించరు.

మీకు రెండు mechanisms అవసరం. రెండింటినీ ఉపయోగించాలి.

మొదట, నిరంతరం అవసరమైన intent ను వేరే fileలో ఉంచండి. Design decisions మరియు వాటి వెనుక ఉన్న reasoning ను agent కోసం రాసిన DESIGN.md లో ఉంచండి. People కోసం ఉన్న notes ను AGENTS.md నుంచి HUMAN.md గా వేరు చేసిన చోట ఉంచండి. AGENTS.md లో inventory మరియు local contracts మాత్రమే ఉండాలి. Code మారినప్పుడు మారాల్సిన భాగం అదే.

రెండవది, AGENTS.md లోనే ఉండాల్సిన intent కు fence ఏర్పాటు చేయండి. దాన్ని markers లో చుట్టి, blockను human-owned గా పరిగణించండి:

## User Preferences

<!-- dox:keep start -->
The jobs queue stays single consumer. Ordering is the reason this service exists.
Deploys ship on Tuesday. A Friday deploy is a human decision, not an agent decision.
<!-- dox:keep end -->

Markdown comments pageపై render కావు. అయినా agent వాటిని చదువుతుంది. ఇప్పుడు ఈ block నిలిచి ఉందో లేదో తనిఖీ చేయగలిగేలా చేయండి. దాన్ని తొలగించే pass స్పష్టమైన failureకు దారితీయాలి. ప్రతి pull request పై CI (continuous integration)లో దీన్ని అమలు చేయండి:

git fetch -q origin main
sed -n '/dox:keep start/,/dox:keep end/p' AGENTS.md > /tmp/keep.head
git show origin/main:AGENTS.md | sed -n '/dox:keep start/,/dox:keep end/p' > /tmp/keep.base
diff -u /tmp/keep.base /tmp/keep.head

Blockలో మార్పు లేకపోతే diff ఏదీ print చేయదు మరియు 0తో exit అవుతుంది. ఏదైనా output వస్తే, ఆ pass human-owned textను మళ్లీ రాసిందని అర్థం. అప్పుడు ఒక వ్యక్తి దాన్ని approve చేయాలి లేదా revert చేయాలి. ఎవరైనా దీన్ని గుర్తుంచుకోవాల్సిన అవసరం లేకుండానే ఈ check అమలవుతుంది.

pull request పై timer కాకుండా regenerate చేయండి

పత్రాన్ని refresh చేయడానికి సరైన సమయం, దానిని తప్పుగా మార్చే commit చేసిన సమయమే. Structural change ఉన్న అదే pull request లో DOX pass ను చేర్చండి. అప్పుడు diff ను నిజంగా చదవగలిగేంత చిన్నదిగా ఉంచవచ్చు.

దీనిని తప్పనిసరి చేసే blocking check:

#!/usr/bin/env bash
set -euo pipefail
git fetch -q origin main
base=$(git merge-base origin/main HEAD)
changed=$(git diff --name-only "$base" HEAD)
if grep -qE '^(src|apps|packages)/' <<<"$changed" && ! grep -q 'AGENTS\.md$' <<<"$changed"; then
  echo "Code changed but no AGENTS.md was touched. Run a DOX pass, or say why not."
  exit 1
fi

మీ repository కు అనుగుణంగా paths ను సవరించండి. దీని ప్రయోజనం ఏమిటంటే, ఇది branch పైనే విఫలమవుతుంది. అక్కడ fix చేయడం తక్కువ ఖర్చుతో పూర్తవుతుంది. అలాగే reviewer చర్య తీసుకోగల కారణాన్ని ఇది చూపిస్తుంది.

Schedule ఒక backup మాత్రమే, mechanism కాదు. Branch లో ఎవరూ గుర్తించని మార్పులను weekly job గుర్తిస్తుంది: rebase వల్ల మారిన files, merge లో తొలగించిన package, ఇక లేని directory ను సూచించే document. దీన్ని ఒక చిన్న box పై run చేయండి. VPS పై coding agent ను run చేయడానికి ఉపయోగించే అదే box కావచ్చు. ఇది main కు push చేయకుండా pull request ను open చేయాలి.

#!/usr/bin/env bash
set -euo pipefail
cd /srv/src/myapp
git fetch -q origin
git switch -c "dox/refresh-$(date +%Y%m%d)" origin/main
# Your agent CLI goes on the next line, in whatever non-interactive mode it offers.
# Prompt: "Run a DOX pass over this repository. Change AGENTS.md files only."
git add '*AGENTS.md'
git commit -m "dox: refresh AGENTS.md tree" || { echo "nothing to refresh"; exit 0; }
git push -q -u origin HEAD
gh pr create --fill

ఆ comment ఉద్దేశపూర్వకంగా placeholder గా ఉంది. ప్రతి agent కు దాని స్వంత CLI (command line interface), అలాగే దాని స్వంత non-interactive flag ఉంటాయి. మీ version కు సరిపోని web page నుంచి copy చేసిన command, ఎవరూ error చూడని cron పరిసరంలో విఫలమవుతుంది. దాన్ని పూరించి, schedule చేయడానికి ముందు script ను చేతితో ఒకసారి run చేయండి. || exit 0 కూడా ముఖ్యమే: tree ఇప్పటికే current గా ఉంటే git commit, nothing to commit, working tree clean తో non-zero గా exit అవుతుంది. set -e కింద అది విజయవంతమైన run ను failure గా report చేస్తుంది.

ప్రతి pass కు tokens ఖర్చవుతాయి. ఎందుకంటే "Read Before Editing" ప్రతి task లో agent మొత్తం chain ను చదివేలా చేస్తుంది. ఇదే trade-off. మీరు ఇప్పటికే మీ agent run లకు ఎంత ఖర్చవుతుందో లెక్కిస్తున్నట్లయితే, దీన్ని గమనించడం ఉపయోగకరం.

Monorepos: అనేక contracts, ఒకే index

నలభై packages ఉన్న repository లో ఒకే root AGENTS.md ఉంచితే, ఎవరూ చదవని regeneration diff ఏర్పడుతుంది. అలాగే agent ప్రస్తుతం చేస్తున్న పనికి ఎక్కువగా సంబంధం లేని document తయారవుతుంది. దీనికి dox సమాధానం Child DOX Index. root లో repository మొత్తానికి వర్తించే rules ఉంటాయి. అది తన child files కు pointers ఇస్తుంది. ప్రతి స్థిరమైన boundary కు ప్రత్యేక file ఉంటుంది. ఈ tree ను ఎలా అమర్చాలి, nested files ను ఏ tools చదువుతాయో monorepos కోసం nested AGENTS.md files లో వివరించారు.

dox మార్చేది review surface. packages/api ను తాకే pull request లో documentation diff packages/api లో మాత్రమే ఉండాలి. మరెక్కడా ఉండకూడదు:

git diff --stat -- '*AGENTS.md'

ఒక package మార్పు కోసం ఆ command ఆరు files ను చూపిస్తే, tree సరిగ్గా అమర్చలేదు. Boundaries చాలా విస్తృతంగా ఉండవచ్చు. లేదా root లో ఉండాల్సిన rule ప్రతి child లోకి copy అయి ఉండవచ్చు. dox పరిష్కారాన్ని నేరుగా చెబుతుంది: విస్తృత rules parent docs లో ఉంచాలి. నిర్దిష్ట వివరాలను child docs లో ఉంచాలి. Duplicated rules వల్ల సాధారణ pass సమయంలో మొత్తం documentation మళ్లీ రాయబడుతుంది. ఒకే rules వేర్వేరు repositories అంతటా నిజంగా వర్తిస్తే, అది వేరే సమస్య. దానికి repositories అంతటా agent skills పంచుకోవడం మరింత అనుకూలమైన tool.

కోడ్‌ను పరిశీలించినట్లే diff ను సమీక్షించండి

చదవకుండానే రూపొందించిన documentation diff ను ఆమోదించడం సులభం. దాని వల్ల తప్పు file విడుదల అవుతుంది. రూపొందించిన code ను పరిశీలించే సమయంలో పాటించే జాగ్రత్తతోనే దీన్ని చదవండి. ఈ నాలుగు విషయాలను పరిశీలించండి.

• file ఇప్పుడు పేర్కొన్న command ను merge చేయడానికి ముందు మీరే run చేయాలి. కల్పిత build instructions అత్యంత సాధారణ వైఫల్య కారణం.
• ఉద్దేశాన్ని తెలిపిన deleted line. Additions తక్కువ నష్టాన్ని కలిగిస్తాయి. నష్టం జరిగేది deletions లోనే.
• absolute path, hostname, internal URL లేదా credential లా కనిపించే ఏదైనా విషయం
• ఇక ఉనికిలో లేని దాని inventory entry. దీన్ని ls ఒక్క క్షణంలో నిర్ధారిస్తుంది.

తర్వాత పరిమాణాన్ని wc -l AGENTS.md తో తనిఖీ చేయండి. root file రెండు వందల lines దాటితే దాన్ని విభజించాలి. మొత్తం chain విలువ ఏమిటంటే agent మొత్తం file ను కాకుండా అవసరమైన చిన్న భాగాన్ని మాత్రమే చదవడం.

విఫలమైనప్పుడు

pass మీ intent block ను తొలగించింది. పైన ఉన్న diff check తొలగించిన lines ను చూపిస్తుంది. git restore --source=origin/main AGENTS.md తో branch point నుండి file ను restore చేసి, తర్వాత touch చేయగల sections పేర్లను స్పష్టంగా పేర్కొనే మరింత పరిమిత instruction తో pass ను మళ్లీ run చేయండి.

రెండు branches రెండూ మళ్లీ generate చేశాయి. మీకు CONFLICT (content): Merge conflict in AGENTS.md మరియు file లో conflict markers <<<<<<< HEAD కనిపిస్తాయి. Markers ను చేతితో edit చేయవద్దు. ఈ file generated file కాబట్టి, merged tree పై fresh pass run చేయడం సరైన resolution.

agent file ను పూర్తిగా పట్టించుకోదు. మీ tool వాస్తవంగా ఏ filename ను read చేస్తుందో తనిఖీ చేయండి. అది వేరే file ను read చేస్తే, ln -s AGENTS.md CLAUDE.md తో అదే content వైపు దాన్ని point చేసి symlink ను commit చేయండి. ఇలా రెండు documents వేర్వేరుగా మారకుండా ఒకే source ను ఉంచవచ్చు. Filename ఇప్పటికే సరైనదై ఉండి, rules ఇంకా skip అవుతుంటే, document ను మళ్లీ rewrite చేయడానికి ముందు coding agents మీ instructions ను ఎందుకు పట్టించుకోవు అనే diagnosis ను run చేయండి.

tree లో ఎవరూ index చేయని children పెరిగాయి. find . -name AGENTS.md output ను parent documents లోని index entries తో పోల్చండి. ఏ index ప్రస్తావించని child ను agent నేరుగా దాటి వెళ్లవచ్చు.

Generator అవసరానికి మించినప్పుడు

ఒక package, ఒక test command, మరియు repository గురించి ఇద్దరికీ పూర్తి అవగాహన ఉంటే, ఆ ఇరవై పంక్తులను చేతితో రాయండి. ఇరవై పంక్తుల AGENTS.md త్వరగా పాతబడదు. అందువల్ల tree, index, CI check, weekly job అవసరాన్ని సమర్థించదు. Build మార్చినప్పుడు దాన్ని మళ్లీ చదవండి. మొత్తం maintenance ఖర్చు అంతే. దాని చుట్టూ ఉండే machinery ఖర్చుకంటే ఇది తక్కువ.

Repositoryలో ఏ ఒక్కరికీ పూర్తిగా గుర్తుండని boundaries ఉన్నప్పుడు dox కోసం ఖర్చు చేయడం సముచితం. ఉదాహరణకు, వేర్వేరు నియమాలు ఉన్న అనేక packages ఉండవచ్చు. లేదా అవసరమైన నేపథ్య అవగాహన లేకుండా contributors చేరవచ్చు. విలువ generated textలో లేదు. Documentation pull request విఫలమయ్యే కారణంగా మారడంలో ఉంది. Repositoryలోని ఏ file అయినా ప్రస్తుత స్థితిలో ఉండటానికి ఇదే ఏకైక కారణం.

FAQ

dox ఉపయోగించడానికి ఏదైనా ఇన్‌స్టాల్ చేయాలా?

లేదు. dox ఒకే Markdown ఫైల్, ఇది MIT లైసెన్స్‌లో అందుబాటులో ఉంది. 11 August 2026 నాటికి repositoryలో package లేదా releases ఏవీ లేవు. దాని కంటెంట్‌ను మీ projectలోని AGENTS.mdలోకి copy చేయాలి. ఆ తరువాత coding agent అక్కడి నియమాలను అనుసరిస్తుంది. మీరు copy చేసిన commitను, ఈ పాఠ్యం రాసే సమయానికి ఉన్న f34ec7ad1055d3393887e5a2670e8cb7320c9165ను, నిర్దిష్టంగా ఉంచండి. అలాగే మీ commit messageలో దాని పేరు నమోదు చేయండి. అప్పుడు మీ tree ఏ rules version ఆధారంగా నిర్మించబడిందో తరువాత తెలుసుకోవచ్చు.

నేను స్వయంగా రాసిన rulesను regeneration తొలగించకుండా ఎలా ఆపాలి?

ఉద్దేశాన్ని, inventoryని వేర్వేరుగా ఉంచండి. దీర్ఘకాలం నిలిచే reasoningను ప్రత్యేక documentలో ఉంచండి. AGENTS.mdలో తప్పనిసరిగా ఉండాల్సిన విషయాలను marked blockలో ఉంచండి. తరువాత ఆ blockను CIలో తనిఖీ చేయండి: దాన్ని branch నుంచి, origin/main నుంచి sedతో extract చేసి, రెండింటినీ diffతో compare చేయండి. ఏదైనా తేడా ఉంటే buildను విఫలమయ్యేలా చేయండి. అప్పుడు పెద్ద diffలో మార్పు గుర్తించబడకుండా వెళ్లిపోకుండా, ఒక వ్యక్తి దాన్ని approve చేయవచ్చు లేదా revert చేయవచ్చు.

AGENTS.mdను ఎంత తరచుగా regenerate చేయాలి?

దాన్ని తప్పుగా మార్చే pull requestలోనే చేయాలి. Structural change మరియు దానికి సంబంధించిన documentation ఒకే diffలో ఉండాలి. రెండింటినీ సమీక్షించడానికి అవసరమైన context ఎవరికైనా ఉండే ఏకైక సమయం అదే. Branch నుంచి తప్పించుకున్న drift కోసం weekly scheduled pass backupగా పనిచేయాలి. అది mainకు commit చేయకుండా pull requestను తెరవాలి.

Build commandsను root AGENTS.mdలో ఉంచాలా, childలో ఉంచాలా?

ఆ commandsకు బాధ్యత వహించే అత్యంత సమీప documentలో ఉంచాలి. Repository-wide rules మరియు child index rootలో ఉండాలి. ఒక packageకు మాత్రమే వర్తించే command ఆ packageలోని AGENTS.mdలో ఉండాలి. dox దూరం ఆధారంగా conflictsను పరిష్కరిస్తుంది: సమీప document local detailsను నియంత్రిస్తుంది. ఏ child కూడా parent ruleను బలహీనపరచకూడదు. అదే commandను ప్రతి childలో copy చేయడం వల్ల routine pass మొత్తం treeను తిరిగి రాస్తుంది.

చిన్న repositoryకి dox ఉపయోగకరమా?

సాధారణంగా కాదు. ఒక test command మరియు ఇరవై లైన్ల AGENTS.md ఉన్న ఒక package నెమ్మదిగా మాత్రమే పాతబడుతుంది. అది గుర్తించిన వెంటనే వచ్చే నిమిషంలో దాన్ని సరిచేయవచ్చు. Repositoryలో వేర్వేరు rules కలిగిన అనేక boundaries ఉన్నప్పుడు, లేదా నేపథ్య పరిజ్ఞానం లేని contributors ఉన్నప్పుడు dox ఖర్చు సమర్థించబడుతుంది. అప్పుడు documents chain, ఒక్క వ్యక్తి చేయని పనిని నిర్వహిస్తుంది.