DESIGN.md फ़ाइल क्या है और इसे क्यों इस्तेमाल करें?

DESIGN.md क्या है, और AGENTS.md में क्या शामिल नहीं है

DESIGN.md आपके रिपॉजिटरी रूट में मौजूद एक markdown फ़ाइल है जो एक AI कोडिंग एजेंट को बताती है कि कोड को इस तरह से क्यों बनाया गया है। AGENTS.md एक अलग सवाल का जवाब देता है: यहाँ काम कैसे करना है, जिसका मतलब है build कमांड, test कमांड, वह lint जो पास होना चाहिए, और वे पाथ जिन्हें नहीं छेड़ना है। DESIGN.md उन निर्णयों को रिकॉर्ड करता है जो पहले ही तय हो चुके हैं, और यह बताता है कि उनमें से किसी एक को बदलने पर क्या खराब हो सकता है।

एक कोडिंग एजेंट, यानी Claude Code या Cursor जैसा टूल जो अपने आप आपकी रिपॉजिटरी को पढ़ता और एडिट करता है, डिफ़ॉल्ट रूप से आत्मविश्वास से काम करता है। यह एक ऐसा पैटर्न ढूंढता है जिसे वह नहीं पहचानता और उस पैटर्न को 'बेहतर' बनाने की कोशिश करता है। एक हाथ से लिखा गया cache, Redis (एक in-memory डेटा स्टोर) बन जाता है, क्योंकि मॉडल ने जितना भी कोड पढ़ा है, उसमें cache अक्सर ऐसा ही दिखता है। AGENTS.md इसे नहीं रोकता, क्योंकि make test दोनों ही स्थितियों में पास हो जाता है। जो नियम तोड़ा गया था, वह कहीं भी ऐसी जगह नहीं लिखा था जिसे एजेंट पढ़ सके।

यदि आपने अभी तक पहली फ़ाइल नहीं लिखी है, तो वहीं से शुरुआत करें। AGENTS.md और इसके साथ मौजूद HUMAN.md इसके फॉर्मेट को कवर करता है और यह बताता है कि प्रत्येक टूल इसे कहाँ ढूंढता है। इसके बाद जो दिया गया है, वह उस अध्याय का अगला भाग है।

DESIGN.md के भीतर वास्तव में क्या होता है

इस फॉर्मेट को सीखने का सबसे तेज़ तरीका उन फाइलों को पढ़ना है जिन्हें कंपनियां अपने बारे में प्रकाशित करती हैं। रिपॉजिटरी official-design-md केवल उन्हीं को ट्रैक करती है। इसका समावेशन नियम एक पंक्ति का है, और वह पंक्ति ही इस संग्रह का मुख्य उद्देश्य है:

Every entry here is a DESIGN.md published by the company or project itself — not extracted, not reverse-engineered, not community-made.

अक्टूबर 2026 तक इसमें ग्यारह नाम सूचीबद्ध हैं: Ant Design, Atlassian, Clerk, Juspay, Microsoft FAST, Mintlify, Nuxt, Oxide Computer, Resend, Vercel और VoltAgent। प्रत्येक फाइल एक सार्वजनिक URL पर स्थित है, जिनमें से अधिकांश प्रकाशक के अपने डोमेन पर हैं और बाकी एक सार्वजनिक GitHub रिपॉजिटरी में हैं, इसलिए आप अभी टर्मिनल में एक फाइल पढ़ सकते हैं।

curl -s https://nuxt.com/design.md | head -n 60
curl -s https://vercel.com/design.md | wc -w

ये दोनों ही डिज़ाइन सिस्टम दस्तावेज़ हैं। वे बताते हैं कि किसी उत्पाद को कैसा दिखना चाहिए: रंग, टाइप, स्पेसिंग, मोशन। विषय-वस्तु से आगे बढ़कर पढ़ें, क्योंकि उपयोगी हिस्सा विषय के बजाय लेखन का स्वरूप है।

Nuxt फाइल 27 अक्टूबर, 2026 तक लगभग 2,000 शब्दों की है, और इसका अधिकांश हिस्सा एक नियम और उसके साथ जुड़े कारण के रूप में है। यह इस कथन के साथ शुरू होती है कि डार्क मोड डिफ़ॉल्ट थीम है। यह ब्रांड ग्रीन #00DC82 को इस नोट के साथ सूचीबद्ध करती है कि ब्रांड के रंग "लोगो, सोशल इमेज और प्रिंट के लिए हैं। इन्हें UI कोड में रॉ वैल्यू के रूप में उपयोग न करें।" अंत के पास, Reject these शीर्षक वाले एक सेक्शन में शामिल है:

