mr-feedback
擷取一個 GitLab 合併請求，評估其審查準備程度，並將回饋報告寫入一個新的 markdown 檔案，該檔案可直接複製貼上到 MR 留言中。
要做什麼
判斷審查準備程度。檢查 MR 是否具備能讓審查者有效接手的背景資訊、範圍明確性、測試說明及審查指引。
為什麼
一份準備充分的 MR 代表用心，也能讓審查更快、更好。報告應讓好的 MR 獲得肯定，並為較弱的 MR 提供具體且具鼓勵性的改善步驟。
不要做什麼
不要審查或評論程式碼本身，也不要建議程式碼/邏輯變更
偏好設定
在執行任何其他動作之前，請先讀取 reference/preferences.md（相對於此技能的路徑）。它是所有可設定行為的真實來源——輸出語言、語氣、擷取方式、允許的工具及輸出路徑。此 SKILL.md 不重述這些值；請一律從偏好設定檔中讀取。
優先順序，由高至低：
- 使用者目前請求中的明確指示（例如「這次用中文寫」）。
reference/preferences.md。- 此技能中的指示。
輸入
使用者提供以下其一：
- 完整的 MR URL：
https://gitlab.com/<群組>/<子群組>/<專案>/-/merge_requests/<iid> - 專案路徑 + MR iid：
群組/子群組/專案+42
從 URL 解析：
project_id= 主機與/-/merge_requests/之間的路徑（呼叫工具時請以group%2Fsubgroup%2Fproject的方式進行 URL 編碼）mergeRequestIid=/-/merge_requests/後面的數字
如果缺少任何一項或資訊不明確，請先詢問再擷取。
工作流程
使用 reference/preferences.md 中宣告的方法和工具。下列步驟說明要收集哪些資訊以及為什麼，而非呼叫哪個工具——請從偏好設定檔中為每個步驟挑選相符的工具。
- MR 元資料——標題、描述、作者、狀態、來源/目標分支、草稿標記、標籤、里程碑、核准、合併狀態。
- 變更檔案清單——路徑 + 新增/刪除計數；無需擷取所有差異即可了解範圍/大小。
- 抽樣差異以確認描述與現實相符——每次 3-5 個檔案。僅用於合理性檢查範圍及測試是否被更動——不要評論程式碼。跳過鎖定檔案、產生檔案及純重新命名；如果 MR 很大則進行抽樣。
- 提交記錄——使用 MR 元資料（步驟 1）中已包含的提交摘要，作為衛生/原子性訊號（提交次數 / 新增摘要）。
- CI 狀態——該 MR 的最新管線狀態（通過/失敗/無）。
- 評估依據
reference/rubric.md中的評分標準。 - 撰寫報告至一個新檔案（請見輸出），使用
reference/report-template.md。 - 告知使用者檔案路徑，並提供調整語氣/長度的選項，供使用者複製貼上。
在評分之前請先讀取 reference/rubric.md，在撰寫之前請先讀取 reference/report-template.md。不要虛構資料——如果某個類別的擷取未回傳任何結果（例如沒有管線），請標註為「無法取得」而非猜測。
評分標準的每個類別都有一個原因，說明該類別對作者的重要性。當你在「提升準備度」中報告缺口時，務必包含為何重要（對作者而言）——如此回饋才能解釋每個請求背後的目的，而不只是提出請求本身。
不要逐字複製類別的「原因」。「原因」是涵蓋整個類別的背景說明；請根據你發現的確切問題重新改寫。僅提及有問題的具體事項，切勿提及類別中沒問題的部分。例如，如果分支落後 master 但管線是綠燈，只需說明分支落後 master 的原因——不要提及管線，因為它通過了。「為何重要」必須針對此 MR 的特定缺口，而不是該類別的通用陳述。
輸出
寫入 reference/preferences.md 中宣告的輸出路徑，解析其中的佔位符，並建立路徑所需的任何資料夾。
護欄
- **唯讀。**此技能絕不張貼留言、核准或修改 MR。它僅在本地寫入一個 markdown 檔案。由使用者決定是否貼上。
- 請勿在報告中包含差異中可能出現的密碼/權杖。
- 如果 MR 是草稿或尚無差異，你仍然可以對其進行判斷並生成報告，但請務必明確說明此情況。