Maaaring dumaan ang aprubadong feature sa tatlong sistema bago matapos: dokumento ng mga kinakailangan, herarkiya ng mga issue sa Jira, at repository. Makakatulong ang Claude Code sa pagbuo ng dokumento at pagpapatupad, ngunit kailangan ng pahintulot ng tao at direktang pagsusuri sa mga ugnayan ng mga sistemang iyon. Ginagabayan nito ang developer o pinuno ng pangkat sa isang tunay na feature, kasama ang bawat aprubadong story, mga orihinal na test nito, awtorisadong update sa Jira, at nasuring pasya tungkol sa gabay ng proyekto.

Pamamaraang batay sa dokumentasyon ito. Hindi nag-access ng Jira project, nagpatakbo ng Claude Code, nagbago ng repository o nagsukat ng oras ng paghahatid ng feature ang BIG CHANGE. Ang eksaktong mga uri ng issue, field, transition, command at gastos ay nakadepende sa iyong proyekto at account.

Ang malaking pagbabago

  • Ano ang nagbago: Maaaring masubaybayan ang feature mula sa aprubadong kinakailangan hanggang sa tunay na parent issue sa Jira at bawat story, patungo sa nasuring code, orihinal na pagsusuri at awtorisadong update sa issue.
  • Bakit mahalaga: Ipinapakita ng mapa ng mga issue, tala ng mga test at direktang pagbasa muli mula sa Jira kung aling aprubadong gawain ang tapos at aling story ang bukas pa.
  • Ano ang dapat bantayan: Nangangailangan ng pasya ng tao ang mga field at transition na partikular sa proyekto, mga pagsulat na hindi tiyak ang resulta at mga nabigong pagsusuri; hindi sapat na awtorisasyon ang gabay ng Claude Code lamang.

Bago magsimula

Pumili ng feature na may buod na aprubado ng may-ari, repository na maaari mong baguhin, at orihinal na pagsusuri sa pagtanggap na kaya mong patakbuhin. Dapat talagang kailangan ng gawain nito ang isang parent na nasa antas ng epic, ang mga aprubadong story nito, at kahit isang makabuluhang subtask sa ilalim ng isang story sa napiling Jira Cloud project. Kung walang tunay na subtask ang gawain, hindi pa makukumpleto ang partikular na kabuuang resultang ito; magiging maling representasyon ng plano ang pagdaragdag ng issue para lamang may mailagay. Itala ang humiling, may awtoridad na mag-apruba, bersiyon ng pinagmulan, pinapayagang datos, panimulang Git commit, paraan ng paghihiwalay o pagbabalik, at taong maaaring magsuri ng code at magbago ng Jira status.

Suriin ang naka-install na bersiyon, authentication at mga pahintulot ng Claude Code. Tiyaking ang CLAUDE.md ng repository ay gabay sa proyekto at hindi pahintulot na mag-edit, magpatakbo ng command o magpadala ng datos. Magpasya kung anong kinakailangan at code ang maaaring matanggap ni Claude, anong command ang maaari nitong patakbuhin, at ang limitasyon sa paggamit para sa feature. Maaaring gumamit ng allowance ng subscription o magdulot ng singil mula sa provider ang Claude Code; hindi itinatakda ng gabay sa gastos ng Anthropic ang iyong magiging bayarin nang maaga.

Para sa Jira, kumuha ng pahintulot na tingnan at likhain ang kaugnay na mga uri ng issue at, sa susunod, magkomento o mag-transition ng issue bilang awtorisadong gumagamit. Maaaring gamitin ng pribadong script ang paraang email at API token na inilalarawan ng Atlassian; maaaring kailangan ng OAuth ang isang integration. Itago ang mga kredensiyal sa pribadong imbakan ng mga lihim. Huwag isama ang mga ito sa mga prompt, teksto ng issue, CLAUDE.md, log o source control. Pagkasunduan ang kakayahang makita ang mga issue bago ipadala ang mga kinakailangan sa Jira.

Magpanatili ng pitong pribadong tala habang sumusulong: docs/feature-prd.md, ticket-plan.json, log ng pagsulat ng issue na dinaragdagan lamang, ticket-map.json, isang katibayan ng pagpapatupad bawat story, log ng update sa Jira, at pasya sa pagbabalik-tanaw. Mga tala ito ng iyong feature, hindi mga file na ibinigay o pinatakbo ng BIG CHANGE.

1. Aprubahan ang isang tiyak na PRD

Ibigay sa Claude Code ang aktuwal na aprubadong buod ng feature at ipatukoy ang mga hindi pa nalulutas na tanong bago gumawa ng docs/feature-prd.md. Kailangan sa dokumento ang humiling at nag-aprubang may-ari, bersiyon ng input, problema at nilalayong gumagamit, saklaw at hindi kasama, mga requirement ID na may bilang, pagsusuri sa pagtanggap at pinagmumulan ng ebidensiya, mga limitasyong hindi kaugnay ng mismong pag-andar, Jira project at mga bukas na tanong. Ipakumpara sa responsableng tao ang draft at orihinal na buod, at ipaapruba ang isang tiyak na bersiyon ng nilalaman at hash. Lutasin ang mahahalagang tanong bago lumikha ng issue o mag-edit ng code.

Nagbibigay ang hash ng eksaktong pinagmulan para sa mga susunod na tala. Kapag nagbago ang PRD, suriin muli ang apektadong plano ng mga ticket at mga pagsusuri; hindi dahilan ang kabiguan sa pagpapatupad upang baguhin ang pamantayan ng pagtanggap para lamang pumasa.

2. Alamin ang herarkiya at mga field ng Jira project na ito

Gamit ang awtorisadong para sa pagbasa lamang na mga request sa Jira REST API v3, basahin ang lahat ng pahina ng GET /rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypes. Para sa bawat iminungkahing uri ng issue, basahin ang lahat ng pahina ng GET /rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypes/{issueTypeId} upang makita ang kinakailangang mga field sa paggawa at pinapayagang halaga. Minamarkahan ng Atlassian na hindi na inirerekomenda ang malawak na GET /issue/createmeta operation sa reperensiya ng issue API nito.

Tiyakin ang tunay na parent na katumbas ng epic, mga child sa antas ng story, at sinusuportahang mga subtask para sa proyektong ito. Inilalarawan ng Atlassian ang karaniwang herarkiya at pagsasaayos nito; hindi pare-pareho sa lahat ang mga pangalan at ID ng uri. Suriin kung paano gumagana ang Parent field ng proyekto sa bawat antas ng child at anong custom field o visibility setting ang kailangan sa paggawa. Kung hindi kayang katawanin ng proyekto ang aprubadong ugnayan, itala ang kulang na uri, field o pahintulot at ipagpaliban ang paggawa. Hindi nagiging child ang isang issue dahil lamang sa pangkalahatang link.

3. Suriin ang buong plano ng mga ticket bago magsulat

Itugma ang bawat kinakailangan at pagsusuri sa pagtanggap ng PRD sa ticket-plan.json. Itala ang planVersion nito, PRD hash, Jira site at project key, lokal na run ID, at nag-apruba sa plano at oras. Para sa bawat iminungkahing issue, itala ang natatanging lokal na ID, nilalayong parent local ID, natuklasang issue-type ID, kinakailangang mga field ng proyekto, buod, paglalarawan, mga requirement at acceptance ID, may-ari at pinapayagang visibility. Ang aprubadong gawain ang nagtatakda ng bilang ng mga story at subtask. Dapat may tunay na gawain ang bawat subtask sa ilalim ng aktuwal nitong story.

Ginagamit ng Jira REST v3 ang Atlassian Document Format (ADF), isang nakaayos na JSON document, para sa maraming-linyang paglalarawan ng issue at komento. Ihanda ang mga dokumentong iyon mula sa aprubadong nilalaman at suriin ang field metadata na ibinalik ng site bago buuin ang bawat request. Inilalarawan ng issue API ang paggawa; hindi nito maibibigay ang handang field object para sa hindi kilalang proyekto. Dapat aprubahan ng tao ang buong ugnayan, saklaw ng lahat ng kinakailangan, parent relation at eksaktong nilalayong pagsulatan bago ang anumang POST.