Raw hex values or palette classes (`text-gray-500`) in components instead of semantic tokens.

Vercel फाइल लंबी है, अक्टूबर 2026 तक लगभग 6,000 शब्द, और यह एक कदम आगे जाती है। इसके शीर्षकों में से एक Reject generated-design reflexes है। इसके नीचे उन चीजों की सूची है जिन्हें एक सक्षम जनरेटर तब चुनता है जब उसे ऐसा न करने के लिए नहीं कहा गया हो:

Hard reject decorative gradients, gradient text, glows, blobs, stripes, textures, grid backgrounds, glass effects, paper simulations, colored side rails, ornamental shadows, and fake depth.

वह वाक्य फाइल के प्रकार को परिभाषित करता है। यह उन डिफ़ॉल्ट्स की एक लिखित सूची है जो एक कॉन्फिडेंट मॉडल तैयार करता है, जिसे इसलिए प्रकाशित किया जाता है ताकि मॉडल उन्हें बनाना बंद कर दे। हर वह DESIGN.md जो कमिट करने योग्य है, किसी न किसी डोमेन के लिए वही सूची है।

कंपनियां अपना खुद का DESIGN.md क्यों प्रकाशित करती हैं?

समुदाय इस मामले में सबसे आगे रहा है। awesome-design-md में सार्वजनिक वेबसाइटों से निकाली गई 84 फाइलें मौजूद हैं। 27 अक्टूबर, 2026 तक इसके README के अनुसार, प्रत्येक फाइल को नौ-खंडों वाले एक ही प्रारूप में लिखा गया है, ताकि किसी एजेंट को एक फाइल दिखाकर उसके जैसा परिणाम प्राप्त किया जा सके। ये फाइलें उपयोगी हैं, लेकिन ये केवल अनुमान हैं। कंपनियों में से किसी ने भी इनकी समीक्षा नहीं की है।

फर्स्ट-पार्टी फाइल अलग होती है क्योंकि यह आउटपुट का विश्लेषण नहीं, बल्कि उसका स्रोत होती है। जब Vercel अपना type scale बदलता है, तो vercel.com/design.md भी उसके साथ बदल जाता है। मार्च में कॉपी की गई फाइल आपके एजेंट को पुराना scale ही सिखाती रहेगी, और आपके रिपॉजिटरी में ऐसी कोई चीज नहीं होगी जो आपको बताए कि वह कॉपी पुरानी हो चुकी है।

ग्यारह प्रकाशक अभी भी एक छोटी संख्या है, और रिपॉजिटरी में भी यही कहा गया है: यह मानक नया है और आधिकारिक तौर पर इसे अपनाने वालों की संख्या बढ़ रही है। दोनों संग्रहों का रखरखाव VoltAgent द्वारा किया जाता है, जो एक ओपन सोर्स एजेंट फ्रेमवर्क है और अपनी खुद की फाइल भी प्रकाशित करता है। इसलिए इस सूची को एक ट्रैकर के रूप में पढ़ें, न कि एक निष्पक्ष जनगणना के रूप में। फिर भी इसे देखना सार्थक है, क्योंकि इसमें शामिल नाम महत्वपूर्ण हैं। इनमें से कई वे कंपनियां हैं जिनका फ्रंट-एंड कोड अन्य डेवलपर्स सबसे ज्यादा कॉपी करते हैं, और नए नाम जैसे Ant Design, Microsoft FAST, Juspay और Oxide Computer, ऐसे डिज़ाइन सिस्टम हैं जिन पर अन्य टीमें काम करती हैं। उनकी फाइलें इस बात का उदाहरण बन रही हैं कि DESIGN.md क्या होता है। AGENTS.md द्वारा अपनाए गए रास्ते की तुलना करें: agents.md में अब 60,000 से अधिक ओपन सोर्स प्रोजेक्ट्स इस प्रारूप का उपयोग कर रहे हैं, और इसका प्रबंधन Linux Foundation के अंतर्गत Agentic AI Foundation के पास है। DESIGN.md ने भी उसी रास्ते पर चलना शुरू कर दिया है। 21 अप्रैल, 2026 को, Google ने इस प्रारूप के लिए एक ड्राफ्ट स्पेसिफिकेशन ओपन-सोर्स किया, जिसे google-labs-code/design.md के रूप में प्रकाशित किया गया। इसमें एक टोकन स्कीमा और Apache-2.0 लाइसेंस के तहत एक CLI शामिल है। अक्टूबर 2026 तक, यह प्रारूप alpha संस्करण पर है और अभी भी सक्रिय विकास के अधीन है। इसका रखरखाव किसी तटस्थ फाउंडेशन के बजाय Google Labs द्वारा किया जा रहा है, और यह एक विजुअल आइडेंटिटी का वर्णन करता है, इसलिए यह उन इनवेरिएंट्स (invariants) के बारे में कुछ नहीं कहता जिनकी एक बैकएंड फाइल को आवश्यकता होती है। एजेंट-पठनीय फाइलों के लिए कन्वेंशन तेजी से स्थापित हो रहे हैं, और वे ऊपर से नीचे की ओर विकसित हो रहे हैं।

