DESIGN.md — AI कोडिंग टूल्स के लिए डिज़ाइन सिस्टम का सिंगल-फ़ाइल फ़ॉर्मैट (कोरियाई सारांश)

Google Labs ने Stitch प्रोजेक्ट में जो DESIGN.md फ़ॉर्मैट प्रस्तावित किया है, वह दिलचस्प लगा। मैंने कुछ दिनों तक उसकी स्पेक को गहराई से देखा, और लगा कि इसे सिर्फ़ अपने तक रखना ठीक नहीं होगा, इसलिए उसे कोरियाई में खोलकर 28 चैप्टर वाले curriculum के रूप में व्यवस्थित कर दिया। उद्देश्य यह था कि जो लोग इसी विषय को पढ़ रहे हैं उन्हें शुरू से अंग्रेज़ी स्पेक खंगालनी न पड़े, और जो लोग मेरी तरह यह सवाल रखते हैं कि "AI को डिज़ाइन सिस्टम कैसे पढ़ाया जाए", वे इसे एक बार में देख सकें.

DESIGN.md एक ऐसा फ़ॉर्मैट है जो डिज़ाइन सिस्टम को एक ही Markdown फ़ाइल में व्यक्त करना चाहता है। color, typography, spacing, radius, component token जैसी वैल्यूज़ को YAML frontmatter में मशीन-पठनीय रूप में रखा जाता है, और उसके नीचे Markdown में "यह रंग क्यों इस्तेमाल किया जाता है", "यह button style किन स्थितियों में इस्तेमाल होना चाहिए", "किन patterns से बचना चाहिए" जैसी डिज़ाइन निर्णय-मानदंड लिखे जाते हैं। यानी यह सिर्फ़ एक style guide नहीं, बल्कि Claude Code, Cursor, Codex जैसे AI coding agents के लिए हर बार संदर्भित किया जाने वाला "डिज़ाइन सिस्टम का source file" अधिक है.

पृष्ठभूमि — व्यवस्थित करते समय फिर से देखे गए बदलाव

• पुराना सवाल: "डिज़ाइन सिस्टम को Figma में अच्छी तरह कैसे व्यवस्थित करें"
• आज का सवाल: "AI coding tools हमारे डिज़ाइन सिस्टम को कैसे पढ़ें", "नई page बनाते समय AI हमारे brand के color, spacing, component rules का पालन करे, इसके लिए क्या चाहिए"
• Claude Design, Claude Code, Figma MCP जैसे प्रवाह के साथ जुड़ा वह बदलाव जिसमें डिज़ाइन सिस्टम अब सिर्फ़ Figma में नहीं रहता, बल्कि codebase में आता है, PR में review होता है, और AI agent का "persistent context" बनता है

DESIGN.md फ़ॉर्मैट का सार (स्पेक पढ़ते समय जो हिस्से प्रभावशाली लगे)

• YAML (मशीन के लिए) + Markdown (इंसान और AI के लिए) की दोहरी संरचना — tokens को मशीन parse करती है, और body वह परत है जहाँ इंसान निर्णय का आधार दर्ज करता है
• token सही उत्तर, body उसका कारण — जब दोनों में अंतर हो तो किस पर भरोसा करना है, इसकी priority पहले से तय होना साफ़-सुथरा लगा
• 8 sections का क्रम तय — colors, typography, spacing, components आदि sections स्वयं डिज़ाइन सिस्टम के mental model की भूमिका निभाते हैं
• lint / diff / export / spec CLI — broken references, कम contrast ratio, orphan tokens, section order violation जैसी चीज़ों की स्वतः जाँच
• DTCG, Tailwind, Figma variables के साथ interoperability policy को अलग से स्पष्ट किया गया है

curriculum संरचना (28 चैप्टर, 7 modules)

• M1 फ़ॉर्मैट दर्शन · 3 चैप्टर — यह फ़ॉर्मैट कौन-सी समस्या हल करना चाहता है, दोहरी संरचना, token और body की priority
• M2 token schema · 5 चैप्टर — पूरा schema / color / length·unit / font / token references
• M3 section structure · 6 चैप्टर — 8 sections का क्रम और हर section के डिज़ाइन सिद्धांत
• M4 वास्तविक उदाहरण पढ़ना · 3 चैप्टर — Atmospheric Glass, Paws & Paths, Totality Festival cases
• M5 CLI · 4 चैप्टर — lint, diff, export, spec
• M6 lint rules · 4 चैप्टर — broken-ref, contrast, orphaned, section-order आदि 8
• M7 विस्तारशीलता · 2 चैप्टर — अज्ञात सामग्री को संभालने की policy, DTCG और Tailwind के साथ संबंध
• अंतिम सार · 1 चैप्टर — 27 चैप्टर का सारांश + काम में ले जाने लायक 10 सिद्धांत

