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, g

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 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. 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: 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 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: 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 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 . 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: 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 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 Step 2: Polling Loop Repeat until done: 2a. Spawn subagent (FETCH STATUS) Determine select fields based on mode: Wait mode : use WAIT FIELDS ( cipeUrl,commitSha,cipeStatus ) Normal mode (first poll or after newCipeDetected) : use LIGHT FIELDS The subagent calls ci information and returns a JSON object with the requested fields. This is a foreground call — wait for the result. 2b. Run decision script 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? } 2c. Process script output Parse the JSON output and update tracking state: no progress count = output.noProgressCount env rerun count = output.envRerunCount prev cipe status = subagent result.cipeStatus prev sh status = subagent result.selfHealingStatus prev verification status = subagent result.verificationStatus prev failure classification = subagent result.failureClassification prev 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 If output.newCipeDetected : clear wait mode, reset wait mode = false action == "wait" : Print output.message , sleep output.delay seconds, go to 2a action == "done" : Proceed to Step 3 with output.code Step 3: Handle Actionable Status When decision script returns action == "done" : 1. Run cycle check (Step 4) before handling the code 2. Check the returned code 3. Look up default behavior in the table above 4. Check if user instructions override the default 5. Execute the appropriate action 6. If action expects new CI Attempt , update tracking (see Step 3a) 7. If action results in looping, go to Step 2 Spawning subagents for actions Several statuses require fetching heavy data or calling MCP: fix apply ready : Spawn UPDATE FIX subagent with APPLY fix needs local verify : Spawn FETCH HEAVY subagent for fix details before local verification fix needs review : Spawn FETCH HEAVY subagent → get suggestedFixDescription , suggestedFixSummary , taskFailureSummaries fix failed / no fix : Spawn FETCH HEAVY subagent → get taskFailureSummaries for local fix context environment issue : Spawn UPDATE FIX subagent with RERUN ENVIRONMENT STATE self healing throttled : Spawn FETCH HEAVY subagent → get selfHealingSkipMessage ; then FETCH THROTTLE INFO + UPDATE FIX for each old fix Step 3a: Track State for New CI Attempt Detection After actions that should trigger a new CI Attempt, run: Action types: fix auto applying , apply

monitor-ci