technical-spec-template

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

तकनीकी स्पेक टेम्पलेट स्किल

ऐसे तकनीकी विनिर्देश लिखें जिन्हें इंजीनियर वास्तव में पढ़ें — स्पष्ट समस्या ढाँचा, असंदिग्ध आवश्यकताएँ, स्पष्ट निर्णय और दस्तावेज़ित समझौते।

आवश्यक इनपुट

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

• फ़ीचर या सिस्टम विवरण (किसका स्पेक बनाना है)
• संबंधित PRD या प्रोडक्ट ब्रीफ़ (उपलब्ध हो तो)
• इंजीनियरिंग समीक्षक (किसका साइन-ऑफ़ चाहिए)
• ज्ञात बाधाएँ (तकनीकी सीमाएँ, सुरक्षा आवश्यकताएँ, प्रदर्शन लक्ष्य)

टेक स्पेक कब लिखें

टेक स्पेक तब लिखें जब:

• फ़ीचर को 2+ सिस्टम में बदलाव चाहिए
• महत्वपूर्ण आर्किटेक्चर निर्णय लेने हैं
• कार्यान्वयन पर एक से ज़्यादा इंजीनियर काम करेंगे
• फ़ीचर के सुरक्षा, गोपनीयता या अनुपालन निहितार्थ हैं
• अनुमानित प्रयास >5 स्टोरी पॉइंट है

मामूली बग फ़िक्स या 1-2 घंटे के बदलावों के लिए स्पेक छोड़ दें।

---

तकनीकी स्पेक आउटपुट फ़ॉर्मैट

तकनीकी विनिर्देश — [फ़ीचर का नाम]

लेखक: [नाम] स्थिति: मसौदा | समीक्षा में | मंज़ूर | लागू बनाया: [तारीख़] | अंतिम अपडेट: [तारीख़] समीक्षक: [इंजीनियरिंग लीड, आर्किटेक्ट, PM, ज़रूरत हो तो सुरक्षा] संबंधित PRD: [लिंक] | Jira एपिक: [लिंक]

---

1. समस्या कथन

[2–3 वाक्य। हम कौन सी समस्या हल कर रहे हैं और अभी क्यों? यहाँ कोई समाधान भाषा नहीं।]

2. लक्ष्य और गैर-लक्ष्य

लक्ष्य (दायरे में):

• [विशिष्ट, मापने योग्य परिणाम]
• [विशिष्ट, मापने योग्य परिणाम]

गैर-लक्ष्य (स्पष्ट रूप से दायरे से बाहर):

• [यह स्पेक क्या कवर नहीं करता]
• [जल्दी बंद करने योग्य आम धारणा]

3. पृष्ठभूमि और संदर्भ

[कोई पूर्व कार्य, संबंधित सिस्टम, या संदर्भ जो इंजीनियरों को निर्णय क्षेत्र समझने के लिए चाहिए। पिछले स्पेक, ADR या रिसर्च के लिंक।]

4. प्रस्तावित समाधान

उच्च-स्तरीय तरीका: [चुने गए समाधान का वर्णन करते 2–4 वाक्य। विकल्पों के बजाय यह तरीका क्यों?]

सिस्टम आर्किटेक्चर आरेख: [वर्णन करें या एम्बेड करें: कौन सी सेवाएँ शामिल हैं, डेटा कैसे बहता है, कौन से API कॉल होते हैं]

डेटा मॉडल बदलाव:

-- New tables or schema changes
[Include DDL or schema definition]

API डिज़ाइन:

[Endpoint] [Method]
Request: { [fields and types] }
Response: { [fields and types] }
Error codes: [list]

मुख्य कार्यान्वयन विवरण:

• [महत्वपूर्ण तकनीकी बाधा या तरीका]
• [किनारे के मामलों का संचालन]
• [तृतीय-पक्ष डिपेंडेंसी और संस्करण]

