skills-software-development/create-merge-request/SKILL.md

name, description, allowed-tools, argument-hint

name	description	allowed-tools	argument-hint
create-merge-request	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.	bash	[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