dox سے AGENTS.md خودکار طور پر تازہ رکھیں

آپ کی AGENTS.md تین ہفتے بعد غلط کیوں ہو جاتی ہے

AGENTS.md فائل اس لیے پرانی ہو جاتی ہے کہ کوئی چیز اسے code سے مربوط نہیں کرتی۔ آپ اسے ایک بار خود لکھتے ہیں، اس دن جب repository ایک مخصوص حالت میں ہوتی ہے۔ پھر test runner تبدیل ہو جاتا ہے، کوئی package rename ہو جاتا ہے، کوئی service حذف ہو جاتی ہے، لیکن فائل اب بھی جون کی حالت بیان کرتی رہتی ہے۔ کچھ ناکام نہیں ہوتا، کیونکہ build کا کوئی مرحلہ اسے پڑھتا ہی نہیں۔

agent اسے پڑھتا ہے اور اس پر یقین کرتا ہے۔ اصل نقصان یہیں ہوتا ہے۔ ایسی repository جس میں AGENTS.md نہ ہو، coding agent کو کارروائی سے پہلے خود جائزہ لینے پر مجبور کرتی ہے۔ لیکن غلط AGENTS.md والی repository میں agent جائزہ لینا روک دیتا ہے، کیونکہ اسے جواب پہلے ہی مل چکا ہوتا ہے۔ وہ آپ کی فائل میں دیا گیا command چلاتا ہے، shell Missing script: "test" جواب دیتا ہے، اور اب agent اندازے لگانا شروع کر دیتا ہے۔ اکثر وہ package.json میں آپ کی documentation کے وعدہ کردہ script کو شامل کرنے کے لیے ترمیم کر دیتا ہے۔ پرانی فائل خاموشی سے ناکام نہیں ہوئی۔ اس نے ایسی ترمیم کروا دی جو آپ نہیں چاہتے تھے۔

dox اس مسئلے کا ایک حل ہے۔ یہ agent کے لیے لکھی گئی rules کا مجموعہ ہے، جو documentation کو update کرنا کام مکمل کرنے کا حصہ بناتا ہے۔ یوں فائل اسی commit میں تبدیل ہوتی ہے جس میں وہ code شامل ہوتا ہے جس نے اسے غلط بنایا تھا۔

dox کیا ہے، اور کیا نہیں ہے

dox ایک واحد Markdown فائل ہے۔ repository agent0ai/dox ہے، اس پر MIT license لاگو ہے، اور 11 August 2026 تک پورا project ایک 3906-byte AGENTS.md، ایک README، ایک LICENSE اور دو images پر مشتمل ہے۔ install کرنے کے لیے کوئی package نہیں اور کوئی runtime بھی نہیں ہے۔

یہ بات اہم ہے، کیونکہ generator کا لفظ ایسے program کا تصور دیتا ہے جو آپ کے code کو parse کرتا ہے۔ آپ کے code کو کچھ بھی parse نہیں کرتا۔ dox ایک contract ہے جسے آپ کا coding agent پڑھتا ہے: agent generator ہے، جبکہ dox وہ instruction set ہے جو اسے بتاتا ہے کہ docs کب پڑھنی ہیں، انہیں کب دوبارہ لکھنا ہے، اور ہر document کی ساخت کیا ہونی چاہیے۔

فائل میں دس sections ہیں، اور ان میں سے دو اصل کام کرتے ہیں۔ "Read Before Editing" agent کو بتاتا ہے کہ repository root سے ہر اس path تک جائے جسے وہ تبدیل کرنے کا ارادہ رکھتا ہے، اور ہر route پر موجود تمام AGENTS.md فائلیں اسی session میں پڑھے، memory پر انحصار کیے بغیر۔ "Update After Editing" اسے بتاتا ہے کہ ہر بامعنی تبدیلی کے لیے DOX pass ضروری ہے، یعنی documentation update step چلائے بغیر task مکمل نہیں سمجھا جائے گا۔ جب purpose، structure، workflow، permissions یا user preferences تبدیل ہوں تو یہ pass قریب ترین owning document کو update کرتا ہے۔

