← LeaderboardThe Skill Leaderboard

architecture-decision-record

किसी भी तकनीकी निर्णय के लिए आर्किटेक्चर डिसीज़न रिकॉर्ड (ADR) बनाएँ। जब कोई तकनीकी निर्णय दस्तावेज़ित करने, ADR लिखने, आर्किटेक्चर का चुनाव दर्ज करने या यह दर्ज करने को कहे कि कोई तकनीक या तरीका क्यों चुना गया, तब इसका उपयोग करें। संदर्भ, निर्णय, परिणाम और समझौतों के साथ एक संरचित ADR तैयार करता है।

Published by mohitagw15856 ↗mohitagw15856/pm-claude-skills

Try your first task

A source-grounded starter task has not been verified for this skill yet.

SKILL.md

# machine-translated to hi from skills/architecture-decision-record/SKILL.md — review: pending. Native fixes welcome via PR.name: architecture-decision-recorddescription: "किसी भी तकनीकी निर्णय के लिए आर्किटेक्चर डिसीज़न रिकॉर्ड (ADR) बनाएँ। जब कोई तकनीकी निर्णय दस्तावेज़ित करने, ADR लिखने, आर्किटेक्चर का चुनाव दर्ज करने या यह दर्ज करने को कहे कि कोई तकनीक या तरीका क्यों चुना गया, तब इसका उपयोग करें। संदर्भ, निर्णय, परिणाम और समझौतों के साथ एक संरचित ADR तैयार करता है।"

आर्किटेक्चर डिसीज़न रिकॉर्ड (ADR) स्किल

यह स्किल Nygard प्रारूप — सबसे व्यापक रूप से अपनाया गया मानक — के अनुसार एक पूरा आर्किटेक्चर डिसीज़न रिकॉर्ड (ADR) तैयार करती है। ADR महत्वपूर्ण तकनीकी निर्णयों के पीछे के तर्क को दर्ज करते हैं ताकि भविष्य के टीम सदस्य सिर्फ़ यह नहीं कि क्या तय हुआ, बल्कि क्यों तय हुआ, यह भी समझ सकें।

आवश्यक इनपुट

जो दिया गया है उसी से काम करें। इनमें से कुछ न हो तो भी पूरा आउटपुट बनाएँ: हर खाली जगह को (माना गया, पुष्टि करें) चिह्नित एक उचित धारणा से भरें और अंत में उन धारणाओं की सूची दें। सवाल पहले सिर्फ़ तब पूछें जब मुख्य विषय ही न हो (लिखने के लिए कुछ हो ही नहीं)।

  • ADR संख्या (आपकी ADR रजिस्ट्री में क्रमिक संख्या — जैसे 012; या अज्ञात हो तो "अगली उपलब्ध")
  • निर्णय का शीर्षक (संक्षिप्त, जैसे "प्राथमिक डेटास्टोर के रूप में PostgreSQL का उपयोग करें")
  • संदर्भ (किस स्थिति ने इस निर्णय की ज़रूरत पैदा की?)
  • विचार किए गए विकल्प (कम से कम 2; अगर सिर्फ़ 1 दिया गया है, तो उन विकल्पों के बारे में पूछें जिन पर विचार हुआ या जिन्हें खारिज किया गया)
  • लिया गया निर्णय (कौन सा विकल्प चुना गया)
  • चुनाव का कारण
  • स्थिति (प्रस्तावित / स्वीकृत / डेप्रिकेटेड / अधिक्रमित)
  • लेखक और तारीख़
  • टीम का संदर्भ (वैकल्पिक — टीम का आकार, प्रासंगिक अनुभव, संगठनात्मक बाधाएँ; संदर्भ खंड की औपचारिकता और गहराई तय करने में मदद करता है)

आउटपुट फ़ॉर्मैट

ADR-[NNN]: [निर्णय का शीर्षक]

तारीख़: [YYYY-MM-DD] स्थिति: [प्रस्तावित / स्वीकृत / डेप्रिकेटेड / ADR-NNN द्वारा अधिक्रमित] लेखक: [नाम] निर्णायक: [अंतिम फ़ैसला किसका था — व्यक्ति या टीम]

संदर्भ

[3–6 वाक्य। वह स्थिति, बाधाएँ और दबाव बताएँ जिनकी वजह से यह निर्णय ज़रूरी हुआ। शामिल करें: हल की जा रही समस्या, सिस्टम की प्रासंगिक स्थिति, टीम की बाधाएँ, समयसीमा का दबाव, या अनिवार्य आवश्यकताएँ। ऐसे लिखें मानो 18 महीने बाद टीम में शामिल होने वाले किसी ऐसे व्यक्ति को समझा रहे हों जिसके पास कोई पूर्व संदर्भ नहीं है।]

