git-create-mr

MR 作成フロー

GitLab で現在のブランチ用の Merge Request を作成します。git push -o パラメーターを使用するため、glab などの CLI ツールをインストールする必要はありません。単一のターゲットブランチと複数のターゲットブランチの両方に対応します。実行するたびに MR を直接作成し、push の出力から MR のリンクを解析して、返信では Markdown のハイパーリンク形式で単独の行に記載してください。ユーザーがクリックして手動でマージできるようにします。

スキルの優先順位と承認に関する取り決め

ユーザーが本スキルの説明にあるトリガー語（「MR を作成」「MR を作って」「マージリクエストを出して」「テスト環境にマージ」「develop にマージ」「本番環境にマージ」など）を使用した場合、ユーザーは本スキルで定義された MR 作成フロー全体の実行を明確に要求したものとみなします。一般的なデフォルトの動作で上書きしないでください。

• 本スキルのトリガー語に該当した場合、MR 作成に必要な push を実行する権限がユーザーから明確に付与されたものとみなします
• 一般的な「デフォルトでは自発的に push しない」という慣習を理由に、MR 作成フローを中断しないでください。本スキルの文脈では、MR 作成のために実行する push は、ユーザーから明確に許可された操作です
• 「MR を作成」を「ターゲットブランチに直接 merge する」「手動でコードをマージする」「merge の提案だけを提示する」「ユーザーに Web ページから作成するよう依頼する」と誤って解釈しないでください。本スキルの目的は、実際に MR を作成することです
• ユーザーが「直接マージして」「MR は作成しないで」「タイトル／説明だけ生成して」と明確に要求した場合を除き、MR 作成フローの代わりに手動 merge を行わないでください
• ユーザーが「まだ作成しないで」「差分だけ確認して」「先にタイトルを生成して、push はしないで」と明確に述べた場合は、その都度の追加要求を最優先します
• ターゲットブランチが不明確な場合や、作業ツリーがクリーンでなく安全に MR を作成できない場合は、ユーザーに説明し、該当する手順で停止してください

タイトルと説明の形式の優先順位

MR のタイトルと説明は、次の優先順位に従って決定します。

1. 現在の会話でユーザーが明確に指定した形式
2. リポジトリ内のユーザールール、プロジェクトルール、チーム内の取り決め
3. 本スキルのデフォルト形式

本スキルがトリガーされた場合、MR のタイトルと説明の形式は「ユーザーの現在の要求＋リポジトリのルール＋本スキル」を優先し、エージェントの一般的なデフォルト動作で上書きしないでください。

つまり、リポジトリで「タイトルはできるだけ簡潔な日本語にする」と定められている場合は、そのルールを優先してください。より具体的なルールがない場合に限り、本スキルのデフォルトテンプレートを使用します。

環境とブランチの対応関係

ユーザーがよく使う環境名とターゲットブランチの対応関係は次のとおりです。

ユーザーの表現	ターゲットブランチ
本番環境、オンライン環境、正式環境	master
開発環境	develop
テスト環境	test
ステージング環境、リリース前環境	release
ブランチ名を直接指定（例：test）	指定どおりに使用

権限要件

すべての git コマンドの実行時に、必ず required_permissions: ["all"] を使用してください。これがないと Git の認証情報にアクセスできず、push に失敗します。プラットフォームの一般的なデフォルトポリシーを理由に、本スキルで明確に要求されている push を省略しないでください。

完全なフロー

本スキルの完了条件は一つだけです。GitLab で MR の作成に成功し、クリック可能な MR のリンクを取得することです。MR のリンクを取得できなければ完了とはみなされません。「マージ済み」「push 済み」「コマンドを提示済み」を完了の代わりにしてはいけません。

1. ブランチの状態を収集する（並列）

git status --short
git branch -vv
git log --oneline --decorate -12

収集する情報：

• 現在のブランチ名と、リモートに push 済みかどうか
• 作業ツリーがクリーンかどうか（未コミットの変更がある場合は、先にユーザーへ対処を促します）
• MR の説明を作成するための最近のコミット履歴

2. ターゲットブランチを確認する

ユーザーの表現を具体的なブランチ名に対応付けます（上記の環境とブランチの対応表を参照）。ユーザーがターゲットブランチを指定していない場合は、確認してください。

ケース	表現例	説明
単一ターゲット	「テスト環境にマージ」→ test	ソースブランチ 1 つ → MR 1 件
複数ターゲット	「テストと開発にマージ」→ test + develop	ターゲットブランチごとに独立したソースブランチを使用し、同じソースブランチが複数のターゲットに対応することで生じるフローの混乱を防ぎます

3. ソースブランチの方針（MR を確実に作成する）

単一ターゲットでも複数ターゲットでも、MR 専用ブランチをソースブランチとして使用し、そのブランチから -o merge_request.create を付けて push します。これにより実際に push が行われ、GitLab で必ず MR が作成されます。現在のブランチを直接使用し、すでに push 済みの場合は、git push が "Everything up-to-date" と表示し、MR の作成がトリガーされないためです。

