dox দিয়ে AGENTS.md স্বয়ংক্রিয়ভাবে আপডেট রাখুন

তিন সপ্তাহ পরে আপনার AGENTS.md কেন ভুল

AGENTS.md ফাইল stale হয়ে যায়, কারণ কোনো কিছুই এটিকে code-এর সঙ্গে সংযুক্ত রাখে না। Repository যে অবস্থায় আছে, সেই অনুযায়ী আপনি নির্দিষ্ট একটি দিনে হাতে করে ফাইলটি একবার লিখে রাখেন। এরপর test runner বদলে যায়, কোনো package-এর নাম পরিবর্তিত হয়, কোনো service মুছে ফেলা হয়, কিন্তু ফাইলটি এখনও June মাসের অবস্থা বর্ণনা করে। কিছুই ব্যর্থ হয় না, কারণ কোনো build step ফাইলটি পড়ে না।

Agent ফাইলটি পড়ে এবং সেটির তথ্য বিশ্বাস করে। সমস্যার মূল খরচ এখানেই। কোনো AGENTS.md না থাকা repository-তে coding agent কাজ করার আগে নিজে পরিস্থিতি যাচাই করে। ভুল AGENTS.md থাকা repository-তে agent আর যাচাই করে না, কারণ তার কাছে ইতিমধ্যে একটি উত্তর আছে। এটি আপনার ফাইলে উল্লেখ করা command চালায়, shell উত্তর দেয় Missing script: "test", এবং তখন agent অনুমান করতে শুরু করে। প্রায়ই এটি package.json সম্পাদনা করে আপনার documentation-এ প্রতিশ্রুত script যোগ করে। Stale ফাইলটি নীরবে ব্যর্থ হয়নি। এটি এমন একটি edit ঘটিয়েছে, যা আপনি চাননি।

dox এর একটি সমাধান দেয়। এটি agent-এর জন্য লেখা কিছু rule-এর সমষ্টি। এই rule-গুলো documentation update করাকে কাজ শেষ করার অংশে পরিণত করে। ফলে যে code-এর কারণে ফাইলটি ভুল হয়েছে, সেই code-এর একই commit-এ ফাইলটিও পরিবর্তিত হয়।

dox কী এবং এটি কী নয়

dox একটি একক Markdown ফাইল। Repository হলো agent0ai/dox, এটি MIT লাইসেন্সের অধীনে প্রকাশিত, এবং 11 August 2026 অনুযায়ী পুরো project-এ একটি 3906-byte AGENTS.md, একটি README, একটি LICENSE এবং দুটি image রয়েছে। Install করার মতো কোনো package নেই এবং কোনো runtime-ও নেই।

এটি গুরুত্বপূর্ণ, কারণ generator শব্দটি এমন একটি program-এর ধারণা দেয়, যা আপনার code parse করে। কোনো কিছুই আপনার code parse করে না। dox হলো আপনার coding agent যে contract পড়ে: আপনার agent-ই generator, আর dox হলো সেই instruction set, যা agent-কে বলে কখন documentation পড়তে হবে, কখন তা পুনর্লিখতে হবে এবং প্রতিটি document-এর কাঠামো কেমন হবে।

ফাইলটিতে দশটি section আছে এবং এর মধ্যে দুটি মূল কাজ করে। "Read Before Editing" agent-কে বলে repository root থেকে সে যেসব path পরিবর্তন করতে চায়, সেগুলো পর্যন্ত এগোতে এবং প্রতিটি route-এ থাকা সব AGENTS.md বর্তমান session-এ পড়তে; memory-এর ওপর নির্ভর করা যাবে না। "Update After Editing" agent-কে বলে, প্রতিটি অর্থবহ পরিবর্তনের জন্য একটি DOX pass প্রয়োজন। অর্থাৎ task সম্পন্ন হয়েছে বলে গণ্য করার আগে documentation update step চালাতে হবে। Purpose, structure, workflow, permissions বা user preferences পরিবর্তিত হলে এই pass সবচেয়ে কাছের owning 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 document-গুলো খুঁজে পায়। "Closeout" হলো task-এর শেষে agent যে checklist চালায়: chain-এর সঙ্গে পরিবর্তিত path-গুলো আবার যাচাই করা, নিকটতম owning docs আপডেট করা, প্রভাবিত প্রতিটি index refresh করা, বিরোধপূর্ণ নির্দেশনা মুছে ফেলা, বিদ্যমান verification চালানো এবং ইচ্ছাকৃতভাবে কোন docs অপরিবর্তিত রাখা হয়েছে তা জানানো।

