DESIGN.md கோப்பு என்றால் என்ன? AI ஏஜெண்டுகளுக்கு ஏன் தேவை?

DESIGN.md என்றால் என்ன, AGENTS.md எதை உள்ளடக்குவதில்லை

DESIGN.md என்பது உங்கள் repository-ன் root-ல் இருக்கும் ஒரு markdown கோப்பு. இது உங்கள் code ஏன் இந்த வடிவில் வடிவமைக்கப்பட்டுள்ளது என்பதை ஒரு AI coding agent-க்கு விளக்குகிறது. AGENTS.md வேறு ஒரு கேள்விக்கு பதிலளிக்கிறது: இங்கே எவ்வாறு வேலை செய்வது? அதாவது, build command, test command, நிறைவேற்றப்பட வேண்டிய lint, மற்றும் மாற்றக்கூடாத பாதைகள் (paths) ஆகியவற்றை இது குறிப்பிடுகிறது. ஏற்கனவே எடுக்கப்பட்ட முடிவுகளையும், அவற்றை மாற்றினால் என்ன பாதிப்புகள் ஏற்படும் என்பதையும் DESIGN.md பதிவு செய்கிறது.

Coding agent என்பது Claude Code அல்லது Cursor போன்ற, உங்கள் repository-ஐ தானாகவே வாசித்து திருத்தக்கூடிய ஒரு கருவியாகும். இது இயல்பாகவே அதிக தன்னம்பிக்கையுடன் செயல்படும். தனக்குத் தெரியாத ஒரு pattern-ஐக் கண்டால், அதை மேம்படுத்த முயற்சிக்கும். உதாரணமாக, கையால் எழுதப்பட்ட ஒரு cache-ஐ Redis (ஒரு in-memory data store) ஆக மாற்றும்; ஏனெனில், அந்த model வாசித்த பெரும்பாலான code-களில் cache என்பது அப்படித்தான் இருக்கும். AGENTS.md இதைத் தடுக்காது, ஏனெனில் make test எந்த நிலையிலும் நிறைவேறும். மீறப்பட்ட அந்த விதி, agent வாசிக்கக்கூடிய எந்த இடத்திலும் எழுதப்படவில்லை என்பதே இதற்குக் காரணம்.

நீங்கள் இன்னும் முதல் கோப்பை எழுதவில்லை என்றால், அங்கிருந்து தொடங்குங்கள். AGENTS.md மற்றும் அதன் அருகில் இருக்கும் HUMAN.md அதன் வடிவத்தையும், ஒவ்வொரு கருவியும் அதை எங்கே தேடும் என்பதையும் விளக்குகிறது. அதற்கு அடுத்த அத்தியாயம் கீழே கொடுக்கப்பட்டுள்ளது.

DESIGN.md கோப்பில் உண்மையில் என்ன இருக்கிறது

இதன் வடிவமைப்பைக் கற்றுக்கொள்ள மிக வேகமான வழி, நிறுவனங்கள் தங்களைப் பற்றி வெளியிடும் கோப்புகளைப் படிப்பதுதான். official-design-md என்ற களஞ்சியம் (repository) அவற்றை மட்டுமே தொகுக்கிறது. அதன் உள்ளடக்க விதி ஒரே ஒரு வரியில்தான் உள்ளது, அந்த வரியே இந்தத் தொகுப்பின் முழு நோக்கமும் ஆகும்:

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

ஆகஸ்ட் 2026 நிலவரப்படி, இதில் ஏழு நிறுவனங்கள் பட்டியலிடப்பட்டுள்ளன: Atlassian, Clerk, Mintlify, Nuxt, Resend, Vercel மற்றும் VoltAgent. ஒவ்வொரு கோப்பும் நிலையான பொது URL-ல் இருப்பதால், நீங்கள் இப்போதே terminal-ல் ஒன்றைப் படிக்கலாம்.

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

இவை இரண்டுமே design system ஆவணங்கள். ஒரு தயாரிப்பு எப்படித் தெரிய வேண்டும் என்பதை இவை விவரிக்கின்றன: நிறம், எழுத்துரு, இடைவெளி, இயக்கம். இதில் உள்ள பொருளைத் தாண்டிப் படியுங்கள், ஏனெனில் பயனுள்ள பகுதி அதன் தலைப்பு அல்ல, மாறாக அந்த எழுத்துக்களின் வடிவம் ஆகும்.

