agentsclimarketplace

Glab cli

Skill danielsitek/skills/skills/glab-cli

My personal directory of skills

Install
npx -y skills add danielsitek/skills --skill glab-cli

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when running any glab (GitLab CLI) command in an agent session: creating a merge request, accepting or merging an MR, triggering or tracing CI pipelines, managing pipeline schedules, or handling interactive prompts glab raises at runtime. All patterns are non-interactive.

SKILL.md

8.9 KB, ~2.3k tokens by cl100k_base, as published. Nobody here has run it

glab CLI — Agent Guide

The central virtue is non-interactive: always pass all required values as flags so glab never prompts. The nuclear option: set GLAB_NO_PROMPT=1 in the environment to suppress every prompt globally.

The same virtue applies to reading: several read commands default to an interactive/live view or open a pager, which stalls an agent. For any command that reports state (ci status, ci list, mr view, mr list), request machine output with -F json and filter with --jq — this never pages and is directly parseable. Avoid the bare interactive forms.


Creating a Merge Request

glab mr create \
  --title "feat: short imperative description" \
  --description "Full description of the change." \
  --target-branch main \
  --yes

Completion criterion: glab prints an MR URL in stdout — e.g. https://gitlab.com/org/repo/-/merge_requests/42.

Useful optional flags

FlagEffect
--draftOpen as draft / WIP
--label "bugfix,backend"Attach labels
--assignee usernameAssign to a user
--reviewer usernameRequest review
--remove-source-branchDelete branch on merge
--milestone "Sprint 10"Attach milestone
--pushPush current commits before creating MR

--fill mode (auto-title from commits)

--fill derives title and description from commit history. It is mutually exclusive with --title and --description:

# ✅ non-interactive with explicit title
glab mr create --title "fix: login timeout" --yes

# ✅ non-interactive with commit-derived title
glab mr create --fill --yes

# ❌ invalid — glab ignores --title when --fill is set
glab mr create --fill --title "fix: login timeout" --yes

Accepting / Merging a Merge Request

glab mr merge and glab mr accept are aliases — use either.

# Merge immediately (skip pipeline wait)
glab mr merge 42 --yes --auto-merge=false

# Merge when all checks pass (auto-merge, default when pipeline is running)
glab mr merge 42 --yes

# Squash commits on merge
glab mr merge 42 --squash --yes

# Rebase before merge
glab mr merge 42 --rebase --yes

# Remove source branch on merge
glab mr merge 42 --remove-source-branch --yes

Note: When a pipeline is running, --auto-merge is true by default — glab waits for checks to pass before merging. Pass --auto-merge=false to merge immediately regardless of pipeline state.

Race condition: a just-created pipeline can lag in GitLab's bookkeeping, so glab mr merge --yes may print No pipeline running on <branch> and merge immediately without waiting. Before merging, confirm the pipeline is actually registered: glab ci list -F json --jq '.[0].status'.

Waiting for a pipeline before merge? Don't poll. Never sleep + poll ci status — foreground sleep is blocked in agent harnesses, and it is redundant: glab mr merge <id> --yes is the wait. With auto-merge it blocks until the pipeline passes, then merges — and merges nothing if the pipeline fails. So "create → wait for pipeline → approve → merge" collapses to:

glab mr approve 42
glab mr merge 42 --yes --remove-source-branch

Note: --squash has no local default — unlike --auto-merge, glab only sends a squash value when you pass the flag. Omitting it hands the decision to the GitLab project's "Squash commits when merging" setting, so be explicit when the outcome matters:

FlagResult
(omitted)GitLab project setting decides
--squashforce squash
--squash=falseforce no-squash

Common MR Operations

# List open MRs
glab mr list

# View an MR (current branch or by ID)
glab mr view
glab mr view 42

# Approve
glab mr approve 42

# Update title / labels
glab mr update 42 --title "fix: corrected title"
glab mr update 42 --label "reviewed" --unlabel "wip"

# Update description — multiline works via normal bash quoting
glab mr update 42 --description "Full multiline
description here."
# ⚠ Never pass --description "-": it opens an editor and stalls the agent.

