---
name: create-merge-request
description: >
  Create a GitLab Merge Request from uncommitted changes. Automatically creates a feature
  branch, organizes changes into logical commits, pushes to remote, and opens an MR.
allowed-tools: bash
argument-hint: "[branch-name] [optional: description]"
---

# Create a GitLab Merge Request from Uncommitted Changes

You are tasked with creating a GitLab Merge Request (MR) from the current uncommitted changes in the working directory.

## Steps to Follow

### 1. Analyze the Current State
- Run `git status` to see all uncommitted changes (staged and unstaged)
- Run `git diff` to understand what has been modified
- Identify the default branch (check if it's `main` or `master`)

### 2. Create a New Feature Branch
- Create and checkout a new branch with a descriptive name
- If the user provided a branch name as $1, use that
- Otherwise, derive a meaningful branch name from the changes (e.g., `feature/add-user-authentication`, `fix/login-validation-bug`)
- Use the format: `<type>/<short-description>` where type is one of: feature, fix, refactor, docs, chore

### 3. Organize and Commit Changes Logically
- Group related changes into logical, atomic commits
- Each commit should represent a single logical change
- Write clear, conventional commit messages following this format:
  ```
  <type>(<scope>): <description>

  [optional body explaining what and why]
  ```
- Types: feat, fix, refactor, docs, style, test, chore
- If all changes are related, a single well-described commit is acceptable
- Stage and commit the changes appropriately

### 4. Push the Branch to Remote
- Push the new branch to the GitLab remote: `git push -u origin <branch-name>`

### 5. Create the Merge Request
- Use the GitLab CLI (`glab`) to create the merge request
- Target the default branch (main or master)
- Command: `glab mr create --target-branch <default-branch> --title "<title>" --description "<description>"`
- The title should summarize the changes concisely
- The description should include:
  - A summary of what the MR accomplishes
  - List of key changes made
  - Any relevant context or notes
- If the user provided a description as $ARGUMENTS (after the branch name), incorporate it

### 6. Report the Result
- Display the MR URL for easy access
- Summarize what was done (branch created, commits made, MR opened)

## Important Notes
- Do NOT force push or use destructive git operations
- Ensure all changes are properly staged before committing
- If there are no uncommitted changes, inform the user and stop
- If `glab` CLI is not installed, inform the user how to install it