Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/fprochazka/claude-code-plugins/pipelinegit clone --depth 1 https://github.com/fprochazka/claude-code-pluginsWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00009 | $0.00509 |
| Opus 5 | $0.00005 | $0.00254 |
| Sonnet 5 | $0.00002 | $0.00102 |
| Haiku 4.5 | $0.00001 | $0.00051 |
Grade A, and why
pipeline scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
What it actually says
Context
${CLAUDE_PLUGIN_ROOT}/scripts/fetch-mr-state.sh --pipeline
Your task
Analyze the MR pipeline state above, no implementation yet. Help triage any issues by analyzing the logs of any failed jobs and looking up the context and proposing fixes. If all jobs passed, report the pipeline status and note that no action is needed.
Reading the pipeline dump
The script already ran glab-pipeline inspect for you. Read the dump in this order and stop as soon as you have the cause:
- The pipeline summary file printed above — it names each failed job, its stage, and its failure reason, and it points at the file that explains it. Read it first, never the raw dump directory.
job-logs/<failed-job>.logfor a script or runtime failure — the tail carries the error. Read only the logs the summary names. Do not read the logs of jobs that passed.test-report.jsonfor a test failure — it holds per-test results, which beats grepping a long trace.lint.jsonandmerged.ymlfor a YAML,needs, or config error — they show what GitLab actually parsed.downstream/<bridge>-<id>.jsonfor a failed child pipeline, then recurse withglab-pipeline inspect --pipeline-id <id>.
summary.json in the same directory holds the same summary as structured data. Use it when you want to filter with jq instead of reading prose.
Running glab-pipeline yourself
Invoke the glab-pipeline skill before you run the CLI directly. Run it again when the dump is stale or incomplete:
- After a retry or a new push, to inspect the new pipeline.
- With
--with-merged-ci-configwhen aninclude:resolves differently on the source branch. - With
--with-test-reportwhen a test job failed but the report is missing.
Use glab ci retry <job-name> to retry a job. glab-pipeline inspects only, so it has no retry of its own.
$ARGUMENTS
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 41 lines · 9 tokens per session scan A 8a5a9508ce3e
pipeline is a command published in the GitHub repository fprochazka/claude-code-plugins (11 stars, last pushed 4d ago), licensed MIT. It adds 9 tokens to every session and 509 once invoked, about $0.0000 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other commands, from other repositories
monitor-ci
Monitors pull request CI checks until they are resolved (pass or fail).
monitor-ci
You are the orchestrator for monitoring Nx Cloud CI pipeline executions and handling self-healing fixes. You spawn the ci-monitor-subagent subagent to poll CI status and make decisions based on the results.
actions
Command "actions" from openclaw/crabbox, covering actions, subcommands, hydrate, register and dispatch.
ci-report
Generate a CI failure report for PR $PRNUMORURL (or current branch if no argument given).
check-release-health
Summarize the CI health of an OpenShift release using live data from the openshift-ci-mcp server.
ci-health
Check all GitHub Actions workflows for failures, create P0 tickets, gate each ticket, and auto-fix safe failures.