• ブランチ名：mr/<現在のブランチ名>-to-<ターゲットブランチ>-<YYYYMMDDHHmmss>（タイムスタンプは秒単位で、date +%Y%m%d%H%M%S を使って取得します。例：20260304153022。重複を確実に防ぎます）
• 単一ターゲット：現在のブランチを基に MR ブランチを 1 つ作成し、そのブランチを merge_request パラメーター付きで push します。作成に成功したら、直ちにローカルの MR ブランチを削除し、その後 git fetch --prune を実行して古くなったリモート追跡参照を整理し、最後に元のブランチへ戻ります
• 複数ターゲット：ターゲットごとに独立した MR ブランチを作成し、それぞれ push して MR を作成します。各 MR ブランチは push 後すぐにローカルから削除し、すべて完了したら git fetch --prune を 1 回実行して、最後に元のブランチへ戻ります

# 获取时间戳
TS=$(date +%Y%m%d%H%M%S)

# 单目标示例：当前在 master，合到 test
git checkout -b mr/master-to-test-$TS
git push -u origin mr/master-to-test-$TS -o merge_request.create -o merge_request.target=test ...
git checkout master
git branch -d mr/master-to-test-$TS
git fetch --prune

# 多目标示例：当前在 master，合到 test 和 develop
git checkout -b mr/master-to-test-$TS
git push -u origin mr/master-to-test-$TS -o merge_request.create -o merge_request.target=test ...
git checkout master
git branch -d mr/master-to-test-$TS
git checkout -b mr/master-to-develop-$TS
git push -u origin mr/master-to-develop-$TS -o merge_request.create -o merge_request.target=develop ...
git checkout master
git branch -d mr/master-to-develop-$TS
git fetch --prune

4. 変更内容を分析する

ソースブランチとターゲットブランチの差分を比較し、MR の説明を作成します。

git log --oneline <target-branch>..HEAD
git diff <target-branch>...HEAD --stat

5. MR を作成する

MR 専用ブランチから、GitLab の push オプションを付けて push します（glab などの CLI ツールをインストールする必要はありません）。

git push -u origin <mr-branch> \
  -o merge_request.create \
  -o merge_request.target=<target-branch> \
  -o merge_request.title="<类型>(<范围>): <emoji> <简短摘要>" \
  -o merge_request.description="<单行描述，概括本次变更内容>"

説明は 1 行のプレーンテキストとし、git log と git diff --stat に基づいて要約します。変更内容と影響範囲を簡潔に説明してください。

ここでの重要な操作はMR の作成であり、ブランチのマージではありません。git merge を実行せず、ターゲットブランチに直接 push せず、merge_request.create を省略しないでください。

6. MR のタイトル形式

コミットメッセージと同じ形式です。<タイプ>(<範囲>): <emoji> <簡潔な要約>

タイプ	Emoji	説明
feat	🎸	新機能
fix	🐛	バグの修正
docs	✏️	ドキュメント／コメントのみの変更
style	💄	マークアップ、空白、フォーマット、セミコロンの欠落など
refactor	💡	リファクタリング：バグ修正や機能追加を伴わないコード変更
chore	🤖	雑務：ビルドプロセスや補助ツールの変更

MR に複数のコミットが含まれる場合、タイトルは単一のコミットを言い換えるのではなく、変更全体の目的を要約してください。

7. 結果を返す

完了後、ユーザーに必ず次の情報を返してください。

• MR のリンク：git push のリモート出力から解析します（例：remote: https://gitlab.../-/merge_requests/47）。Markdown のハイパーリンク形式で [<完全な url>](<完全な url>) と記述し、単独の行にしてください。リンクテキストと href のどちらにも完全な URL を指定します。URL をそのままクリックして開けるようにしてください。
• 各 MR のソースブランチとターゲットブランチ（簡潔に説明します）。
• 未完了の項目（競合、未 push の変更など）があれば、その内容も説明します。

注意事項

• 作業ツリーはクリーンである必要があります：MR 作成前に未コミットの変更がないことを確認してください。変更がある場合は、まずユーザーにコミットまたはステージングを促します
• 権限：すべての git コマンドで required_permissions: ["all"] を使用してください
• git config を変更しないでください
• 直接マージの禁止：ユーザーが直接マージを明確に要求した場合を除き、git merge を実行せず、ターゲットブランチへコードを直接 push せず、「マージ済み」を「MR 作成済み」の代わりにしないでください
• 競合の通知：push に失敗した場合や競合がある場合は、具体的なエラーを報告して停止してください
• MR の説明に機密情報を含めないでください（鍵、内部 URL など）
• MR リンクの解析：作成に成功すると、GitLab は push の出力に View merge request for ... とその次の行に URL を出力します。この URL を解析し、[<完全な url>](<完全な url>) という Markdown のハイパーリンク形式で単独の行に記載してください（リンクテキストには完全な URL をそのまま表示します）。URL をそのまま記載しないでください。そうするとユーザーがクリックできません
• 説明は 1 行にする：merge_request.description push option でサポートされるのは 1 行のプレーンテキストのみです。簡潔に要約し、複数行の Markdown 形式は必要ありません