解釋此 PR
讀取 GitHub 上的 Pull Request，了解其變更內容，並用白話文撰寫解釋。將其發布為 PR 評論，讓審查者能立即掌握背景資訊。
步驟 1：檢查設定
確認 gh 已通過驗證：
gh auth status
如果未驗證：執行 gh auth login 並依照提示操作。
確認輸入內容。使用者必須提供下列其中一項：
- GitHub PR 網址（例如
https://github.com/owner/repo/pull/123） - 當前儲存庫中的 PR 編號（例如
#123） - 關鍵字 "current"，表示使用當前分支所對應的 PR
如果沒有輸入，請詢問：「哪個 PR 需要我解釋？請提供網址、PR 編號，或說 'current' 來指定目前分支。」
步驟 2：取得 PR 上下文
取得 PR 中繼資料：
gh pr view PR_URL_OR_NUMBER --json number,url,title,body,author,baseRefName,headRefName,additions,deletions,changedFiles,commits,labels,state,isDraft
如果 isDraft 為 true，請告知使用者：「此 PR 仍在草稿階段。解釋內容是根據其當前狀態。」
取得差異比較：
gh pr diff PR_URL_OR_NUMBER
如果差異超過 400 行，請讀取 --stat 摘要以及差異的前 200 行：
gh pr view PR_URL_OR_NUMBER --json files
gh pr diff PR_URL_OR_NUMBER | head -200
取得現有評論（以避免重複已存在的內容）：
gh pr view PR_URL_OR_NUMBER --json comments --jq '.comments[].body' 2>/dev/null | head -20
步驟 3：撰寫解釋
寫兩個段落。在寫作之前，請先閱讀每一條規則。
第一段：做了什麼（技術面）
- 每個主要變更用一句話說明
- 指出變更的特定檔案、函式或系統
- 如果差異比較中能清楚看出變更前後的差異，請說明
- 如果差異中出現具體數字（如刪除的行數、刪除的表格、新增的端點），請包含這些數字
- 使用主動語態、現在式
範例：
將 auth.middleware.ts 中的記憶體工作階段快取，改用 Redis 支援的快取（src/cache/redis.ts）。為新的 Redis 模組新增 get、set 和 invalidate 方法，並將 UserService.getById() 包裝成具有 5 分鐘 TTL 的調用。移除了限制在單一程序內、且會在多個實例間造成工作階段漂移的 Map 型快取。
第二段：為什麼重要（商業/產品影響）
- 誰會受益，以及如何受益
- 這個變更解決了什麼問題或降低了什麼風險
- 如果提交訊息中包含「為什麼」，請使用該背景資訊
- 如果差異比較或提交中沒有明確的「為什麼」，則省略此段落，而非猜測
範例：
在負載下存取 /api/me 端點的使用者，會在不同伺服器實例之間取得不一致的工作階段資料，導致間歇性的 401 錯誤。此變更使所有實例的工作階段狀態保持一致，並透過減少每個已驗證請求所需的一次資料庫查詢，來降低資料庫負載。
兩個段落的規則：
- 不要使用破折號（em dash），改用逗號或句號
- 不要使用填充詞彙：「這個 PR」、「這個變更」、「如您所見」
- 不要編造結果。只能說明在差異比較或提交訊息中直接可見的影響
- 如果此 PR 是純重構且行為沒有改變，請直接說明：「將 X 重構為 Y，可觀察到的行為不變。」
- 總字數低於 150 字
步驟 4：自我檢查
在發布之前，請檢查：
- 第一段中提到了差異比較中的特定檔案或函式
- 沒有編造的指標或結果
- 沒有使用破折號
- 沒有填充詞彙
- 總字數低於 150 字
- 如果沒有明確的「為什麼」，則省略第二段，而非猜測
請在發布前修正任何違規事項。
步驟 5：發布為 PR 評論
將解釋呈現給使用者。詢問：「準備好將此發布為 PR 評論了嗎，或者您想先編輯它？」
確認後，透過標準輸入傳遞內文，以安全處理反引號、引號和換行符：
git pr comment PR_URL_OR_NUMBER --body-file - << 'EOF'
EXPLANATION_HERE
EOF
發布後：「評論已添加。請在以下網址檢視：[步驟 2 中的網址]」
如果使用者說「僅輸出」（output only），則在程式碼區塊中呈現解釋，供手動複製貼上，而不發布。