gitlab-mr-issue

GitLab CLI Skill（MR/Issue）

MR Review

• Prioritize reading MR discussions / notes / diff comments, then consolidate them uniformly.
• When necessary, you may view the code of the corresponding local branch; before viewing, first git fetchto ensure the branch is at the latest remote state.
• When the user asks to consolidate MR review comments, arrange them by severity from high to low, numbered sequentially, to make it easy for the user to reply.
• Show at most 10 items each time; if there are more, indicate at the end “N items remain undisplayed”.

Basic preparation

• Confirm identity and authentication:
  • glab auth status Read the current instance and the “Logged in to as ” line.
  • Get the username directly:GITLAB_HOST=<host> glab api /user | jq -r '.username'(depends on the local jq, if the global GITLAB_HOST is already set, you can directly glab api /user）。
  • For self-hosted instances, preferably specify via the environment variable GITLAB_HOST ; if a one-time override is needed, you can prepend GITLAB_HOST=<host> to the command or use -R group/project。
• The default output format is sufficient; if machine-readable output is needed, use --output json。
• After successfully creating an MR or Issue, in the terminalon a separate lineoutput the complete URL returned by the CLI.

Issue quick view

• Body only:glab issue view <id|url>.
• With discussions:glab issue view <id|url> --comments(if necessary, add --system-logs）。
• List:glab issue list --state opened --per-page 50 [-R group/project]; to filter labels use --label foo,bar。
• Add a comment:glab issue note <id> -m "comment"。

MR quick view

• MR overview (retrieve fields as needed):glab mr view <id|branch|url> --output json | jq -r '.title,.state,.author.username,.web_url,.description'。
• View diff:glab mr diff <id|branch> --color=never; if the raw patch is needed, use --raw。
• Related issue:glab mr issues <id>。

Create MR (non-interactive)

The following title and description conventions are the default recommended format; if they conflict with existing constraints such as those of the team/repository/platform, the existing constraints take precedence. If there are explicit requirements (e.g., in Chinese), follow them first; for parts not covered, fill them in according to this convention.

1. Ensure the local branch has been pushed and that git status is clean.
2. Title style: English, follow semantic commit conventions (e.g., feat(scope): short summary), keep it concise and describe the core purpose; even if the title is required to be in Chinese, the semantic prefix (e.g., feat、fix) should still be in English.
3. Description style: English, short sentences and bullet points, prioritizing helping readers who do not look at the code quickly understand the motivation, changes, and verification method. Focus on what/why/testing, avoiding a running account and excessive implementation details. If the context is insufficient to clarify the goal or constraints, proactively confirm with the developer before writing. When proprietary terms, function names, method names, class names, API names, or configuration keys are involved, wrap them in inline code (backticks) to improve readability and accuracy.
4. Default body format:

• ## Why: 1-2 short sentences explaining why this change is being made, focusing on the problem background or goal.
• ## What: 1-3 items describing the main changes, focusing on changes at the functional or behavioral level, without listing trivial implementation details.
• ## Testing: Explain the verification method, commands, or scenarios; if untested, note the reason.

1. Optional body blocks: add them only when truly necessary.

• ## Risks: Compatibility impact, potential risks, rollback considerations.
• ## Notes: Points reviewers need to pay special attention to, or follow-up plans.

1. Special emphasis: The description should focus on the changes and impact on the system before and after the MR merge, and avoid recording intermediate processes or modification steps during development.
2. Use heredoc to pass a multi-line description, avoiding interactive editing:

glab mr create \
  --title "feat(scope): short summary" \
  --description "$(cat <<'EOF'
## Why
- explain why

## What
- summarize key changes

## Testing
- list validation steps
EOF
)" \
  --target-branch main \
  --source-branch $(git branch --show-current) \
  --label bugfix \
  --draft \
  --yes

• Recommended parameters (can be enabled as needed):--remove-source-branch(delete the source branch after merging),--squash-before-merge(squash into a single commit before merging); can be omitted if the team prefers.
• Other commonly used parameters:--reviewer user1,user2、--allow-collaboration。
• Modify an existing MR:glab mr update <id> --title "..." --description "$(cat <<'EOF'\n...\nEOF\n)" --label ... --yes。

Issue creation (non-interactive)

• The command mode is similar to that for MRs, using --title with a heredoc description:

glab issue create \
  --title "feat: short summary" \
  --description "$(cat <<'EOF'\n- context\n- expected\nEOF\n)" \
  --label backlog,team-x \
  --assignee user1 \
  --yes

• If privacy is needed: add --confidential; due date --due-date YYYY-MM-DD。

Common options quick reference

• -R group/project: Specify a self-hosted instance project, equivalent to the full URL.
• --per-page and --page: Used when viewing lists or comments with pagination.

Update Issue/MR title or description (prerequisite)

Before updating the title/description of an Issue or MR, you must first read the current title/body (the content about to be modified), and then make the modification.