4. Unahing likhain ang mga parent at basahin muli ang bawat issue

Likhain ang aprubadong parent sa pamamagitan ng POST /rest/api/3/issue, saka ang mga story nito, at pagkatapos ang bawat tunay na subtask. Bago ang bawat request, magdagdag ng pribadong hanay sa log na may run ID, lokal na issue ID, kumpirmadong parent key kung naaangkop, destinasyon, hash ng eksaktong aprubadong request, oras ng pagsubok sa UTC, at pending na estado. Huwag isama ang token. Kapag HTTP 201 ang tugon, itala ang issue ID at key na ibinalik ng Jira, pagkatapos ay direktang gumamit ng GET /rest/api/3/issue/{issueIdOrKey}. Ikumpara ang proyekto, uri, buod, paglalarawan o PRD reference, at parent sa aprubadong plano. Markahan lamang ang hanay na confirmed pagkatapos ng pagbasa muli. Kapag nakumpirma ang parent, maaari nang likhain ang mga child nito.

Kapag nag-timeout ang request o nawala ang tugon, markahan itong unknown. Suriin ang Jira ayon sa proyekto, oras, aprubadong buod at sanggunian sa plano, saka direktang buksan ang posibleng tugma at ipatukoy sa awtorisadong may-ari ang pagkakakilanlan nito. Nagbababala ang Atlassian na maaaring mahuli ang paghahanap pagkatapos ng pagsulat. Hindi patunay ng nabigong paggawa ang kawalan ng resulta. Nakakatulong ang run ID at log sa pagtutugma, ngunit hindi nito pinapatanggi sa server ang paulit-ulit na paggawa. Huwag basta ulitin ang POST na hindi tiyak ang naging resulta.

Direktang basahin ang natapos na ugnayan papunta sa ticket-map.json: bawat lokal na ID, aktuwal na Jira ID at key, kanonikal na URL ng issue, proyekto, uri, parent key, PRD at acceptance ID, oras ng pagbasa muli, at sanggunian sa log. Ikumpara ang lahat ng aprubadong issue at pamantayan sa PRD. Itigil ang susunod na pagsulat kung may nawawala o maling parent ang issue; gamitin ang nasuring proseso ng pagwawasto ng proyekto.

5. Ipatupad at ipasuri nang hiwalay ang bawat aprubadong story

Isagawa ang mga aprubadong story ayon sa pagkakasunod ng dependency. Para sa bawat isa, itala ang Jira key, panimulang Git commit at branch o worktree, orihinal na command sa pagtanggap, at pinapayagang mga path at command. Hilingin sa Claude Code na gamitin ang Plan mode upang itugma ang pamantayan ng story sa repository. Sinusuri ng developer ang plano at pinahihintulutan ang edit sa takdang saklaw. Pinananatiling madaling suriin ng hangganan ng story ang pagbabago; hindi nito inaalis ang natitirang aprubadong story sa feature.

Pagkatapos ng edit, panatilihin ang eksaktong diff, orihinal na command ng pagsusuri kasama ang buong output at exit status, kaugnay na nakatutok na mga test, at pasya para sa bawat requirement ID. Suriin ang aktuwal na code at mga log. Hindi patunay na gumagana ang pagbabago ang nakasulat na plano, nabuong file o pahayag ni Claude na pumasa ang mga test. Ipahinto muna ang story kapag nabigo ang pagsusuri, may hindi inaasahang lihim, nabagong dependency, panlabas na pagsulat o malawakang refactor; ayusin sa loob ng aprubadong saklaw at ulitin ang orihinal na pagsusuri. Hiwalay na code reviewer ang magpapasya kung tatanggapin ang commit o ihihinto muna ang diff. Itala ang pasyang iyon para sa bawat story. Ang nauna naming gabay sa isang nasuring pagbabago ng Claude Code ay para sa mas makitid na yugto ng code review; ang PRD at kumpletong Jira na ugnayan dito ang nagbibigay ng mas malawak na hangganan ng feature.

6. Tiyakin ang awtorisadong mga update sa Jira