जब प्रोजेक्ट में कोई user interface न हो तो DESIGN.md में क्या लिखें

VPS पर चलने वाले अधिकांश software में कोई visual language नहीं होती जिसे निर्दिष्ट किया जाए। फिर भी यह file अपना स्थान रखती है, क्योंकि इसका mechanism रंग-रूप से संबंधित नहीं है। यह उन constraints को लिखने के बारे में है जिनका उल्लंघन एक आत्मविश्वासी editor अनजाने में कर सकता है।

Invariants (अपरिवर्तनीय नियम)। प्रत्येक के लिए एक वाक्य, जो यह बताए कि किसी भी edit के बाद क्या सत्य रहना चाहिए। "प्रत्येक write queue.enqueue() के माध्यम से होता है। सीधा database write audit log को छोड़ देता है, और compliance export उसी audit log को पढ़ता है।" कारण के साथ जुड़ा एक invariant उस कार्य के दौरान भी बना रहता है जिसकी आपने कल्पना नहीं की थी। केवल एक invariant एक प्राथमिकता जैसा लगता है, और प्राथमिकताओं को अक्सर optimize करके हटा दिया जाता है।

Rejected alternatives (अस्वीकृत विकल्प)। स्पष्ट विकल्प, और यह क्यों खारिज हुआ। "हम caching के लिए Redis का उपयोग नहीं करते हैं। सेवा एक ही VPS पर चलती है, इसलिए in-process map अधिक तेज़ है और यह एक कम daemon है जिसे जीवित रखना पड़ता है। जब दूसरा application server मौजूद हो, तब इस पर पुनर्विचार करें।" उस पैराग्राफ के बिना, यदि किसी agent को cache की गति बढ़ाने के लिए कहा जाए तो वह Redis जोड़ देगा, और ऐसा करना सही भी होगा: आपने उसे constraint के बारे में नहीं बताया था। यह वह section है जो पूरी file की सार्थकता सिद्ध करता है।

Boundaries (सीमाएं)। वे स्थान जहाँ एक छोटा सा edit बड़ा प्रभाव डाल सकता है। Database schema। वह public route prefix जिसके खिलाफ ग्राहक पहले से ही script लिख चुके हैं। वह config file जिसे application शुरू होने से पहले एक deploy पढ़ता है। वह cron entry जो यह मानती है कि उसकी केवल एक ही copy चलती है। उन्हें नाम दें, और बताएं कि उनमें से प्रत्येक में बदलाव की क्या कीमत है। यदि agent open web तक भी पहुँच सकता है, जैसे कि a self-hosted SearXNG instance wired up as its search backend के माध्यम से, तो वह भी एक ऐसी boundary है जिसे लिखना सार्थक है, क्योंकि file में यह स्पष्ट होना चाहिए कि कौन सा fetched text code को प्रभावित कर सकता है और कौन सा केवल आपको वापस quote करने के लिए है।

Vocabulary (शब्दावली)। यदि code tenant कहता है और टीम customer कहती है, तो उस mapping को लिख लें। एक agent जो यहाँ गलत अनुमान लगाता है, वह ऐसा code तैयार करता है जो पढ़ने में तो सही लगता है लेकिन गलत चीज़ को model करता है, जो review में पकड़ने के लिए सबसे कठिन गलती है।

