technical-debt-register

# machine-translated to hi from skills/technical-debt-register/SKILL.md — review: pending. Native fixes welcome via PR.name: technical-debt-registerdescription: "व्यावसायिक प्रभाव, प्रयास अनुमानों और समाधान रणनीति के साथ तकनीकी ऋण बैकलॉग को दस्तावेज़ित और प्राथमिकता दें। जब कोई तकनीकी ऋण का ऑडिट करने, ऋण रजिस्टर बनाने, तिमाही के लिए तकनीकी ऋण को प्राथमिकता देने, आर्किटेक्चर शॉर्टकट दस्तावेज़ित करने या ऋण कटौती रोडमैप बनाने को कहे, तब इसका उपयोग करें। श्रेणी के अनुसार ऋण सूची, प्रति आइटम व्यावसायिक प्रभाव, प्रयास और प्राथमिकता स्कोर, शीर्ष आइटम समाधान योजनाओं और त्रैमासिक ऋण कटौती रोडमैप को कवर करने वाला संरचित तकनीकी ऋण रजिस्टर तैयार करता है।"

तकनीकी ऋण रजिस्टर स्किल

किसी टीम या सेवा के लिए पूरा तकनीकी ऋण रजिस्टर तैयार करें। ऋण रजिस्टर शिकायत सूची नहीं है — यह एक प्राथमिकता-क्रम, व्यावसायिक-प्रभाव-सजग सूची है जो इंजीनियरिंग टीम को यह सोच-समझकर चुनने देती है कि कौन सा ऋण चुकाना है, किस क्रम में, और किस अपेक्षित प्रतिफल के साथ।

अच्छा ऋण प्रबंधन सारा ऋण ख़त्म करना नहीं है। यह सुनिश्चित करना है कि ऋण दृश्य हो, उसका स्वामी हो, और जब ब्याज की लागत ठीक करने की लागत से ज़्यादा हो जाए तब उसे हल किया जाए।

आवश्यक इनपुट

पहले से न दिए गए हों तो ये माँगें:

• टीम या सेवा का नाम — यह रजिस्टर किस टीम और/या सेवा को कवर करता है
• ज्ञात ऋण आइटम — ज्ञात तकनीकी ऋण की सूची, या Claude से इनके बारे में पूछकर निकालने को कहें: लीगेसी कोड, गायब टेस्ट, पुरानी डिपेंडेंसी, आर्किटेक्चर शॉर्टकट, मैनुअल प्रक्रियाएँ, ऑब्ज़र्वेबिलिटी की कमियाँ, सुरक्षा बैकलॉग
• टेक स्टैक — भाषा, फ़्रेमवर्क, इंफ़्रास्ट्रक्चर (Claude को आइटम सही वर्गीकृत और स्कोर करने में मदद करता है)
• टीम का आकार और वेलोसिटी — इंजीनियरों की संख्या और प्रति स्प्रिंट अनुमानित स्टोरी पॉइंट या दिन (प्रयास अनुमानों के लिए ज़रूरी)
• वर्तमान तिमाही / योजना अवधि — ताकि रोडमैप सही समयसीमा को लक्षित करे

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

---

तकनीकी ऋण रजिस्टर: [टीम / सेवा का नाम]

टीम: [नाम] | सेवा(एँ): [नाम] लेखक: [नाम] | अंतिम अपडेट: [तारीख़] योजना अवधि: [Q[X] [वर्ष]] | समीक्षा आवृत्ति: [मासिक / त्रैमासिक]

---

अवलोकन

[2–3 वाक्य जो टीम की वर्तमान ऋण स्थिति, ऋण की मुख्य श्रेणियाँ और व्यावसायिक संदर्भ बताएँ — जैसे क्या वे विकास चरण में हैं जहाँ वेलोसिटी मायने रखती है, या अनुपालन समयसीमा के पास जहाँ सुरक्षा ऋण गंभीर है?]

रजिस्टर में कुल आइटम: [X] अनसुलझे आइटम: [X] गंभीर/उच्च प्राथमिकता आइटम: [X] अनुमानित कुल समाधान प्रयास: [X स्टोरी पॉइंट / X इंजीनियर-सप्ताह]

---

ऋण श्रेणी परिभाषाएँ

---

ऋण रजिस्टर

स्कोरिंग विधि

व्यावसायिक प्रभाव (1–5):

• 5 — विकास रोक रहा, प्रोडक्शन घटनाएँ पैदा कर रहा, या अनुपालन जोखिम बना रहा
• 4 — डिलीवरी काफ़ी धीमी कर रहा या घटना की संभावना बढ़ा रहा
• 3 — ध्यान देने योग्य मंदी; प्रबंधनीय पर जमा हो रहा
• 2 — मामूली घर्षण; कम तात्कालिक जोखिम
• 1 — कॉस्मेटिक या आकांक्षी; कोई वर्तमान व्यावसायिक प्रभाव नहीं

हल करने का प्रयास (1–5, कम = आसान):