একটি commit-এ pin করুন, main-এ নয়

Repository-তে কোনো tag বা release নেই, তাই 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 হলে বুঝবেন, এই guide-এ বর্ণিত file-টি fetch করেননি। তাই file-টি যাচাই না করে বিশ্বাস করবেন না। 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 করবেন না। আপনার বিদ্যমান content-এর ওপরে dox section-গুলো রাখুন, নিজের rules নিচে রাখুন, এবং শুরু থেকে শেষ পর্যন্ত ফলাফলটি একবার পড়ুন। পরস্পরবিরোধী দুটি document থাকলে agent শেষবার পড়া line-টি অনুসরণ করতে পারে।

এরপর repository-এর ভিতরে আপনার agent-কে প্রথম pass চালাতে বলুন। README-তে সঠিক wording দেওয়া আছে:

Initialize DOX tree for this project now.

এটি child AGENTS.md file এবং সেগুলোর দিকে নির্দেশ করা index তৈরি করে। বিশ্বাস করার আগে এটি কী করেছে তা পরীক্ষা করুন:

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

ওই find output-এর প্রতিটি file-এর নাম উপরের কোনো না কোনো Child DOX Index-এ থাকা উচিত। কোনো index-এ উল্লেখ না থাকা child document agent বাদ দিতে পারে। কারণ যে path ধরে agent এগোচ্ছে, তার সরাসরি path-এ না থাকা document খুঁজে পাওয়ার উপায় হলো index।

dox কী দেখতে পারে এবং কী জানতে পারে না

আপনার tree তৈরি করা agent repository পড়ে। তাই repository-তে থাকা যেকোনো তথ্য inventory-তে অন্তর্ভুক্ত হতে পারে: directory layout, package manifest ও lockfile, package.json বা Makefile বা pyproject.toml-এর script, CI workflow file, Dockerfile, entry point এবং আপনার থাকলে CODEOWNERS। এগুলো থেকে তৈরি inventory সত্যিই self-maintaining হয়। কোনো package স্থানান্তরিত হলে পরবর্তী pass-এ সেটি বর্ণনা করা line-ও স্থানান্তরিত হয়।

নিচের সবকিছু আপনাকেই উল্লেখ করতে হবে, কারণ এগুলো repository-তে নেই এবং পড়া যায় না:

• কোনো rule কেন আছে; এটিই agent-কে সেটিকে অপ্রয়োজনীয় জটিলতা মনে করে সরিয়ে ফেলা থেকে বিরত রাখে
• কার্যকর দুইটি path-এর মধ্যে কোনটি supported এবং কোনটি মুছে ফেলার অপেক্ষায় আছে
• repository-এর বাইরের যেকোনো তথ্য, যেমন staging environment বা কোনো dependency-কে দুই version পিছনে pin করার কারণ
• আগামী সপ্তাহে আপনি কী করতে চান; এটিই একটি file বর্তমান থাকা এবং কার্যকর হওয়ার মধ্যে পার্থক্য

dox নিজের এই সীমাবদ্ধতা জানে। এর নিজস্ব rule অনুযায়ী, Work Guidance-এ project-এর বর্তমান standard বা user-এর নির্দেশনা প্রতিফলিত হতে হবে। এখনো কোনোটি না থাকলে section-টি খালি রাখতে হবে। Verification-এ বিদ্যমান কোনো check প্রতিফলিত হতে হবে। তাই repository-তে কোনো test framework না থাকলে সেখানে একটি যুক্ত না হওয়া পর্যন্ত section-টি খালি থাকবে। কোনো standard বানিয়ে ফেলা generated file খালি section-এর চেয়ে খারাপ, কারণ agent পরে সেই বানানো standard কার্যকর করবে।

উৎপন্ন inventory-তে হাতে লেখা অভিপ্রায় রাখবেন না

উৎপন্ন documentation দেখে মানুষ যে কারণে কাজ ছেড়ে দেয়, এটি তার একটি প্রধান কারণ। আপনি লিখলেন যে jobs queue-তে single consumer থাকতে হবে। তিন সপ্তাহ পরে একটি pass file-টি নতুন করে লেখে, এবং আপনার paragraph-টি হারিয়ে যায়। এটি ঘটে এমন একটি diff-এর মধ্যে, যেখানে মূলত 40টি file name-এর ক্রম বদলানো হয়েছে, তাই কেউ বিষয়টি ধরতে পারে না।

দুটি পদ্ধতি ব্যবহার করুন। দুটিই প্রয়োজন।