आज ही कॉपी करने योग्य DESIGN.md

# DESIGN.md

## What this service is
One paragraph. What it does, who calls it, where it runs.

## Invariants
- Every write goes through `queue.enqueue()`. Direct writes skip the audit log.
- Timestamps are stored as UTC integers. Only the display layer converts them.
- One process writes to SQLite. The database is in WAL mode, and a second writer
  gets `database is locked` under load.

## Rejected alternatives
- **Redis for caching.** Rejected: one VPS, one process, an in-process map is
  enough. Revisit at two application servers.
- **An ORM for the reporting queries.** Rejected: the reports are four hand-tuned
  SQL statements. The generated query joined the same table twice.

## Boundaries
- `schema.sql` is append-only. A column rename needs a migration and a deploy window.
- The `/v1/` routes are public. Customers script against them, so the response
  shape is frozen.

## Vocabulary
- `tenant` in code is what the docs and the billing system call a customer account.

## Keeping this file honest
Update it in the commit that changes the decision. A stale DESIGN.md is worse
than no DESIGN.md, because the agent believes it.

जिन दो अनुभागों को आप आज याददाश्त से लिख सकते हैं, उन्हें भरें: invariants (अपरिवर्तनीय) और rejected alternatives (अस्वीकृत विकल्प)। बाकी को केवल headings के रूप में छोड़ दें। चार ईमानदार पंक्तियों वाली फाइल भी काम करती है। चालीस अनुमानित पंक्तियों वाली फाइल काम नहीं करती। यदि repository में कई packages हैं, तो एक root file सभी के लिए उपयुक्त नहीं होगी। वही per-directory विभाजन जो monorepo में nested AGENTS.md files के लिए काम करता है, यहाँ भी लागू होता है: सभी के लिए साझा निर्णयों हेतु एक छोटी root file, और प्रत्येक package के बगल में एक छोटी file जिसमें उसके अपने निर्णय हों।

कुछ tools repository root में मौजूद हर markdown file को load करते हैं, जबकि कुछ केवल उसी को load करते हैं जिसके बारे में उन्हें बताया जाता है, इसलिए कोई धारणा न बनाएं। AGENTS.md का एक pointer जोड़ें:

Read DESIGN.md before editing anything under `src/`. It lists the invariants and
the alternatives that were already rejected.

एंटी-पैटर्न: एक ऐसा DESIGN.md जो README को दोहराता है

सबसे आम खराब संस्करण अच्छी तरह से पढ़ा तो जाता है, लेकिन कुछ सिखाता नहीं है। यह इस बात से शुरू होता है कि प्रोजेक्ट क्या करता है, फीचर्स की सूची देता है, इसे इंस्टॉल करने का तरीका बताता है, और लाइसेंस के साथ समाप्त होता है। इसकी हर पंक्ति पहले से ही README में मौजूद होती है, और इनमें से कोई भी यह नहीं बताती कि कोई चीज वैसी क्यों है जैसी वह है।

यह आपको दो बार नुकसान पहुँचाता है। पहली लागत संदर्भ (context) की है। जिस फाइल को एजेंट हर टास्क की शुरुआत में पढ़ता है, उसकी कीमत हर टास्क पर चुकानी पड़ती है, और एक डुप्लिकेट इंस्टॉलेशन सेक्शन एक निश्चित विंडो के मुकाबले पूरी तरह से अतिरिक्त बोझ है। उस विंडो का बजट बनाना अपने आप में एक कौशल है, जिसे managing the context window in Claude Code में कवर किया गया है। संक्षेप में: जो कुछ भी स्वचालित रूप से लोड होता है, वह रिपॉजिटरी में सबसे अधिक मूल्यवान टेक्स्ट होना चाहिए।

दूसरी लागत और भी खराब है। एक ही कथन की दो प्रतियां समय के साथ अलग-अलग हो जाती हैं। README कहता है कि सर्विस 8080 पर listen करती है, DESIGN.md अभी भी 3000 कहता है, और एजेंट के पास एक को दूसरे से बेहतर मानने का कोई तरीका नहीं है, इसलिए वह किसी एक को चुन लेता है और उसके इर्द-गिर्द कोड लिख देता है। एक ऐसी फाइल जो कभी-कभी गलत होती है, उसे उसी भरोसे के साथ देखा जाता है जैसे कि हमेशा सही रहने वाली फाइल को।

