一項核准功能在完成前，可能橫跨三套系統：需求文件、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，將該故事的標準對應到儲存庫。由開發者檢查計畫並授權範圍明確的修改。故事邊界讓變更便於審查，並不表示其餘核准故事可以從功能中刪除。

修改後，保留確切差異、原始檢查指令及完整輸出與結束狀態、相關針對性測試，以及每個需求 ID 的判定。檢查實際程式碼和日誌。書面計畫、生成檔案，或 Claude 聲稱測試通過，都無法證明變更可正常運作。檢查失敗、發現意外機密、相依套件變更、外部寫入或大幅重構時，暫停該故事；在核准範圍內修復，再執行原始檢查。由另一位程式碼審查者決定接受最終提交或暫緩差異。每個故事都要記錄此決定。我們先前關於一項經審查的 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 證據留言：接受的提交或暫緩的差異、原始檢查與針對性測試、剩餘失敗項及審查決定。從 Jira 的留言 API回讀新留言的 ID 與內文。任一寫入回應不確定時，考慮再次請求前，先直接檢查狀態或留言。轉換清單為空或必填欄位不可用，是應與專案負責人解決的工作流程或權限缺口，不是捏造 ID 的理由。

7. 決定是否修改 CLAUDE.md 檔案

對照實際 PRD、問題、差異、測試、審查及 Jira 日誌。請 Claude 做簡短回顧，指出實際觀察到的誤解或遺漏檢查。由人工選定明確的指引修改，或記錄不修改的決定，連同審查人與時間。若核准，僅檢查並提交這份 CLAUDE.md 差異及其雜湊值。Anthropic 的記憶指南說明專案指引；這次審查不會自動授權未來工作。不要加入機密，也不要將推測經驗變成專案規則。

完成條件與復原

只有滿足以下條件，功能才算完成：核准 PRD 修訂版本對應直接確認的史詩、故事與子任務結構；每個核准故事都有起始狀態、接受的差異、原始檢查與針對性測試證據，以及獨立審查；每個授權 Jira 轉換及證據留言都有直接回讀；並且人工已作出回顧決定。若任何項目缺少，記錄確切的剩餘階段。選擇第一個 AI 任務這份指南停在較早的任務選擇及擬定檢查階段，無法證明這裡的實作結果。

結果不確定的 Jira 建立操作保持 unknown，直到人工核對身分。父問題錯誤時停止建立子問題。測試失敗時保留原標準。缺少轉換或用量耗盡時，為負責人保留附日期的部分完成紀錄。只將核准的最少需求與客戶資料提供給 Claude 和 Jira，檢查目前帳戶費用與權限，並為人工程式碼審查預留資源。本指南說明一條有條件的工具操作路徑，並未報告 BIG CHANGE 已完成的功能、Jira 寫入、模型執行、實測節省、合併或部署。

來源與延伸閱讀