मुख्य बाधाएँ:

  • [बाधा 1: जैसे "एंटरप्राइज़ ग्राहकों के लिए on-premise तैनाती योग्य होना चाहिए"]
  • [बाधा 2: जैसे "टीम को Go का कोई पूर्व अनुभव नहीं"]
  • [जितनी प्रासंगिक हों, जोड़ें]

विचार किए गए विकल्प

हर विकल्प के लिए तैयार करें:

विकल्प [N]: [नाम]

विवरण: [यह विकल्प क्या है — 1–3 वाक्य]

पक्ष:

  • [पक्ष 1]
  • [पक्ष 2]

विपक्ष:

  • [विपक्ष 1]
  • [विपक्ष 2]

इसे क्यों खारिज किया गया (अगर नहीं चुना गया): [ईमानदार कारण]

निर्णय

हम [चुना गया विकल्प] करेंगे।

[2–4 वाक्यों में निर्णय को सादी भाषा में समझाएँ। यह अकेले पढ़ने योग्य होना चाहिए — किसी को पूरा दस्तावेज़ पढ़े बिना सिर्फ़ इस अनुच्छेद से निर्णय समझ में आ जाना चाहिए।]

परिणाम

सकारात्मक परिणाम

  • [यह निर्णय क्या सक्षम या बेहतर करता है]
  • [यह किस जोखिम को कम करता है]

नकारात्मक परिणाम / स्वीकृत समझौते

  • [इस निर्णय के फलस्वरूप हम क्या छोड़ रहे हैं या क्या ज़िम्मेदारी ले रहे हैं]
  • [पेश किया गया तकनीकी ऋण या सीमाएँ]
  • [इस निर्णय के वैध बने रहने के लिए अब क्या सच होना चाहिए]

जोखिम

  • [क्या इस निर्णय को पीछे मुड़कर देखने पर गलत साबित कर सकता है]
  • [क्या हमें इस निर्णय पर फिर से विचार करने के लिए प्रेरित करेगा]

कार्यान्वयन नोट

[अगर निर्णय में स्पष्ट न दिखने वाले कार्यान्वयन के पेच हैं, या संबंधित टिकट/RFC हैं जिनकी कार्यान्वयन करने वालों को ज़रूरत होगी, तो शामिल करें। सिर्फ़ तब छोड़ें जब निर्णय विशुद्ध टूलिंग चुनाव हो और कार्यान्वयन में कोई अस्पष्टता न हो।]

समीक्षा तिथि

[तब तक शामिल करें जब तक निर्णय स्थायी या स्वतः स्पष्ट रूप से अंतिम न हो। एक ठोस ट्रिगर स्थिति बताएँ — जैसे "अगर टीम 20 इंजीनियरों से बड़ी हो जाए या ट्रैफ़िक 10M अनुरोध/दिन से ऊपर जाए तो समीक्षा करें" — सिर्फ़ "समय-समय पर समीक्षा होनी चाहिए" नहीं।]

गहरी सामग्री

यह स्किल सहायक फ़ाइलों के साथ आती है — उपलब्ध हों तो उनका उपयोग करें:

  • references/decision-scoping.md — किसे ADR चाहिए (और "संदर्भ" में क्या होना चाहिए)। आउटपुट बनाते समय इसे लागू करें; इसमें वह कैलिब्रेशन और निर्णय-विवेक है जिसे ऊपर का संक्षिप्त तरीका संकुचित कर देता है।
  • templates/adr.md — डिलिवरेबल का भरने योग्य संस्करण, गुणवत्ता-जाँच इनलाइन सहित। जब उपयोगकर्ता दस्तावेज़ खुद बनाना चाहे, उसे जनरेट करवाने के बजाय, तब यह पेश करें।

स्कोरिंग रूब्रिक (0–40)

इस स्किल का कोई भी आउटपुट सौंपने से पहले स्कोर करें; 32+ शिप-गुणवत्ता है।