इसका परीक्षण त्वरित है। यदि कोई पैराग्राफ README में आराम से फिट हो सकता है, तो उसे DESIGN.md से हटा दें। जो बचता है वह वह हिस्सा होना चाहिए जिसे आप कोड रिव्यू के दौरान जोर से बोलेंगे, वह हिस्सा जो "हमने पहले ही वह कोशिश कर ली थी" से शुरू होता है।

आपको कैसे पता चलेगा कि यह फाइल काम कर रही है?

इसके लिए कोई linter नहीं है। एक जांच है जिसे आप एक मिनट में चला सकते हैं।

एजेंट को एक ऐसा कार्य दें जो सीधे किसी invariant (अपरिवर्तनीय नियम) का उल्लंघन करता हो। "एक बैकग्राउंड जॉब जोड़ें जो पुरानी पंक्तियों (stale rows) को expired के रूप में चिह्नित करे।" जो फाइल अपना काम सही ढंग से कर रही है, वह किसी भी कोड से पहले उत्तर में दिखाई देगी: एजेंट को आपको बताना चाहिए कि जॉब queue.enqueue() के माध्यम से लिखती है, क्योंकि सीधा write ऑपरेशन audit log को छोड़ देगा। यदि यह डेटाबेस कनेक्शन खोलकर लिखती है, तो दो में से एक बात सच है। या तो फाइल बिल्कुल भी नहीं पढ़ी जा रही है, या invariant को इतनी ढीली भाषा में लिखा गया है कि उस पर बहस की जा सकती है।

टोकन काउंट पर भी नजर रखें, क्योंकि यह फाइल हर टर्न पर लोड होती है। यदि DESIGN.md जोड़ने के बाद कॉन्टेक्स्ट का उपयोग बढ़ जाता है और उत्तरों में सुधार नहीं होता है, तो फाइल में ऐसी जानकारी है जो एजेंट के पास पहले से थी। Claude Code में टोकन काउंटर्स को पढ़ना दिखाता है कि वह बजट कहाँ खर्च होता है।

यह तब सबसे महत्वपूर्ण होता है जब एजेंट आपके लैपटॉप के बजाय सर्वर पर रहता है। tmux के साथ VPS पर Claude Code वर्कस्पेस जैसे सेटअप में, लंबे समय तक चलने वाले सेशन में काम करने वाले एजेंट को कल की बातचीत याद नहीं रहती। रिपॉजिटरी ही उसकी याददाश्त है। चैट में आपने जो कुछ भी समझाया और कभी कमिट नहीं किया, वह अगले सेशन तक खत्म हो जाता है, और DESIGN.md वह जगह है जहाँ वह स्पष्टीकरण सुरक्षित रहता है।

उन निर्णयों से शुरुआत करें जिन पर आप बहस करते हैं

पहला संस्करण तैयार करने में बीस मिनट लगते हैं। उन पिछली कई pull requests को खोलें जहाँ किसी reviewer ने लिखा था "नहीं, हम यहाँ इसे अलग तरह से करते हैं"। उन टिप्पणियों में से प्रत्येक एक ऐसा invariant है जिसे कभी लिखा नहीं गया था, और उनमें से प्रत्येक वह जगह है जहाँ एक agent वही गलती करेगा, और एक इंसान की तुलना में अधिक तेजी से और बार-बार करेगा। जब यह आपको विफल करे तब फाइल में जोड़ें, किसी तय समय-सारणी पर नहीं। यदि आप अभी भी यह तय कर रहे हैं कि सामान्य development workflow में agents कहाँ फिट होते हैं, तो AI agents सीखने के लिए 2026 की गाइड अगला उचित पड़ाव है।

FAQ

क्या DESIGN.md एक आधिकारिक मानक है?

