कोई स्वीकृत सुविधा पूरी होने से पहले तीन प्रणालियों से गुजर सकती है: आवश्यकता दस्तावेज, Jira इश्यू पदानुक्रम और रिपॉजिटरी। Claude Code मसौदा बनाने और लागू करने में मदद कर सकता है, लेकिन इन प्रणालियों के बीच संबंधों को मानवीय स्वीकृति और प्रत्यक्ष जाँच चाहिए। यह मार्गदर्शिका डेवलपर या टीम प्रमुख को एक वास्तविक सुविधा के पूरे काम से ले जाती है, जिसमें हर स्वीकृत स्टोरी, उसके मूल परीक्षण, अधिकृत Jira अपडेट और परियोजना निर्देशों पर समीक्षा किया गया निर्णय शामिल हैं।

यह दस्तावेजों पर आधारित प्रक्रिया है। BIG CHANGE ने Jira परियोजना नहीं खोली, Claude Code नहीं चलाया, रिपॉजिटरी नहीं बदली और सुविधा देने में लगा समय नहीं मापा। सटीक इश्यू प्रकार, फ़ील्ड, ट्रांज़िशन, कमांड और लागत आपकी परियोजना और खाते पर निर्भर हैं।

बड़ा बदलाव

  • क्या बदला: सुविधा को स्वीकृत आवश्यकता से वास्तविक Jira पैरेंट और हर स्टोरी के जरिए समीक्षा किए गए कोड, मूल जाँचों और अधिकृत इश्यू अपडेट तक ट्रैक किया जा सकता है।
  • यह क्यों मायने रखता है: इश्यू मैप, परीक्षण रिकॉर्ड और Jira से सीधे दोबारा पढ़ी गई जानकारी बताते हैं कि कौन-सा स्वीकृत काम पूरा है और कौन-सी स्टोरी अभी खुली है।
  • किन बातों पर ध्यान दें: परियोजना-विशिष्ट फ़ील्ड और ट्रांज़िशन, अनिश्चित परिणाम वाले लेखन और असफल जाँचों को इंसान को सुलझाना होगा; Claude Code के निर्देश अपने आप काम का अधिकार नहीं देते।

शुरू करने से पहले

ऐसी सुविधा चुनें जिसका विवरण जिम्मेदार स्वामी ने स्वीकृत किया हो, जिसकी रिपॉजिटरी बदलने का अधिकार आपके पास हो और जिसकी मूल स्वीकृति जाँच आप चला सकें। वास्तविक काम में चुनी गई Jira Cloud परियोजना में एपिक-स्तर का एक पैरेंट, उसकी स्वीकृत स्टोरी और कम से कम एक स्टोरी के तहत सार्थक उपकार्य जरूरी होना चाहिए। वास्तविक उपकार्य न हो तो यह खास संपूर्ण परिणाम अभी लंबित है; केवल दिखावे का इश्यू जोड़ना योजना को गलत पेश करेगा। अनुरोधकर्ता, स्वीकृति प्राधिकारी, स्रोत संशोधन, अनुमत डेटा, शुरुआती Git कमिट, अलगाव या वापसी का तरीका और कोड समीक्षा तथा Jira स्थिति बदलने के अधिकारी का नाम दर्ज करें।

स्थापित वातावरण में Claude Code का संस्करण, प्रमाणीकरण और अनुमतियाँ जाँचें। सुनिश्चित करें कि रिपॉजिटरी की CLAUDE.md फ़ाइल परियोजना निर्देश देती है, संपादन, कमांड चलाने या डेटा भेजने की अनुमति नहीं। तय करें कि Claude को कौन-सी आवश्यकताएँ और कोड दिए जा सकते हैं, वह कौन-से कमांड चला सकता है और इस सुविधा की उपयोग सीमा क्या होगी। Claude Code का उपयोग सदस्यता कोटा खर्च कर सकता है या प्रदाता शुल्क लगा सकता है; Anthropic की लागत मार्गदर्शिका आपका बिल पहले से तय नहीं करती।

Jira के लिए संबंधित इश्यू प्रकार देखने और बनाने तथा बाद में अधिकृत उपयोगकर्ता के रूप में टिप्पणी करने या ट्रांज़िशन करने की अनुमति लें। निजी स्क्रिप्ट Atlassian द्वारा वर्णित ईमेल और API टोकन विधि इस्तेमाल कर सकती है; इंटीग्रेशन को OAuth की जरूरत पड़ सकती है। क्रेडेंशियल निजी गोपनीय भंडार में रखें। उन्हें प्रॉम्प्ट, इश्यू टेक्स्ट, CLAUDE.md, लॉग या संस्करण नियंत्रण में न डालें। आवश्यकताएँ Jira भेजने से पहले इश्यू की दृश्यता तय करें।

