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），而不是猜测。
检索：当前标题、当前描述、源/目标分支以及变更（差异和提交列表），按照参考文档进行。阅读差异以理解 MR/PR 的实际内容。
确定：
- 仓库名称：项目路径的最后一段，使用大写字母。
- 卡片号：在现有标题、分支名称、提交和描述中查找（例如
ABC-123、#123）。如果未找到，询问一次；如果用户说没有，则完全省略中括号。
2. 标题
模式（两个平台相同）：
[<卡片号>] <REPO NAME> - <主题> - 简短描述
- 仅当存在卡片时才包含括号和卡片号。
<REPO NAME>：仓库名称大写。<主题>：始终向用户询问（从差异推断出建议作为默认选项，但不要独自决定）。如果当前标题已包含主题，建议保留它。- 简短描述：简洁，法语，小写开头，无结尾句号。
- 如果现有标题格式正确且仍然符合 MR/PR 内容，则保留它并说明。如果不再符合，提议修改版本并显示修改前后对比。
3. 描述
结构（Markdown，法语）：
# 描述
<一句话或两句话概括 MR/PR 的目标。>
## 背景
<如果是修改，描述代码的当前状态；预期结果：约束、目标、架构、策略。>
## 变更
- <高级别变更>
- ...
## 测试
- <已编写的测试，或执行的手动测试>
各部分指导：
- 描述：1-2 句介绍目标。草稿提议后请用户验证或更正。
- 背景：描述修改前的状态和预期结果（约束、目标、架构、策略）。逐点进行：每次向用户提交一个点进行验证，当某个点可以澄清时（为什么选择这个、哪个约束、拒绝了哪个替代方案）提出一个问题。不要带着未验证的假设继续。
- 变更：仅列出高级别内容。仅在变更具体涉及某个细节或对于理解整个 MR/PR 至关重要时才深入细节。
- 测试：概括已编写的自动测试（覆盖的文件/区域）和已执行的手动测试。如果未知，则询问；绝不声称未执行的测试。
优先使用 AskUserQuestion 批量提出相关问题（主题、卡片号、背景要点），以减少往返次数。
4. 现有描述（更新情况）
如果 MR/PR 已有描述：
- 按部分显示哪些内容会变化（新增/修改/删除），而不是仅显示新文本。
- 保留用户编写的有用内容（链接、截图、检查清单、模板部分、关闭关键词如
Closes #12）；如果某些内容将被删除，说明。 - 在继续之前请求确认更改。
5. 确认，然后发送
- 呈现最终的标题、目标 MR/PR（URL、分支）和完整的描述，并请求确认所有三项。
- 只有在此之后，再单独询问一个问题：授权将修改内容发送到平台。
- 批准后，将描述写入临时文件（scratchpad/temp），并使用平台参考文档中的命令更新 MR/PR。这些命令有意未包含在
allowed-tools中，以便用户获得权限提示。 - 报告结果和 MR/PR URL。如果失败，显示错误；不要静默重试。