MR / PR 標題與描述
所有寫入 MR/PR 的內容（標題、描述）以及向使用者提出的問題均使用法語。對於 GitLab 使用「MR」，對於 GitHub 使用「PR」。
引數（可選）
接收到的內容：$ARGUMENTS
| 引數 | 目標 |
|---|---|
https://github.com/<owner>/<repo>/pull/<n> | GitHub PR |
https://<host>/<group>/<repo>/-/merge_requests/<iid> | GitLab MR |
#<n> / 單獨 <n> | 當前倉庫的 MR 或 PR：透過 git remote -v 推斷平台 |
| 無 | 當前分支的 MR 或 PR：透過 git remote -v 推斷平台 |
如果無法推斷平台（自託管主機、多個遠端），請詢問使用者。
強制規則
- 未經使用者明確確認標題與描述，且未獲得單獨的明確授權前，絕不修改 MR/PR。
- 絕不編造事實（卡片編號、背景、測試）。應詢問或省略。
- MR/PR 內容中不得提及 Claude。
步驟
1. 識別並擷取 MR/PR
根據引數（上表）解析目標，然後在執行任何指令之前閱讀對應的參考文件：
references/sources/gitlab.mdreferences/sources/github.md
如果 CLI（glab / gh）遺失或未經認證，請告知使用者（建議使用 ! glab auth login / ! gh auth login），而非自行猜測。
擷取：當前標題、當前描述、來源/目標分支，以及變更內容（diff 與提交列表），並遵循參考文件。閱讀 diff 以了解 MR/PR 的實際內容。
判斷：
- 倉庫名稱：專案路徑的最後一段，以大寫表示。
- 卡片編號：在現有標題、分支名稱、提交與描述中尋找（例如
ABC-123、#123）。若未找到，詢問一次；若使用者表示沒有卡片，則完全省略方括號。
2. 標題
模式（兩個平台相同）：
[<卡片編號>] <倉庫名稱> - <主題> - 簡短描述
- 僅在有卡片時才包含方括號與卡片編號。
<倉庫名稱>：以大寫表示的倉庫名稱。<主題>：始終向使用者詢問（可根據 diff 推斷出建議作為預設選項，但不獨自決定）。如果當前標題已包含主題，建議保留它。- 簡短描述：簡潔，法語，以小寫開頭，結尾無句號。
- 如果現有標題已格式良好且仍符合 MR/PR 內容，則保留它並告知使用者。如果不再符合，則提出修改後的版本並顯示修改前後的對比。
3. 描述
結構（Markdown，法語）：
# Description
<一兩句總結 MR/PR 目標的句子。>
## Contexte
<如果是修改，則描述程式碼的當前狀態；預期結果：限制條件、目標、架構、策略。>
## Changements
- <高層級變更>
- ...
## Tests
- <已撰寫的測試，或已進行的手動測試>
各區段指引：
- Description：1–2 句說明目標。提出草稿並請使用者驗證或修正。
- Contexte：描述修改前的狀態以及預期結果（限制條件、目標、架構、策略）。逐點進行：將每個點提交給使用者驗證，並在可能需釐清時提出問題（為何選擇此方案、哪個限制條件、拒絕了哪個替代方案）。不要帶著未經驗證的假設繼續前進。
- Changements：僅列出高層級變更。僅在變更精確涉及該細節或為理解整個 MR/PR 所必需時才深入細節。
- Tests：概述已撰寫的自動化測試（涵蓋的檔案/領域）以及已進行的手動測試。若不清楚，詢問；絕不要聲稱未執行的測試。
建議將相關問題批次使用 AskUserQuestion（主題、卡片編號、背景要點）提出，以減少來回次數。
4. 現有描述（更新情況）
如果 MR/PR 已有描述：
- 逐區段顯示將會變更的內容（新增 / 修改 / 移除），而非僅顯示新文字。
- 保留使用者撰寫的有用內容（連結、螢幕截圖、檢查清單、範本區段、關閉關鍵字如
Closes #12）；若有任何內容將被移除，需提及。 - 在繼續之前，請使用者確認變更。
5. 確認，然後送出
- 展示最終的標題、目標 MR/PR（URL、分支）以及完整的描述，並請使用者確認三者。
- 僅在此之後，再提出一個單獨的問題：授權將修改送至平台。
- 獲得批准後，將描述寫入暫存檔案，並使用平台參考文件中的指令更新 MR/PR。這些指令故意未列在
allowed-tools中，以便使用者收到權限提示。 - 報告結果以及 MR/PR 的 URL。如果失敗，顯示錯誤；不要默默重試。