काम करते हुए सात निजी रिकॉर्ड रखें: docs/feature-prd.md, ticket-plan.json, केवल नए रिकॉर्ड जोड़ने वाला इश्यू लेखन जर्नल, ticket-map.json, हर स्टोरी का एक कार्यान्वयन प्रमाण, Jira अपडेट जर्नल और पुनरावलोकन निर्णय। ये आपकी सुविधा के रिकॉर्ड हैं, BIG CHANGE द्वारा दी या चलाई गई फ़ाइलें नहीं।

1. एक सटीक PRD स्वीकृत करें

Claude Code को वास्तव में स्वीकृत सुविधा विवरण दें और docs/feature-prd.md का मसौदा बनाने से पहले अनसुलझे प्रश्न पहचानने को कहें। दस्तावेज में अनुरोधकर्ता और स्वीकृति देने वाला स्वामी, इनपुट संशोधन, समस्या और लक्षित उपयोगकर्ता, दायरा और बाहर रखी बातें, क्रमांकित आवश्यकता ID, स्वीकृति जाँचें और प्रमाण स्रोत, गैर-कार्यात्मक सीमाएँ, Jira परियोजना और खुले प्रश्न होने चाहिए। जिम्मेदार व्यक्ति मसौदे को मूल विवरण से मिलाकर सामग्री के एक सटीक संशोधन और हैश को स्वीकृत करे। इश्यू बनाने या कोड बदलने से पहले महत्वपूर्ण प्रश्न सुलझाएँ।

हैश बाद के रिकॉर्ड को सटीक स्रोत देता है। PRD बदले तो प्रभावित टिकट योजना और जाँचें दोबारा देखें; कार्यान्वयन की विफलता स्वीकृति मानदंड इस तरह बदलने का कारण नहीं है कि परिणाम पास हो जाए।

2. इस परियोजना का Jira पदानुक्रम और फ़ील्ड पता करें

अधिकृत और केवल पढ़ने वाले Jira REST API v3 अनुरोधों से GET /rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypes के सभी पृष्ठ पढ़ें। हर प्रस्तावित इश्यू प्रकार के लिए GET /rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypes/{issueTypeId} के सभी पृष्ठ पढ़कर निर्माण के जरूरी फ़ील्ड और अनुमत मान खोजें। Atlassian व्यापक GET /issue/createmeta ऑपरेशन को अपनी इश्यू API संदर्भ सामग्री में अप्रचलित बताता है।

इस परियोजना में एपिक के बराबर वास्तविक पैरेंट, स्टोरी-स्तर के चाइल्ड और समर्थित उपकार्य की पुष्टि करें। Atlassian डिफ़ॉल्ट पदानुक्रम और उसके विन्यास का वर्णन करता है; प्रकारों के नाम और ID हर जगह समान नहीं होते। जाँचें कि परियोजना का Parent फ़ील्ड हर चाइल्ड स्तर पर कैसे काम करता है और बनाने के लिए कौन-से कस्टम फ़ील्ड या दृश्यता सेटिंग चाहिए। परियोजना स्वीकृत संरचना नहीं दर्शा सकती तो गायब प्रकार, फ़ील्ड या अनुमति दर्ज करें और निर्माण रोकें। सामान्य इश्यू लिंक से कोई इश्यू चाइल्ड नहीं बन जाता।

3. लिखने से पहले पूरी टिकट योजना की समीक्षा करें

हर PRD आवश्यकता और स्वीकृति जाँच को ticket-plan.json में मैप करें। उसका planVersion, PRD हैश, Jira साइट और परियोजना कुंजी, स्थानीय रन ID तथा योजना स्वीकृत करने वाला व्यक्ति और समय दर्ज करें। हर प्रस्तावित इश्यू के लिए अलग स्थानीय ID, अपेक्षित पैरेंट का स्थानीय ID, पता किया गया इश्यू प्रकार ID, परियोजना के जरूरी फ़ील्ड, सारांश, विवरण, आवश्यकता और स्वीकृति ID, स्वामी और अनुमत दृश्यता दर्ज करें। स्वीकृत काम स्टोरी और उपकार्यों की संख्या तय करता है। हर उपकार्य अपनी वास्तविक स्टोरी के तहत असली काम करे।

Jira REST v3 कई पंक्तियों वाले इश्यू विवरण और टिप्पणियों के लिए Atlassian Document Format (ADF) नामक संरचित JSON दस्तावेज इस्तेमाल करता है। स्वीकृत सामग्री से दस्तावेज तैयार करें और हर अनुरोध बनाने से पहले साइट से लौटे फ़ील्ड मेटाडेटा जाँचें। इश्यू API निर्माण ऑपरेशन बताता है; अनजान परियोजना के लिए तैयार फ़ील्ड ऑब्जेक्ट नहीं दे सकता। किसी भी POST से पहले इंसान पूरी संरचना, सभी आवश्यकताओं का कवरेज, पैरेंट संबंध और लेखन का सटीक गंतव्य स्वीकृत करे।