প্রথমত, স্থায়ী অভিপ্রায় আলাদা file-এ রাখুন। Design decision এবং তার পেছনের যুক্তি agent-এর জন্য লেখা DESIGN.md-তে রাখুন। মানুষের জন্য লেখা notes-এর ক্ষেত্রে AGENTS.md থেকে HUMAN.md আলাদা করুন। AGENTS.md-তে inventory এবং স্থানীয় contract রাখুন। Code পরিবর্তিত হলে এই অংশটিই পরিবর্তিত হওয়া উচিত।

দ্বিতীয়ত, যে অভিপ্রায় AGENTS.md-তেই রাখতে হবে, সেটিকে সুরক্ষিত করুন। সেটিকে marker-এর মধ্যে রাখুন এবং 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 comment page-এ render হয় না, কিন্তু agent সেগুলো পড়তে পারে। এখন block-টির অক্ষত থাকা যাচাইযোগ্য করুন, যাতে কোনো pass সেটি মুছে ফেললে স্পষ্টভাবে ব্যর্থ হয়। প্রতিটি 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 code দিয়ে শেষ হয়। কোনো output থাকলে বুঝতে হবে pass human-owned text নতুন করে লিখেছে। সে ক্ষেত্রে কোনো ব্যক্তি পরিবর্তনটি অনুমোদন করবেন অথবা revert করবেন। কাউকে এটি মনে রাখার প্রয়োজন ছাড়াই এই check কার্যকর থাকে।

Pull request-এ চালান, timer-এ নয়

কোনো document ভুল হয়ে যাওয়ার কারণ যে commit, সেটিই refresh করার সেরা সময়। 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 অনুযায়ী path পরিবর্তন করুন। এর সুবিধা হলো, branch-এই এটি ব্যর্থ হয়, যেখানে fix করা সহজ। ব্যর্থতার কারণও এমন থাকে, যার ভিত্তিতে reviewer ব্যবস্থা নিতে পারেন।

Schedule হলো backup, mechanism নয়। একটি weekly job branch-এ কেউ লক্ষ্য না করা সমস্যাগুলো ধরে: rebase-এর ফলে সরানো file, merge-এ মুছে যাওয়া package, অথবা এমন document যা আর বিদ্যমান নয় এমন directory-এর নাম উল্লেখ করে। এটি একটি ছোট box-এ চালান। একই box ব্যবহার করে VPS-এ coding agent চালাতে পারেন। Script-টি 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 থাকে। আপনার version-এর সঙ্গে না মেলা কোনো web page থেকে copy করা command cron-এর ভিতরে ব্যর্থ হবে, কিন্তু সেই error দেখার জন্য কেউ থাকবে না। এটি পূরণ করুন এবং schedule করার আগে script-টি একবার হাতে চালান। || exit 0-ও গুরুত্বপূর্ণ: tree ইতিমধ্যে current থাকলে git commit, nothing to commit, working tree clean সহ non-zero exit করে। আর set -e-এর অধীনে সেটি সুস্থভাবে সম্পন্ন হওয়া run-কেও failure হিসেবে report করবে।

প্রতিটি pass-এ token খরচ হয়, কারণ “Read Before Editing” নির্দেশনার ফলে agent-কে প্রতিটি task-এ পুরো chain পড়তে হয়। এটাই trade-off। আপনি যদি ইতিমধ্যে আপনার agent চালাতে কত খরচ হচ্ছে তা গণনা করেন, তাহলে বিষয়টি পর্যবেক্ষণ করা উচিত।

Monorepo: অনেক contract, একটি index

চল্লিশটি package থাকা একটি repository-তে একটি root AGENTS.md রাখলে এমন regeneration diff তৈরি হয়, যা কেউ পড়ে না। এছাড়া agent বর্তমানে যে কাজটি করছে, তার সঙ্গে document-টির বেশিরভাগ অংশই অপ্রাসঙ্গিক থাকে। dox-এর সমাধান হলো Child DOX Index: root-এ repository-জুড়ে প্রযোজ্য নিয়ম থাকে এবং সেখান থেকে child-গুলোর দিকে নির্দেশ করা হয়। প্রতিটি স্থায়ী boundary নিজের file-এর দায়িত্বে থাকে। এই tree কীভাবে সাজাতে হবে এবং কোন tool nested file পড়ে, তা monorepo-র nested AGENTS.md file-এ ব্যাখ্যা করা হয়েছে।

