How do I install the Gitlab CLI skill?

Run npx skillmds@latest add abdullahkhawer/gitlab-cli in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Gitlab CLI safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Gitlab CLI?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Gitlab CLI free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Gitlab CLI?

abdullahkhawer (@abdullahkhawer) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Gitlab CLI by abdullahkhawer — Agent Skill

Name: Gitlab CLI
Author: abdullahkhawer

Gitlab CLI

Perform GitLab operations using the glab CLI. Use for issues, merge requests, pipelines, repositories, and project management. ALSO use this skill when asked to review a GitLab MR or PR — when a GitLab MR URL or MR ID is provided, use glab to fetch and review the diff instead of the code-review skill.

File contents

GitLab CLI Skill

Use the instance and rules below when constructing all glab commands.

Configuration

Set your GitLab hostname below before using this skill:

Setting	Value
GitLab Hostname	`<YOUR_GITLAB_HOSTNAME>` (e.g. `gitlab.example.com`)

Replace <YOUR_GITLAB_HOSTNAME> with your GitLab instance hostname throughout this skill.

Prerequisites (one-time setup by user)

If not already authenticated, inform the user that authentication is required and ask them to complete the following steps manually. Do not perform these steps yourself.

Install the glab CLI if not already installed:

brew install glab

Run the following command to authenticate with your GitLab instance:

glab auth login --hostname <YOUR_GITLAB_HOSTNAME>

MR Code Review

When asked to review a GitLab MR or PR (URL or MR ID provided), extract the <group/repo> and <MR_ID> from the URL (ask the user if the repo is missing), then use glab api --hostname <YOUR_GITLAB_HOSTNAME> to fetch the MR metadata (projects/<URL_ENCODED_REPO>/merge_requests/<MR_ID>) and its diff (…/diffs --paginate), where the repo path is URL-encoded with / → %2F. To fully understand the context and impact of all code changes, read the complete source branch codebase — the diff alone does not capture the surrounding logic, dependencies, or broader design that the changes interact with. Report the MR title, author, and branches, then review all changed files for: secrets/injection/XSS (security), inefficient algorithms/memory leaks (performance), code smells/dead code (quality), missing error handling, excessive or sensitive logging, and missing/outdated documentation. For each finding, include the file path, line number(s), the problematic snippet, and a suggested fix. If nothing is wrong, summarize what was reviewed and state it looks good.

Rules

NEVER target any GitLab instance other than <YOUR_GITLAB_HOSTNAME>. If a command or URL references a different host, stop and ask the user to confirm.
Always pass --repo <YOUR_GITLAB_HOSTNAME>/<group/repo> explicitly for any glab subcommand that accepts it (e.g., mr list, issue list, pipeline list) — without it, the command infers the repo from the current git directory, which may silently return wrong results.
When using glab api, always pass --hostname <YOUR_GITLAB_HOSTNAME> explicitly — omitting it may default to gitlab.com.
NEVER use glab repo list --group — it does not work reliably against self-hosted instances; use glab api --hostname <YOUR_GITLAB_HOSTNAME> "groups/<GROUP>/projects" instead. For nested subgroups, URL-encode the slashes: "groups/parent%2Fchild/projects".
All glab api calls that return lists are paginated (default 20/page). Always pass --paginate to fetch all pages: glab api --hostname <YOUR_GITLAB_HOSTNAME> --paginate "<endpoint>".
For glab mr list, prefer explicit state flags over --state: use --closed (-c) for closed, --merged (-M) for merged, or --all (-A) for all states. Omitting a state flag returns open MRs by default.

---name: gitlab-clidescription: Perform GitLab operations using the glab CLI. Use for issues, merge requests, pipelines, repositories, and project management. ALSO use this skill when asked to review a GitLab MR or PR — when a GitLab MR URL or MR ID is provided, use glab to fetch and review the diff instead of the code-review skill.---# GitLab CLI SkillUse the instance and rules below when constructing all glab commands.## ConfigurationSet your GitLab hostname below before using this skill:| Setting | Value ||---|---|| GitLab Hostname | `<YOUR_GITLAB_HOSTNAME>` (e.g. `gitlab.example.com`) |Replace `<YOUR_GITLAB_HOSTNAME>` with your GitLab instance hostname throughout this skill.### Prerequisites (one-time setup by user)If not already authenticated, inform the user that authentication is required and ask them to complete the following steps manually. Do not perform these steps yourself.1. Install the `glab` CLI if not already installed:```bashbrew install glab```2. Run the following command to authenticate with your GitLab instance:```bashglab auth login --hostname <YOUR_GITLAB_HOSTNAME>```## MR Code ReviewWhen asked to review a GitLab MR or PR (URL or MR ID provided), extract the `<group/repo>` and `<MR_ID>` from the URL (ask the user if the repo is missing), then use `glab api --hostname <YOUR_GITLAB_HOSTNAME>` to fetch the MR metadata (`projects/<URL_ENCODED_REPO>/merge_requests/<MR_ID>`) and its diff (`…/diffs --paginate`), where the repo path is URL-encoded with `/` → `%2F`. To fully understand the context and impact of all code changes, read the complete source branch codebase — the diff alone does not capture the surrounding logic, dependencies, or broader design that the changes interact with. Report the MR title, author, and branches, then review all changed files for: secrets/injection/XSS (security), inefficient algorithms/memory leaks (performance), code smells/dead code (quality), missing error handling, excessive or sensitive logging, and missing/outdated documentation. For each finding, include the file path, line number(s), the problematic snippet, and a suggested fix. If nothing is wrong, summarize what was reviewed and state it looks good.## Rules- NEVER target any GitLab instance other than `<YOUR_GITLAB_HOSTNAME>`. If a command or URL references a different host, stop and ask the user to confirm.- Always pass `--repo <YOUR_GITLAB_HOSTNAME>/<group/repo>` explicitly for any `glab` subcommand that accepts it (e.g., `mr list`, `issue list`, `pipeline list`) — without it, the command infers the repo from the current git directory, which may silently return wrong results.- When using `glab api`, always pass `--hostname <YOUR_GITLAB_HOSTNAME>` explicitly — omitting it may default to `gitlab.com`.- NEVER use `glab repo list --group` — it does not work reliably against self-hosted instances; use `glab api --hostname <YOUR_GITLAB_HOSTNAME> "groups/<GROUP>/projects"` instead. For nested subgroups, URL-encode the slashes: `"groups/parent%2Fchild/projects"`.- All `glab api` calls that return lists are paginated (default 20/page). Always pass `--paginate` to fetch all pages: `glab api --hostname <YOUR_GITLAB_HOSTNAME> --paginate "<endpoint>"`.- For `glab mr list`, prefer explicit state flags over `--state`: use `--closed` (`-c`) for closed, `--merged` (`-M`) for merged, or `--all` (`-A`) for all states. Omitting a state flag returns open MRs by default.

Frequently asked questions