nx-ci-monitor
Monitor Nx Cloud CI pipeline status and handle self-healing fixes automatically. Use when user says "watch CI", "monitor pipeline", "check CI status", "fix CI failures", or "self-heal CI". Requires Nx Cloud connection. Do NOT use for local task execution (use nx-run-tasks) or general CI debugging outside Nx Cloud.
npx skills add tech-leads-club/agent-skills --skill nx-ci-monitor --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
What it does
Orchestrates monitoring of Nx Cloud CI pipeline executions and handles self-healing fixes automatically by spawning the ci-watcher subagent to poll CI status and make decisions based on results.
How it works
- Uses context like current branch, commit, and remote status to inform monitoring.
- Parses user arguments to override configuration defaults (max cycles, timeout, verbosity, branch, timeouts, fresh start, auto-fix workflow, new-cipe timeout, local verify attempts).
- Verifies Nx Cloud connection upfront by inspecting
nx.jsonfornxCloudIdornxCloudAccessToken; exits with a message if not connected. - Runs a main loop with a ci-watcher subagent in either fresh or wait mode, tracking cycle_count, start_time, no_progress_count, local_verify_count, last_state, last_cipe_url, and expected_commit_sha.
- Handles a variety of subagent statuses with specified default behaviors (e.g.,
ci_success,fix_auto_applying,fix_available,fix_failed,environment_issue,no_fix,no_new_cipe,polling_timeout,cipe_canceled,cipe_timed_out,error). - When fixes are available, decides between MCP application, local verification flow (detects package manager, runs verifiable tasks in parallel via
<pm> nx run <taskId>, evaluates results, and may performnx apply-locally <shortLink>with optional enhancements), or rejects fixes via MCP. - Supports auto-apply eligibility, applying via MCP, applying locally, or rejecting via MCP, with detailed flows for enhancement and commit/push steps.
- Defines specific commands and file names verbatim where used (e.g.,
nx run,nx apply-locally,update_self_healing_fix,ci-watcher, etc.). - Tracks new CIPE detection via wait mode, recording
last_cipe_urlorexpected_commit_shato ensure old CIPEs are ignored until a new one appears.
When to use it
Use when the user asks to watch CI, monitor pipeline, check CI status, fix CI failures, or self-heal CI, and you have an Nx Cloud connection configured. Not for local task execution or general CI debugging outside Nx Cloud.
What it can touch
- Spawns and communicates with the
ci-watchersubagent (tool: claude-code). - May run local commands such as
pnpm nx run <taskId>,nx apply-locally <shortLink>,git commit, andgit pushas part of local verification or fix enhancement flows. - Reads workspace state via
nx.json, and uses file-based checks likepnpm-lock.yaml,yarn.lock, orpackage-lock.jsonto determine package manager.
Caveats
- Requires Nx Cloud connection; otherwise exits with a specific message.
- Behavior and flows are defined per the explicit status handling table and detailed decision logic; outcomes depend on subagent responses and the availability of fixes, verifications, and auto-apply eligibility.
- No speculation beyond listed rules and commands; uses exact commands and flows described in the skill.
# CI Monitor Command You are the orchestrator for monitoring Nx Cloud CI pipeline executions and handling self-healing fixes. You spawn the `ci-watcher` subagent to poll CI status and make decisions 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 CIPE cycles before timeout | | `--timeout` | 120 | Maximum duration in minutes | | `--verbosity` | medium | Output level: minimal, medium, verbose | | `--branch` | (auto-detect) | Branch to monitor | | `--subagent-timeout` | 60 | Subagent polling timeout in minutes | | `--fresh` | false | Ignore previous context, start fresh | | `--auto-fix-workflow` | false | Attempt common fixes for pre-CIPE failures (e.g., lockfile updates) | | `--new-cipe-timeout` | 10 | Min
- Context
- User Instructions
- Configuration Defaults
- Nx Cloud Connection Check
- Step 0: Verify Nx Cloud Connection
- Session Context Behavior
- Default Behaviors by Status
- Fix Available Decision Logic
- Unverified Fix Flow (No Verification Attempted)
- Auto-Apply Eligibility
- Apply vs Reject vs Apply Locally
- Apply Locally + Enhance Flow
- Reject + Fix From Scratch Flow
- Environment Issue Handling
git commit -m "fix(<projects>): <brief description> Failed tasks: <taskId1>, <taskId2> Local verification: passed|enhanced|failed-pushing-to-ci" git add -A git commit -m "fix: resolve <failedTaskIds>" git push origin $(git branch --show-current) pnpm install # or npm install / yarn install git add pnpm-lock.yaml # or appropriate lockfile git commit -m "chore: update lockfile"
What does the nx-ci-monitor skill do?
Monitor Nx Cloud CI pipeline status and handle self-healing fixes automatically. Use when user says "watch CI", "monitor pipeline", "check CI status", "fix CI failures", or "self-heal CI". Requires Nx Cloud connection. Do NOT use for local task execution (use nx-run-tasks) or general CI debugging outside Nx Cloud.
How do I install it?
Run `npx skills add tech-leads-club/agent-skills --skill nx-ci-monitor --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From tech-leads-club/agent-skills, a repository with 4,983 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.