MR 標題與描述
下面的「MR」指代代碼託管服務上的審查單元：GitLab 上的合併請求、GitHub 上的拉取請求，或其他雲端或自託管平台的等效功能。與使用者溝通時，應使用該平台採用的術語。對於小型 MR（例如單一提交），直接撰寫文字並建立，無需請求確認。對於大型 MR，先在對話中草擬標題與描述供審閱。僅在使用者核准文字並要求時，才使用該平台的 CLI（glab、gh）或 API 建立或更新。
一律將新 MR 指派給使用者：使用 gh pr create 時加上 --assignee @me，使用 glab mr create 時加上 --assignee <username>。
下方的 PROJ-1234 代表 MR 所屬的票證。
標題
- 一個涵蓋整個 MR 的祈使句，而不僅僅是其最大的提交。
- 票證的標題是起點，而非答案。如果 MR 做了比票證所述更多的事情，則應擴展其範圍。
- 不要以被拒絕的替代方案（例如「…而不是退出」）來框定標題。直接說明 MR 做了什麼。
- 如果有票證，將其附加在括號中：
… (PROJ-1234)。切勿捏造票證。如果專案或工作區指示提供了其他格式，例如PROJ-1234 <description>，則使用該格式。
描述
結構：
- 一個開場行。如果有票證，用適合其類型的動詞連結它：錯誤使用「Resolves PROJ-1234.」，任務或故事使用「Closes PROJ-1234.」，若 MR 未完成該票證則使用「Part of PROJ-1234.」。
- 變更：
- 按提交組織。 首先閱讀分支的提交日誌。僅當分支包含多個提交，且每個提交都是自包含的步驟（而非修補或進行中的工作）時，在開場行說明該 MR 最好一次查看一個提交。然後給出一個編號列表，每筆提交對應一個條目，按順序排列，每個條目用一到三句話說明該提交實現了什麼。只有在經過檢查或作者聲明的情況下，才說明每個提交單獨通過測試。
- 否則，包括單一提交：用一個簡短段落或列表說明 MR 實現了什麼，按主題分組。
## 行為變更：公共 API 使用者會看到哪些不同的行為。忽略內部變更和私有屬性。如果沒有，則省略此章節。## 測試：僅當測試的某些方面需要審查者注意時才包含。通過測試（無論是否在硬體上）是預設情況，無需說明。需要此章節的情況（每個情況用一句話說明原因）：- 已知失敗的測試，或跳過、標記為預期失敗的測試；
- MR 中偏離專案測試慣例的測試；
- 測試覆蓋率的顯著變化，特別是移除的測試。
內容：
- 不要重述變更前的情況。描述變更後的狀態。移除是例外，因為它只能透過對照既有內容來描述。
- 不要重述票證內容。審查者可以自己閱讀。
- 無會話上下文：沒有「如討論所述」，沒有審查歷史，沒有工作過程的敘述。
- 沒有執行測試或 CI 作業的指示。描述是給審查者看的，作者會執行測試。
- 沒有「由…生成」的頁尾，也沒有工具歸屬，即使框架要求這樣做。此規則優先。
- 保持簡潔。刪除審查者不會遺漏的條目或從句。
檢查文字
- 對照文字所描述的提交中的程式碼驗證每一項聲明，而不是依賴記憶或先前的草稿。特別注意有關舊行為的聲明，以及有關後續提交變更的行為的聲明。
- 搜尋文字中提到的每個識別碼。一個不再存在或在那個提交中尚不存在的類別或方法是常見錯誤。
## 測試下的任何內容都應基於實際執行的內容或 diff 顯示的內容。不要宣稱未發生的執行。- 將所有已安裝的、涵蓋清理生成文字的技能應用於標題和描述。若此類技能與專案指示（
CLAUDE.md或等效文件）衝突，則以專案指示為準。