Help us improve
Share bugs, ideas, or general feedback.
From gitlab
Investigates GitLab CI pipeline failures by identifying failed jobs, extracting error logs via glab, and providing concise diagnostic summaries. Useful for status checks, job debugging, or post-push monitoring.
npx claudepluginhub bendrucker/claude --plugin gitlabHow this skill is triggered — by the user, by Claude, or both
Slash command
/gitlab:ci-monitorhaikuThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Investigate GitLab CI pipeline failures and extract diagnostic information. Extract only: find the failures and present them concisely. Do not analyze root causes or suggest fixes.
Manages GitLab CI/CD pipelines and jobs using glab ci: lists pipelines, validates .gitlab-ci.yml, views status, traces/retires jobs. Useful for debugging failures and config validation.
Monitors running CI builds on GitHub Actions and CircleCI via polling, reports completion status, and diagnoses failures by fetching logs, job summaries, and artifacts.
Monitors GitHub Actions workflow runs, identifies failing jobs, extracts error logs, and summarizes diagnostics. Useful for checking CI status after pushes or investigating failures.
Share bugs, ideas, or general feedback.
Investigate GitLab CI pipeline failures and extract diagnostic information. Extract only: find the failures and present them concisely. Do not analyze root causes or suggest fixes.
$ARGUMENTS
If no pipeline ID or MR is specified, use the current branch.
!glab ci status 2>/dev/null || echo "no pipeline"
From the pipeline status above, identify the relevant pipeline. If still running, use glab ci status --wait to wait for completion.
Query the MR to get the source branch SHA: glab api projects/:id/merge_requests/:iid and read the sha field. Report this as "Source SHA" in the output. The sha field reflects the branch tip, not the pipeline SHA (which may be a synthetic merge commit from refs/merge-requests/N/merge).
glab ci get --output json | jq '[.jobs[] | select(.status == "failed") | {name, id, stage, status}]'
If glab ci get is unavailable, use glab ci list to find the pipeline ID and glab api projects/:id/pipelines/<pipeline-id>/jobs for job details.
For each failing job, fetch its log:
glab ci trace <job-id>
Parse the log output for failure-relevant sections. See references/log-parsing.md for CI-specific log structure.
When multiple jobs fail, fetch logs for each job in separate parallel Bash calls.
For each failed job, report:
Keep the total output concise. The parent conversation will use this to investigate.