Nuxt கோப்பு சுமார் 2,100 சொற்களைக் கொண்டது, அதில் பெரும்பாலானவை ஒரு விதியும் அதற்கான காரணமும் ஆகும்:

Dark mode is the default theme.
Colors are semantic (`primary`, `neutral`, `error`…) rather than hardcoded hex values in components.
Don't hardcode `#00DC82` in UI code — use `text-primary` or `color="primary"`.

Vercel கோப்பு நீளமானது, ஆகஸ்ட் 2026-ல் சுமார் 6,500 சொற்கள் உள்ளன, இது இன்னும் ஒரு படி மேலே செல்கிறது. அதன் தலைப்புகளில் ஒன்று Reject generated-design reflexes ஆகும். அதன் கீழ், ஒரு திறமையான generator-க்கு யாரும் கட்டளையிடாதபோது அது எதை நோக்கிச் செல்லும் என்பதன் பட்டியல் உள்ளது:

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

அந்த வாக்கியமே இந்த கோப்பு வகையை வரையறுக்கிறது. இது ஒரு நம்பிக்கையான model உருவாக்கும் இயல்புநிலைகளின் (defaults) எழுத்துப்பூர்வமான பட்டியல்; model அவற்றை உருவாக்குவதை நிறுத்த வேண்டும் என்பதற்காகவே இது வெளியிடப்படுகிறது. எந்தவொரு DESIGN.md-ம் ஒரு குறிப்பிட்ட துறைக்கான அத்தகைய பட்டியலாகவே இருக்க வேண்டும்.

நிறுவனங்கள் ஏன் தங்கள் சொந்த DESIGN.md கோப்புகளை வெளியிடுகின்றன?

சமூகம் ஏற்கனவே இதில் முந்திக்கொண்டது. awesome-design-md களஞ்சியத்தில் பொது இணையதளங்களிலிருந்து ரிவர்ஸ்-இன்ஜினியரிங் (reverse-engineered) செய்யப்பட்ட 73 கோப்புகள் உள்ளன. இவை ஒவ்வொன்றும் ஒரே மாதிரியான ஒன்பது-பிரிவு வடிவமைப்பில் எழுதப்பட்டுள்ளன. எனவே, ஒரு ஏஜென்ட்டை (agent) ஒரு கோப்பின் பக்கம் திருப்பினால், அது அந்த வடிவமைப்பிற்கு நெருக்கமான முடிவைத் தரும். இந்தக் கோப்புகள் பயனுள்ளவை, ஆனால் அவை யூகங்களே. சம்பந்தப்பட்ட நிறுவனங்களில் யாரும் அவற்றைச் சரிபார்க்கவில்லை.

முதல் தரப்பு (first-party) கோப்பு என்பது வெளியீட்டின் வாசிப்பு அல்ல, அதுவே மூலமாகும். Vercel தனது type scale-ஐ மாற்றும்போது, vercel.com/design.md கோப்பும் அதனுடன் சேர்ந்து மாறுகிறது. மார்ச் மாதம் ஸ்கிரேப் (scrape) செய்யப்பட்ட ஒரு நகல், உங்கள் ஏஜென்ட்டிற்கு பழைய அளவீட்டையே தொடர்ந்து கற்பிக்கும். அந்த நகல் காலாவதியாகிவிட்டது என்பதை உங்கள் களஞ்சியத்தில் (repository) எதுவும் உங்களுக்குத் தெரிவிக்காது.

ஏழு வெளியீட்டாளர்கள் என்பது சிறிய எண்ணிக்கைதான். அந்த களஞ்சியமே இதைக் குறிப்பிடுகிறது: இந்தத் தரம் புதியது மற்றும் அதிகாரப்பூர்வ ஏற்பு அதிகரித்து வருகிறது. இரண்டு தொகுப்புகளுமே VoltAgent-ஆல் பராமரிக்கப்படுகின்றன. இது ஒரு திறந்தநிலை ஏஜென்ட் கட்டமைப்பாகும் (open source agent framework). இதுவும் தனது சொந்தக் கோப்பை வெளியிடுகிறது. எனவே, இந்த பட்டியலை ஒரு நடுநிலையான கணக்கெடுப்பாகப் பார்க்காமல், ஒரு கண்காணிப்புப் பட்டியலாகப் பாருங்கள். இருப்பினும், அந்த ஏழு நிறுவனங்கள் யார் என்பதற்காக இதைக் கவனிப்பது மதிப்புடையது. மற்ற டெவலப்பர்கள் அதிகம் நகலெடுக்கும் front-end குறியீடுகளைக் கொண்ட நிறுவனங்கள் இவை. DESIGN.md என்றால் என்ன என்பதற்கு இவர்களது கோப்புகளே முன்மாதிரியாக மாறி வருகின்றன. AGENTS.md சென்ற பாதையை ஒப்பிட்டுப் பாருங்கள்: agents.md இப்போது 60,000-க்கும் மேற்பட்ட திறந்தநிலைத் திட்டங்களில் இந்த வடிவமைப்பைப் பயன்படுத்துகிறது. இதன் பொறுப்பு Linux Foundation-ன் கீழ் உள்ள Agentic AI Foundation-இடம் உள்ளது. ஏஜென்ட்-வாசிக்கக்கூடிய கோப்புகளுக்கான மரபுகள் வேகமாக நிலைபெற்று வருகின்றன, மேலும் அவை மேலிருந்து கீழ்நோக்கி நிலைபெறுகின்றன.

பயனர் இடைமுகம் இல்லாத திட்டங்களில் DESIGN.md கோப்பில் என்ன இருக்க வேண்டும்

VPS-ல் இயங்கும் பெரும்பாலான மென்பொருட்களுக்குக் குறிப்பிட வேண்டிய காட்சி மொழி (visual language) இருப்பதில்லை. இருப்பினும், இந்த கோப்பு அவசியமானது, ஏனெனில் இதன் செயல்முறைக்கும் நிறங்களுக்கும் எந்தத் தொடர்பும் இல்லை. ஒரு நம்பிக்கையான எடிட்டர் கவனிக்காமல் மீறக்கூடிய கட்டுப்பாடுகளை ஆவணப்படுத்துவதே இதன் நோக்கம்.

மாறாத விதிகள் (Invariants). ஒவ்வொரு திருத்தத்திற்குப் பிறகும் உண்மையாக இருக்க வேண்டிய ஒரு விஷயத்தை, தலா ஒரு வாக்கியத்தில் குறிப்பிடவும். "ஒவ்வொரு எழுதும் செயலும் queue.enqueue() வழியாகவே நடக்க வேண்டும். நேரடியாக database-ல் எழுதினால் audit log தவிர்க்கப்படும், compliance export-க்கு audit log-தான் தேவை." ஒரு விதியுடன் அதற்கான காரணத்தையும் இணைத்தால் மட்டுமே, நீங்கள் எதிர்பாராத ஒரு பணியின் போதும் அது நிலைத்திருக்கும். காரணம் இல்லாமல் விதியை மட்டும் எழுதினால், அது ஒரு விருப்பமாகவே கருதப்படும்; விருப்பங்கள் பெரும்பாலும் மேம்படுத்தல் என்ற பெயரில் நீக்கப்பட்டுவிடும்.

நிராகரிக்கப்பட்ட மாற்றுகள் (Rejected alternatives). வெளிப்படையான ஒரு விருப்பம் ஏன் நிராகரிக்கப்பட்டது என்பதைக் குறிப்பிடவும். "நாங்கள் caching-க்கு Redis-ஐப் பயன்படுத்துவதில்லை. இந்த service ஒரே ஒரு VPS-ல் மட்டுமே இயங்குகிறது, எனவே in-process map வேகமானது மற்றும் பராமரிக்க வேண்டிய daemon-களின் எண்ணிக்கை குறையும். இரண்டாவது application server உருவாக்கப்படும்போது இதை மறுபரிசீலனை செய்யவும்." இந்த விளக்கம் இல்லையென்றால், cache-ஐ வேகப்படுத்தச் சொல்லப்படும் ஒரு முகவர் (agent) Redis-ஐச் சேர்க்கும்; நீங்கள் கட்டுப்பாட்டைச் சொல்லாததால் அது செய்வது சரிதான். இந்த ஒரு பகுதிதான் முழு கோப்பிற்கும் மதிப்பு சேர்க்கிறது.

எல்லைகள் (Boundaries). சிறிய மாற்றங்கள் பெரிய பாதிப்பை ஏற்படுத்தும் இடங்கள் இவை. Database schema, வாடிக்கையாளர்கள் ஏற்கனவே script செய்துள்ள public route prefix, application தொடங்குவதற்கு முன் வாசிக்கும் config file, ஒரே ஒரு நகல் மட்டுமே இயங்கும் என்று கருதும் cron entry போன்றவை. இவற்றை அடையாளம் கண்டு, ஒவ்வொன்றிலும் மாற்றம் செய்வதற்கான செலவு என்ன என்பதைக் குறிப்பிடவும். முகவர் இணையத்தை அணுக முடிந்தால், அதன் search backend-ஆக இணைக்கப்பட்டுள்ள self-hosted SearXNG instance போன்றவற்றை எல்லைகளாகக் குறிப்பிடவும். ஏனெனில், எந்தத் தரவு குறியீட்டை (code) மாற்ற அனுமதிக்கப்படுகிறது, எது மேற்கோளாக மட்டுமே காட்டப்பட வேண்டும் என்பதை இந்தக் கோப்பு தெளிவுபடுத்த வேண்டும்.

சொற்களஞ்சியம் (Vocabulary). குறியீட்டில் tenant என்றும், குழுவில் customer என்றும் பயன்படுத்தினால், அவற்றுக்கிடையேயான தொடர்பை எழுதி வைக்கவும். இதில் தவறாக ஊகிக்கும் ஒரு முகவர், பார்ப்பதற்குச் சரியாகத் தோன்றும் ஆனால் தவறான மாதிரியைக் கொண்ட குறியீட்டை உருவாக்கும். இதுவே மதிப்பாய்வின் போது கண்டறிய கடினமான பிழையாகும்.

இன்றே நீங்கள் நகலெடுக்கக்கூடிய ஒரு 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). மீதமுள்ளவற்றை தலைப்புகளாக அப்படியே விட்டுவிடுங்கள். நான்கு உண்மையான வரிகளைக் கொண்ட கோப்பு போதுமானது. ஊகத்தின் அடிப்படையில் நாற்பது வரிகளை எழுத வேண்டாம். ஒரு களஞ்சியத்தில் (repository) பல தொகுப்புகள் (packages) இருந்தால், ஒரே ஒரு root கோப்பு அனைத்திற்கும் பொருந்தாது. monorepo-வில் உள்ள nested AGENTS.md கோப்புகள் போலவே இதற்கும் ஒரு பிரிப்பு முறை தேவை: அனைத்து தொகுப்புகளுக்கும் பொதுவான முடிவுகளுக்கு ஒரு சிறிய root கோப்பும், ஒவ்வொரு தொகுப்பிற்கும் அதன் அருகில் ஒரு சிறிய கோப்பும் இருக்க வேண்டும்.

சில கருவிகள் களஞ்சியத்தின் root-ல் உள்ள அனைத்து markdown கோப்புகளையும் ஏற்றும், சில குறிப்பிட்ட கோப்புகளை மட்டுமே ஏற்றும். எனவே, எதையும் ஊகிக்க வேண்டாம். AGENTS.md-க்கு ஒரு சுட்டியை (pointer) சேர்க்கவும்:

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

தவறான அணுகுமுறை: README-ஐ மீண்டும் சொல்லும் DESIGN.md

மிகவும் பொதுவான தவறான வடிவம், வாசிப்பதற்கு நன்றாக இருக்கும், ஆனால் எதையும் கற்றுக்கொடுக்காது. இது திட்டம் என்ன செய்கிறது என்பதை விவரித்து, அம்சங்களை பட்டியலிட்டு, நிறுவும் முறையை விளக்கி, உரிமத்துடன் முடிகிறது. இதில் உள்ள ஒவ்வொரு வரியும் ஏற்கனவே README-ல் உள்ளது, மேலும் எதையும் ஏன் அவ்வாறு வடிவமைத்தோம் என்பதற்கான காரணம் இதில் இல்லை.

இது உங்களுக்கு இரண்டு விதமான இழப்புகளை ஏற்படுத்துகிறது. முதலாவது சூழல் (context) தொடர்பான இழப்பு. ஒவ்வொரு பணியின் தொடக்கத்திலும் ஏஜென்ட் வாசிக்கும் ஒரு கோப்பிற்கு, ஒவ்வொரு முறையும் நீங்கள் கட்டணம் செலுத்துகிறீர்கள். மீண்டும் மீண்டும் வரும் நிறுவல் பகுதி, ஒரு குறிப்பிட்ட அளவுள்ள விண்டோவிற்கு (context window) தேவையற்ற சுமையாகும். அந்த விண்டோவை நிர்வகிப்பது ஒரு தனித்திறமை, இது managing the context window in Claude Code பகுதியில் விளக்கப்பட்டுள்ளது. சுருக்கமாகச் சொன்னால், தானாகவே ஏற்றப்படும் எந்தவொரு தகவலும் களஞ்சியத்தில் (repository) மிக உயர்ந்த மதிப்புடையதாக இருக்க வேண்டும்.

இரண்டாவது இழப்பு இன்னும் மோசமானது. ஒரே தகவலின் இரண்டு பிரதிகள் காலப்போக்கில் மாறுபடும். README-ல் சேவை 8080-ல் இயங்குகிறது என்று இருக்கும், DESIGN.md-ல் 3000 என்று இருக்கும். இதில் எது சரி என்று ஏஜென்டால் தீர்மானிக்க முடியாது, எனவே அது ஏதோ ஒன்றை எடுத்துக்கொண்டு அதற்கேற்ப குறியீட்டை (code) எழுதும். சில நேரங்களில் தவறான தகவலைக் கொண்ட ஒரு கோப்பு, எப்போதும் சரியான தகவலைக் கொண்ட கோப்பைப் போலவே அதே நம்பிக்கையுடன் அணுகப்படுகிறது.

இதற்கான சோதனை எளிதானது. ஒரு பத்தி README-ல் இருக்கத் தகுதியானது என்றால், அதை DESIGN.md-லிருந்து நீக்கிவிடுங்கள். எஞ்சியிருப்பது, நீங்கள் ஒரு code review-ன் போது வாய்மொழியாகச் சொல்லக்கூடிய பகுதியாக இருக்க வேண்டும்; அதாவது, "நாங்கள் ஏற்கனவே அதை முயற்சி செய்துவிட்டோம்" என்று தொடங்கும் பகுதியாக இருக்க வேண்டும்.

இந்தக் கோப்பு சரியாகச் செயல்படுகிறதா என்பதை எப்படி அறிவது?

இதற்கென பிரத்யேக linter எதுவும் இல்லை. ஆனால், ஒரு நிமிடத்தில் நீங்கள் செய்யக்கூடிய ஒரு சோதனை உள்ளது.

அந்த agent-க்கு ஒரு மாறாத விதியைப் (invariant) பாதிக்கும் வகையில் ஒரு பணியைக் கொடுங்கள். உதாரணமாக, "பழைய வரிசைகளை expired என மாற்றும் ஒரு background job-ஐச் சேர்க்கவும்" என்று கூறலாம். இந்தக் கோப்பு சரியாகச் செயல்பட்டால், எந்தக் குறியீட்டையும் (code) எழுதுவதற்கு முன்பே agent பதில் அளிக்கும்: அந்த job queue.enqueue() வழியாகவே எழுத வேண்டும் என்று அது சொல்ல வேண்டும், ஏனெனில் நேரடியாக எழுதினால் audit log விடுபட்டுவிடும். ஒருவேளை அது database connection-ஐத் திறந்து நேரடியாக எழுதினால், இரண்டு விஷயங்களில் ஒன்று நடக்கிறது என்று அர்த்தம். ஒன்று, அந்தக் கோப்பு வாசிக்கப்படவே இல்லை, அல்லது அந்த விதி மிகவும் தளர்வாக இருப்பதால் அதை agent விவாதிக்கிறது.

Token எண்ணிக்கையையும் கவனியுங்கள், ஏனெனில் ஒவ்வொரு முறையும் இந்தக் கோப்பு ஏற்றப்படுகிறது. DESIGN.md-ஐச் சேர்த்த பிறகு context பயன்பாடு அதிகரித்து, ஆனால் பதில்களில் முன்னேற்றம் இல்லை என்றால், அந்த agent-க்கு ஏற்கனவே தெரிந்த தகவல்களைத்தான் இந்தக் கோப்பு சுமந்து கொண்டிருக்கிறது என்று அர்த்தம். Claude Code-ல் token counters-ஐ வாசித்தல் என்ற பகுதி அந்த வரவு-செலவு எங்கே செல்கிறது என்பதைக் காட்டுகிறது.

உங்கள் laptop-ஐ விட, ஒரு server-ல் agent இயங்கும்போது இது மிக முக்கியமானது. VPS-ல் tmux உடன் கூடிய Claude Code workspace போன்ற நீண்ட நேரம் இயங்கும் session-களில், முந்தைய நாள் உரையாடல்கள் agent-க்கு நினைவில் இருக்காது. அந்த repository-தான் அதன் நினைவகம். நீங்கள் chat-ல் விளக்கி, ஆனால் commit செய்யாத அனைத்தும் அடுத்த session-ல் அழிந்துவிடும். அந்த விளக்கங்கள் அழியாமல் இருக்க, அவற்றை DESIGN.md கோப்பில் சேமிக்க வேண்டும்.

நீங்கள் விவாதிக்கும் முடிவுகளிலிருந்து தொடங்குங்கள்

முதல் பதிப்பை உருவாக்க இருபது நிமிடங்கள் ஆகும். ஒரு reviewer "இல்லை, நாங்கள் இதை இங்கே வேறு விதமாகச் செய்கிறோம்" என்று குறிப்பிட்ட கடைசி சில pull requests-களைத் திறந்து பாருங்கள். அவற்றில் உள்ள ஒவ்வொரு கருத்தும் எழுதப்படாத ஒரு invariant ஆகும். ஒவ்வொரு கருத்தும் ஒரு agent அதே தவறை, மனிதனை விட வேகமாகவும் அடிக்கடிவும் செய்யும் இடமாகும். ஒரு கால அட்டவணையின்படி அல்லாமல், அது உங்களுக்குத் தோல்வியைத் தரும்போது கோப்பில் அதைச் சேர்க்கவும். சாதாரண development workflow-ல் agents எங்கே பொருந்தும் என்பதை நீங்கள் இன்னும் கண்டறிந்து கொண்டிருந்தால், 2026 AI agents கற்றல் வழிகாட்டி அடுத்த கட்டமாகச் செல்ல ஒரு சரியான இடமாகும்.

FAQ

DESIGN.md என்பது ஒரு அதிகாரப்பூர்வமான தரநிலையா?

AGENTS.md போல இது ஒரு தரநிலை அல்ல. AGENTS.md-க்கு agents.md என்ற தளம் உள்ளது, 60,000-க்கும் மேற்பட்ட open source திட்டங்கள் இதைப் பயன்படுத்துகின்றன, மேலும் Linux Foundation-ன் ஒரு பகுதியான Agentic AI Foundation-ன் நிர்வாகத்தில் இது உள்ளது. ஆகஸ்ட் 2026 நிலவரப்படி, DESIGN.md-க்கு எந்தவொரு நிர்வாக அமைப்போ அல்லது வெளியிடப்பட்ட விவரக்குறிப்போ (specification) இல்லை. ஆனால், Vercel, Nuxt, Atlassian மற்றும் Resend உள்ளிட்ட ஏழு நிறுவனங்கள் இதைத் தங்கள் பொது இணையதளங்களில் பயன்படுத்துகின்றன. மேலும், பொதுத் தளங்களிலிருந்து reverse-engineer செய்யப்பட்ட 73 கோப்புகளைக் கொண்ட ஒரு சமூகத் தொகுப்பும் உள்ளது. இதை நீங்கள் இப்போதே பின்பற்றக்கூடிய ஒரு மரபாகக் கருதி தாராளமாகப் பயன்படுத்தலாம், ஏனெனில் உங்கள் section பெயர்களை உறுதிப்படுத்த எந்தக் கட்டுப்பாடும் இல்லை.