AGENTS.md की तरह नहीं। AGENTS.md का अपना स्थान agents.md पर है, 60,000 से अधिक ओपन सोर्स प्रोजेक्ट्स इसका उपयोग करते हैं, और यह Linux Foundation का हिस्सा, Agentic AI Foundation के संरक्षण में है। DESIGN.md के लिए एक प्रकाशित विनिर्देश (specification) तो है, लेकिन कोई तटस्थ संरक्षक नहीं है। Google ने 21 अप्रैल, 2026 को एक ड्राफ्ट विनिर्देश ओपन-सोर्स किया था, और यह Apache-2.0 लाइसेंस के तहत google-labs-code/design.md रिपॉजिटरी में स्थित है। अक्टूबर 2026 तक यह alpha संस्करण में है और सक्रिय विकास के अधीन है, और यह एक विजुअल पहचान का वर्णन करता है: रंग, टाइपोग्राफी, लेआउट और घटक। DESIGN.md को प्रथम-पक्ष (first-party) द्वारा भी अपनाया गया है: Vercel, Nuxt, Atlassian और Resend सहित ग्यारह कंपनियां और प्रोजेक्ट्स इसे प्रकाशित करते हैं, और 27 अक्टूबर, 2026 तक एक सामुदायिक संग्रह में सार्वजनिक साइटों से निकाली गई 84 और फाइलें मौजूद थीं। इनवेरिएंट्स (invariants) और अस्वीकृत विकल्पों (rejected alternatives) की बैकएंड फाइल के लिए, इसे एक ऐसी परंपरा मानें जिसे आप अभी अपना सकते हैं और स्वतंत्र रूप से विस्तारित कर सकते हैं, क्योंकि कोई भी विनिर्देश उन सेक्शन नामों को कवर नहीं करता है।

क्या DESIGN.md को केवल AGENTS.md का एक सेक्शन होना चाहिए?

एक छोटी रिपॉजिटरी के लिए, हाँ। एक फाइल जिसे एजेंट निश्चित रूप से पढ़ता है, दो फाइलों से बेहतर है जिनमें से एक को अनदेखा कर दिया जाए। इन्हें तब अलग करें जब AGENTS.md को स्कैन करना कठिन हो जाए, या जब आप देखें कि दोनों हिस्से अलग-अलग दरों पर बदल रहे हैं। AGENTS.md तब बदलता है जब बिल्ड बदलता है। DESIGN.md तब बदलता है जब कोई निर्णय (decision) बदलता है, जो कि बिल्ड में होने वाले बदलावों की तुलना में कम बार होता है और अधिक महत्वपूर्ण होता है। जब आप इन्हें अलग करें, तो AGENTS.md में एक लाइन जोड़ें जो एजेंट को कोड एडिट करने से पहले DESIGN.md पढ़ने के लिए कहे, क्योंकि हर टूल रूट में मौजूद हर मार्कडाउन फाइल को लोड नहीं करता है।

DESIGN.md एक आर्किटेक्चर डिसीजन रिकॉर्ड (ADR) से कैसे अलग है?

एक ADR (आर्किटेक्चर डिसीजन रिकॉर्ड) एक निर्णय का दिनांकित रिकॉर्ड होता है, और एक स्वस्थ प्रोजेक्ट में एक फोल्डर के भीतर ऐसे दर्जनों रिकॉर्ड जमा हो जाते हैं। यह एक इतिहास है, और इतिहास को लोड करना महंगा होता है, क्योंकि यह पता लगाने के लिए कि कौन से निर्णय अभी भी मान्य हैं, एजेंट को उन सभी को पढ़ना होगा। DESIGN.md वर्तमान स्थिति है, जिसे हर टास्क पर पूरी तरह पढ़ने के लिए लिखा गया है। यदि आप पहले से ही ADR लिखते हैं, तो दोनों को रखें। ADR बताता है कि क्या निर्णय लिया गया था और कब। DESIGN.md बताता है कि आज क्या सत्य है, और यही वह फाइल है जिसे आप एजेंट को रेफर करते हैं।

DESIGN.md कितना लंबा होना चाहिए?

इतना छोटा कि बिना किसी हिचकिचाहट के हर टर्न पर लोड किया जा सके। प्रकाशित उदाहरण लंबे हैं क्योंकि वे एक पूरी विजुअल भाषा को निर्दिष्ट करते हैं: अक्टूबर 2026 तक Nuxt फाइल लगभग 2,000 शब्दों की है और Vercel फाइल लगभग 6,000 शब्दों की। एक बैकएंड सर्विस को आमतौर पर बहुत कम की आवश्यकता होती है। एक पेज से शुरुआत करें और इसे केवल तब बढ़ाएं जब एजेंट कुछ ऐसा गलत करे जिसे एक सिंगल सेंटेंस रोक सकता था। लंबाई कोई पैमाना नहीं है। हर लाइन ऐसी चीज होनी चाहिए जिसे एजेंट अन्यथा गलत कर देता।