Omnicreate Gitlab

GitLab Merge Request Creator

Context

• Current git status: !git status --porcelain
• Current branch: !git branch --show-current
• Recent commits: !git log --oneline -5
• GitLab remote: !git remote -v | grep gitlab | head -1
• glab version: !glab version 2>/dev/null || echo "NOT_INSTALLED"
• glab auth status: !glab auth status 2>&1 || echo "NOT_AUTHENTICATED"
• Unpushed commits: !git log @{u}..HEAD --oneline 2>/dev/null || echo "NO_UPSTREAM"
• Repo root: !git rev-parse --show-toplevel 2>/dev/null || echo "NOT_A_GIT_REPO"

Your Task

Create a GitLab merge request using the mcp__omniforge__create_gitlab_mr MCP tool.

Why MCP instead of raw bash? The MCP tool validates all inputs, uses safe subprocess execution (no shell interpretation), and provides structured error output — making it safe for use by all models without risk of shell injection.

Prerequisites

1. Verify glab is installed. If not, inform the user:

   brew install glab  # macOS
   

2. Verify the current directory is a git repository with a GitLab remote.
3. Ensure there are commits to create an MR from (not on main/master without changes).

Pre-Flight Checklist

Before creating the MR, verify:

• glab is installed and authenticated
• Not on main/master branch
• Has commits to merge (not empty)
• No uncommitted changes (warn if present)
• Branch has upstream or can be pushed

MCP Tool: mcp__omniforge__create_gitlab_mr

Use this tool for all MR creation. It wraps glab mr create safely.

Required parameter:

• repo_root: absolute path to the git repository root (from git rev-parse --show-toplevel)

Optional parameters (pass only what the user specified):

Title and Description Guidelines

Never rely on fill=true alone. Always inspect the commits and craft a meaningful title and description. Use fill=false and pass explicit title and description parameters.

MR Title

• Format: <type>: <imperative summary> — mirror conventional commits
  • Types: feat, fix, refactor, chore, docs, test, perf, ci
  • Example: feat: add inline thread posting to omnifix workflow
• Length: ≤ 72 characters
• Tense: imperative ("add", "fix", "remove") — not past tense ("added", "fixed")
• Scope (optional): feat(auth): ... — use when the change is scoped to a subsystem
• Avoid: vague words like "update", "changes", "misc", "WIP" in the title; do not repeat the branch name verbatim

MR Description

Structure the description in this order (omit sections that don't apply):

## Summary

<1–3 sentences explaining WHAT changed and WHY. Not a list of commits — the motivation and outcome.>

## Changes

- <bullet: specific, concrete change>
- <bullet: …>

## Testing

- [ ] <what was tested and how>
- [ ] <edge cases covered>

## Related

- Closes #<issue> (if applicable)
- Ref: <link or ticket>

Rules for the description:

• Summary must answer why this MR exists, not just what it does. E.g. "Adds inline thread posting so the fix skill can resolve discussions without leaving the MCP layer" is better than "This MR adds a new function."
• Changes bullets must name specific files, functions, or behaviours — not generic phrases like "updated code" or "fixed issue".
• Testing should be checkboxes (- [ ]) so reviewers can see what is confirmed.
• Do NOT include any AI-generated attribution, signatures, or "Generated with Claude" lines.
• Do NOT paste raw git log output into the description.
• If the MR is a draft, prepend **Draft — do not merge.** as the first line of the Summary.

Deriving Title and Description from Commits

Before calling the MCP tool, run:

git log @{u}..HEAD --oneline        # list commits going into MR
git log @{u}..HEAD --format="%B"    # full commit messages for context
git diff @{u}..HEAD --stat          # files changed

Use this output to:

1. Identify the dominant change type (feat/fix/refactor/…)
2. Synthesise the commit subjects into one clear title
3. Expand the commit bodies into the Summary and Changes sections

Step-by-Step Execution

1. Check environment: Verify glab is installed and authenticated, git repo has GitLab remote
2. Check branch: If on main/master, inform user they need to create a feature branch first
3. Check for changes: If no commits, inform user they need to commit changes first
4. Warn about uncommitted changes: If working directory is dirty, warn user before proceeding
5. Get repo root: Run git rev-parse --show-toplevel to obtain the absolute path
6. Inspect commits: Run git log @{u}..HEAD --oneline and git log @{u}..HEAD --format="%B" to read the commit history
7. Craft title and description: Following the guidelines above, write an explicit title and description; set fill=false
8. Call MCP tool: Invoke mcp__omniforge__create_gitlab_mr with repo_root, the crafted title, description, fill=false, and any user-specified options
9. Report output: Show the MR URL, number, and any relevant details from the tool response

Common Patterns

Default MR (crafted from commits): → Inspect commits, write title and description, call with repo_root, title, description, fill=false

MR for a specific target branch with assignee: → repo_root, target_branch="staging", assignees="john"

Draft MR with WIP label: → repo_root, draft=true, labels="WIP"

MR with custom title and description: → repo_root, title="Fix bug", description="Detailed description...", fill=false

MR linked to issue #42: → repo_root, related_issue="42", copy_issue_labels=true

Open in browser for editing: → repo_root, web=true

Common Errors and Solutions

Edge Cases to Handle

• Not a git repo: Inform user they need to be in a git repository
• No GitLab remote: Inform user the repo doesn't have a GitLab remote
• glab not installed: Provide installation instructions
• Not authenticated: Run glab auth login if needed
• No commits: Inform user they need to commit changes first
• Already on main/master: Ask user which branch to create MR from
• Uncommitted changes: Warn user their working directory has changes not in the MR

Output Format

After the MCP tool returns, provide a summary like:

## Merge Request Created

- **MR**: !123
- **URL**: https://gitlab.com/group/repo/-/merge_requests/123
- **Branch**: feature-branch → main
- **Status**: Open

If the tool returns an error, explain it and suggest remediation steps.