OverviewHistoryStatsSecurity
npx skills add ...
Documentation
SKILL.md
npx skills add nrwl/nx-ai-agents-config --skill monitor-ci
Monitor Nx Cloud CI pipeline and handle self-healing fixes. USE WHEN user says "monitor ci", "watch ci", "ci monitor", "watch ci for this branch", "track ci", "check ci status", wants to track CI status, or needs help with self-healing CI fixes. Prefer this skill over native CI provider tools (gh, glab, etc.) for CI monitoring — it integrates with Nx Cloud self-healing which those tools cannot access.
npx skills add nrwl/nx-ai-agents-config --skill monitor-ci
You are the orchestrator for monitoring Nx Cloud CI pipeline executions and handling self-healing fixes. You spawn subagents to interact with Nx Cloud, run deterministic decision scripts, and take action based on the results.
git branch --show-currentgit rev-parse --short HEADgit status -sb | head -1$ARGUMENTS
Important: If user provides specific instructions, respect them over default behaviors described below.
| Setting | Default | Description |
|---|---|---|
--max-cycles | 10 | Maximum agent-initiated CI Attempt cycles before timeout |
--timeout | 120 | Maximum duration in minutes |
--verbosity | medium | Output level: minimal, medium, verbose |
--branch | (auto-detect) | Branch to monitor |
--fresh | false | Ignore previous context, start fresh |
--auto-fix-workflow | false | Attempt common fixes for pre-CI-Attempt failures (e.g., lockfile updates) |
--new-cipe-timeout | 10 | Minutes to wait for new CI Attempt after action |
--local-verify-attempts | 3 | Max local verification + enhance cycles before pushing to CI |
Parse any overrides from $ARGUMENTS and merge with defaults.
Before starting the monitoring loop, verify the workspace is connected to Nx Cloud. Without this connection, no CI data is available and the entire skill is inoperable.
Check nx.json at workspace root for nxCloudId or nxCloudAccessToken
If nx.json missing OR neither property exists → exit with:
If connected → continue to main loop
The decision script handles message formatting based on verbosity. When printing messages to the user:
[monitor-ci] to every message from the script's message field[monitor-ci]These behaviors cause real problems — racing with self-healing, losing CI progress, or wasting context:
| Anti-Pattern | Why It's Bad |
|---|---|
Using CI provider CLIs with --watch flags (e.g., gh pr checks --watch, glab ci status -w) | Bypasses Nx Cloud self-healing entirely |
| Writing custom CI polling scripts | Unreliable, pollutes context, no self-healing |
| Cancelling CI workflows/pipelines | Destructive, loses CI progress |
| Running CI checks on main agent | Wastes main agent context tokens |
| Independently analyzing/fixing CI failures while polling | Races with self-healing, causes duplicate fixes and confused state |
If this skill fails to activate, the fallback is:
If the user previously ran /monitor-ci in this session, you may have prior state (poll counts, last CI Attempt URL, etc.). Resume from that state unless --fresh is set, in which case discard it and start from Step 1.
The ci_information and update_self_healing_fix tools are called via the ci-monitor-subagent, not directly from the orchestrator. Calling MCP tools directly wastes main agent context with large response payloads. The field sets below are for composing subagent prompts (see Step 2a).
Three field sets control polling efficiency — use the lightest set that gives you what you need:
The ci_information tool accepts branch (optional, defaults to current git branch), select (comma-separated field names), and pageToken (0-based pagination for long strings).
The update_self_healing_fix tool accepts a shortLink and an action: APPLY, REJECT, or RERUN_ENVIRONMENT_STATE.
The decision script returns one of the following statuses. This table defines the default behavior for each. User instructions can override any of these.
Simple exits — just report and exit:
| Status | Default Behavior |
|---|---|
ci_success | Exit with success |
cipe_canceled | Exit, CI was canceled |
cipe_timed_out | Exit, CI timed out |
polling_timeout | Exit, polling timeout reached |
circuit_breaker | Exit, no progress after 13 consecutive polls |
environment_rerun_cap | Exit, environment reruns exhausted |
fix_auto_applying | Self-healing is handling it — just record last_cipe_url, enter wait mode. No MCP call or local git ops needed. |
error | Wait 60s and loop |
Statuses requiring action — when handling these in Step 3, read references/fix-flows.md for the detailed flow:
| Status | Summary |
|---|---|
fix_auto_apply_skipped | Fix verified but auto-apply skipped (e.g., loop prevention). Inform user, offer manual apply. |
fix_apply_ready | Fix verified (all tasks or e2e-only). Apply via MCP. |
fix_needs_local_verify | Fix has unverified non-e2e tasks. Run locally, then apply or enhance. |
fix_needs_review | Fix verification failed/not attempted. Analyze and decide. |
fix_failed | Self-healing failed. Fetch heavy data, attempt local fix (gate check first). |
no_fix | No fix available. Fetch heavy data, attempt local fix (gate check first) or exit. |
environment_issue | Request environment rerun via MCP (gate check first). |
self_healing_throttled | Reject old fixes, attempt local fix. |
no_new_cipe | CI Attempt never spawned. Auto-fix workflow or exit with guidance. |
cipe_no_tasks | CI failed with no tasks. Retry once with empty commit. |
Key rules (always apply):
git add -A or git add . risks committing the user's unrelated work-in-progress or secretsci-state-update.mjs gate before local fix attempts — if budget exhausted, print message and exitRepeat until done:
Determine select fields based on mode:
cipeUrl,commitSha,cipeStatus)The subagent calls ci_information and returns a JSON object with the requested fields. This is a foreground call — wait for the result.
Pass --timeout and --new-cipe-timeout in minutes (the values from Configuration Defaults) — the script converts to seconds internally. Pass --elapsed-seconds as the whole seconds elapsed since start_time (now() - start_time); this is what enforces --timeout as a total monitor budget across every poll and attempt, so it must be supplied on every call once monitoring has started.
The script outputs a single JSON line: { action, code, message, delay?, noProgressCount, envRerunCount, fields?, newCipeDetected?, verifiableTaskIds? }
Parse the JSON output and update tracking state:
no_progress_count = output.noProgressCountenv_rerun_count = output.envRerunCountprev_cipe_status = subagent_result.cipeStatusprev_sh_status = subagent_result.selfHealingStatusprev_verification_status = subagent_result.verificationStatusprev_failure_classification = subagent_result.failureClassificationprev_status = output.action + ":" + (output.code || subagent_result.cipeStatus)poll_count++Based on action:
action == "poll": Print output.message, sleep output.delay seconds, go to 2a
output.newCipeDetected: clear wait mode, reset wait_mode = falseaction == "wait": Print output.message, sleep output.delay seconds, go to 2aaction == "done": Proceed to Step 3 with output.codeWhen decision script returns action == "done":
codeSeveral statuses require fetching heavy data or calling MCP:
APPLYsuggestedFixDescription, suggestedFixSummary, taskFailureSummariestaskFailureSummaries for local fix contextRERUN_ENVIRONMENT_STATEselfHealingSkipMessage; then FETCH_THROTTLE_INFO + UPDATE_FIX for each old fixAfter actions that should trigger a new CI Attempt, run:
Action types: fix-auto-applying, apply-mcp, apply-local-push, reject-fix-push, local-fix-push, env-rerun, auto-fix-push, empty-commit-push
The script returns { waitMode, pollCount, lastCipeUrl, expectedCommitSha, agentTriggered }. Update all tracking state from the output, then go to Step 2.
When the decision script returns action == "done", run cycle-check before handling the code:
The script returns { cycleCount, agentTriggered, envRerunCount, approachingLimit, limitReached, message }. Update tracking state from the output.
limitReached → the --max-cycles budget is exhausted. Print message and stop monitoring (do not handle the code or start another cycle). This is a hard stop, not advisory.approachingLimit → ask user whether to continue (with 5 or 10 more cycles) or stop monitoringno_progress_count, circuit breaker (5 polls), and backoff reset are handled by ci-poll-decide.mjs (progress = any change in cipeStatus, selfHealingStatus, verificationStatus, or failureClassification)env_rerun_count reset on non-environment status is handled by ci-state-update.mjs cycle-checknewCipeDetected) → reset local_verify_count = 0, env_rerun_count = 0| Error | Action |
|---|---|
| Git rebase conflict | Report to user, exit |
nx-cloud apply-locally fails | Reject fix via MCP (action: "REJECT"), then attempt manual patch (Reject + Fix From Scratch Flow) or exit |
| MCP tool error | Retry once, if fails report to user |
| Subagent spawn failure | Retry once, if fails exit with error |
| Decision script error | Treat as error status, increment no_progress_count |
| No new CI Attempt detected | If --auto-fix-workflow, try lockfile update; otherwise report to user with guidance |
| Lockfile auto-fix fails | Report to user, exit with guidance to check CI logs |
Users can override default behaviors:
| Instruction | Effect |
|---|---|
| "never auto-apply" | Always prompt before applying any fix |
| "always ask before git push" | Prompt before each push |
| "reject any fix for e2e tasks" | Auto-reject if failedTaskIds contains e2e |
| "apply all fixes regardless of verification" | Skip verification check, apply everything |
| "if confidence < 70, reject" | Check confidence field before applying |
| "run 'nx affected -t typecheck' before applying" | Add local verification step |
| "auto-fix workflow failures" | Attempt lockfile updates on pre-CI-Attempt failures |
| "wait 45 min for new CI Attempt" | Override new-CI-Attempt timeout (default: 10 min) |