gitlab-mr

GitLab MR

Create an MR and drive it to a truly mergeable state (all CI green + no merge conflicts). Core principle: write documentation first, then submit the MR, verify with APIs, and loop through fixes until the MR is mergeable.

Prerequisite: The current repository's remote points to gitlab.example.com, and glab CLI is installed.

---

Rules

1. Never use the skip-doc-check label — every MR must have a real documentation link
2. User Story must be relevant to the MR changes — CI checks relevance (check:mr-us-relevance); irrelevant links will be rejected
3. Blob links must point to pushed files — the branch name and file path in the link must exist on the remote
4. Verify with APIs, don't guess — confirm results at every step using glab commands

---

Execution Flow

Step 1: Check Prerequisites

# Confirm remote points to gitlab.example.com
git remote get-url origin

# Confirm current branch is not main/master
git branch --show-current

# Confirm no uncommitted changes
git status

If there are uncommitted changes, commit or stash them first.

Step 2: Ensure Documentation Exists

The MR description must contain documentation links. CI performs two checks:

• check:mr-documentation: whether the link format is valid
• check:mr-us-relevance: whether the linked document is relevant to the MR changes

Prefer GitLab blob links pointing to documentation files within the repository.

2a: Find or Create Documentation

Check whether related documentation already exists in the repository:

# Look for potentially related documents
ls docs/plans/ docs/04-user-stories/ 2>/dev/null

If no related documentation exists, create one for this MR:

• Place the document at docs/plans/YYYY-MM-DD-<feature-name>.md (design doc) or docs/04-user-stories/<feature-name>.md (User Story)
• The document content must cover the core changes in this MR (otherwise the relevance check will fail)
• The document does not need to be long, but must describe: what was done and why