- Next.js 16 API पर किए गए मूल्यांकन में, प्रोजेक्ट रूट में शामिल
AGENTS.mddocument index ने skills-आधारित approach की तुलना में अधिक accuracy दर्ज की - skills एक domain knowledge package के रूप में काम करते हैं, जिसे एजेंट ज़रूरत पड़ने पर call करता है, लेकिन call की अस्थिरता के कारण default setting में pass rate सिर्फ 53% रहा
- इसके विपरीत, 8KB में compressed
AGENTS.mdindex ने सभी tests (Build, Lint, Test) में 100% pass rate हासिल किया - यह तरीका decision points हटाने, हमेशा उपलब्ध रहने, और ordering issues खत्म करने की वजह से proactive calling की तुलना में अधिक stable परिणाम दिखाता है
- framework maintainers version-matched document index को AGENTS.md में शामिल करके code generation accuracy बढ़ा सकते हैं
समस्या की पृष्ठभूमि
- AI coding agents की एक सीमा यह है कि training data अक्सर पुराने API versions पर आधारित होता है, इसलिए वे latest framework को ठीक से handle नहीं कर पाते
- Next.js 16 के
'use cache',connection(),forbidden()जैसे फीचर्स मौजूदा model training data में मौजूद नहीं हैं
- Next.js 16 के
- दूसरी ओर, पुराने version वाले projects में model ऐसे नए API सुझा देता है जो वास्तव में मौजूद नहीं होते
- इस समस्या को हल करने के लिए version-matched documentation access approach का प्रयोग किया गया
दो तरीके
- Skills: prompts, tools और documents को जोड़ने वाला open standard package, जिसे एजेंट ज़रूरत पड़ने पर call करके इस्तेमाल करता है
AGENTS.md: project root में रखा गया persistent context file, जिसे हर conversation turn में हमेशा refer किया जा सकता है- एक ही Next.js documentation के आधार पर दोनों तरीकों का तुलनात्मक मूल्यांकन किया गया
Skills approach की सीमाएँ
- मूल्यांकन में पाया गया कि 56% tests में skill call ही नहीं हुआ, और baseline pass rate 53% ही रहा, यानी कोई सुधार नहीं
- कुछ मामलों में तो score baseline से भी कम रहा (जैसे test 58% vs 63%)
- इसे इस बात की सीमा के रूप में देखा गया कि मौजूदा models tool use को स्थिर रूप से execute नहीं कर पाते
explicit instruction जोड़ने का प्रयोग
- जब
AGENTS.mdमें यह explicit instruction जोड़ा गया कि “code लिखने से पहले skill call करो”, तो pass rate 79% तक बढ़ गया - लेकिन instruction की wording में छोटे अंतर ने परिणामों पर बड़ा असर डाला
- “पहले skill call करो” → documentation pattern पर अटक गया, project context छूट गया
- “project explore करने के बाद skill call करो” → बेहतर परिणाम
- इस तरह की linguistic fragility की वजह से real-world use में reliability कम मानी गई
भरोसेमंद evaluation बनाना
- शुरुआती tests में vague prompts और duplicate verification issues के कारण reliability कम थी
- इसे सुधारकर behavior-based verification और Next.js 16 के untrained APIs पर केंद्रित tests तैयार किए गए
- प्रमुख test APIs:
connection(),'use cache',cacheLife(),forbidden(),proxy.ts,cookies(),headers(),after(),refresh()आदि
AGENTS.md approach का प्रयोग
- एजेंट की selection process को हटाकर document index को सीधे AGENTS.md में insert किया गया
- index में पूरी documentation नहीं, बल्कि version-specific document paths की सूची शामिल थी
- अतिरिक्त instruction:
IMPORTANT: Prefer retrieval-led reasoning over pre-training-led reasoning for any Next.js tasks.- इससे model को existing training data के बजाय documentation-based reasoning को प्राथमिकता देने के लिए प्रेरित किया गया
मूल्यांकन परिणाम
- AGENTS.md index insert करने पर 100% pass rate हासिल हुआ
- Build, Lint, Test तीनों में perfect result
- तुलना के आँकड़े:
- Baseline 53%, Skill default 53%, Skill+instruction 79%, AGENTS.md 100%
- passive context approach, active calling से बेहतर क्यों रही
- कोई decision point नहीं — जानकारी हमेशा मौजूद रहती है
- consistent availability — हर turn में system prompt का हिस्सा
- ordering issue खत्म — documentation exploration order पर निर्भरता नहीं
context capacity समस्या का समाधान
- शुरुआती index 40KB का था, लेकिन compression के बाद यह 8KB रह गया (80% कमी)
- pipe(
|) separated structure के जरिए document paths और filenames को न्यूनतम जगह में store किया गया - एजेंट
.next-docs/directory से ज़रूरत की files पढ़कर सही version information का उपयोग करता है
इसे लागू करने का तरीका
- एक line command से setup किया जा सकता है
npx @next/codemod@canary agents-md - यह command:
- Next.js version detect करती है
- उस version की documentation को
.next-docs/में download करती है - compressed index को
AGENTS.mdमें insert करती है
- Cursor जैसे AGENTS.md को पहचानने वाले agents में भी यह समान रूप से काम करता है
framework developers के लिए संकेत
- Skills अब भी उपयोगी हैं, लेकिन सामान्य code generation accuracy सुधारने में AGENTS.md approach अधिक प्रभावी दिखी
- Skills, “version upgrade”, “App Router migration” जैसे specific task-centric workflows के लिए अधिक उपयुक्त हैं
- सुझाव:
- skills के बेहतर होने का इंतज़ार न करें, तुरंत AGENTS.md का उपयोग करें
- context को छोटा रखने के लिए सिर्फ document index शामिल करें
- training data में न होने वाले APIs पर केंद्रित evaluation से validate करें
- documents को fine-grained retrieval structure के साथ design करें
- लक्ष्य है pre-training-centric reasoning से retrieval-based reasoning की ओर बदलाव, और
AGENTS.mdइसे सबसे स्थिर तरीके से लागू करने का माध्यम है
4 टिप्पणियां
Context7 का इस्तेमाल करने पर ऊपर की समस्या कुछ हद तक हल हो जाती है।
https://context7.com
context7 अक्षम है, इसलिए ऊपर बताए गए दो तरीकों का इस्तेमाल किया जाता है...
मैं समझता हूँ कि आप क्या कहना चाहते हैं, लेकिन फिर भी हर बार AGENTS.md या Skills में इस समय इस्तेमाल हो रहे सभी framework/library के latest documentation links को एक-एक करके व्यवस्थित करके जोड़ने से बेहतर, context7 को सहायक रूप में इस्तेमाल करना इतना बुरा विकल्प नहीं लगता।
साथ ही, GeekNews और Vercel दोनों के मूल लेख में context7 का कोई उल्लेख नहीं है। मुझे लगा कि आपने सामग्री का अर्थ लगभग आधा कदम आगे बढ़ाकर निकाला है, इसलिए यह जवाब छोड़ रहा हूँ।
(संदर्भ के लिए कहूँ तो, अच्छी तरह लिखे गए Skills और AGENTS.md से token की बचत हो सकती है, यह एक अच्छी तरह से ज्ञात तथ्य है, और मैं भी इसे अच्छी तरह जानता हूँ.)
Hacker News टिप्पणियाँ
मॉडल AGI नहीं है। यह सिर्फ एक text generator है, जिसे file editing या tool calling जैसे प्रभाव पैदा करने के लिए train किया गया है
मॉडल यूज़र के skills को “समझकर” इस्तेमाल नहीं करता, बल्कि इंसानों द्वारा बनाए गए उदाहरणों और usage logs पर आधारित reinforcement learning (RL) की वजह से ऐसा टेक्स्ट जनरेट करता है
skills को हमेशा इस्तेमाल न करने की वजह यह है कि ऐसे cases पर अभी पर्याप्त training नहीं हुई है। RL से इसे ज़बरदस्ती लागू करने पर मॉडल उल्टा और बेवकूफ हो सकता है
अभी हम skill usage logs जमा कर रहे हैं ताकि future models यह बेहतर सीख सकें कि skills कब इस्तेमाल करने चाहिए
AGENTS.md बस context है। मॉडल को शुरू से ही context follow करने के लिए train किया गया है
skills का frontmatter भी आख़िरकार context में शामिल होता है, इसलिए अगर AGENTS.md बेहतर काम करता है तो वजह skill information को extract और inject करने के तरीके का फ़र्क है
कुछ agents छोटे models (जैसे Haiku) का इस्तेमाल करके यह तय कर सकते हैं कि कौन-सी skill information बड़े models (जैसे Sonnet, Opus) तक पहुँचाई जाए
आख़िरकार मुख्य बात यह है कि “raw prompt” में कौन-सी जानकारी जाती है
उपयोगी है, लेकिन परफेक्ट नहीं। GPT तकनीक खुद शायद पहले ही performance plateau में पहुँच चुकी है
आगे सुधार skills जैसे सहायक systems में होगा। लेकिन मौजूदा skill implementation, AGENTS.md को सीधे इस्तेमाल करने से कमज़ोर है
eval में यह नतीजा आया कि 56% मामलों में skills एक बार भी call नहीं हुए। यानी दस्तावेज़ मौजूद थे, लेकिन इस्तेमाल नहीं हुए। साथ में मज़ाक था: “ट्यूरिंग टेस्ट तो पास कर लिया…”
फ़र्क बस इतना है कि AI बिना ego के correction instructions मान लेता है
अभी senior developer स्तर का नहीं है, लेकिन junior से बेहतर तरीके से निर्देश मान लेता है
मुख्य खोज यह थी कि document pointers की compression असरदार है
इंसानों के लिए पढ़ना मुश्किल है, लेकिन LLM के लिए यह ज़्यादा direct और efficient reference structure है
आगे चलकर agents.md/claude.md/skills.md जैसी heuristics की जगह, हमेशा load होने वाला compressed index format standard बन सकता है
API test suites को LLM code performance validation में दोबारा इस्तेमाल किया जा सकता है
जैसे-जैसे LLM adoption बढ़ेगा, libraries और APIs को भी उसी हिसाब से evolve होना पड़ेगा
Antigravity (=GEMINI.md आधारित) में AGENTS.md rules follow करने को कहा गया था, लेकिन उसे नज़रअंदाज़ कर दिया गया
इसके बजाय “जाँचो कि project में AGENTS.md है या नहीं” वाला prompt हर बार काम करता था
यह कुछ वैसा ही दिलचस्प phenomenon है जैसा पहले “let’s think step by step” chain of thought trigger करता था
AGENTS.md को system prompt में सीधे शामिल कर दिया जाए तो वह हमेशा context में रहेगा
लेकिन हर बार सारे skills शामिल करना फिजूलखर्ची है। इसलिए Anthropic के advanced tool use जैसी approach चाहिए, जो ज़रूरत पड़ने पर ही उन्हें लाए
आख़िरकार यह context और cost के balance का सवाल है। जगह हो तो AGENTS.md में compress करके डालना efficient है
ऐसे self-context-managing agents इस साल काफ़ी आगे बढ़ सकते हैं
Claude की skill compliance कम है
मैं भी इसी तरह के क्षेत्र में काम कर रहा हूँ। मैं यह evaluate करना चाहता हूँ कि project scaffolding structure Claude Code/Opencode के results को कैसे प्रभावित करता है
लेकिन Vercel की testing method साफ़ नहीं है, इसलिए तुलना मुश्किल है
AGENTS.md skills से पूरी तरह अलग चीज़ नहीं है, बल्कि skills का simplified form है
मुख्य बात skill design quality है — यानी AI को सही जानकारी मिलने तक जिन steps से गुजरना पड़ता है, उनकी संख्या कम से कम हो
steps जितने कम होंगे, error accumulation उतना कम होगा
और token waste कम करने के लिए, बड़ी files को system prompt में सिर्फ एक बार डालता हूँ
ब्लॉग में जब भी prompt engineering की तुलना की जाती है, मुझे हमेशा यह जिज्ञासा होती है कि इसे एक बार चलाया गया था या कई बार दोहराया गया था
LLM एक ही input पर भी हमेशा एक जैसा result नहीं देता
ज़्यादातर यह anecdotal data को science की तरह पैक करने जैसा लगता है
लेकिन अगर benchmark ईमानदारी से किया जाए तो views कम मिलते हैं, और अगर बस ऊपर-ऊपर से किया जाए तो blog traffic 9 गुना बढ़ जाता है
distorted incentive structure ही समस्या है
AGENTS.md से भी बेहतर एक तरीका हो सकता है
.contextfolder बनाइए, उसमें project-related documents (README, dependency docs आदि) को symbolic links के ज़रिए रखिए, और उन्हें हमेशा context में load होने दीजिएइससे LLM के पास शुरू से ही ज़रूरी जानकारी रहेगी, और performance improvement व cost reduction दोनों मिल सकते हैं
_vendorfolder में रखना कहीं ज़्यादा उपयोगी हैLLM सीधे code analyze करके behavior समझ सकता है
यह मेरा custom agent बनाते समय का अनुभव है
read/write_fileको state में डालकर system prompt में दिखाया तो यह बहुत बेहतर काम करने लगाअब मैं इसे quantitative evals से साबित करने की कोशिश कर रहा हूँ। अनुभव के आधार पर performance बहुत अच्छी लग रही है