باقی حصہ ساخت سے متعلق ہے۔ child AGENTS.md میں sections کی default ترتیب یہ ہے: Purpose، Ownership، Local Contracts، Work Guidance، Verification، اور Child DOX Index۔ root file میں project-wide rules کے ساتھ top-level Child DOX Index بھی ہوتا ہے، جس کے ذریعے agent child documents دریافت کرتا ہے۔ "Closeout" وہ checklist ہے جسے agent task کے اختتام پر چلاتا ہے: تبدیل شدہ paths کو chain کے مقابل دوبارہ check کرنا، nearest owning docs کو update کرنا، ہر متاثرہ index کو refresh کرنا، متضادات حذف کرنا، موجودہ verification چلانا، اور رپورٹ کرنا کہ کن docs کو اس نے جان بوجھ کر تبدیل نہیں کیا۔

main کے بجائے dox کو ایک ہی commit پر pin کریں

Repository میں کوئی 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 پرنٹ کرنا چاہیے۔ مختلف number کا مطلب ہے کہ آپ نے وہ file fetch نہیں کی جس کی یہ guide وضاحت کرتی ہے، اس لیے اس پر اعتماد کرنے سے پہلے اسے پڑھیں۔ اگر commit hash غلط لکھ دیں تو -f، curl کو curl: (22) The requested URL returned error: 404 کے ساتھ روک دیتا ہے اور کوئی content نہیں لکھتا، جبکہ wc -c پھر 0 پرنٹ کرتا ہے۔ ادھوری 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 ایسی repository کے لیے ہے جس میں ابھی AGENTS.md موجود نہیں ہے۔ اگر آپ کے پاس پہلے سے ایک موجود ہے تو اسے overwrite نہ کریں۔ dox sections کو اپنے موجودہ content کے اوپر رکھیں، اپنے rules نیچے برقرار رکھیں، اور نتیجے کو ایک بار شروع سے آخر تک پڑھیں۔ ایک دوسرے سے متصادم دو documents ایسا agent پیدا کرتے ہیں جو آخر میں پڑھی گئی line پر عمل کرتا ہے۔

اس کے بعد repository کے اندر اپنے agent سے first 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 میں ظاہر ہونی چاہیے۔ جس child document کا کسی index میں ذکر نہ ہو، اسے agent miss کر سکتا ہے، کیونکہ index ہی وہ طریقہ ہے جس سے agent ان documents کو تلاش کرتا ہے جو اس path پر براہ راست موجود نہیں ہوتے جس پر وہ چل رہا ہے۔

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 کیوں موجود ہے؛ یہی بات agent کو اسے غیر ضروری پیچیدگی سمجھ کر ہٹانے سے روکتی ہے
• کام کرنے والے دو طریقوں میں سے کون سا supported ہے، اور کون سا حذف کیے جانے کا منتظر ہے
• repository سے باہر کی کوئی بھی بات، جیسے staging environment یا یہ وجہ کہ کسی dependency کو دو versions پیچھے کیوں pinned رکھا گیا ہے
• آپ اگلے ہفتے کیا کرنے کا ارادہ رکھتے ہیں؛ یہی current file اور useful file کے درمیان فرق ہے

dox اپنے بارے میں یہ بات جانتا ہے۔ اس کے اپنے rules کے مطابق Work Guidance میں project کے موجودہ standards یا user کی instructions کی عکاسی ہونی چاہیے، اور اگر ابھی کوئی standards موجود نہ ہوں تو section خالی چھوڑنا چاہیے۔ Verification میں موجودہ check کی عکاسی ہونی چاہیے، اس لیے repository میں test framework نہ ہونے کی صورت میں یہ section اس وقت تک خالی رہتا ہے جب تک ایسا framework موجود نہ ہو۔ ایسا generated file جو اپنی طرف سے کوئی standard بنا دے، خالی section سے بدتر ہوتا ہے، کیونکہ agent پھر اسی ایجاد کردہ standard کو نافذ کرے گا۔

تیار کردہ inventory میں ہاتھ سے لکھی گئی نیت شامل نہ ہونے دیں

یہ وہ خرابی ہے جس کی وجہ سے لوگ generated دستاویزات بنانا چھوڑ دیتے ہیں۔ آپ ایک پیراگراف لکھتے ہیں جس میں وضاحت ہوتی ہے کہ jobs queue میں صرف ایک consumer رہنا چاہیے۔ تین ہفتے بعد ایک pass فائل کو دوبارہ لکھتا ہے، اور آپ کا پیراگراف غائب ہو جاتا ہے۔ یہ سب چالیس سطروں کے ایسے diff کے اندر ہوتا ہے جس میں زیادہ تر صرف file names کی ترتیب بدلی ہوتی ہے، اس لیے کسی کی نظر نہیں پڑتی۔

