Coding-agent skills for pull-request work and orchestration: an adversarial multi-pass PR reviewer, PR description and title writing, answering review comments, CI failure triage and PR nursing, a DAG orchestrator that delegates to cheaper subagents, and file-channel coordination between agents. Supports GitHub and GitLab.
95%
Does it follow best practices?
Impact
98%
1.88xAverage score across 10 eval scenarios
Low
Low-risk findings worth noting
Platform-specific commands for investigating CI failures on GitLab CI/CD using glab.
The repository uses GitLab CI if .gitlab-ci.yml (or .gitlab/ci/*.yml referenced from it) exists at the repo root.
glabglab api does not support a --jq flag. Pipe to jq in the shell instead.:fullpath as the project identifier — glab auto-fills it from the current Git remote (e.g. glab api projects/:fullpath/...).glab ci ≡ glab pipe ≡ glab pipeline. The -O, --output json flag is incompatible with --live/--compact.glab mr view --output json
glab ci status --branch <head-branch> --output jsonThe glab mr view JSON includes head_pipeline (when present) — its id and status are useful shortcuts.
glab api projects/:fullpath/pipelines/<pipeline-id>/jobs \
| jq '[.[] | select(.status == "failed") | {id, name, stage}]'glab has no --log-failed shorthand. Trace each failing job by id (or name):
glab ci trace <job-id>Use the run count N from the skill (default: 10) as the --per-page value. To find pipelines on branches other than the current one, list and filter with jq:
glab ci list --per-page <N> --output json \
| jq '[.[] | select(.status != "running" and .status != "pending" and .ref != "<current-branch>")] | .[0:5]'To pre-filter by status (e.g., only failed pipelines):
glab ci list --status failed --per-page <N> --output jsonAvailable statuses: running, pending, success, failed, canceled, skipped, created, manual, scheduled.
glab api projects/:fullpath/pipelines/<pipeline-id>/jobs \
| jq '[.[] | select(.name | test("<failing-job-pattern>")) | {id, name, status}]'glab mr diff --raw