dox যে পরিবর্তন আনে, তা হলো review surface। packages/api-এ পরিবর্তন করা একটি pull request-এর documentation diff শুধু packages/api-এর ভেতরেই হওয়া উচিত:

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

একটি package-এর পরিবর্তনের জন্য ওই command যদি ছয়টি file দেখায়, তাহলে tree সঠিকভাবে সাজানো হয়নি। হয় boundary-গুলো অতিরিক্ত বিস্তৃত, নয়তো root-এ থাকার কথা এমন কোনো rule প্রতিটি child-এ কপি করা হয়েছে। dox সরাসরি সংশোধনটি নির্দিষ্ট করে: বিস্তৃত rule parent docs-এ থাকবে, আর নির্দিষ্ট detail child docs-এ থাকবে। একই rule বারবার কপি করাই routine pass-এ সবকিছু rewrite করায়। পৃথক repository-তে সত্যিই একই rule প্রযোজ্য হলে সেটি ভিন্ন সমস্যা। সে ক্ষেত্রে repository-গুলোর মধ্যে agent skill ভাগ করা বেশি উপযোগী tool।

কোডের মতো diff পর্যালোচনা করুন

কোনো generated documentation diff না পড়েই অনুমোদন করা সহজ। এভাবেই ভুল file release হয়ে যায়। Generated code পর্যালোচনার সময় যে সতর্কতা প্রয়োগ করবেন, এখানেও একইভাবে diff পড়ুন এবং চারটি বিষয় খুঁজুন।

• file-এ এখন উল্লেখ করা এমন কোনো command, যা merge করার আগে নিজে চালানো উচিত। বানানো build instruction-ই সবচেয়ে সাধারণ ব্যর্থতার কারণ।
• intent বহন করা কোনো deleted line। Addition যোগ করা সহজ। আসল ক্ষতি হয় deletion-এ।
• কোনো absolute path, hostname, internal URL অথবা credential-এর মতো দেখতে কোনো কিছু
• আর নেই এমন কোনো কিছুর inventory entry, যা ls এক সেকেন্ডে যাচাই করে

এরপর wc -l AGENTS.md দিয়ে আকার পরীক্ষা করুন। root file দুইশো line ছাড়িয়ে গেলে সেটিকে ভাগ করার কথা বিবেচনা করুন। কারণ এই chain-এর মূল সুবিধা হলো agent পুরো file না পড়ে ছোট প্রাসঙ্গিক অংশ পড়ে।

যখন এটি ব্যর্থ হয়

Pass আপনার intent block মুছে দিয়েছে। উপরের diff check সরিয়ে দেওয়া লাইনগুলো দেখায়। git restore --source=origin/main AGENTS.md ব্যবহার করে branch point থেকে file restore করুন। তারপর কোন section-গুলো পরিবর্তন করা যাবে তা নির্দিষ্ট করে আরও সীমিত instruction দিয়ে pass আবার চালান।

দুটি branch-ই নতুন করে তৈরি হয়েছে। File-এর মধ্যে CONFLICT (content): Merge conflict in AGENTS.md এবং conflict marker <<<<<<< HEAD দেখতে পাবেন। Marker হাতে সম্পাদনা করবেন না। File-টি generated, তাই সঠিক সমাধান হলো merged tree-এর ওপর নতুন করে pass চালানো।

Agent file-টি সম্পূর্ণ উপেক্ষা করছে। আপনার tool আসলে কোন filename পড়ে তা পরীক্ষা করুন। এটি যদি অন্য file পড়ে, তাহলে ln -s AGENTS.md CLAUDE.md ব্যবহার করে একই content-এর দিকে নির্দেশ করুন এবং symlink commit করুন। এতে পরস্পর থেকে পৃথক হয়ে যাওয়া দুটি document-এর বদলে একটি source বজায় থাকবে। Filename সঠিক থাকা সত্ত্বেও rules এড়িয়ে গেলে document আবার লেখার আগে coding agents কেন আপনার instruction উপেক্ষা করে বিষয়ক diagnosis চালান।

Tree-তে এমন child যোগ হয়েছে যেগুলো কেউ index করেনি। find . -name AGENTS.md output-এর সঙ্গে parent document-গুলোর index entry তুলনা করুন। কোনো child-এর উল্লেখ যদি কোনো index-এ না থাকে, agent সেটিকে সরাসরি অতিক্রম করে যেতে পারে।

জেনারেটর অতিরিক্ত হয়ে গেলে