• 1 — <0.5 दिन; एक इंजीनियर
• 2 — 0.5–2 दिन; एक इंजीनियर
• 3 — 3–5 दिन; एक इंजीनियर या छोटी जोड़ी
• 4 — 1–2 सप्ताह; टीम सहयोग ज़रूरी
• 5 — >2 सप्ताह; महत्वपूर्ण योजना और समन्वय

प्राथमिकता स्कोर = व्यावसायिक प्रभाव × (6 − प्रयास) (उच्च-प्रभाव, कम-प्रयास आइटम को पुरस्कृत करता है)

---

---

श्रेणी विभाजन

Category distribution (by item count):
─────────────────────────────────────────────
Code quality     ████████░░  [X items]  ([X]%)
Architecture     ██████░░░░  [X items]  ([X]%)
Testing          █████████░  [X items]  ([X]%)
Security         ████░░░░░░  [X items]  ([X]%)
Dependencies     ███░░░░░░░  [X items]  ([X]%)
Infrastructure   ████░░░░░░  [X items]  ([X]%)
Observability    ████░░░░░░  [X items]  ([X]%)
Process          ██░░░░░░░░  [X items]  ([X]%)
─────────────────────────────────────────────

Priority distribution:
Critical (score 20–25): [X items]
High     (score 12–19): [X items]
Medium   (score  6–11): [X items]
Low      (score   1–5): [X items]

---

शीर्ष 5 प्राथमिकता आइटम — समाधान योजनाएँ

TD-XXX: [सर्वोच्च प्राथमिकता आइटम का नाम]

प्राथमिकता स्कोर: [स्कोर] | श्रेणी: [श्रेणी] | स्वामी: [नाम]

समस्या: [2–3 वाक्य जो बताएँ ऋण क्या है, कैसे प्रकट होता है, और अभी क्या दर्द देता है। विशिष्ट रहें — वास्तविक घटनाओं, मंदी या जोखिमों का संदर्भ दें।]

व्यावसायिक प्रभाव: [हल न हो तो क्या होगा? किसी घटना, नज़दीकी चूक या विकास अवरोधक का संदर्भ दें। जैसे "इसने पिछली तिमाही 2 प्रोडक्शन घटनाएँ पैदा कीं और इस क्षेत्र के किसी भी बदलाव में ~30 मिनट का डीबगिंग समय जोड़ता है।"]

समाधान का तरीका: [फ़िक्स का स्पष्ट विवरण। "कोड सुधारें" नहीं — वास्तविक काम बताएँ: "पेमेंट प्रोसेसिंग तर्क को समर्पित PaymentService क्लास में निकालें, 80% कवरेज तक यूनिट टेस्ट लिखें, और 3 कॉल साइट अपडेट करें।"]

चरण:

1. [विशिष्ट, टिकट-योग्य चरण]
2. [विशिष्ट, टिकट-योग्य चरण]
3. [विशिष्ट, टिकट-योग्य चरण]

स्वीकृति मानदंड:

• [मापने योग्य मानदंड — जैसे "एप्लिकेशन कोड में शून्य हार्ड-कोडेड कॉन्फ़िग मान बचे"]
• [मापने योग्य मानदंड — जैसे "नए टेस्ट के साथ CI पाइपलाइन पास"]
• [मापने योग्य मानदंड]

प्रयास अनुमान: [X स्टोरी पॉइंट / X दिन] सुझाया गया स्प्रिंट: [Q[X] स्प्रिंट [Y] / जब [निर्भरता] पूरी हो]

---

TD-XXX: [दूसरा प्राथमिकता आइटम का नाम]

प्राथमिकता स्कोर: [स्कोर] | श्रेणी: [श्रेणी] | स्वामी: [नाम]

समस्या: [विवरण]

व्यावसायिक प्रभाव: [प्रभाव विवरण]

समाधान का तरीका: [तरीके का विवरण]

चरण:

1. [चरण]
2. [चरण]
3. [चरण]

स्वीकृति मानदंड:

• [मानदंड]
• [मानदंड]

प्रयास अनुमान: [X स्टोरी पॉइंट / X दिन] सुझाया गया स्प्रिंट: [स्प्रिंट या समयसीमा]

---

TD-XXX: [तीसरा प्राथमिकता आइटम]

(ऊपर जैसा प्रारूप अपनाएँ)

---

TD-XXX: [चौथा प्राथमिकता आइटम]

(ऊपर जैसा प्रारूप अपनाएँ)

---

TD-XXX: [पाँचवाँ प्राथमिकता आइटम]

(ऊपर जैसा प्रारूप अपनाएँ)

---

ऋण कटौती रोडमैप

मार्गदर्शक सिद्धांत