इसे व्यवस्थित करते समय आए विचार

• जितना ज़्यादा AI UI बनाएगा, उतना ही डिज़ाइन सिस्टम शायद और महत्वपूर्ण होगा। मुद्दा यह कम लगता है कि "AI डिज़ाइन अच्छा करता है या नहीं", और यह ज़्यादा कि "टीम ने AI के पालन के लिए मानदंड कितनी स्पष्टता से छोड़े हैं"
• DESIGN.md उस मानदंड को Notion या PDF में नहीं, बल्कि codebase के भीतर रखने की एक व्यावहारिक कोशिश है। इसका मतलब यह भी है कि designer का output PR unit पर review का विषय बनता है
• जो लोग डिज़ाइन सिस्टम बना रहे हैं, या AI coding tools से UI बनाते हुए यह महसूस कर चुके हैं कि "हर बार output इतना अलग-अलग क्यों आता है", उनके साथ यह साझा करना उपयोगी लगा। अगर कहीं समझने या व्यवस्थित करने में गलती हुई हो, तो comments में बताइए, मैं उसे शामिल कर दूँगा.

[m00nlygreat]

एक बात जाननी है: अगर DESIGN.md को डिज़ाइन निकालने के लिए दिए गए निर्देशों की तरह माना जाए, तो आखिरकार यह शुरुआती कुछ पेजों... या एक पेज, मूड बोर्ड बनाने के लिए इस्तेमाल होगा। उसके बाद क्या कोड और निर्देश.md के बीच असंगति नहीं पैदा होगी, जिसके कारण लगातार दोनों दिशाओं में sync करना पड़ेगा?

आखिर में बाद का डिज़ाइन तो code को source of truth मानकर, variables या names जैसी चीज़ों को लगातार reuse करते हुए ही सुसंगत रहना चाहिए। अगर DESIGN.md को लगातार update करके SSoT की तरह manage न किया जाए, तो क्या फिर tokens बार-बार hardcode नहीं करने पड़ेंगे? वास्तविक उपयोग में क्या इस तरह की समस्या नहीं आती, यह जानना चाहता हूँ.

[neostom432]

DESIGN.md => कोड की दिशा को ऑटोमेट करना आसान है, लेकिन उल्टा कोड में नए बने पैटर्न का DESIGN.md तक ऊपर आना अपने-आप नहीं होता, इसलिए लोगों को इसे सीधे संभालना पड़ता है। समय बीतने पर कोड में छोटी-छोटी hardcoding जमा होती जाती है, लेकिन वह डॉक्यूमेंट में नहीं पहुंचती, और ऐसी बातें धीरे-धीरे इकट्ठी हो जाती हैं.

हालांकि, इस फ़ॉर्मैट की मूल फिलॉसफी ही यह है कि "design system को codebase के भीतर लगातार संवारा जाए", इसलिए मैं इसे कमी से ज़्यादा एक इरादतन ऑपरेटिंग तरीका मानता हूँ। Notion या PDF में स्थिर पड़े guides को PR-स्तर की review के दायरे में खींच लाने के साथ, लोगों की नियमित देखरेख की ज़िम्मेदारी भी साथ आती है। हमने इसे अपने प्रोजेक्ट में अपनाकर देखा, और अपनाने से पहले की तुलना में स्क्रीन की consistency स्पष्ट रूप से बेहतर हुई। इसका फ़ायदा महसूस होने लगा, तो manual review बोझ नहीं लगा। आख़िरकार बात इस पर आकर टिकती है कि टीम AI के लिए पालन किए जाने वाले मानदंडों को कितना साफ़-साफ़ छोड़कर जाती है, और उन मानदंडों को जीवित बनाए रखने वाला स्पर्श अभी भी इंसानों के पास रहता है — मैं इसे इसी तरह संक्षेप में समझता हूँ।