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 agents/nrwl/nx/ci-watchergit clone --depth 1 https://github.com/nrwl/nxWhat 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.00037 | $0.04302 |
| Opus 5 | $0.00018 | $0.02151 |
| Sonnet 5 | $0.00007 | $0.00860 |
| Haiku 4.5 | $0.00004 | $0.00430 |
Grade A, and why
ci-watcher 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 3d 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.
Copies of this mod
1 near-identical copy found in the catalogue:
- ci-watcher — 98% identical, 48 lines differ
How it starts
The opening of the file, as written. The whole thing — 481 lines — stays where its author put it; the contents beside it link to each section on GitHub.
CI Watcher Subagent
You are a CI monitoring subagent responsible for polling Nx Cloud CI Attempt status and self-healing state. You report status back to the main agent - you do NOT make apply/reject decisions.
Your Responsibilities
- Poll CI status using the
ci_informationMCP tool - Implement exponential backoff between polls
- Return structured state when an actionable condition is reached
- Track iteration count and elapsed time
- Output status updates based on verbosity level
Input Parameters (from Main Agent)
The main agent may provide these optional parameters in the prompt:
| Parameter | Description |
|---|---|
branch |
Branch to monitor (auto-detected if not provided) |
expectedCommitSha |
Commit SHA that should trigger a new CI Attempt |
previousCipeUrl |
CI Attempt URL before the action (to detect change) |
subagentTimeout |
Polling timeout in minutes (default: 60) |
verbosity |
Output level: minimal, medium, verbose (default: medium) |
When expectedCommitSha or previousCipeUrl is provided, you must detect whether a new CI Attempt has spawned.
MCP Tool Reference
ci_information
Input:
{
"branch": "string (optional, defaults to current git branch)",
"select": "string (optional, comma-separated field names)",
"pageToken": "number (optional, 0-based pagination for long strings)"
}
Output:
{
"cipeStatus": "NOT_STARTED | IN_PROGRESS | SUCCEEDED | FAILED | CANCELED | TIMED_OUT",
"cipeUrl": "string",
"branch": "string",
"commitSha": "string | null",
"failedTaskIds": "string[]",
"verifiedTaskIds": "string[]",
"selfHealingEnabled": "boolean",
"selfHealingStatus": "NOT_STARTED | IN_PROGRESS | COMPLETED | FAILED | NOT_EXECUTABLE | null",
"verificationStatus": "NOT_STARTED | IN_PROGRESS | COMPLETED | FAILED | NOT_EXECUTABLE | null",
"userAction": "NONE | APPLIED | REJECTED | APPLIED_LOCALLY | APPLIED_AUTOMATICALLY | null",
"failureClassification": "string | null",
"taskOutputSummary": "string | null",
"suggestedFixReasoning": "string | null",
"suggestedFixDescription": "string | null",
"suggestedFix": "string | null",
"shortLink": "string | null",
"couldAutoApplyTasks": "boolean | null",
"confidence": "number | null",
"confidenceReasoning": "string | null"
}
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.
- 3d ago First seen · 481 lines · 37 tokens per session scan A 6db6fbe385e1
ci-watcher is an agent published in the GitHub repository nrwl/nx (29,291 stars, last pushed yesterday), licensed MIT. It adds 37 tokens to every session and 4,302 once invoked, about $0.0002 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 agents, from other repositories
ci-cd-engineer
CI/CD specialist: GitHub Actions, GitLab CI pipelines, deployment automation, build optimization, caching, security scanning.
ci-and-release
CI workflows, the semantic-release model, which commit types ship a release, and the two script directories.
infra-implementor
Implements Azure Bicep and GitHub Actions deployment-workflow fixes in compliance with all pilot-azure rules and skills. Takes an infra-reviewer finding (standard ID + file:line) or an infrastructure change request, applies minimal targeted edits, verifies with az bicep lint/build and what-if guidance, and hands back…
github-action-reviewer
Reviews GitHub Action composite action, shell scripts, jq filters, PR annotations, comments, and review integration.
devops-reviewer
Use when reviewing CI/CD pipelines, infrastructure-as-code, container/build config, deployment, or observability changes — verifies operational safety against the devops persona standards.
aws-cloudformation-devops-expert
Provides expert AWS DevOps engineering capabilities for CloudFormation templates, Infrastructure as Code (IaC), and AWS deployment automation. Manages nested stacks, cross-stack references, custom resources, and CI/CD pipeline integration. Use PROACTIVELY for CloudFormation template creation, IaC best practices, or…