Monitor Ci
Orchestrate Nx Cloud CI failure handling—local verify, subagent fix apply/review, and gated re-runs—so a solo maintainer can recover green pipelines without babysitting the dashboard.
Overview
Monitor CI is an agent skill most often used in Ship (also Operate) that routes Nx Cloud CI fix statuses through verify, review, apply, and gated recovery subagent flows.
Install
npx skills add https://github.com/nrwl/nx-ai-agents-config --skill monitor-ciWhat is this skill?
- Branches on fix status codes: auto-apply skipped, apply ready, local verify, review, failed/no-fix
- Spawns UPDATE_FIX and FETCH_HEAVY subagents and records last_cipe_url for wait-mode polling
- Runs verifiable Nx tasks in parallel via general subagents with pnpm/yarn/npx nx detection
- Applies ci-state-update.mjs gate --gate-type local-fix before reject or fix-from-scratch paths
- Supports manual APPLY when auto-apply is skipped for Nx Cloud–triggered pipelines
- Five documented fix status branches including fix_auto_apply_skipped and fix_needs_local_verify
- Three Nx invocation variants: pnpm nx, yarn nx, and npx nx
Adoption & trust: 1.3k installs on skills.sh; 24 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You see a failing Nx CI pipeline but the fix path depends on status codes, local verification, and Cloud auto-apply rules you do not want to mis-handle in chat.
Who is it for?
Solo builders maintaining Nx monorepos with Nx Cloud CI and agent-driven fix application.
Skip if: Teams without Nx/Nx Cloud, or projects that only need generic GitHub Actions log reading without Nx fix orchestration.
When should I use this skill?
Nx Cloud CI returns a fix status and the agent must verify, review, apply, or gate a recovery path.
What do I get? / Deliverables
The agent follows the correct branch for each fix status, runs parallel local Nx verification when required, and applies or rejects fixes through subagents while respecting ci-state-update gates.
- Applied or rejected CI fix via UPDATE_FIX subagent
- Local verification results for verifiableTaskIds
- Wait-mode state with recorded last_cipe_url
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
CI remediation is canonically a Ship concern because it sits on the path between failing checks and a releasable commit. Launch subphase fits the gate between CI signals and actually landing fixes on the branch that will ship.
Where it fits
Parallel-run verifiable Nx targets locally before the agent APPLYs a Cloud-suggested fix.
Enter wait mode after APPLY while tracking last_cipe_url until the pipeline goes green.
Re-use the same status handlers when recurring CI failures need gated local-fix attempts.
How it compares
Use instead of pasting CI logs into chat without status-specific gates and subagent handoffs.
Common Questions / FAQ
Who is monitor-ci for?
Indie and solo developers using Nx and Nx Cloud who want their coding agent to handle CI fix states systematically rather than improvising each failure.
When should I use monitor-ci?
Use it in Ship when CI reports fix_auto_apply_skipped, fix_apply_ready, fix_needs_local_verify, or fix_needs_review; use it in Operate when you are iterating on recurring pipeline failures and need wait-mode tracking with last_cipe_url.
Is monitor-ci safe to install?
Review the Security Audits panel on this Prism page and treat subagent APPLY paths as code-changing actions that should run only on branches you control.
SKILL.md
READMESKILL.md - Monitor Ci
# Detailed Status Handling & Fix Flows ## Status Handling by Code ### fix_auto_apply_skipped The script returns `autoApplySkipReason` in its output. 1. Report the skip reason to the user (e.g., "Auto-apply was skipped because the previous CI pipeline execution was triggered by Nx Cloud") 2. Offer to apply the fix manually — spawn UPDATE_FIX subagent with `APPLY` if user agrees 3. Record `last_cipe_url`, enter wait mode ### fix_apply_ready - Spawn UPDATE_FIX subagent with `APPLY` - Record `last_cipe_url`, enter wait mode ### fix_needs_local_verify The script returns `verifiableTaskIds` in its output. 1. **Detect package manager:** `pnpm-lock.yaml` → `pnpm nx`, `yarn.lock` → `yarn nx`, otherwise `npx nx` 2. **Run verifiable tasks in parallel** — spawn `general` subagents for each task 3. **If all pass** → spawn UPDATE_FIX subagent with `APPLY`, enter wait mode 4. **If any fail** → Apply Locally + Enhance Flow (see below) ### fix_needs_review Spawn FETCH_HEAVY subagent, then analyze fix content (`suggestedFixDescription`, `suggestedFixSummary`, `taskFailureSummaries`): - If fix looks correct → apply via MCP - If fix needs enhancement → Apply Locally + Enhance Flow - If fix is wrong → run `ci-state-update.mjs gate --gate-type local-fix`. If not allowed, print message and exit. Otherwise → Reject + Fix From Scratch Flow ### fix_failed / no_fix Spawn FETCH_HEAVY subagent for `taskFailureSummaries`. Run `ci-state-update.mjs gate --gate-type local-fix` — if not allowed, print message and exit. Otherwise attempt local fix (counter already incremented by gate). If successful → commit, push, enter wait mode. If not → exit with failure. ### environment_issue 1. Run `ci-state-update.mjs gate --gate-type env-rerun`. If not allowed, print message and exit. 2. Spawn UPDATE_FIX subagent with `RERUN_ENVIRONMENT_STATE` 3. Enter wait mode with `last_cipe_url` set ### self_healing_throttled Spawn FETCH_HEAVY subagent for `selfHealingSkipMessage`. 1. **Parse throttle message** for CI Attempt URLs (regex: `/cipes/{id}`) 2. **Reject previous fixes** — for each URL: spawn FETCH_THROTTLE_INFO to get `shortLink`, then UPDATE_FIX with `REJECT` 3. **Attempt local fix**: Run `ci-state-update.mjs gate --gate-type local-fix`. If not allowed → skip to step 4. Otherwise use `failedTaskIds` and `taskFailureSummaries` for context. 4. **Fallback if local fix not possible or budget exhausted**: push empty commit (`git commit --allow-empty -m "ci: rerun after rejecting throttled fixes"`), enter wait mode ### no_new_cipe 1. Report to user: no CI attempt found, suggest checking CI provider 2. If `--auto-fix-workflow`: detect package manager, run install, commit lockfile if changed, enter wait mode 3. Otherwise: exit with guidance ### cipe_no_tasks 1. Report to user: CI failed with no tasks recorded 2. Retry: `git commit --allow-empty -m "chore: retry ci [monitor-ci]"` + push, enter wait mode 3. If retry also returns `cipe_no_tasks`: exit with failure ## Fix Action Flows ### Apply via MCP Spawn UPDATE_FIX subagent with `APPLY`. New CI Attempt spawns automatically. No local git ops. ### Apply Locally + Enhance Flow 1. `nx-cloud apply-locally <shortLink>` (sets state to `APPLIED_LOCALLY`) 2. Enhance code to fix failing tasks 3. Run failing tasks to verify 4. If still failing → run `ci-state-update.mjs gate --gate-type local-fix`. If not allowed, commit current state and push (let CI be final judge). Otherwise loop back to enhance. 5. If passing → commit and push, enter wait mode ### Reject + Fix From Scratch Flow 1. Run `ci-state-update.mjs gate --gate-type local-fix`. If not allowed, print message and exit. 2. Spawn UPDATE_FIX subagent with `REJECT` 3. Fix from scratch locally 4. Commit and push, enter wait mode ## Environment vs Code Failure Recognition When any local fix path runs a task and it fails, assess whether the failure is a **code issue** or an **environment/tooling issue** before running the gate script. **Indicators of envi