user-story-writer
स्वीकृति मानदंड और किनारे के मामलों के साथ सुसंरचित यूज़र स्टोरी लिखें। जब कोई यूज़र स्टोरी लिखने, फ़ीचर ब्रीफ़ से टिकट बनाने, PRD को स्टोरी में बदलने या स्वीकृति मानदंड लिखने को कहे, तब इसका उपयोग करें। स्पष्ट स्वीकृति मानदंड, किनारे के मामलों और definition of done के साथ मानक प्रारूप में अनुमान-तैयार स्टोरी तैयार करता है।
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/user-story-writer/SKILL.md — review: pending. Native fixes welcome via PR.name: user-story-writerdescription: "स्वीकृति मानदंड और किनारे के मामलों के साथ सुसंरचित यूज़र स्टोरी लिखें। जब कोई यूज़र स्टोरी लिखने, फ़ीचर ब्रीफ़ से टिकट बनाने, PRD को स्टोरी में बदलने या स्वीकृति मानदंड लिखने को कहे, तब इसका उपयोग करें। स्पष्ट स्वीकृति मानदंड, किनारे के मामलों और definition of done के साथ मानक प्रारूप में अनुमान-तैयार स्टोरी तैयार करता है।"यूज़र स्टोरी राइटर स्किल
यह स्किल फ़ीचर ब्रीफ़, PRD खंड या मौखिक विवरण से प्रोडक्शन-तैयार यूज़र स्टोरी तैयार करती है। हर स्टोरी स्पष्ट कौन/क्या/क्यों, Given/When/Then प्रारूप में व्यवहारिक स्वीकृति मानदंड, किनारे के मामलों और definition of done के साथ मानक प्रारूप का पालन करती है। आउटपुट Jira, Linear या आपके प्लानिंग टूल में पेस्ट करने के लिए तैयार होता है।
आवश्यक इनपुट
जो दिया गया है उसी से काम करें। इनमें से कुछ न हो तो भी पूरा आउटपुट बनाएँ: हर खाली जगह को (माना गया, पुष्टि करें) चिह्नित एक उचित धारणा से भरें और अंत में उन धारणाओं की सूची दें। सवाल पहले सिर्फ़ तब पूछें जब मुख्य विषय ही न हो (लिखने के लिए कुछ हो ही नहीं)।
- स्टोरी में बाँटने योग्य फ़ीचर या बदलाव — ब्रीफ़, PRD खंड पेस्ट करें, या फ़ीचर बताएँ
- शामिल उपयोगकर्ता प्रकार / पर्सोना (जैसे एडमिन, अंतिम उपयोगकर्ता, अतिथि, API उपभोक्ता)
- दायरा — क्या हम एक स्टोरी लिख रहे हैं या एपिक को स्टोरी के पूरे सेट में बाँट रहे हैं?
- स्वीकृति मानदंड प्रारूप की पसंद — Given/When/Then, बुलेट चेकलिस्ट, या दोनों?
- तकनीकी बाधाएँ या नोट — इंजीनियरिंग टीम ने जो भी चिह्नित किया हो जो स्टोरी को आकार दे
आउटपुट संरचना
हर स्टोरी के लिए:
स्टोरी: [संक्षिप्त शीर्षक — क्रिया + संज्ञा, जैसे "खोज परिणामों को तारीख़ सीमा से फ़िल्टर करें"]
एपिक: [मूल एपिक का नाम — जैसे "उन्नत खोज"] स्टोरी ID: [Jira/Linear ID — अभी न बना हो तो ख़ाली छोड़ें] प्राथमिकता: [P1 / P2 / P3] स्टोरी पॉइंट: [ख़ाली छोड़ें — इंजीनियरिंग के अनुमान के लिए]
यूज़र स्टोरी
एक [विशिष्ट उपयोगकर्ता प्रकार — "उपयोगकर्ता" नहीं] के रूप में, मैं [वह ठोस क्रिया जो वे करना चाहते हैं] चाहता/चाहती हूँ, ताकि [वह परिणाम जो वे हासिल करते हैं — व्यावसायिक मूल्य, फ़ीचर विवरण नहीं]।
उदाहरण:
एक अकाउंट मैनेजर के रूप में, मैं अपनी क्लाइंट सूची को अंतिम संपर्क तारीख़ से फ़िल्टर करना चाहता हूँ, ताकि मैं उन क्लाइंट को जल्दी पहचान सकूँ जिनसे 30 दिनों से ज़्यादा बात नहीं हुई और संपर्क को प्राथमिकता दे सकूँ।
संदर्भ
[1–3 वाक्य का ऐसा संदर्भ जो यूज़र स्टोरी में नहीं है: यह स्टोरी कब मायने रखती है, ज़रूरत क्या ट्रिगर करती है, यह बड़े प्रवाह में कैसे बैठती है। इससे इंजीनियर पूछने से पहले क्यों समझ जाते हैं।]
स्वीकृति मानदंड
प्रारूप: Given / When / Then
हर मानदंड एक विशिष्ट व्यवहार परखता है। प्रति अवलोकन योग्य परिणाम एक GWT लिखें — पूरे फ़ीचर के लिए एक GWT नहीं।
AC1: [इस मानदंड का संक्षिप्त नाम]
Given [starting state or context]
When [user action]
Then [observable system behaviour]
AC2: [संक्षिप्त नाम]
Given [...]
When [...]
Then [...]
AC3: [संक्षिप्त नाम]
Given [...]
When [...]
Then [...]
किनारे के मामले
[ऐसे परिदृश्य सूचीबद्ध करें जो स्पष्ट नहीं पर सँभालने ज़रूरी हैं। ये अतिरिक्त AC या इंजीनियरिंग के लिए नोट बनते हैं।]
- [किनारे का मामला 1]: [जैसे उपयोगकर्ता ऐसा तारीख़ फ़िल्टर लगाता है जो 0 परिणाम देता है — स्पष्ट संदेश और "फ़िल्टर साफ़ करें" क्रिया के साथ ख़ाली स्थिति दिखाएँ]
- [किनारे का मामला 2]: [जैसे उपयोगकर्ता के >10,000 क्लाइंट हैं — फ़िल्टर लोड समय >200ms न बिगाड़े]
- [किनारे का मामला 3]: [जैसे तारीख़ फ़िल्टर पेज रिफ़्रेश पर बना रहता है — या निर्णय हो तो स्पष्ट रूप से नहीं]
- [अनुमति किनारे का मामला]: [जैसे केवल-पढ़ने वाले उपयोगकर्ता फ़िल्टर देख सकते हैं पर फ़िल्टर प्रीसेट सहेज नहीं सकते]
दायरे से बाहर
[स्पष्ट रूप से बताएँ कि यह स्टोरी क्या कवर नहीं करती — स्कोप क्रीप रोकता है और स्पष्ट करता है अगली स्टोरी कहाँ शुरू होती है।]
- फ़िल्टर प्रीसेट सहेजना और साझा करना (अलग स्टोरी — [स्टोरी X] देखें)
- फ़िल्टर किए परिणामों पर बल्क क्रियाएँ
- फ़िल्टर की गई क्लाइंट सूची को CSV में एक्सपोर्ट करना
Definition of Done
- सभी स्वीकृति मानदंड पास
- किनारे के मामले सँभाले गए (या नया टिकट उठाकर स्पष्ट रूप से टाले गए)
- हर AC के लिए यूनिट टेस्ट लिखे गए
- मोबाइल व्यूपोर्ट पर काम करता है (लागू हो तो)
- पहुँच-योग्यता: कीबोर्ड से नेविगेट योग्य और स्क्रीन-रीडर संगत
- त्रुटि स्थितियाँ सँभाली गईं और कॉपी मंज़ूर
- प्रोडक्ट और डिज़ाइन ने स्टेजिंग में समीक्षा की
- प्रोडक्शन बिल्ड में कोई कंसोल त्रुटि नहीं
एपिक विघटन टेम्पलेट
अगर उपयोगकर्ता एपिक या फ़ीचर ब्रीफ़ दे, तो स्टोरी लिखने से पहले उसे स्टोरी के पूरे सेट में बाँटें:
एपिक: [नाम] लक्ष्य: [इस एपिक को पूरा करने से क्या परिणाम मिलता है?] स्टोरी:
| # | स्टोरी | नोट | निर्भरताएँ |
|---|---|---|---|
| 1 | [मुख्य सुखद पथ स्टोरी — फ़ीचर का सबसे सरल संस्करण जो मूल्य देता है] | ||
| 2 | [सत्यापन / त्रुटि संचालन स्टोरी] | #1 पर निर्भर | |
| 3 | [किनारे का मामला या पावर उपयोगकर्ता स्टोरी] | #1 पर निर्भर | |
| 4 | [एडमिन या कॉन्फ़िगरेशन स्टोरी] | ||
| 5 | [प्रदर्शन या पैमाना स्टोरी — लागू हो तो] | #1 पर निर्भर |
सुझाया गया स्प्रिंट क्रम: [MVP के लिए कौन सी स्टोरी P1 हैं? कौन सी बाद के स्प्रिंट में आ सकती हैं?]
आम स्टोरी एंटी-पैटर्न — और सुधार
इंजीनियरिंग को सौंपने से पहले स्टोरी की समीक्षा के लिए इनका उपयोग करें:
| एंटी-पैटर्न | उदाहरण | सुधार |
|---|---|---|
| स्टोरी में समाधान | "एक उपयोगकर्ता के रूप में मैं ड्रॉपडाउन फ़िल्टर चाहता हूँ" | UI निर्णय हटाएँ — "एक उपयोगकर्ता के रूप में मैं तारीख़ सीमा से फ़िल्टर करना चाहता हूँ" |
| धुँधला "ताकि" | "ताकि यह उपयोग में आसान हो" | विशिष्ट बनाएँ — "ताकि मैं हर रिकॉर्ड मैनुअल खोले बिना संपर्क को प्राथमिकता दे सकूँ" |
| बहुत बड़ी | स्टोरी 5 अलग उपयोगकर्ता प्रवाह कवर करती है | प्रति प्रवाह अलग स्टोरी में बाँटें |
| कोई स्वीकृति मानदंड नहीं | स्टोरी में सिर्फ़ विवरण | इंजीनियरिंग शुरू होने से पहले कम से कम 3 GWT मानदंड जोड़ें |
| AC जो व्यवहार नहीं, समाधान परखते हैं | "Given ड्रॉपडाउन खुला है, When मैं एक विकल्प चुनता हूँ" | परिणाम परखें — "Given मैंने तारीख़ फ़िल्टर लगाया है, When मैं अपने परिणाम देखता हूँ, Then सिर्फ़ उस तारीख़ सीमा में अंतिम संपर्क वाले क्लाइंट दिखते हैं" |
| गायब ख़ाली स्थिति | 0 परिणाम पर क्या होता है इसका कोई AC नहीं | जोड़ें — ख़ाली स्थितियाँ फ़ीचर का हिस्सा हैं |
| गायब त्रुटि स्थिति | नेटवर्क विफलता या अमान्य इनपुट का कोई AC नहीं | त्रुटि संचालन AC स्पष्ट रूप से जोड़ें |
उदाहरण: एक फ़ीचर के लिए पूरा स्टोरी सेट
फ़ीचर ब्रीफ़: "उपयोगकर्ताओं को अपना इनवॉइस इतिहास PDF या CSV में एक्सपोर्ट करने दें"
स्टोरी 1: इनवॉइस सूची CSV में एक्सपोर्ट करें
एक वित्त एडमिन के रूप में, मैं अपना इनवॉइस इतिहास CSV फ़ाइल में एक्सपोर्ट करना चाहता हूँ, ताकि मैं इसे बिना मैनुअल डेटा एंट्री के अपने अकाउंटिंग सॉफ़्टवेयर में आयात कर सकूँ।
AC1: सफल एक्सपोर्ट
Given I am on the Invoices page with at least one invoice
When I click "Export" and select "CSV"
Then a CSV file is downloaded containing all visible invoices with columns: Invoice ID, Date, Amount, Status, Customer Name
AC2: ख़ाली स्थिति
Given I am on the Invoices page with no invoices
When I click "Export"
Then the export button is disabled and a tooltip reads "No invoices to export"
AC3: फ़िल्टर किया एक्सपोर्ट
Given I have applied a date filter showing invoices from Jan 2026 only
When I click "Export" and select "CSV"
Then the export contains only invoices from Jan 2026 — not all invoices
किनारे के मामले:
- >10,000 इनवॉइस के साथ एक्सपोर्ट — <30 सेकंड में पूरा हो या प्रगति संकेतक दिखे
- मोबाइल पर ट्रिगर किया एक्सपोर्ट — डिवाइस के डिफ़ॉल्ट डाउनलोड स्थान पर डाउनलोड हो
दायरे से बाहर: PDF एक्सपोर्ट (स्टोरी 2), निर्धारित एक्सपोर्ट (भविष्य का एपिक)
स्टोरी 2: इनवॉइस सूची PDF में एक्सपोर्ट करें
एक वित्त एडमिन के रूप में, मैं अपना इनवॉइस इतिहास प्रारूपित PDF में एक्सपोर्ट करना चाहता हूँ, ताकि मैं अपने अकाउंटेंट के साथ पेशेवर सारांश साझा कर सकूँ।
[... AC उसी पैटर्न का पालन करते हैं ...]
गहरी सामग्री
यह स्किल सहायक फ़ाइलों के साथ आती है — उपलब्ध हों तो उनका उपयोग करें:
references/acceptance-criteria-craft.md— ऐसे स्वीकृति मानदंड जो वास्तव में गेट करते हैं। आउटपुट बनाते समय इसे लागू करें; इसमें वह कैलिब्रेशन और निर्णय-विवेक है जिसे ऊपर का संक्षिप्त तरीका संकुचित कर देता है।templates/story-card.md— डिलिवरेबल का भरने योग्य संस्करण, गुणवत्ता-जाँच इनलाइन सहित। जब उपयोगकर्ता दस्तावेज़ खुद बनाना चाहे, उसे जनरेट करवाने के बजाय, तब यह पेश करें।
स्कोरिंग रूब्रिक (0–40)
इस स्किल का कोई भी आउटपुट सौंपने से पहले स्कोर करें; 32+ शिप-गुणवत्ता है।
| आयाम | 0 | 5 | 10 |
|---|---|---|---|
| उपयोगकर्ता की आवाज़ और मूल्य | स्टोरी सिस्टम या डेवलपर के नज़रिए से लिखी गईं; "ताकि" गायब या गोलमोल ("ताकि यह आसान हो") | पर्सोना विशिष्ट हैं पर कुछ "ताकि" खंड उपयोगकर्ता को मिलने वाले परिणाम के बजाय फ़ीचर का वर्णन करते हैं | हर स्टोरी विशिष्ट उपयोगकर्ता प्रकार और ऐसा "ताकि" नामित करती है जो उनका ठोस परिणाम बताता है — हितधारक इसे पढ़कर जान सके कि यह बनाने लायक क्यों है |
| AC की परख-योग्यता और बारीकी | AC गायब, या बिना पास/फ़ेल शर्त के गद्य विवरण | GWT प्रारूप उपयोग हुआ, पर मानदंड कई व्यवहार बंडल करते हैं या अवलोकन योग्य परिणाम के बजाय UI समाधान परखते हैं | प्रति अवलोकन योग्य व्यवहार एक GWT, हर एक असंदिग्ध पास/फ़ेल शर्त के साथ, कार्यान्वयन नहीं परिणाम परखते हुए |
| दुखद-पथ कवरेज | सिर्फ़ सुखद पथ — कहीं कोई ख़ाली, त्रुटि या अनुमति स्थिति नहीं | कुछ किनारे के मामले सूचीबद्ध, पर मुख्य विफलता तरीके (ख़ाली स्थिति, बीच-प्रवाह विफलता, अनुमति सीमाएँ) गायब या धुँधले | ख़ाली स्थितियाँ, त्रुटि स्थितियाँ, अनुमति सीमाएँ और ज्ञात तकनीकी बाधाएँ सब परिभाषित व्यवहार के साथ स्पष्ट AC या किनारे के मामलों के रूप में दिखती हैं |
| दायरा अनुशासन और आकार | स्टोरी एपिक-आकार की, परस्पर निर्भर, बिना दायरे-से-बाहर खंड के | दायरे से बाहर मौजूद पर सामान्य; कुछ स्टोरी एक स्प्रिंट में अनुमान या स्वतंत्र शिपिंग के लिए बहुत बड़ी | हर स्टोरी स्प्रिंट-आकार की और स्वतंत्र रूप से शिप योग्य, विभाजन कारण सहित दर्ज, और दायरे से बाहर बताता है अगली स्टोरी कहाँ शुरू होती है |
गुणवत्ता जाँच
- हर स्टोरी का विशिष्ट उपयोगकर्ता प्रकार है — "एक उपयोगकर्ता" या "सिस्टम" नहीं
- "ताकि" व्यावसायिक मूल्य समझाता है — सिर्फ़ फ़ीचर विवरण नहीं
- हर AC एक अवलोकन योग्य परिणाम परखता है — व्यवहारों का बंडल नहीं
- ख़ाली स्थितियाँ, त्रुटि स्थितियाँ और किनारे के मामले स्पष्ट रूप से सँभाले गए हैं
- दायरे से बाहर दस्तावेज़ित है — माना गया नहीं
- स्टोरी स्वतंत्र हैं — अजारी काम पर निर्भर हुए बिना अलग-अलग शिप हो सकती हैं (जहाँ स्पष्ट रूप से नोट हो उसे छोड़कर)
एंटी-पैटर्न
- तकनीकी नज़रिए से यूज़र स्टोरी न लिखें — हर स्टोरी उपयोगकर्ता के दृष्टिकोण से होनी चाहिए और उनका लक्ष्य बताए
- अपरीक्ष्य स्वीकृति मानदंड न लिखें — हर मानदंड की स्पष्ट पास/फ़ेल शर्त होनी चाहिए
- एक स्प्रिंट में पूरी न हो सकने वाली बड़ी स्टोरी न बनाएँ — एपिक को अनुमान योग्य, स्वतंत्र रूप से डिलीवर योग्य स्टोरी में बाँटें
- किनारे के मामले न छोड़ें — दुखद पथ और त्रुटि स्थितियाँ ज़रूरी हैं, वैकल्पिक नहीं
- Definition of Done न छोड़ें — इसके बिना "done" का अलग-अलग लोगों के लिए अलग मतलब होता है
उदाहरण ट्रिगर वाक्य
- "इस ब्रीफ़ से [फ़ीचर] के लिए यूज़र स्टोरी लिखो"
- "इस PRD खंड को स्वीकृति मानदंड के साथ यूज़र स्टोरी में बाँटो"
- "इन फ़ीचर आवश्यकताओं को Jira टिकट में बदलो"
- "[फ़ीचर का नाम] के लिए यूज़र स्टोरी और AC लिखो"
- "इस एपिक को स्प्रिंट प्लानिंग के लिए तैयार अलग-अलग स्टोरी में बाँटो"
इस स्किल को अपने ब्राउज़र में चलाएँ: https://mohitagw15856.github.io/pm-claude-skills/skill/user-story-writer.html