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の目標を1～2文でまとめます。>
## Contexte
<修正の場合はコードの現在の状態。期待される結果：制約、目標、アーキテクチャ、戦略。>
## Changements
- <高レベルの変更>
- ...
## Tests
- <記述したテスト、または実行した手動テスト>
セクションごとの指針:
- Description: 目標を1～2文で記述します。草案を提案し、ユーザーに確認または修正を依頼します。
- Contexte: 修正前の状態と期待される結果（制約、目標、アーキテクチャ、戦略）を説明します。項目ごとにユーザーに確認を求め、各項目が明確になるように質問をします（なぜこの選択か、どのような制約か、どのような代替案が却下されたか）。未確認の仮定で先に進まないでください。
- Changements: 高レベルのリストのみ。詳細は、その詳細そのものが変更の本質である場合、またはMR/PR全体を理解するために不可欠な場合にのみ記述します。
- Tests: 記述した自動テスト（カバーされたファイル/領域）と実行した手動テストの概要。不明な場合は質問します。実行していないテストを決して主張しないでください。
関連する質問は、AskUserQuestionを使用してバッチ処理し（件名、カード番号、コンテキストポイントなど）、多くのラウンドトリップを避けることを推奨します。
4. 既存の説明（更新の場合）
MR/PRに既に説明がある場合:
- 新しいテキストだけでなく、セクションごとに何が変更されるか（追加/修正/削除）を示します。
- ユーザーが書いた有用なコンテンツ（リンク、スクリーンショット、チェックリスト、テンプレートセクション、
Closes #12などのクロージングキーワード）は保持し、何か削除されるものがあればその旨を伝えます。 - 変更内容の確認を求め、その後に進みます。
5. 確認後、送信
- 最終的なタイトル、対象のMR/PR（URL、ブランチ）、および完全な説明を提示し、3つすべての確認を求めます。
- その後、別の質問として、プラットフォームへの変更送信の承認を求めます。
- 承認後、説明をスクラッチパッド/一時ファイルに書き込み、プラットフォームリファレンスのコマンドを使用してMR/PRを更新します。これらのコマンドは意図的に
allowed-toolsに含まれていないため、ユーザーに権限プロンプトが表示されます。 - 結果とMR/PRのURLを報告します。失敗した場合はエラーを表示します。静かに再試行しないでください。