4. पहले पैरेंट बनाएँ और हर इश्यू दोबारा पढ़ें

स्वीकृत पैरेंट POST /rest/api/3/issue से बनाएँ, फिर उसकी स्टोरी और फिर हर वास्तविक उपकार्य। हर अनुरोध से पहले निजी जर्नल में रन ID, स्थानीय इश्यू ID, जहाँ लागू हो पुष्टि की गई पैरेंट कुंजी, गंतव्य, सटीक स्वीकृत अनुरोध का हैश, प्रयास का UTC समय और pending स्थिति वाली पंक्ति जोड़ें। टोकन शामिल न करें। HTTP 201 मिलने पर Jira से लौटे इश्यू ID और कुंजी दर्ज करें, फिर सीधे GET /rest/api/3/issue/{issueIdOrKey} चलाएँ। परियोजना, प्रकार, सारांश, विवरण या PRD संदर्भ और पैरेंट को स्वीकृत योजना से मिलाएँ। दोबारा पढ़ने के बाद ही पंक्ति को confirmed चिह्नित करें। पुष्टि किया गया पैरेंट उसके चाइल्ड बनाने का रास्ता खोलता है।

अनुरोध का समय समाप्त हो या उत्तर खो जाए तो उसे unknown चिह्नित करें। परियोजना, समय, स्वीकृत सारांश और योजना संदर्भ से Jira जाँचें, संभावित मिलान सीधे खोलें और अधिकृत स्वामी से पहचान सुलझाने को कहें। Atlassian चेतावनी देता है कि लेखन के बाद खोज में देरी हो सकती है। खोज परिणाम न मिलना निर्माण असफल होने का प्रमाण नहीं है। रन ID और जर्नल मिलान में मदद करते हैं, लेकिन सर्वर से डुप्लिकेट निर्माण अस्वीकार नहीं करवाते। अनिश्चित POST को कभी अंधाधुंध दोबारा न भेजें।

पूरी संरचना सीधे पढ़कर ticket-map.json में दर्ज करें: हर स्थानीय ID, वास्तविक Jira ID और कुंजी, इश्यू का कैनोनिकल URL, परियोजना, प्रकार, पैरेंट कुंजी, PRD और स्वीकृति ID, दोबारा पढ़ने का समय और जर्नल संदर्भ। सभी स्वीकृत इश्यू और मानदंड PRD से मिलाएँ। इश्यू गायब हो या गलत पैरेंट के नीचे हो तो आगे लेखन रोकें; परियोजना की समीक्षा की गई सुधार प्रक्रिया इस्तेमाल करें।

5. हर स्वीकृत स्टोरी लागू करें और स्वतंत्र समीक्षा कराएँ

स्वीकृत स्टोरी निर्भरता के क्रम में करें। हर स्टोरी की Jira कुंजी, शुरुआती Git कमिट और ब्रांच या वर्कट्री, मूल स्वीकृति कमांड, अनुमत पथ और कमांड दर्ज करें। Claude Code से Plan mode का उपयोग करके उस स्टोरी के मानदंड रिपॉजिटरी से मैप करने को कहें। डेवलपर योजना जाँचकर सीमित संपादन अधिकृत करता है। स्टोरी की सीमा बदलाव को समीक्षा योग्य रखती है; बाकी स्वीकृत स्टोरी को सुविधा से हटाती नहीं।

संपादन के बाद सटीक diff, मूल जाँच कमांड के पूरे आउटपुट और एग्ज़िट स्थिति, संबंधित लक्षित परीक्षण और हर आवश्यकता ID का निर्णय सुरक्षित रखें। वास्तविक कोड और लॉग देखें। लिखी योजना, बनी फ़ाइलें या Claude का यह कहना कि परीक्षण पास हैं, काम करता बदलाव साबित नहीं करता। जाँच असफल होने, अनपेक्षित गोपनीय जानकारी, निर्भरता बदलाव, बाहरी लेखन या व्यापक रीफ़ैक्टरिंग पर स्टोरी रोकें; स्वीकृत दायरे में सुधारकर मूल जाँच दोहराएँ। अलग कोड समीक्षक तय करे कि अंतिम कमिट स्वीकार करना है या diff रोकना है। हर स्टोरी के लिए निर्णय दर्ज करें। एक समीक्षा किए गए Claude Code बदलाव पर हमारी पिछली मार्गदर्शिका कोड समीक्षा के छोटे चरण तक सीमित है; यहाँ PRD और पूरी Jira संरचना सुविधा का व्यापक दायरा देते हैं।

