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

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

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

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

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

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

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

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

• M1 format philosophy · 3 चैप्टर — यह फ़ॉर्मैट कौन-सी समस्या हल करना चाहता है, दोहरी संरचना, token·मुख्य पाठ priority
• M2 token schema · 5 चैप्टर — पूरा schema / color / length·unit / font / token references
• M3 section structure · 6 चैप्टर — 8 sections का क्रम और हर section के design principles
• 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 extensibility · 2 चैप्टर — अनजान सामग्री के लिए handling 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 में बताइए, मैं उसे reflect करूँगा.

[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 के लिए पालन किए जाने वाले मानदंडों को कितना साफ़-साफ़ छोड़कर जाती है, और उन मानदंडों को जीवित बनाए रखने वाला स्पर्श अभी भी इंसानों के पास रहता है — मैं इसे इसी तरह संक्षेप में समझता हूँ।