Automates CI monitoring and handles self-healing for Nx Cloud pipelines.

Install

mkdir -p .claude/skills/monitor-ci-ever-co && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/10640" && unzip -o skill.zip -d .claude/skills/monitor-ci-ever-co && rm skill.zip

Installs to .claude/skills/monitor-ci-ever-co

Activation

This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.

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.
404 chars✓ has a “when” triggerlonger than Claude Code's old 250-char listing cap (fine on current versions)
Advanced

Key capabilities

  • Monitor Nx Cloud CI pipeline
  • Handle self-healing CI fixes
  • Track build status across branches
  • Orchestrate subagent CI interactions

How it works

The skill orchestrates CI monitoring by spawning subagents to interact with Nx Cloud, running deterministic decision scripts, and applying self-healing fixes.

Inputs & outputs

You give it
CI monitoring request
You get back
CI status updates and automated fixes

When to use monitor-ci

  • Monitoring CI build status
  • Automating CI error resolution
  • Tracking build failures
  • Running self-healing CI tasks

About this skill

Monitor CI Command

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.

Context

  • Current Branch: !git branch --show-current
  • Current Commit: !git rev-parse --short HEAD
  • Remote Status: !git status -sb | head -1

User Instructions

$ARGUMENTS

Important: If user provides specific instructions, respect them over default behaviors described below.

Configuration Defaults

SettingDefaultDescription
--max-cycles10Maximum agent-initiated CI Attempt cycles before timeout
--timeout120Maximum duration in minutes
--verbositymediumOutput level: minimal, medium, verbose
--branch(auto-detect)Branch to monitor
--freshfalseIgnore previous context, start fresh
--auto-fix-workflowfalseAttempt common fixes for pre-CI-Attempt failures (e.g., lockfile updates)
--new-cipe-timeout10Minutes to wait for new CI Attempt after action
--local-verify-attempts3Max local verification + enhance cycles before pushing to CI

Parse any overrides from $ARGUMENTS and merge with defaults.

Nx Cloud Connection Check

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.

Step 0: Verify Nx Cloud Connection

  1. Check nx.json at workspace root for nxCloudId or nxCloudAccessToken

  2. If nx.json missing OR neither property exists → exit with:

    Nx Cloud not connected. Unlock 70% faster CI and auto-fix broken PRs with https://nx.dev/nx-cloud
    
  3. If connected → continue to main loop

Architecture Overview

  1. This skill (orchestrator): spawns subagents, runs scripts, prints status, does local coding work
  2. ci-monitor-subagent (haiku): calls one MCP tool (ci_information or update_self_healing_fix), returns structured result, exits
  3. ci-poll-decide.mjs (deterministic script): takes ci_information result + state, returns action + status message
  4. ci-state-update.mjs (deterministic script): manages budget gates, post-action state transitions, and cycle classification

Status Reporting

The decision script handles message formatting based on verbosity. When printing messages to the user:

  • Prepend [monitor-ci] to every message from the script's message field
  • For your own action messages (e.g. "Applying fix via MCP..."), also prepend [monitor-ci]

Anti-Patterns

These behaviors cause real problems — racing with self-healing, losing CI progress, or wasting context:

Anti-PatternWhy 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 scriptsUnreliable, pollutes context, no self-healing
Cancelling CI workflows/pipelinesDestructive, loses CI progress
Running CI checks on main agentWastes main agent context tokens
Independently analyzing/fixing CI failures while pollingRaces with self-healing, causes duplicate fixes and confused state

If this skill fails to activate, the fallback is:

  1. Use CI provider CLI for a one-time, read-only status check (single call, no watch/polling flags)
  2. Immediately delegate to this skill with gathered context
  3. Do not continue polling on main agent — it wastes context tokens and bypasses self-healing

Session Context Behavior

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.

MCP Tool Reference

Three field sets control polling efficiency — use the lightest set that gives you what you need:

WAIT_FIELDS: 'cipeUrl,commitSha,cipeStatus'
LIGHT_FIELDS: 'cipeStatus,cipeUrl,branch,commitSha,selfHealingStatus,verificationStatus,userAction,failedTaskIds,verifiedTaskIds,selfHealingEnabled,failureClassification,couldAutoApplyTasks,autoApplySkipped,autoApplySkipReason,shortLink,confidence,confidenceReasoning,hints,selfHealingSkippedReason,selfHealingSkipMessage'
HEAVY_FIELDS: 'taskOutputSummary,suggestedFix,suggestedFixReasoning,suggestedFixDescription'

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.

Default Behaviors by Status

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:

StatusDefault Behavior
ci_successExit with success
cipe_canceledExit, CI was canceled
cipe_timed_outExit, CI timed out
polling_timeoutExit, polling timeout reached
circuit_breakerExit, no progress after 5 consecutive polls
environment_rerun_capExit, environment reruns exhausted
fix_auto_applyingSelf-healing is handling it — just record last_cipe_url, enter wait mode. No MCP call or local git ops needed.
errorWait 60s and loop

Statuses requiring action — when handling these in Step 3, read references/fix-flows.md for the detailed flow:

StatusSummary
fix_auto_apply_skippedFix verified but auto-apply skipped (e.g., loop prevention). Inform user, offer manual apply.
fix_apply_readyFix verified (all tasks or e2e-only). Apply via MCP.
fix_needs_local_verifyFix has unverified non-e2e tasks. Run locally, then apply or enhance.
fix_needs_reviewFix verification failed/not attempted. Analyze and decide.
fix_failedSelf-healing failed. Fetch heavy data, attempt local fix (gate check first).
no_fixNo fix available. Fetch heavy data, attempt local fix (gate check first) or exit.
environment_issueRequest environment rerun via MCP (gate check first).
self_healing_throttledReject old fixes, attempt local fix.
no_new_cipeCI Attempt never spawned. Auto-fix workflow or exit with guidance.
cipe_no_tasksCI failed with no tasks. Retry once with empty commit.

Key rules (always apply):

  • Git safety: Stage specific files by name — git add -A or git add . risks committing the user's unrelated work-in-progress or secrets
  • Environment failures (OOM, command not found, permission denied): bail immediately. These aren't code bugs, so spending local-fix budget on them is wasteful
  • Gate check: Run ci-state-update.mjs gate before local fix attempts — if budget exhausted, print message and exit

Main Loop

Step 1: Initialize Tracking

cycle_count = 0            # Only incremented for agent-initiated cycles (counted against --max-cycles)
start_time = now()
no_progress_count = 0
local_verify_count = 0
env_rerun_count = 0
last_cipe_url = null
e

---

*Content truncated.*

When not to use it

  • General CI monitoring
  • Cancelling CI workflows

Prerequisites

Nx Cloud connection

Limitations

  • Requires Nx Cloud connection
  • Cannot cancel pipelines

How it compares

It integrates directly with Nx Cloud self-healing, which standard CI provider CLIs cannot access, preventing race conditions and lost progress.

Compared to similar skills

monitor-ci side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
monitor-ci (this skill)04moReviewAdvanced
project-workflow06moReviewBeginner
turborepo612moReviewIntermediate
turborepo-caching55moReviewIntermediate

Try saying

Example prompts that trigger this skill in your AI assistant.

Search skills

Search the agent skills registry