assumption-mapper

# machine-translated to hi from skills/assumption-mapper/SKILL.md — review: pending. Native fixes welcome via PR.name: assumption-mapperdescription: "किसी प्रोडक्ट ब्रीफ़ या PRD में छिपी धारणाओं को निकालें और उनके जोखिम का आकलन करें। जब कोई प्रोडक्ट ब्रीफ़ की धारणाओं की समीक्षा करने, PRD के जोखिमों का ऑडिट करने, छिपी धारणाएँ खोजने, प्रोडक्ट योजनाओं को सत्यापित करने या धारणा विश्लेषण चलाने को कहे, तब इसका उपयोग करें। विश्वास और प्रभाव स्कोर, सुझाई गई सत्यापन विधियों और महत्वपूर्ण धारणाओं के चिह्नों के साथ एक प्राथमिकता-क्रम वाला धारणा मानचित्र तैयार करता है।"

असम्प्शन मैपर स्किल

विकास शुरू होने से पहले किसी भी प्रोडक्ट योजना में अंतर्निहित अपरीक्षित धारणाओं को सामने लाएँ और प्राथमिकता दें।

आवश्यक इनपुट

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

• प्रोडक्ट ब्रीफ़, PRD या कॉन्सेप्ट विवरण (कच्चे नोट भी चलेंगे)
• चरण (कॉन्सेप्ट / डिस्कवरी / निर्माण-पूर्व / लॉन्च-पश्चात — तय करता है कि कौन सी धारणाएँ सबसे ज़्यादा मायने रखती हैं)

यह कहाँ बैठता है — रीढ़ का प्रवेश बिंदु

यह प्रोडक्ट-निर्णय रीढ़ का अगला सिरा है: assumption-mapper → /prd-template → /rice-prioritisation → /roadmap-narrative। यह एक कच्चा विचार या ब्रीफ़ लेता है और अगली स्किल को एक चीज़ सौंपता है: सबसे जोखिम भरी धारणा, और क्या वह एक सस्ते परीक्षण से बच पाई। साझा शब्द (धारणा, भार-वाहक, विश्वास, स्रोत) एक ही बार docs/craft/product-decisions.md में परिभाषित हैं — उन्हें दोबारा गढ़ने के बजाय वहीं देखें। एक अपरीक्षित भार-वाहक धारणा के ऊपर PRD लिखना वही विफलता है जिसे रोकने के लिए यह स्किल है, इसलिए इसे /prd-template से पहले चलाएँ, बाद में नहीं।

चक्र

चार चरण। चरण 3 ही स्किल है; बाकी उसे पोषित करते हैं। हर चरण एक पूर्णता मानदंड पर समाप्त होता है — उसके पूरे हुए बिना आगे न बढ़ें।

1. चारों लेंस से सामने लाएँ। वांछनीयता (क्या उपयोगकर्ता इसे चाहते हैं?), व्यवहार्यता (क्या हम इसे बना सकते हैं?), लाभप्रदता (क्या व्यवसाय इसे टिका पाएगा?), उपयोगिता (क्या उपयोगकर्ता वास्तव में इसका उपयोग कर पाएँगे?) में धारणाएँ निकालें। ख़तरनाक धारणाएँ वे हैं जो इतनी स्पष्ट हैं कि किसी ने उन्हें लिखा ही नहीं। पूरा तब जब: हर लेंस में कम से कम एक धारणा हो, और सबसे खाली लेंस के लिए ब्रीफ़ को दोबारा पढ़ने पर कुछ नया न निकले।
2. सिर्फ़ दो अक्षों पर आँकें। हर एक के लिए: भार-वाहक (1–5, अगर यह झूठी निकले तो क्या योजना ढह जाती है?) और विश्वास (1–5, हम कितने निश्चित हैं कि यह सच है?)। प्राथमिकता = भार-वाहक − विश्वास। हर तथ्य के स्रोत को टैग करें ([data]/[hunch])। पूरा तब जब: हर धारणा के दोनों स्कोर और स्रोत टैग हों, और सबसे ऊँची प्राथमिकता वाली वास्तव में सबसे डरावनी हो — सबसे आसानी से परखने योग्य नहीं।
3. सबसे जोखिम भरी को खोजें और दबाव डालें। शीर्ष-प्राथमिकता धारणा (उच्च भार-वाहक × निम्न विश्वास) वह है जो पूरी योजना डुबो सकती है। कोड की एक पंक्ति लिखे जाने से पहले उसे ग़लत साबित कर सकने वाले सबसे सस्ते परीक्षण का नाम लें (मेन्यू के लिए cheap-tests संदर्भ देखें)। पूरा तब जब: एकमात्र सबसे जोखिम भरी धारणा नामित हो, एक ऐसे परीक्षण के साथ जो इसी सप्ताह चल सके और एक स्पष्ट "असफलता कैसी दिखेगी" के साथ।
4. सौंपें। क्रमबद्ध मानचित्र दें, और स्पष्ट रूप से बताएँ कि /prd-template को किस धारणा को सत्यापित-या-खुला मानना चाहिए। अनसुलझी सबसे जोखिम भरी धारणा PRD में एक खुला प्रश्न बनती है, मौन दाँव नहीं। पूरा तब जब: अगली स्किल यह दोबारा पूछे बिना कि जोखिम भरा दाँव क्या है, इस आउटपुट से शुरू कर सके।

आउटपुट संरचना

धारणा मानचित्र: [फ़ीचर/प्रोडक्ट का नाम]

महत्वपूर्ण धारणाएँ (प्रभाव 4+ और विश्वास 2 या कम)

[विस्तृत सत्यापन सिफ़ारिशों के साथ चिह्नित आइटम]

सबसे पहले सत्यापित करने योग्य शीर्ष 3 धारणाएँ

[विस्तृत सिफ़ारिशें, जिनमें विशिष्ट रिसर्च विधि, अनुमानित प्रयास, और नतीजा क्या बदलेगा, शामिल हों]

उदाहरण (आंशिक)

इनपुट: "हम SMB ग्राहकों के लिए time-to-value घटाने हेतु एक सेल्फ़-सर्व ऑनबोर्डिंग फ़्लो बना रहे हैं।"

एंटी-पैटर्न

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

गहरी सामग्री

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

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

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

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

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

• हर श्रेणी (वांछनीयता, व्यवहार्यता, लाभप्रदता, उपयोगिता) में कम से कम एक धारणा
• प्रभाव 4+ / विश्वास 2− वाली सभी धारणाएँ CRITICAL चिह्नित
• हर सत्यापन विधि विशिष्ट है (सिर्फ़ "रिसर्च करें" नहीं — विधि और सैंपल साइज़ का नाम लें)
• प्राथमिकता स्कोर संगत हैं (प्रभाव − विश्वास, जितना ऊँचा उतना अधिक अत्यावश्यक)

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

• "इस प्रोडक्ट ब्रीफ़ की धारणाओं की समीक्षा करो।"
• "PRD के जोखिमों का ऑडिट करो।"
• "छिपी धारणाएँ खोजो।"
• "प्रोडक्ट योजनाओं को सत्यापित करो।"
• "धारणा विश्लेषण चलाओ।"

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