ఆమోదించిన ఫీచర్ పూర్తయ్యేలోపు మూడు వ్యవస్థల ద్వారా వెళ్లవచ్చు: అవసరాల పత్రం, 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 రాత, మోడల్ అమలు, కొలిచిన ఆదా, విలీనం లేదా అమలులో పెట్టడాన్ని నివేదించదు.

మూలాలు, మరింత చదవడానికి