آپ کو دونوں mechanisms درکار ہیں۔

پہلے، مستقل intent کو ایک الگ فائل میں منتقل کریں۔ Design decisions اور ان کی وجوہات agent کے لیے لکھی گئی DESIGN.md میں رکھیں، جبکہ لوگوں کے لیے موجود notes وہاں رکھیں جہاں آپ HUMAN.md کو AGENTS.md سے الگ کرتے ہیں۔ AGENTS.md میں پھر inventory اور local contracts رہیں۔ یہی وہ حصہ ہے جسے code تبدیل ہونے پر تبدیل ہونا چاہیے۔

دوسرے، اس intent کو fence کریں جسے AGENTS.md کے اندر رہنا ضروری ہے۔ اسے 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 صفحے پر 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

diff اس وقت کچھ print نہیں کرتا اور 0 کے ساتھ exit کرتا ہے جب block میں کوئی تبدیلی نہ ہوئی ہو۔ کسی بھی output کا مطلب ہے کہ pass نے human-owned text کو دوبارہ لکھا ہے، اس لیے کوئی شخص اس کی منظوری دے یا اسے revert کرے۔ یہ check کسی کے یاد رکھنے کے بغیر بھی برقرار رہتا ہے۔

pull request پر دوبارہ بنائیں، timer پر نہیں

دستاویز کو تازہ کرنے کا بہترین وقت وہ commit ہے جو اسے غلط بناتا ہے۔ DOX pass کو structural change والی اسی pull request میں شامل کریں، تاکہ 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

Paths کو اپنی repository کے مطابق تبدیل کریں۔ فائدہ یہ ہے کہ check branch پر ہی fail ہو جاتی ہے، جہاں fix کم لاگت میں ہو جاتا ہے، اور failure کی وجہ ایسی ہوتی ہے جس پر reviewer کارروائی کر سکتا ہے۔

Schedule backup ہے، mechanism نہیں۔ ہفتہ وار job ان مسائل کو پکڑ لیتی ہے جنہیں branch پر کسی نے محسوس نہیں کیا: rebase سے منتقل ہونے والی files، merge میں delete ہونے والا package، یا ایسی directory کا حوالہ دینے والی دستاویز جو اب موجود نہیں۔ اسے ایک چھوٹے box پر چلائیں، مثلاً وہی جسے آپ VPS پر coding agent چلانے کے لیے استعمال کر سکتے ہیں، اور اسے main پر push کرنے کے بجائے pull request کھولنے دیں۔

#!/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 ہوتا ہے۔ Web page سے copy کیا گیا ایسا command جو آپ کے version سے مطابقت نہ رکھتا ہو، cron کے اندر fail ہو جاتا ہے، جہاں کوئی error نہیں دیکھتا۔ اسے مکمل کریں اور schedule بنانے سے پہلے script کو ایک بار manually چلائیں۔ || 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" agent کو ہر task پر پوری chain پڑھنے پر مجبور کرتا ہے۔ یہی trade-off ہے، اور اگر آپ پہلے ہی اپنے agent کے run کی لاگت گن رہے ہیں تو اس کی نگرانی کرنا مفید ہے۔

Monorepos: متعدد معاہدے، ایک index

چالیس packages والی repository میں ایک root AGENTS.md ایسی regeneration diff پیدا کرتی ہے جسے کوئی نہیں پڑھتا، اور ایسا document بناتی ہے جو agent کے موجودہ کام سے زیادہ تر غیر متعلق ہوتا ہے۔ dox کا حل Child DOX Index ہے: root میں repository کی سطح کے قواعد رکھے جاتے ہیں اور اس کے children کی طرف اشارہ کیا جاتا ہے، جبکہ ہر مستقل boundary اپنی file کی مالک ہوتی ہے۔ اس tree کو کیسے ترتیب دینا ہے، اور کون سے tools nested files کو پڑھتے بھی ہیں، یہ monorepos کے لیے nested AGENTS.md files میں بیان کیا گیا ہے۔

dox جس چیز کو تبدیل کرتا ہے وہ review surface ہے۔ packages/api کو تبدیل کرنے والی pull request کو documentation diff صرف packages/api کے اندر پیدا کرنا چاہیے، اور کہیں نہیں:

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