• हर स्प्रिंट की क्षमता का [X%] ऋण समाधान को आवंटित करें — स्वस्थ टीमों के लिए 15–20% की सिफ़ारिश
• सुरक्षा और डिपेंडेंसी ऋण प्राथमिकता स्कोर की परवाह किए बिना तय अंतराल पर संबोधित होता है
• गंभीर ऋण वाले मॉड्यूल में कोई नया फ़ीचर काम नहीं जब तक ऋण वर्तमान स्प्रिंट में निर्धारित न हो
• बिना समाधान के बंद (स्वीकृत/टाले गए) ऋण आइटम का नामित स्वामी और समीक्षा तिथि होनी चाहिए

त्रैमासिक योजना

स्प्रिंट आवंटन मॉडल

Sprint capacity: [X] story points

Allocation:
  ├── Feature work:        [X * 0.75 = ~Y] points  (75%)
  ├── Debt resolution:     [X * 0.15 = ~Y] points  (15%)
  └── Unplanned/bugs:      [X * 0.10 = ~Y] points  (10%)

Debt items that fit in one sprint ([≤Y] points each):
  ✓ TD-002 ([X] points)
  ✓ TD-012 ([X] points)
  ✓ TD-006 ([X] points)
  ✓ TD-008 ([X] points)

Multi-sprint debt items (break into phases):
  ~ TD-001: Phase 1 ([X] pts) → Phase 2 ([X] pts)
  ~ TD-009: Requires dedicated debt sprint or pairing

---

स्वीकृत / टाला गया ऋण

ऐसे आइटम जहाँ उपचार की लागत वर्तमान में व्यावसायिक मूल्य से ज़्यादा है, स्पष्ट समीक्षा तिथियों के साथ स्वीकृत।

नीति: इंजीनियरिंग मैनेजर तक एस्केलेशन के बिना कोई आइटम दो बार से ज़्यादा नहीं टाला जा सकता।

---

गहरी सामग्री

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

• references/debt-pricing.md — ऋण की कीमत तय करना: "यह ख़राब है" को ऐसी संख्या में बदलना जिसे कोई रैंक कर सके। आउटपुट बनाते समय इसे लागू करें; इसमें वह कैलिब्रेशन और निर्णय-विवेक है जिसे ऊपर का संक्षिप्त तरीका संकुचित कर देता है।
• templates/debt-entry.md — डिलिवरेबल का भरने योग्य संस्करण, गुणवत्ता-जाँच इनलाइन सहित। जब उपयोगकर्ता दस्तावेज़ खुद बनाना चाहे, उसे जनरेट करवाने के बजाय, तब यह पेश करें।

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

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

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

• हर आइटम का नामित स्वामी है — कोई बिना स्वामी का ऋण नहीं
• प्राथमिकता स्कोर सूत्र से निकाले गए हैं, मनमाने ढंग से नहीं
• सुरक्षा और डिपेंडेंसी आइटम "तकनीकी" लगने के कारण वास्तविक व्यावसायिक प्रभाव से कम स्कोर नहीं किए गए
• शीर्ष-5 समाधान योजनाओं में विशिष्ट, टिकट-योग्य चरण हैं — "टेस्ट कवरेज सुधारें" जैसे धुँधले विवरण नहीं
• त्रैमासिक रोडमैप यथार्थवादी क्षमता आवंटित करता है — ऋण आवंटन वास्तविक स्प्रिंट बजट से ज़्यादा नहीं
• स्वीकृत/टाले गए आइटम की समीक्षा तिथि और नामित स्वामी है — कोई स्थायी रूप से टाला आइटम नहीं
• रजिस्टर ऋण (जानबूझकर या जमा शॉर्टकट) और बग (अनचाहे दोष) में भेद करता है
• आइटम सिर्फ़ तब हल चिह्नित होते हैं जब स्वीकृति मानदंड पूरे हों — PR मर्ज होने पर नहीं

एंटी-पैटर्न

• ऋण आइटम मनमाने ढंग से स्कोर न करें — प्राथमिकता स्कोर दस्तावेज़ित सूत्र से निकाले जाने चाहिए
• तकनीकी ऋण (जानबूझकर शॉर्टकट) को बग (अनचाहे दोष) से न मिलाएँ — उन्हें अलग उपचार रणनीतियाँ चाहिए
• सुरक्षा और डिपेंडेंसी आइटम को अमूर्त लगने के कारण कम न आँकें — वास्तविक व्यावसायिक प्रभाव के आधार पर स्कोर करें
• "स्थायी रूप से टाले गए" आइटम न बनाएँ — हर स्वीकृत आइटम की समीक्षा तिथि और नामित स्वामी होना चाहिए
• धुँधले विवरण वाली समाधान योजनाएँ शामिल न करें — हर योजना में विशिष्ट, टिकट-योग्य चरण होने चाहिए

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

• "तकनीकी ऋण का ऑडिट करो।"
• "एक ऋण रजिस्टर बनाओ।"
• "एक तिमाही के लिए तकनीकी ऋण को प्राथमिकता दो।"
• "आर्किटेक्चर शॉर्टकट दस्तावेज़ित करो।"
• "ऋण कटौती रोडमैप बनाओ।"

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