gitlab-cli-skills

name	gitlab-cli-skills
description	Comprehensive GitLab CLI (glab) command reference and workflows for all GitLab operations via terminal. Use when user mentions GitLab CLI, glab commands, GitLab automation, MR/issue management via CLI, CI/CD pipeline commands, repo operations, authentication setup, or any GitLab terminal operations. Routes to specialized sub-skills for auth, CI, MRs, issues, releases, repos, and 30+ other glab commands. Triggers on glab, GitLab CLI, GitLab commands, GitLab terminal, GitLab automation.
metadata	{"openclaw":{"requires":{"bins":["glab"],"anyBins":["cosign"]},"install":[{"id":"brew","kind":"brew","formula":"glab","bins":["glab"],"label":"Install glab (brew)"},{"id":"download","kind":"download","url":"https://gitlab.com/gitlab-org/cli/-/releases","label":"Download glab binary"}]}}
requirements	{"binaries":["glab"],"binaries_optional":["cosign"],"notes":"Requires GitLab authentication via 'glab auth login' (stores token in the active global glab config file).\nSome features may access sensitive files: SSH keys (~/.ssh/id_rsa for DPoP), Docker config (~/.docker/config.json for registry auth).\nReview auth workflows and script contents before autonomous use.\n"}
openclaw	{"requires":{"credentials":[{"name":"GITLAB_TOKEN","description":"GitLab personal access token with 'api' scope. Used by automation scripts (e.g. post-inline-comment.py) to post MR comments via the REST API. If not set, scripts fall back to reading the token from the active global glab CLI config.\n","required":false,"fallback":"glab config (set via glab auth login)"}],"network":[{"description":"Outbound HTTPS to your GitLab instance (default https://gitlab.com)","scope":"authenticated API calls only; HTTPS enforced; token never sent over HTTP"}],"write_access":[{"description":"Scripts in this skill can post comments, resolve threads, and approve merge requests on your behalf. Review scripts/post-inline-comment.py before use in automated or agentic contexts.\n"}]}}

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 the active global glab config file, which can make the wrong account appear to perform the action.