اگر یہ command ایک package کی تبدیلی کے لیے چھ files دکھاتی ہے تو tree غلط ہے۔ یا تو boundaries بہت وسیع ہیں، یا root میں رکھنے والا کوئی rule ہر child میں copy کر دیا گیا ہے۔ dox اصلاح براہِ راست بیان کرتا ہے: وسیع rules parent docs میں رکھیں، اور ٹھوس تفصیلات child docs میں۔ Duplicated rules ہی معمول کے pass کو ہر چیز دوبارہ لکھنے پر مجبور کرتے ہیں۔ اگر واقعی یہی rules الگ repositories پر بھی لاگو ہوتے ہیں تو یہ مختلف مسئلہ ہے، اور repositories کے درمیان agent skills شیئر کرنا اس کے لیے بہتر tool ہے۔

diff کا code کی طرح جائزہ لیں

Generated documentation diff کو بغیر پڑھے approve کرنا آسان ہوتا ہے، اور اسی طرح غلط file release ہو جاتی ہے۔ اسے اسی شک کے ساتھ پڑھیں جو آپ generated code کے بارے میں رکھتے ہیں، اور چار چیزیں تلاش کریں۔

• file میں اب درج کیا گیا کوئی command، جسے merge کرنے سے پہلے خود run کرنا چاہیے۔ گھڑی ہوئی build instructions سب سے عام failure ہیں۔
• حذف کی گئی کوئی line جس میں مقصد یا ارادہ موجود تھا۔ additions معمولی ہوتی ہیں۔ اصل نقصان deletions سے ہوتا ہے۔
• کوئی absolute path، hostname، internal URL، یا credential جیسی کوئی چیز
• کسی ایسی چیز کا inventory entry جو اب موجود نہیں، جسے ls ایک سیکنڈ میں settle کر دیتا ہے

پھر wc -l AGENTS.md سے size چیک کریں۔ دو سو lines سے بڑی root file اسے تقسیم کرنے کا اشارہ ہے، کیونکہ اس chain کی پوری افادیت یہ ہے کہ agent ہر چیز کے بجائے متعلقہ چھوٹا حصہ پڑھتا ہے۔

جب یہ ناکام ہو جائے

Pass نے آپ کا intent block حذف کر دیا۔ diff check اوپر حذف کی گئی سطور دکھاتا ہے۔ git restore --source=origin/main AGENTS.md کے ذریعے file کو branch point سے restore کریں، پھر ایسی محدود instruction کے ساتھ pass دوبارہ چلائیں جس میں ان sections کے نام واضح ہوں جنہیں یہ تبدیل کر سکتا ہے۔

دونوں branches نے دوبارہ generation کی۔ File میں CONFLICT (content): Merge conflict in AGENTS.md اور conflict markers <<<<<<< HEAD نظر آتے ہیں۔ Markers کو دستی طور پر edit نہ کریں۔ File generated ہے، اس لیے درست resolution یہ ہے کہ merged tree پر fresh pass چلایا جائے۔

Agent file کو مکمل طور پر نظرانداز کرتا ہے۔ معلوم کریں کہ آپ کا tool اصل میں کون سا filename پڑھتا ہے۔ اگر یہ کوئی دوسری file پڑھتا ہے تو ln -s AGENTS.md CLAUDE.md کے ذریعے اسے اسی content کی طرف point کریں اور symlink commit کریں، تاکہ دو ایسی documents کے بجائے ایک source برقرار رہے جو وقت کے ساتھ مختلف ہو جائیں۔

Tree میں ایسے children شامل ہو گئے جنہیں کسی index میں درج نہیں کیا گیا۔ find . -name AGENTS.md output کا موازنہ parent documents میں موجود index entries سے کریں۔ جس child کا ذکر کسی index میں نہ ہو، agent اسے آسانی سے چھوڑ کر آگے بڑھ سکتا ہے۔

جب generator غیر ضروری بوجھ بن جائے

ایک package، ایک test command، اور repository سے واقف دو افراد ہوں تو بیس سطریں خود لکھیں۔ بیس سطروں والی AGENTS.md اتنی تیزی سے فرسودہ نہیں ہوتی کہ tree، index، CI check اور weekly job کا جواز بن سکے۔ Build تبدیل کرتے وقت اسے دوبارہ پڑھ لیں۔ دیکھ بھال کی پوری لاگت یہی ہے، اور یہ اس machinery کی لاگت سے کم ہے جو اس کے گرد بنائی جاتی ہے۔

