mostafazke/ng-whiteboard/monitor-ci

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

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 ``

1. 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:

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:

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

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
expected_commit_sha = null
agent_triggered = false    # Set true after monitor takes an action that triggers new CI Attempt
poll_count = 0
wait_mode = false
prev_status = null
prev_cipe_status = null
prev_sh_status = null
prev_verification_status = null
prev_failure_classification = null

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

Call the ci_information tool with the determined select fields for the current branch. Wait for the result before proceeding.

2b. Run decision script

node <skill_dir>/scripts/ci-poll-decide.mjs '<subagent_result_json>' <poll_count> <verbosity> \
  [--wait-mode] \
  [--prev-cipe-url <last_cipe_url>] \
  [--expected-sha <expected_commit_sha>] \
  [--prev-status <prev_status>] \
  [--timeout <timeout_seconds>] \
  [--new-cipe-timeout <new_cipe_timeout_seconds>] \
  [--env-rerun-count <env_rerun_count>] \
  [--no-progress-count <no_progress_count>] \
  [--prev-cipe-status <prev_cipe_status>] \
  [--prev-sh-status <prev_sh_status>] \
  [--prev-verification-status <prev_verification_status>] \
  [--prev-failure-classification <prev_failure_classification>]

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: