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-<actor>.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:

Stop posting.
Delete the mistaken comment or reply if cleanup is needed.
unset GITLAB_TOKEN GITLAB_ACCESS_TOKEN OAUTH_TOKEN GITLAB_HOST or start a fresh shell.
Source the correct env file with set -a; source ...; set +a.
Rerun glab auth status --hostname "$GITLAB_HOST" and glab api --hostname "$GITLAB_HOST" user.
Repost under the correct actor.
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:

glab-mr - Merge requests: create, review, approve, merge
glab-issue - Issues: create, list, update, close, comment
glab-ci - CI/CD: pipelines, jobs, logs, artifacts
glab-repo - Repositories: clone, create, fork, manage

Project Management:

glab-milestone - Release planning and milestone tracking
glab-iteration - Sprint/iteration management
glab-label - Label management and organization
glab-release - Software releases and versioning

Authentication & Config:

glab-auth - Login, logout, Docker registry auth
glab-config - CLI configuration and defaults
glab-ssh-key - SSH key management
glab-gpg-key - GPG keys for commit signing
glab-token - Personal and project access tokens
glab-todo - Personal GitLab to-do triage and completion

CI/CD Management:

glab-job - Individual job operations
glab-schedule - Scheduled pipelines and cron jobs
glab-variable - CI/CD variables and secrets
glab-securefile - Secure files for pipelines
glab-runner - Runner management: list, assign/unassign, inspect jobs/managers, pause/unpause, delete
glab-runner-controller - Runner controller, scope, and token management (EXPERIMENTAL, admin-only)

Collaboration:

glab-user - User profiles and information
glab-snippet - Code snippets (GitLab gists)
glab-incident - Incident management
glab-workitems - Work items: tasks, OKRs, key results, next-gen epics

Advanced:

glab-api - Direct REST API calls
glab-cluster - Kubernetes cluster integration
glab-deploy-key - Deploy keys for automation
glab-quick-actions - GitLab slash command quick actions for batching state changes
glab-stack - Stacked/dependent merge requests
glab-opentofu - Terraform/OpenTofu state management

Utilities:

glab-alias - Custom command aliases
glab-completion - Shell autocompletion
glab-help - Command help and documentation
glab-version - Version information
glab-check-update - Update checker
glab-changelog - Changelog generation
glab-attestation - Software supply chain security
glab-duo - GitLab Duo AI assistant
glab-mcp - Model Context Protocol server for AI assistant integration (EXPERIMENTAL)

When to use glab vs web UI

Use glab when:

Automating GitLab operations in scripts
Working in terminal-centric workflows
Batch operations (multiple MRs/issues)
Integration with other CLI tools
CI/CD pipeline workflows
Faster navigation without browser context switching

Use web UI when:

Complex diff review with inline comments
Visual merge conflict resolution
Configuring repo settings and permissions
Advanced search/filtering across projects
Reviewing security scanning results
Managing group/instance-level settings

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 <job-id>

# Retry failed job
glab ci retry <job-id>

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 <issue-id>
└─ No → Direct MR (glab mr create --fill)

Use glab issue create + glab mr for when:

Work needs discussion/approval before coding
Tracking feature requests or bugs
Sprint planning and assignment
Want issue to auto-close when MR merges

Use glab mr create directly when:

Quick fixes or typos
Working from existing issue
Hotfixes or urgent changes

"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 <job-id>
├─ Download build artifacts → glab ci artifact <ref> <job-name>
├─ Validate config file → glab ci lint
├─ Trigger new run → glab ci run
└─ List all pipelines → glab ci list

Quick reference:

Pipeline-level: glab ci status, glab ci view, glab ci run
Job-level: glab ci trace, glab job retry, glab job view
Artifacts: glab ci artifact (by pipeline) or job artifacts via glab job

"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:

You don't have write access to the original repo
Contributing to open source projects
Experimenting without affecting the original
Need your own copy for long-term work

Clone when:

You're a project member with write access
Working on organization/team repositories
No need for a personal copy

"Project vs group labels?"

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

Group-level labels:

Consistent labeling across organization
Examples: priority::high, type::bug, status::blocked
Managed centrally, inherited by projects

Project-level labels:

Project-specific workflows
Examples: needs-ux-review, deploy-to-staging
Managed by project maintainers

Related Skills

MR and Issue workflows:

Start with glab-issue to create/track work
Use glab-mr to create MR that closes issue
Script: scripts/create-mr-from-issue.sh automates this

CI/CD debugging:

Use glab-ci for pipeline-level operations
Use glab-job for individual job operations
Script: scripts/ci-debug.sh for quick failure diagnosis

Repository operations:

Use glab-repo for repository management
Use glab-auth for authentication setup
Script: scripts/sync-fork.sh for fork synchronization

Configuration:

Use glab-auth for initial authentication
Use glab-config to set defaults and preferences
Use glab-alias for custom shortcuts