# Mark as ready (remove draft)
glab mr update 42 --ready

# Close without merging
glab mr close 42

CI Pipeline Operations

# Pipeline status for current branch — JSON is the only agent-safe form.
# ⚠ Bare `glab ci status` runs a live/interactive view; `--compact` is a human
#   view that can still invoke the pager. In an agent, always use -F json.
glab ci status -F json --jq '.status'   # scriptable: one status string

# List recent pipelines (latest first). `ci list` has no --branch filter;
# use --scope to narrow. Request JSON to avoid the pager.
glab ci list -F json --jq '.[0].status'   # status of the most recent pipeline
glab ci list --scope running

# Stream a job log in real time (blocks until job finishes)
glab ci trace <job-name>

# Retry a failed job
glab ci retry <job-name>

# Trigger a manual job
glab ci trigger <job-name>

# Create a new pipeline for current branch
glab ci run

# Lint the .gitlab-ci.yml
glab ci lint

glab api has no --jq flag (unlike mr view/ci status/ci list) — pipe its output to jq instead: glab api projects/:id/pipelines/:id | jq -r '.status'.


Schedule Operations

# List all schedules — note the numeric IDs, required for all other commands
glab schedule list

# Create a schedule (--cron, --description, --ref required; timezone defaults to UTC).
# --variable sets pipeline (CI/CD) variables passed to the run — not shell env vars.
glab schedule create \
  --description "Nightly scan" \
  --cron "0 2 * * *" \
  --ref main \
  --cronTimeZone "Europe/Prague" \
  --variable "ENV:production" \
  --variable "NOTIFY:true"

# Trigger a schedule immediately (one-off run, does not affect the cron)
glab schedule run <id>

# Update — only specified fields are changed
glab schedule update <id> --cron "0 4 * * *"
glab schedule update <id> --description "Updated label" --ref develop
glab schedule update <id> --active=false   # pause schedule
glab schedule update <id> --active=true    # resume schedule

# Update pipeline variables on an existing schedule
glab schedule update <id> \
  --create-variable "NEW_KEY:value" \
  --update-variable "EXISTING_KEY:new-value" \
  --delete-variable "OLD_KEY"

# Delete a schedule permanently (pipelines already run are not affected)
glab schedule delete <id>

# All schedule commands accept -R owner/repo to target another project
glab schedule list -R owner/repo

Handling Interactive Prompts

Even with --yes, glab occasionally prompts (e.g. target branch selection when the remote has no default). The fix is prevention, not answering prompts — the agent should never end up at a live glab prompt.

Prevention (do this every time): set GLAB_NO_PROMPT=1 and pass every required value as a flag. This suppresses all prompts globally, so the command either succeeds or fails fast instead of blocking.

GLAB_NO_PROMPT=1 glab mr create \
  --title "..." --description "..." --target-branch main --yes

If a command still stalls, it means a required value was missing — read the error/prompt text, re-run with the corresponding flag added. The common culprits and the flag that removes each prompt:

Prompt you seeMissing flag to add
Target branch [main]:--target-branch main
Title:--title "..."
Description (optional):--description "..."
editor opens (vi/nano)--no-editor (and pass --description)

Last resort — answering a live prompt. Only if prevention is somehow impossible: run the command as a background/non-blocking process, read its output to see the prompt, then write the single answer to that same process's stdin — one answer per prompt, waiting for the next prompt before sending the next answer. Use whatever background-process + stdin mechanism your harness provides; there is no glab-specific API for this.

Self-Review — mandatory, run unprompted

The moment a glab command misbehaves — needed a retry or extra flag, hit a prompt / pager / interactive view, blocked, errored, or acted differently than documented here — treat that as part of the task, not a footnote. Do not wait for the user to ask "how did the skill go?".

Before reporting the task done, do this yourself, once, without being asked: if nothing misbehaved, skip silently. Otherwise write a few lines: Worked (first try), Didn't (+ root cause), Fix (one concrete change — name the section, command, or flag) — then propose the SKILL.md edit as part of your normal task wrap-up. Don't apply it silently.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.