Gitlab Cli Skills

GitLab CLI Skills

Comprehensive GitLab CLI (glab) command reference and workflows.

Quick start

# First time setup
glab auth login
Common operations
glab mr create --fill              # Create MR from current branch
glab issue create                  # Create issue
glab ci view                       # View pipeline status
glab repo view --web              # Open repo in browser

Multi-agent identity note

When you want different agents to appear as different GitLab users, give each agent its own GitLab bot/service account. Multiple personal access tokens on the same GitLab user still act as that same visible identity.

Use the Actor identity for actor-authored GitLab comments, replies, approvals, and other writes. Use an agent identity only when the GitLab action is explicitly that agent's own work product. Choose the intended visible actor before the first GitLab write.

Treat shell identity as sticky and unsafe by default. If another env file was sourced earlier in the same shell/session, glab may still write as that previously loaded identity unless you deliberately switch and verify first.

A practical pattern is one env file per actor, for example ~/.config/openclaw/env/gitlab-actor.env, ~/.config/openclaw/env/gitlab-reviewer.env, and ~/.config/openclaw/env/gitlab-release.env. Keep these env files outside version control, restrict their permissions (for example chmod 600), be mindful of backup exposure, and use least-privilege bot/service-account tokens. In a reused shell, clear stale GitLab auth vars first or start a fresh shell. If those files use plain KEY=value lines, load them with exported vars before running glab:

unset GITLAB_TOKEN GITLAB_ACCESS_TOKEN OAUTH_TOKEN GITLAB_HOST
set -a
source ~/.config/openclaw/env/gitlab-.env
set +a

Plain source updates the current shell but may not export variables to child processes such as glab. If the token/host vars are not exported, glab may silently fall back to shared stored auth from ~/.config/glab-cli/config.yml, which can make the wrong account appear to perform the action.

Required pre-flight before any GitLab write

Run this immediately before any GitLab write, including glab mr note, review replies/approvals, and any glab api POST/PATCH/PUT/DELETE call:

glab auth status --hostname "$GITLAB_HOST"
glab api --hostname "$GITLAB_HOST" user

This assumes the target actor env file set GITLAB_HOST for the exact GitLab instance you intend to modify. Do not write until both commands clearly show the intended visible actor on that host.

Wrong-identity remediation

If a comment or reply was posted under the wrong identity:

1. Stop posting. 2. Delete the mistaken comment or reply if cleanup is needed. 3. unset GITLAB_TOKEN GITLAB_ACCESS_TOKEN OAUTH_TOKEN GITLAB_HOST or start a fresh shell. 4. Source the correct env file with set -a; source ...; set +a. 5. Rerun glab auth status --hostname "$GITLAB_HOST" and glab api --hostname "$GITLAB_HOST" user. 6. Repost under the correct actor. 7. Verify the thread no longer shows the wrong visible author for the replacement message.

If the wrong-identity write changed state beyond a comment or reply, do not treat the comment cleanup steps as sufficient. Re-auth as above, then use the matching GitLab reversal for that write under the correct actor and host, such as unapproving an MR or sending the compensating glab api --hostname "$GITLAB_HOST" mutation for the exact resource that was changed.

Skill organization

This skill routes to specialized sub-skills by GitLab domain:

Core Workflows:

Project Management:

Authentication & Config:

CI/CD Management:

Collaboration:

Advanced:

Utilities:

When to use glab vs web UI

Use glab when:

Use web UI when:

Common workflows

Daily development

# Start work on issue
glab issue view 123
git checkout -b 123-feature-name
Create MR when ready
glab mr create --fill --draft
Mark ready for review
glab mr update --ready
Merge after approval
glab mr merge --when-pipeline-succeeds --remove-source-branch

Code review

# List your review queue
glab mr list --reviewer=@me --state=opened
Review an MR
glab mr checkout 456
glab mr diff
npm test
Approve
glab mr approve 456
glab mr note 456 -m "LGTM! Nice work on the error handling."

CI/CD debugging

# Check pipeline status
glab ci status
View failed jobs
glab ci view
Get job logs
glab ci trace 
Retry failed job
glab ci retry 

Decision Trees

"Should I create an MR or work on an issue first?"

Need to track work?
├─ Yes → Create issue first (glab issue create)
│         Then: glab mr for 
└─ No → Direct MR (glab mr create --fill)

Use glab issue create + glab mr for when:

Use glab mr create directly when:

"Which CI command should I use?"

What do you need?
├─ Overall pipeline status → glab ci status
├─ Visual pipeline view → glab ci view
├─ Specific job logs → glab ci trace 
├─ Download build artifacts → glab ci artifact  
├─ Validate config file → glab ci lint
├─ Trigger new run → glab ci run
└─ List all pipelines → glab ci list

Quick reference:

"Clone or fork?"

What's your relationship to the repo?
├─ You have write access → glab repo clone group/project
├─ Contributing to someone else's project:
│   ├─ One-time contribution → glab repo fork + work + MR
│   └─ Ongoing contributions → glab repo fork, then sync regularly
└─ Just reading/exploring → glab repo clone (or view --web)

Fork when:

Clone when:

"Project vs group labels?"

Where should the label live?
├─ Used across multiple projects → glab label create --group 
└─ Specific to one project → glab label create (in project directory)

Group-level labels:

Project-level labels:

Related Skills

MR and Issue workflows:

CI/CD debugging:

Repository operations:

Configuration:

# First time setup
glab auth login
Common operations
glab mr create --fill              # Create MR from current branch
glab issue create                  # Create issue
glab ci view                       # View pipeline status
glab repo view --web              # Open repo in browser