Gitlab Cli Skills
Route agent terminal work through `glab` for MRs, issues, releases, repos, auth, and CI/CD without memorizing GitLab’s full CLI surface.
Overview
gitlab-cli-skills is an agent skill most often used in Ship (also Build, Operate) that maps GitLab terminal work to `glab` workflows across auth, MRs, issues, CI/CD, and releases.
Install
npx skills add https://github.com/vince-winkintel/gitlab-cli-skills --skill gitlab-cli-skillsWhat is this skill?
- Comprehensive `glab` command reference with routes to 30+ specialized sub-skills
- Covers auth login, MR/issue management, CI/CD pipelines, releases, and repo operations
- Documents brew and binary install paths plus optional cosign-related tooling
- Flags sensitive paths: `~/.config/glab-cli`, SSH keys, Docker registry config for review
- Triggers on glab, GitLab CLI, GitLab automation, and terminal GitLab operations
- 30+ specialized glab sub-skill routes
Adoption & trust: 1k installs on skills.sh; 32 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You know GitLab has a CLI but waste agent turns guessing `glab` subcommands for MRs, pipelines, and releases.
Who is it for?
Indie teams on GitLab SaaS or self-managed who want MR and pipeline automation from the same agent session as coding.
Skip if: GitHub-only repos, builders who refuse terminal PAT auth, or workflows that must stay entirely in the GitLab web UI for compliance.
When should I use this skill?
User mentions GitLab CLI, glab commands, GitLab automation, MR/issue management via CLI, CI/CD pipeline commands, repo operations, or GitLab terminal operations.
What do I get? / Deliverables
The agent picks the correct glab workflow—auth, MR, issue, CI, or repo—and runs documented commands instead of improvised curl or web-only steps.
- Correct glab command sequences for the requested GitLab operation
- Authenticated CLI session usable for MR/issue/CI tasks
- Pointers to the matching specialized sub-skill workflow when applicable
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Merge requests, pipeline commands, and release automation are where solo builders feel GitLab friction right before and after shipping code. MR and issue workflows via CLI map directly to code review and ship readiness—not greenfield UI coding.
Where it fits
Clone, remote, and scaffold GitLab repo settings before feature work starts.
Open, update, or comment on an MR from the agent without leaving the terminal.
Trigger or inspect CI/CD pipelines ahead of a tagged release.
Pull job logs and pipeline status when production deploy fails overnight.
How it compares
Structured glab command router—not GitHub’s `gh` skill pack and not a hosted GitLab MCP replacement.
Common Questions / FAQ
Who is gitlab-cli-skills for?
Solo and small-team builders using GitLab who want agents to drive `glab` for MRs, issues, CI/CD, releases, and repo tasks from the terminal.
When should I use gitlab-cli-skills?
During Ship for MR review and pipeline commands, during Build for repo bootstrap and integrations, and during Operate when inspecting failed jobs—whenever you mention glab or GitLab CLI.
Is gitlab-cli-skills safe to install?
It may reference tokens, SSH keys, and Docker config; review the Security Audits panel on this Prism page, scope PATs minimally, and inspect automation scripts before autonomous use.
SKILL.md
READMESKILL.md - Gitlab Cli Skills
# GitLab CLI Skills Comprehensive GitLab CLI (glab) command reference and workflows. ## Quick start ```bash # 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`: ```bash unset GITLAB_TOKEN GITLAB_ACCESS_TOKEN OAUTH_TOKEN GITLAB_HOST set -a source ~/.config/openclaw/env/gitlab-<actor>.env set +a ``` P