mr-feedback
获取一个 GitLab 合并请求，评估其审查就绪程度，并将反馈报告写入一个新的 Markdown 文件，该文件可以直接复制到 MR 评论中。
操作内容
判断审查就绪度。检查 MR 是否具备足够的上下文、范围清晰度、测试说明和审查者指南，以便审查者能够高效地开始工作。
原因
准备充分的 MR 体现了对工作的重视，能更快地获得更高质量的审查。报告应让优秀的 MR 得到认可，并为准备不足的 MR 提供具体、有鼓励性的改进步骤，以提高其就绪度。
禁止事项
不要审查或批评代码本身，也不要建议代码/逻辑变更
偏好设置
在执行任何其他操作之前，请先阅读与此技能相关的 reference/preferences.md 文件。它是所有可配置行为的唯一真实来源，包括输出语言、语气、获取方法、允许使用的工具以及输出路径。此 SKILL.md 文件不会重复这些值；请始终从偏好文件中读取它们。
优先级（从高到低）：
- 用户当前请求中的显式指令（例如“这次用葡萄牙语写”）。
reference/preferences.md文件。- 此技能中的指令。
输入
用户提供以下内容之一：
- 一个完整的 MR URL：
https://gitlab.com/<group>/<subgroup>/<project>/-/merge_requests/<iid> - 项目路径 + MR iid：
group/subgroup/project+42
从 URL 中解析：
project_id= 主机名和/-/merge_requests/之间的路径（调用工具时需进行 URL 编码，如group%2Fsubgroup%2Fproject）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。不要编造数据——如果某个类别的获取结果为空（例如没有流水线），则标记为“不可用”，而不是进行猜测。
每个评估标准类别都附带一个原因，向作者解释其重要性。当您在“提升就绪度”部分报告差距时，必须始终包含为什么它对作者重要——这样反馈不仅能解释每个请求本身，还能解释其背后的目的。
不要逐字复制类别原因。 原因是对整个类别的背景说明；请根据您发现的确切问题重写原因。仅引用具体有问题的部分，切勿提及该类别中正常的部分。例如，如果分支落后于主分支但流水线是绿色的，则解释为什么落后于主分支很重要——不要提及流水线，因为它已经通过了。“为什么重要”必须针对此 MR 的具体差距，而不是对该类别的一般性陈述。
输出
写入 reference/preferences.md 中声明的输出路径，解析其占位符，并创建路径所需的任何文件夹。
护栏
- 只读。 此技能永远不会发布评论、批准或修改 MR。它仅写入一个本地 Markdown 文件。用户决定是否粘贴。
- 不要在报告中包含可能出现在差异中的密钥/令牌。
- 如果 MR 是草稿或尚无差异，您仍然可以判断并生成报告，但务必明确说明这一情况。