monitor-ci
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.zipInstalls 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.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
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
| 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
-
Check
nx.jsonat workspace root fornxCloudIdornxCloudAccessToken -
If
nx.jsonmissing 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 -
If connected → continue to main loop
Architecture Overview
- This skill (orchestrator): spawns subagents, runs scripts, prints status, does local coding work
- ci-monitor-subagent (haiku): calls one MCP tool (ci_information or update_self_healing_fix), returns structured result, exits
- ci-poll-decide.mjs (deterministic script): takes ci_information result + state, returns action + status message
- 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'smessagefield - 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:
- Use CI provider CLI for a one-time, read-only status check (single call, no watch/polling flags)
- Immediately delegate to this skill with gathered context
- 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:
| 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 5 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 -Aorgit 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 gatebefore 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
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.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| monitor-ci (this skill) | 0 | 4mo | Review | Advanced |
| project-workflow | 0 | 6mo | Review | Beginner |
| turborepo | 61 | 2mo | Review | Intermediate |
| turborepo-caching | 5 | 5mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
project-workflow
sumanin5
项目启动、环境搭建与日常开发工作流。涵盖 local 与 docker 两种模式下的启动指令。
turborepo
vercel
Turborepo monorepo build system guidance. Triggers on: turbo.json, task pipelines, dependsOn, caching, remote cache, the "turbo" CLI, --filter, --affected, CI optimization, environment variables, internal packages, monorepo structure/best practices, and boundaries. Use when user: configures tasks/workflows/pipelines, creates packages, sets up monorepo, shares code between apps, runs changed/affected packages, debugs cache, or has apps/packages directories.
turborepo-caching
wshobson
Configure Turborepo for efficient monorepo builds with local and remote caching. Use when setting up Turborepo, optimizing build pipelines, or implementing distributed caching.
pipeline-plugin-development
TencentBlueKing
流水线插件开发完整指南,涵盖插件创建、task.json 配置规范、多语言开发示例(Python/Java/NodeJS/Golang)、输入输出规范、错误码规范、发布流程、调试方法。当用户需要开发蓝盾流水线插件、配置 task.json、处理插件输入输出或排查插件错误时使用。
appinsights-instrumentation
github
Instrument a webapp to send useful telemetry data to Azure App Insights
cloud-functions
TencentCloudBase
Complete guide for CloudBase cloud functions development - runtime selection, deployment, logging, invocation, and HTTP access configuration.