5. विचार किए गए वैकल्पिक तरीके

6. सुरक्षा और गोपनीयता विचार

• संग्रहीत डेटा: [कौन सा PII या संवेदनशील डेटा शामिल है]
• प्रमाणीकरण: [पहुँच कैसे नियंत्रित है]
• प्राधिकरण: [कौन सी अनुमतियाँ चाहिए]
• एन्क्रिप्शन: [रेस्ट / ट्रांज़िट में आवश्यकताएँ]
• अनुपालन निहितार्थ: [GDPR, SOC2 आदि, प्रासंगिक हो तो]

7. प्रदर्शन और स्केलेबिलिटी

• अपेक्षित लोड: [अनुरोध/सेकंड, डेटा मात्रा]
• लेटेंसी आवश्यकताएँ: [P50 / P95 लक्ष्य]
• कैशिंग रणनीति: [लागू हो तो]
• डेटाबेस इंडेक्सिंग: [आवश्यक नए इंडेक्स]
• ज्ञात अड़चनें: [कहाँ नज़र रखें]

8. परीक्षण योजना

• यूनिट टेस्ट: [कवर करने योग्य मुख्य परिदृश्य]
• इंटीग्रेशन टेस्ट: [परखने योग्य सिस्टम सीमाएँ]
• लोड टेस्ट: [प्रदर्शन-गंभीर हो तो]
• किनारे के मामले: [ज्ञात पेचीदा परिदृश्य]
• रोलबैक योजना: [कुछ ग़लत हो तो कैसे वापस लें]

9. रोलआउट योजना

• फ़ीचर फ़्लैग: [हाँ / नहीं — फ़्लैग का नाम]
• रोलआउट चरण: [हर चरण में उपयोगकर्ताओं का %]
• मॉनिटरिंग: [सेट करने योग्य मेट्रिक और अलर्ट]
• रोलआउट आगे बढ़ाने के सफलता मानदंड: [क्या सच होना चाहिए]
• रोलबैक ट्रिगर: [क्या तत्काल रोलबैक कराएगा]

10. खुले प्रश्न

11. कार्यान्वयन समयरेखा (मोटी)

---

दिशानिर्देश

• स्पेक एक निर्णय रिकॉर्ड है, कार्य-सूची नहीं — दस्तावेज़ित करें कि निर्णय क्यों लिए गए
• सभी खुले प्रश्नों का स्वामी और नियत तिथि होनी चाहिए
• उपयोगकर्ता डेटा छूने वाले फ़ीचर के लिए सुरक्षा और गोपनीयता खंड कभी वैकल्पिक नहीं
• async समीक्षा की सिफ़ारिश करें: इंजीनियर पहले पढ़ें, फिर प्रश्न सुलझाने के लिए 30-मिनट का सिंक
• कार्यान्वयन के साथ स्पेक अपडेट रखें — पुराने स्पेक बिना स्पेक से बदतर हैं

गहरी सामग्री

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

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

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

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

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

• समस्या कथन में कोई समाधान भाषा नहीं
• गैर-लक्ष्य स्पष्ट रूप से कम से कम 2 ऐसी चीज़ें सूचीबद्ध करते हैं जिन्हें दायरे में माना जा सकता था
• खारिज करने के कारणों के साथ कम से कम 2 वैकल्पिक तरीके दस्तावेज़ित हैं
• उपयोगकर्ता डेटा छूने वाले किसी भी फ़ीचर के लिए सुरक्षा और गोपनीयता खंड पूरा है
• सभी खुले प्रश्नों का नामित स्वामी और नियत तिथि है ("TBD" नहीं)

एंटी-पैटर्न

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

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

• "एक टेक स्पेक लिखो।"
• "इस फ़ीचर के लिए इंजीनियरिंग स्पेक लिखो।"
• "एक सिस्टम डिज़ाइन डॉक लिखो।"
• "एक API विनिर्देश लिखो।"

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