একটি package, একটি test command এবং repository সম্পর্কে জানা দুজন ব্যক্তি থাকলে বিশটি লাইন হাতে লিখুন। বিশ-লাইনের AGENTS.md এত দ্রুত অপ্রচলিত হয় না যে তার জন্য একটি tree, একটি index, একটি CI check এবং একটি weekly job প্রয়োজন হবে। build পরিবর্তন করার সময় এটি আবার পড়ুন। এটাই সম্পূর্ণ maintenance cost, এবং এর পরিমাণ সেটিকে ঘিরে থাকা machinery-এর cost-এর চেয়ে কম।

repository-তে এমন boundary থাকলে dox ব্যবহার করা যুক্তিযুক্ত, যা কোনো একজন ব্যক্তি সম্পূর্ণভাবে মনে রাখতে পারেন না: যেমন ভিন্ন নিয়মসহ একাধিক package, অথবা এমন contributor যারা repository-এর পূর্বপরিচয় ছাড়াই কাজ শুরু করেন। এর মূল্য generated text-এ নয়। মূল্য হলো documentation এমন একটি বিষয় হয়ে ওঠে, যার কারণে একটি pull request ব্যর্থ হতে পারে। Repository-র কোনো file current থাকার একমাত্র কারণ এটিই।

FAQ

dox ব্যবহার করতে কি আমাকে কিছু ইনস্টল করতে হবে?

না। dox একটি Markdown file, এটি MIT licensed, এবং 11 August 2026 অনুযায়ী repository-তে কোনো package বা releases নেই। এর contents আপনার project-এর AGENTS.md-তে copy করুন; এরপর আপনার coding agent সেখানকার rules অনুসরণ করবে। আপনি যে commit copy করেছেন সেটি pin করুন, লেখার সময় যা ছিল f34ec7ad1055d3393887e5a2670e8cb7320c9165, এবং আপনার commit message-এ সেটির নাম লিখুন। তাহলে পরে বোঝা যাবে, আপনার tree কোন version-এর rules অনুসারে তৈরি হয়েছিল।

regeneration-এর কারণে আমার হাতে লেখা rules মুছে যাওয়া কীভাবে বন্ধ করব?

উদ্দেশ্য এবং inventory আলাদা রাখুন। স্থায়ী reasoning একটি আলাদা document-এ রাখুন, আর AGENTS.md-তে থাকা আবশ্যিক বিষয়গুলো একটি চিহ্নিত block-এর মধ্যে রাখুন। এরপর CI-তে block-টি পরীক্ষা করুন: branch এবং origin/main থেকে এটি sed দিয়ে extract করুন, diff দিয়ে দুটির তুলনা করুন, এবং কোনো পার্থক্য থাকলে build ব্যর্থ করুন। এরপর কোনো বড় diff-এর মধ্যে পরিবর্তনটি অজান্তে চলে যাওয়ার বদলে একজন ব্যক্তি সেটি অনুমোদন করবেন বা revert করবেন।

কত ঘন ঘন AGENTS.md regenerate করা উচিত?

যে pull request-এ এটি ভুল হয়েছে, সেই pull request-এ। কোনো structural change এবং তার documentation একই diff-এ থাকা উচিত, কারণ উভয়টি review করার context তখনই থাকে। একটি weekly scheduled pass হলো branch-এর বাইরে থেকে যাওয়া drift সামলানোর backup। এটি main-এ commit না করে একটি pull request খোলা উচিত।

Build command-গুলো root AGENTS.md-তে থাকবে, নাকি child document-এ?

যে nearest document এগুলোর মালিক, সেখানে রাখুন। Repo-wide rules এবং child index root-এ থাকবে। একটি package-এর ক্ষেত্রে প্রযোজ্য command সেই package-এর AGENTS.md-তে থাকবে। dox distance অনুযায়ী conflict resolve করে: কাছের document local details নিয়ন্ত্রণ করে, এবং কোনো child parent rule দুর্বল করতে পারে না। প্রতিটি child-এ একই command copy করলেই একটি routine pass পুরো tree rewrite করে।

একটি ছোট repository-এর জন্য dox কি উপযোগী?

সাধারণত নয়। একটি test command-সহ একটি package এবং বিশ-লাইনের AGENTS.md ধীরে পুরোনো হয়, এবং সমস্যা বুঝতে পারার পরের মিনিটেই তা ঠিক করা যায়। Repository-তে ভিন্ন rules-সহ একাধিক boundary থাকলে, অথবা background knowledge না থাকা contributor থাকলে dox তার খরচ সার্থক করে। কারণ তখন documents-এর chain এমন কাজ করে, যা কোনো একক ব্যক্তি একা করছেন না।