आयाम0510
संदर्भ का पुनर्निर्माणमान लेता है कि पाठक समस्या और दबाव पहले से जानता हैसमस्या बताई गई, पर दबाव (टीम की बाधाएँ, पैमाना, समयसीमा, प्रेरक घटना) गायबदो साल बाद का पाठक सिर्फ़ संदर्भ खंड से निर्णय का अनुमान लगा सके
विकल्पों की ईमानदारीसिर्फ़ चुना गया विकल्प, या खारिज विकल्प कमज़ोर करके लिखे गए≥2 विकल्प, पर खारिज करने के कारण गोलमोल ("आवश्यकताएँ पूरी नहीं कीं")हर खारिज विकल्प की वास्तविक ख़ूबियाँ और संदर्भ के किसी दबाव से जुड़ी एक ठोस हारने वाली बाधा
परिणामों का संतुलनसभी परिणाम सकारात्मकनाममात्र के नकारात्मक, बिना परिचालन विवरण केनकारात्मक वास्तविक ऋण, नए परिचालन बोझ और वह बताते हैं जो निर्णय के टिके रहने के लिए सच रहना चाहिए
पुनर्विचार ट्रिगरकोई जोखिम या समीक्षा शर्त नहीं"समय-समय पर समीक्षा" — कोई मापने योग्य शर्त नहींठोस, मापने योग्य ट्रिगर शर्तें जो निर्णय को अमान्य करेंगी, एक ज़िम्मेदार व्यक्ति के साथ

गुणवत्ता जाँच

  • संदर्भ क्यों समझाता है — सिर्फ़ क्या नहीं
  • कम से कम 2 विकल्प दस्तावेज़ित हैं (खारिज किए गए सहित)
  • खारिज विकल्पों में खारिज करने के ईमानदार कारण हैं
  • परिणामों में नकारात्मक परिणाम शामिल हैं — कोई निर्णय परिणाम-मुक्त नहीं होता
  • निर्णय खंड में निर्णय सादी भाषा में लिखा है
  • जोखिम खंड बताता है कि क्या इस निर्णय को अमान्य करेगा
  • संदर्भ खंड अपने पहले 1–2 वाक्यों में समस्या स्पष्ट रूप से बताता है (यह नहीं मानता कि पाठक जानता है टीम कौन सी समस्या हल कर रही थी)
  • हर खारिज विकल्प का "क्यों खारिज" स्पष्टीकरण कोई ठोस बाधा या समझौता बताता है (न कि "हमारी आवश्यकताएँ पूरी नहीं कीं" जैसा गोलमोल कथन)

एंटी-पैटर्न

  • निर्णय पूरी तरह लागू हो जाने और टीम के आगे बढ़ जाने के बाद ADR न लिखें — पीछे मुड़कर लिखे ADR अक्सर असली कारण और विकल्प छोड़ देते हैं
  • सिर्फ़ चुना गया विकल्प सूचीबद्ध न करें — ईमानदार कारणों के साथ खारिज विकल्प भविष्य के पाठकों के लिए ADR का सबसे मूल्यवान हिस्सा हैं
  • सिर्फ़ सकारात्मक परिणाम न लिखें — हर आर्किटेक्चर निर्णय में समझौते होते हैं; बिना नकारात्मक परिणाम वाले ADR की ईमानदारी से जाँच नहीं हुई
  • स्थिति को अनिश्चित काल तक "प्रस्तावित" न छोड़ें — जिस ADR को किसी ने मंज़ूर नहीं किया, वह किसी के निर्णय का मार्गदर्शन नहीं कर रहा
  • ऐसा संदर्भ न लिखें जो मान ले कि पाठक जानता है कौन सी समस्या हल हो रही थी — संदर्भ खंड ठीक उन्हीं पाठकों के लिए है जिनके पास वह पृष्ठभूमि नहीं है

उपयोग के उदाहरण

  • "[तकनीक] के उपयोग के लिए ADR लिखो"
  • "[आर्किटेक्चर विकल्प] के हमारे निर्णय को दस्तावेज़ित करो"
  • "[विषय] के लिए आर्किटेक्चर डिसीज़न रिकॉर्ड बनाओ"
  • "यह लिखने में मदद करो कि हमने [विकल्प] के बजाय [विकल्प] क्यों चुना"

उदाहरण ट्रिगर वाक्य

  • "एक तकनीकी निर्णय दस्तावेज़ित करो।"
  • "एक ADR लिखो।"
  • "आर्किटेक्चर का चुनाव दर्ज करो।"
  • "दर्ज करो कि कोई तकनीक क्यों चुनी गई।"

इस स्किल को अपने ब्राउज़र में चलाएँ: https://mohitagw15856.github.io/pm-claude-skills/skill/architecture-decision-record.html

architecture-decision-record by mohitagw15856 · The Skill Leaderboard