AI-translated from English; not yet reviewed by a fluent editor. # 讓核准功能經過 Jira 與檢查完畢的 Claude Code 變更 > 把核准功能落實為真正的 Jira 史詩、所有故事與有實質用途的子任務。檢查每項 Claude Code 變更、確認問題更新，並審查專案指引的處理決定。 By BIG CHANGE Editorial Published: 2026-10-20T13:23:38.288Z Updated: 2026-10-20T13:23:38.288Z Canonical: https://bigchange.ai/blog/claude-code-jira-approved-feature-guide ![Conceptual charcoal illustration of a developer at a standing counter reviewing a generic two-column code diff on an arm-mounted display.](https://bigchange.ai/api/media/file/claude-code-jira-feature-review-hero-v2.png) AI-generated conceptual illustration by BIG CHANGE. 一項核准功能在完成前，可能橫跨三套系統：需求文件、Jira 問題階層，以及程式碼儲存庫。Claude Code 能協助起草與實作，但各系統間的對應關係仍須由人核准並直接查核。本指南帶領開發者或團隊負責人推進一項真實功能，包含**每一個核准故事**、原有測試、經授權的 Jira 更新，以及經過審查的專案指引處理決定。 這是根據文件撰寫的操作程序。BIG CHANGE 沒有存取 Jira 專案、執行 Claude Code、修改儲存庫或測量功能交付時間。確切的問題類型、欄位、狀態轉換、指令與費用，取決於你的專案和帳戶。 ## 關鍵改變 - **改變了什麼：** 功能可從核准需求，追蹤到真正的 Jira 父問題與所有故事，再到經審查的程式碼、原有檢查及授權問題更新。 - **為何重要：** 問題對照表、測試紀錄，以及直接從 Jira 回讀的資料，能顯示哪些核准工作已完成、哪個故事仍未完成。 - **應留意什麼：** 專案特有的欄位和狀態轉換、結果不確定的寫入及失敗的檢查，需要人工處理；Claude Code 指引本身不構成工作授權。 ## 開始之前 選擇一項功能，須有負責人核准的簡報、你有權修改的儲存庫，以及可執行的原始驗收檢查。其實際工作必須適合在所選 Jira Cloud 專案中設置一個史詩層級父問題、全部核准故事，以及至少一個故事下有意義的子任務。若工作沒有真正的子任務，本指南的完整結果便尚未達成；新增裝飾性問題會使計畫失真。記錄請求人、核准權責者、來源修訂版本、允許資料、起始 Git 提交、隔離或回復方式，以及有權審查程式碼與更改 Jira 狀態的人。 檢查已安裝環境的[Claude Code 版本、驗證與權限](https://code.claude.com/docs/en/permissions)。確認儲存庫的 `CLAUDE.md` 只提供專案指引，不授權修改、執行指令或傳送資料。決定 Claude 能接收哪些需求和程式碼、能執行哪些指令，以及這項功能的用量上限。使用 Claude Code 可能耗用訂閱額度，或產生供應商費用；[Anthropic 的費用指南](https://code.claude.com/docs/en/costs)無法事先確定你的帳單。 在 Jira，取得瀏覽與建立相關問題類型的權限，並取得之後以授權身分留言或轉換問題狀態的權限。私有指令碼可採用[Atlassian 文件記載的電子郵件與 API 權杖方式](https://developer.atlassian.com/cloud/jira/platform/basic-auth-for-rest-apis)；整合應用可能需要 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 參考文件](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/)。 確認此專案真正存在的史詩等級父問題、故事層級子問題，以及支援的子任務。Atlassian 說明了[預設階層及其設定](https://support.atlassian.com/jira-cloud-administration/docs/configure-the-issue-type-hierarchy/)；類型名稱和 ID 並非通用。檢查專案的 Parent 欄位在各子層級如何運作，以及建立時需要哪些自訂欄位或可見性設定。若專案無法表示核准的問題結構，記錄缺少的類型、欄位或權限，並暫停建立。一般問題連結不代表父子關係。 ## 3. 寫入前審查完整問題計畫 將每項 PRD 需求與驗收檢查對應到 `ticket-plan.json`。記錄其 `planVersion`、PRD 雜湊值、Jira 網站與專案鍵、本機執行 ID，以及計畫核准人和時間。每個擬建問題都要記錄唯一的本機 ID、預期父問題的本機 ID、已查明的問題類型 ID、專案必填欄位、摘要、描述、需求與驗收 ID、負責人及允許的可見範圍。故事及子任務數量應由核准工作決定。每個子任務都須在真正所屬故事下完成實際工作。 Jira REST v3 使用 **Atlassian Document Format (ADF)** 這種結構化 JSON 文件表示多行問題描述與留言。根據核准內容準備文件，並在組成每次請求前檢查網站回傳的欄位中繼資料。[問題 API](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/)文件說明建立操作，但無法替未知專案提供現成欄位物件。在任何 `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 提醒，寫入後的搜尋可能延遲](https://developer.atlassian.com/cloud/jira/platform/search-and-reconcile/)。找不到搜尋結果，不能證明建立失敗。執行 ID 與日誌能協助核對，但不會讓伺服器拒絕重複建立。切勿盲目重送結果不確定的 `POST` 請求。 直接讀取完成的問題結構並記錄到 `ticket-map.json`：各本機 ID、實際 Jira ID 和鍵、標準問題 URL、專案、類型、父問題鍵、PRD 與驗收 ID、回讀時間及日誌引用。將**所有**核准問題和標準與 PRD 對照。若有問題遺漏或父問題錯誤，停止後續寫入，採用專案經審查的修正流程。 ## 5. 實作並獨立審查每個核准故事 依相依順序推進核准故事。對每個故事，記錄 Jira 鍵、起始 Git 提交及分支或工作樹、原始驗收指令、允許路徑與指令。請 Claude Code 使用 [Plan mode](https://code.claude.com/docs/en/common-workflows)，將該故事的標準對應到儲存庫。由開發者檢查計畫並授權範圍明確的修改。故事邊界讓變更便於審查，並不表示其餘核准故事可以從功能中刪除。 修改後，保留確切差異、原始檢查指令及完整輸出與結束狀態、相關針對性測試，以及每個需求 ID 的判定。檢查實際程式碼和日誌。書面計畫、生成檔案，或 Claude 聲稱測試通過，都無法證明變更可正常運作。檢查失敗、發現意外機密、相依套件變更、外部寫入或大幅重構時，暫停該故事；在核准範圍內修復，再執行原始檢查。由另一位程式碼審查者決定接受最終提交或暫緩差異。每個故事都要記錄此決定。[我們先前關於一項經審查的 Claude Code 變更指南](https://bigchange.ai/blog/superpowers-claude-code-plan-test-review-change-guide)涵蓋較窄的程式碼審查階段；這裡的 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 證據留言：接受的提交或暫緩的差異、原始檢查與針對性測試、剩餘失敗項及審查決定。從 Jira 的[留言 API](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-comments/)回讀新留言的 ID 與內文。任一寫入回應不確定時，考慮再次請求前，先直接檢查狀態或留言。轉換清單為空或必填欄位不可用，是應與專案負責人解決的工作流程或權限缺口，不是捏造 ID 的理由。 ## 7. 決定是否修改 `CLAUDE.md` 檔案 對照實際 PRD、問題、差異、測試、審查及 Jira 日誌。請 Claude 做簡短回顧，指出實際觀察到的誤解或遺漏檢查。由人工選定明確的指引修改，或記錄不修改的決定，連同審查人與時間。若核准，僅檢查並提交這份 `CLAUDE.md` 差異及其雜湊值。[Anthropic 的記憶指南](https://code.claude.com/docs/en/memory)說明專案指引；這次審查不會自動授權未來工作。不要加入機密，也不要將推測經驗變成專案規則。 ## 完成條件與復原 只有滿足以下條件，功能才算完成：核准 PRD 修訂版本對應直接確認的史詩、故事與子任務結構；**每個核准故事**都有起始狀態、接受的差異、原始檢查與針對性測試證據，以及獨立審查；每個授權 Jira 轉換及證據留言都有直接回讀；並且人工已作出回顧決定。若任何項目缺少，記錄確切的剩餘階段。[選擇第一個 AI 任務](https://bigchange.ai/blog/map-work-choose-first-ai-task-guide)這份指南停在較早的任務選擇及擬定檢查階段，無法證明這裡的實作結果。 結果不確定的 Jira 建立操作保持 `unknown`，直到人工核對身分。父問題錯誤時停止建立子問題。測試失敗時保留原標準。缺少轉換或用量耗盡時，為負責人保留附日期的部分完成紀錄。只將核准的最少需求與客戶資料提供給 Claude 和 Jira，檢查目前帳戶費用與權限，並為人工程式碼審查預留資源。本指南說明一條有條件的工具操作路徑，並未報告 BIG CHANGE 已完成的功能、Jira 寫入、模型執行、實測節省、合併或部署。 ## 來源與延伸閱讀 - [Atlassian：Jira Cloud REST API v3 問題操作](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/)：限定範圍的建立中繼資料、問題建立與讀取，以及狀態轉換操作。讀者專案的欄位和 ID 必須在該專案查明。 - [Atlassian：問題留言](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-comments/)：ADF 留言建立及回讀。權限與實際回應仍依網站而異。 - [Atlassian：搜尋與核對](https://developer.atlassian.com/cloud/jira/platform/search-and-reconcile/)：解釋為何寫入後立即搜尋不到結果，不能釐清一次結果不確定的建立操作。 - [Atlassian：問題類型階層](https://support.atlassian.com/jira-cloud-administration/docs/configure-the-issue-type-hierarchy/)：預設層級及設定；仍須檢查所選專案的結構。 - [Anthropic：Claude Code 工作流程](https://code.claude.com/docs/en/common-workflows)、[權限](https://code.claude.com/docs/en/permissions)、[記憶](https://code.claude.com/docs/en/memory)及[費用](https://code.claude.com/docs/en/costs)：規劃、修改權限、`CLAUDE.md`指引及用量。這些文件並未記錄本功能的一次執行。 ## Sources - [Atlassian Jira Cloud REST API v3 問題](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/) — 說明限定範圍的建立中繼資料、問題 POST/GET 及轉換；廣泛的建立中繼資料操作已淘汰。專案欄位、ID 和允許的轉換，必須來自讀者的網站。 - [Atlassian Jira Cloud REST API v3 問題留言](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-comments/) — 說明 ADF 留言建立及回讀，受實際權限限制。本指南未發布任何留言。 - [Atlassian 搜尋與核對](https://developer.atlassian.com/cloud/jira/platform/search-and-reconcile/) — 說明搜尋的最終一致性；建立回應不確定後，搜尋未命中無法證明問題不存在。 - [Atlassian 設定問題類型階層](https://support.atlassian.com/jira-cloud-administration/docs/configure-the-issue-type-hierarchy/) — 解釋預設及可設定階層。所選專案的層級和 Parent 行為需要直接查明。 - [Atlassian REST API 基本驗證](https://developer.atlassian.com/cloud/jira/platform/basic-auth-for-rest-apis/) — 說明私有簡單指令碼使用電子郵件加 API 權杖的方式，及整合應用的差異；憑證必須保持私密。 - [Anthropic Claude Code 常見工作流程](https://code.claude.com/docs/en/common-workflows) — 說明 Plan mode 與編碼流程模式；不能證明讀者已完成實作或檢查。 - [Anthropic Claude Code 權限](https://code.claude.com/docs/en/permissions) — 說明實際工具權限及核准機制；僅有 CLAUDE.md 指引不授權執行指令或寫入。 - [Anthropic Claude Code 記憶](https://code.claude.com/docs/en/memory) — 解釋 CLAUDE.md 專案指引；擬議的回顧修改須經人工審查，不是自動學習。 - [Anthropic Claude Code 費用](https://code.claude.com/docs/en/costs) — 用量及計費因方案與供應商而異；這份僅依文件撰寫的指南，未測量費用或節省。