DESIGN.md-ஐ AGENTS.md-ன் ஒரு பகுதியாக மட்டும் வைக்கலாமா?

சிறிய repository-களுக்கு, ஆம். ஒரு கோப்பை agent நிச்சயமாகப் படிக்கும் என்பது, இரண்டு கோப்புகளில் ஒன்று புறக்கணிக்கப்படுவதை விட சிறந்தது. AGENTS.md-ஐ எளிதாகப் படிக்க முடியாத நிலை ஏற்படும்போதோ அல்லது இரண்டு பகுதிகளும் வெவ்வேறு வேகத்தில் மாறுகின்றன என்று நீங்கள் உணரும்போதோ அவற்றை இரண்டாகப் பிரிக்கவும். build மாறும்போது AGENTS.md மாறும். ஒரு முடிவு மாறும்போது DESIGN.md மாறும்; இது அரிதாகவே நடக்கும், ஆனால் அதிக முக்கியத்துவம் வாய்ந்தது. நீங்கள் பிரிக்கும்போது, AGENTS.md-ல் ஒரு வரியைச் சேர்த்து, code-ஐ மாற்றும் முன் DESIGN.md-ஐப் படிக்குமாறு agent-க்கு அறிவுறுத்தவும். ஏனெனில், எல்லா கருவிகளும் root-ல் உள்ள அனைத்து markdown கோப்புகளையும் ஏற்றுவதில்லை.

DESIGN.md, architecture decision record-லிருந்து எவ்வாறு வேறுபடுகிறது?

ADR (architecture decision record) என்பது ஒரு முடிவின் தேதியிடப்பட்ட பதிவு. ஆரோக்கியமான ஒரு திட்டத்தில் இது போன்ற டஜன் கணக்கான பதிவுகள் ஒரு கோப்புறையில் இருக்கும். அது ஒரு வரலாறு; அந்த வரலாற்றைப் படிப்பது கடினம், ஏனெனில் எது இன்னும் நடைமுறையில் உள்ளது என்பதை அறிய agent அவை அனைத்தையும் படிக்க வேண்டியிருக்கும். DESIGN.md என்பது தற்போதைய நிலை; ஒவ்வொரு பணியின் போதும் முழுமையாகப் படிக்கும் வகையில் இது எழுதப்படுகிறது. நீங்கள் ஏற்கனவே ADR-களை எழுதுகிறீர்கள் என்றால், இரண்டையும் வைத்திருங்கள். என்ன முடிவு எடுக்கப்பட்டது, எப்போது எடுக்கப்பட்டது என்பதை ADR கூறுகிறது. இன்று எது உண்மை என்பதை DESIGN.md கூறுகிறது, மேலும் agent-க்கு நீங்கள் இதையே சுட்டிக்காட்ட வேண்டும்.

DESIGN.md எவ்வளவு நீளமாக இருக்க வேண்டும்?

ஒவ்வொரு முறையும் தயக்கமின்றி ஏற்றும் அளவுக்குச் சுருக்கமாக இருக்க வேண்டும். வெளியிடப்பட்ட உதாரணங்கள் நீளமாக இருப்பதற்குக் காரணம், அவை முழுமையான visual language-ஐ வரையறுக்கின்றன: ஆகஸ்ட் 2026 நிலவரப்படி, Nuxt கோப்பு சுமார் 2,100 சொற்களையும், Vercel கோப்பு சுமார் 6,500 சொற்களையும் கொண்டுள்ளன. ஒரு backend service-க்கு இதைவிட மிகக் குறைவான அளவே தேவைப்படும். ஒரு பக்கத்தில் தொடங்கி, ஒரு வரியின் மூலம் தவிர்க்கக்கூடிய தவறை agent செய்யும் போது மட்டும் அதை விரிவுபடுத்துங்கள். நீளம் ஒரு அளவுகோல் அல்ல. ஒவ்வொரு வரியும், agent தவறாகச் செய்யக்கூடிய ஒரு விஷயமாக இருக்க வேண்டும்.