Para sa bawat nasuring story, basahin ang kasalukuyang Jira status nito at hilingin ang GET /rest/api/3/issue/{key}/transitions?expand=transitions.fields. Suriin ang transition na talagang magagamit ng taong ito, destinasyon nito, kinakailangang mga field at pinapayagang halaga. Maaari nang isumite ng awtorisadong may-ari ang napiling transition sa pamamagitan ng POST /rest/api/3/issue/{key}/transitions kasama ang mga field value na natiyak para sa proyekto. Direktang basahin muli ang issue at tiyakin ang bagong status. Hindi awtomatikong pahintulot sa Done, merge o deployment ang pagpasa ng pagsusuri sa code.

Itala sa Jira update log ang status bago ang pagsulat, nilalayong transition, gumaganap na gumagamit, request at tugon. Mag-post ng makatotohanang ADF na komentong may ebidensiya gamit ang POST /rest/api/3/issue/{key}/comment: tinanggap na commit o ipinagpalibang diff, orihinal na pagsusuri at nakatutok na mga test, natitirang kabiguan, at pasya ng reviewer. Basahin muli ang ID at katawan ng nalikhang komento mula sa comment API ng Jira. Kung hindi tiyak ang tugon sa alinmang pagsulat, direktang suriin ang status o mga komento bago isaalang-alang ang isa pang request. Ang walang laman na listahan ng transition o hindi magamit na kinakailangang field ay kakulangan sa workflow o pahintulot na lulutasin kasama ng may-ari ng proyekto, hindi pahintulot na gumawa-gawa ng ID.

7. Magpasya kung dapat baguhin ang CLAUDE.md na file

Ikumpara ang aktuwal na mga tala ng PRD, ticket, diff, test, review at Jira. Hilingin kay Claude ang maikling pagbabalik-tanaw na tumutukoy sa naobserbahang hindi pagkakaunawaan o kulang na pagsusuri. Pipili ang tao ng tiyak na pagbabago sa gabay o magtatala ng pasyang walang pagbabago, kasama ang reviewer at oras. Kung aprubado, suriin at i-commit lamang ang CLAUDE.md na diff at hash nito. Ang gabay sa memorya ng Anthropic ay naglalarawan ng gabay sa proyekto; hindi awtomatikong pinapahintulutan ng repasong ito ang susunod na gawain. Huwag magdagdag ng lihim o gawing tuntunin ng proyekto ang haka-hakang aral.

Pagkumpleto at pagbawi

Kumpleto lamang ang feature kapag tumutugma ang aprubadong bersiyon ng PRD sa direktang nakumpirmang ugnayan ng epic, story at subtask; ang bawat aprubadong story ay may panimulang estado, tinanggap na diff, ebidensiya ng orihinal na pagsusuri at nakatutok na mga test, at hiwalay na review; may direktang pagbasa muli ng bawat awtorisadong Jira transition at komentong may ebidensiya; at nakapagpasya ang tao sa pagbabalik-tanaw. Itala ang eksaktong natitirang yugto kung may kulang. Ang pagpili ng unang AI task ay nagtatapos nang mas maaga, sa pagpili ng gawain at panukalang pagsusuri; hindi nito pinatutunayan ang resultang ito ng pagpapatupad.

Mananatiling unknown ang hindi tiyak na paggawa sa Jira hanggang matukoy ng tao ang pagkakakilanlan nito. Kapag mali ang parent, ihinto ang paggawa ng child. Mananatili ang orihinal na pamantayan kahit bumagsak ang mga test. Kapag kulang ang transition o ubos ang limitasyon ng paggamit, mag-iwan ng tala ng bahagyang natapos na gawain na may petsa para sa may-ari. Limitahan ang kinakailangan at datos ng customer sa minimum na aprubado para sa Claude at Jira, suriin ang kasalukuyang gastos at pahintulot ng account, at maglaan para sa code review ng tao. Inilalarawan ng gabay ang kondisyunal na landas sa mga tool; wala itong iniulat na natapos na feature, pagsulat sa Jira, pagpapatakbo ng modelo, nasukat na pagtitipid, merge o deployment ng BIG CHANGE.

Mga sanggunian at karagdagang babasahin