جب repository میں ایسی boundaries ہوں جنہیں کوئی ایک شخص مکمل طور پر ذہن میں نہ رکھتا ہو تو dox کی لاگت دینا مفید ہے: مثلاً مختلف rules والے کئی packages، یا ایسے contributors جو پس منظر کی معلومات کے بغیر شامل ہوتے ہیں۔ قدر generated text میں نہیں ہے۔ قدر یہ ہے کہ documentation ایسی چیز بن جاتی ہے جس کی خلاف ورزی پر pull request fail ہو سکتی ہے۔ یہی واحد وجہ ہے کہ repository کی کوئی file تازہ حالت میں برقرار رہتی ہے۔

FAQ

dox استعمال کرنے کے لیے کیا مجھے کچھ install کرنا ہوگا؟

نہیں۔ dox ایک ہی Markdown فائل ہے، MIT license کے تحت ہے، اور 11 August 2026 تک repository میں کوئی package یا release موجود نہیں ہے۔ آپ اس کے مواد کو اپنے project کی AGENTS.md میں copy کرتے ہیں، اور آپ کا coding agent وہیں سے rules پر عمل کرتا ہے۔ جو commit آپ نے copy کیا ہے اسے pin کریں، تحریر کے وقت f34ec7ad1055d3393887e5a2670e8cb7320c9165، اور اپنے commit message میں اس کا نام درج کریں تاکہ بعد میں معلوم ہو سکے کہ آپ کی tree کس version کے rules کے تحت تیار ہوئی تھی۔

میں regeneration کو اپنے ہاتھ سے لکھی ہوئی rules حذف کرنے سے کیسے روکوں؟

Intent اور inventory کو الگ رکھیں۔ پائیدار reasoning ایک الگ document میں رکھیں، اور جو کچھ AGENTS.md کے اندر رہنا ضروری ہو اسے ایک marked block میں رکھیں۔ پھر اس block کو CI میں check کریں: اسے branch سے اور origin/main سے sed کے ذریعے extract کریں، دونوں کا diff کے ساتھ موازنہ کریں، اور کسی بھی فرق کی صورت میں build ناکام کریں۔ اس طرح تبدیلی کو کسی بڑے diff کے اندر غیر محسوس طور پر گزرنے دینے کے بجائے کوئی شخص اسے approve یا revert کرتا ہے۔

مجھے AGENTS.md کتنی بار regenerate کرنا چاہیے؟

اس pull request میں جس سے یہ غلط ہو جائے۔ Structural change اور اس کی documentation ایک ہی diff میں ہونی چاہیے، کیونکہ یہی وہ وقت ہوتا ہے جب کوئی شخص دونوں کا جائزہ لینے کے لیے مکمل context رکھتا ہے۔ ہفتہ وار scheduled pass اس drift کے لیے backup ہے جو branch سے گزر گئی ہو، اور اسے main میں commit کرنے کے بجائے pull request کھولنی چاہیے۔

Build commands root AGENTS.md میں ہونے چاہییں یا child میں؟

اس nearest document میں جو ان commands کا مالک ہو۔ Repo-wide rules اور child index root میں رہتے ہیں۔ جو command صرف ایک package پر لاگو ہوتی ہے وہ اس package کی AGENTS.md میں رہتی ہے۔ dox distance کے ذریعے conflicts حل کرتا ہے: جو document زیادہ قریب ہو وہ local details کو control کرتا ہے، اور کوئی child parent rule کو کمزور نہیں کر سکتا۔ ہر child میں ایک ہی command copy کرنا وہ وجہ ہے جس سے routine pass پوری tree کو دوبارہ لکھ دیتا ہے۔

کیا چھوٹی repository کے لیے dox قابلِ استعمال ہے؟

عموماً نہیں۔ ایک package، ایک test command اور بیس سطروں کی AGENTS.md آہستہ خراب ہوتی ہے، اور اس کے نظر آنے کے فوراً بعد آپ اسے ایک منٹ میں درست کر سکتے ہیں۔ dox اس وقت اپنی لاگت پوری کرتا ہے جب repository میں مختلف rules والی کئی boundaries ہوں یا ایسے contributors ہوں جن کے پاس پس منظر کی معلومات نہ ہوں، کیونکہ اس صورت میں documents کا chain وہ کام کر رہا ہوتا ہے جو کوئی ایک شخص نہیں کر رہا۔