6. अधिकृत Jira अपडेट सत्यापित करें

हर समीक्षा की गई स्टोरी की वर्तमान Jira स्थिति पढ़ें और GET /rest/api/3/issue/{key}/transitions?expand=transitions.fields माँगें। उस उपयोगकर्ता को वास्तव में उपलब्ध ट्रांज़िशन, उसका गंतव्य, जरूरी फ़ील्ड और अनुमत मान जाँचें। अधिकृत स्वामी तब परियोजना के लिए तय फ़ील्ड मानों के साथ POST /rest/api/3/issue/{key}/transitions से चुना ट्रांज़िशन भेज सकता है। इश्यू सीधे दोबारा पढ़कर नई स्थिति की पुष्टि करें। कोड जाँच पास होना अपने आप Done, मर्ज या डिप्लॉयमेंट की अनुमति नहीं देता।

लेखन से पहले की स्थिति, अपेक्षित ट्रांज़िशन, उपयोगकर्ता, अनुरोध और उत्तर Jira अपडेट जर्नल में दर्ज करें। POST /rest/api/3/issue/{key}/comment से तथ्यात्मक ADF प्रमाण टिप्पणी पोस्ट करें: स्वीकार किया कमिट या रोका गया diff, मूल जाँच और लक्षित परीक्षण, बची विफलताएँ और समीक्षक का निर्णय। बनी टिप्पणी का ID और पाठ Jira के टिप्पणी API से दोबारा पढ़ें। किसी लेखन का उत्तर अनिश्चित हो तो दूसरे अनुरोध पर विचार करने से पहले स्थिति या टिप्पणियाँ सीधे देखें। खाली ट्रांज़िशन सूची या अनुपलब्ध जरूरी फ़ील्ड कार्यप्रवाह या अनुमति की कमी है जिसे परियोजना स्वामी के साथ सुलझाना है, ID गढ़ने का निमंत्रण नहीं।

7. तय करें कि CLAUDE.md बदलना चाहिए या नहीं

वास्तविक PRD, टिकट, diff, परीक्षण, समीक्षा और Jira रिकॉर्ड मिलाएँ। Claude से छोटा पुनरावलोकन माँगें जो देखी गई गलतफहमियों या गायब जाँचों को बताए। इंसान निर्देशों में सटीक संपादन चुने या बदलाव न करने का निर्णय दर्ज करे, समीक्षक और समय सहित। स्वीकृति मिले तो केवल उस CLAUDE.md के diff और हैश की जाँच करके कमिट करें। Anthropic की मेमोरी मार्गदर्शिका परियोजना निर्देश बताती है; यह समीक्षा आगे के काम को स्वतः अधिकृत नहीं करती। गोपनीय जानकारी न जोड़ें और अनुमानित सीख को परियोजना नियम न बनाएँ।

पूर्णता और सुधार

सुविधा तभी पूरी है जब स्वीकृत PRD संशोधन सीधे पुष्टि की गई एपिक, स्टोरी और उपकार्य संरचना से मेल खाता हो; हर स्वीकृत स्टोरी के लिए शुरुआती स्थिति, स्वीकार किया diff, मूल जाँच और लक्षित परीक्षण के प्रमाण तथा स्वतंत्र समीक्षा हों; हर अधिकृत Jira ट्रांज़िशन और प्रमाण टिप्पणी सीधे दोबारा पढ़ी गई हो; और इंसान ने पुनरावलोकन पर निर्णय किया हो। कुछ गायब हो तो बचा हुआ सटीक चरण दर्ज करें। पहला AI कार्य चुनना इससे पहले, कार्य चयन और प्रस्तावित जाँच पर खत्म होता है; वह इस कार्यान्वयन परिणाम को प्रमाणित नहीं करता।

अनिश्चित Jira निर्माण unknown रहता है जब तक इंसान उसकी पहचान का मिलान नहीं करता। गलत पैरेंट चाइल्ड निर्माण रोकता है। असफल परीक्षणों के मूल मानदंड बने रहते हैं। गायब ट्रांज़िशन या खत्म उपयोग सीमा पर स्वामी के लिए तारीख वाला आंशिक रिकॉर्ड छोड़ें। Claude और Jira को केवल न्यूनतम स्वीकृत आवश्यकताएँ और ग्राहक डेटा दें, खाते की वर्तमान लागत और अनुमति जाँचें और इंसानी कोड समीक्षा का बजट रखें। यह मार्गदर्शिका उपकरणों से गुजरने का सशर्त रास्ता बताती है; BIG CHANGE द्वारा पूरी की गई सुविधा, Jira लेखन, मॉडल रन, मापी गई बचत, मर्ज या डिप्लॉयमेंट का दावा नहीं करती।

स्रोत और आगे की पढ़ाई