Agent skill

Monitor CI

by nrwl in nrwl/nx

Monitor Nx Cloud CI pipeline and handle self-healing fixes. An agent skill from nrwl/nx.

MITAuto-check passedDevOps & Cloud

Install Monitor CI

skills CLI
$ npx skills add nrwl/nx --skill monitor-ci -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install nrwl/nx monitor-ci --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/nrwl/nx.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/monitor-ci .claude/skills/monitor-ci && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
monitor-ci
GitHub stars
29k
Used in
6 other repos
Token cost
~4.7k tokens
SKILL.md length
1,529 words
Files
4 (incl. scripts, references)
Skills in repo
21
Repo updated
First seen
Licence
MIT

At a glance

Monitor Nx Cloud CI pipeline and handle self-healing fixes. An agent skill from nrwl/nx.

  • Works in 5 steps: Verify Nx Cloud Connection → Initialize Tracking → Polling Loop → …
  • User says monitor ci
  • SKILL.md covers Context, User Instructions, Configuration Defaults and Nx Cloud Connection Check, plus 9 more sections
  • Runs JavaScript scripts from its folder; calls git, node and nx; reaches nx.dev

What it does

Monitor CI is an agent skill from nrwl/nx. 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.

Its SKILL.md is about 4.7k tokens, which your agent loads only when the skill is triggered. The skill folder holds 5 other files, including scripts and reference files (for example `references/fix-flows.md`).

It sits in DevOps & Cloud, covering CI/CD. The repository describes itself as: The Monorepo Platform that amplifies both developers and AI agents. Nx optimizes your builds, scales your CI, and fixes failed PRs automatically. Ship in half the time. The licence is MIT.

When your agent uses it

  • User says monitor ci
  • Watch ci for this branch
  • Check ci status
  • Wants to track CI status

Example prompts

  • “monitor ci”
  • “watch ci”
  • “ci monitor”
  • “/monitor-ci”

Requirements

  • Node.js

Workflow steps

5 steps, taken from the step headings in SKILL.md.

  1. Verify Nx Cloud Connection
  2. Initialize Tracking
  3. Polling Loop
  4. Handle Actionable Status
  5. Cycle Classification and Progress Tracking

What it can do on your machine

Read from SKILL.md and the folder at commit db71d69. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Ships 2 files in scripts/ (JavaScript), which the agent can run.

    Shell commands in SKILL.md call:

    • git
    • node
    • nx
    • gh
    • glab

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Hosts in commands or code, which the agent is likely to contact:

    • nx.dev

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Monitor CI loads about 4.7k tokens when it runs, and up to ~6k if it reads all its reference files. Until then it costs about 104 tokens; SKILL.md has 1,529 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~104
When it runs · the whole SKILL.md, loaded when a task matches
~4.7k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.

SKILL.md

The full file from nrwl/nx at commit db71d69, republished under its MIT licence (© nrwl). 1,529 words, ~4,749 tokens.

Download SKILL.mdSave it as .claude/skills/monitor-ci/SKILL.md (or your agent's skills folder). This skill also uses 3 other files; get the full folder from GitHub.
name
monitor-ci
description
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.

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

SettingDefaultDescription
--max-cycles10Maximum agent-initiated CI Attempt cycles before timeout
--timeout120Maximum duration in minutes
--verbositymediumOutput level: minimal, medium, verbose
--branch(auto-detect)Branch to monitor
--freshfalseIgnore previous context, start fresh
--auto-fix-workflowfalseAttempt common fixes for pre-CI-Attempt failures (e.g., lockfile updates)
--new-cipe-timeout10Minutes to wait for new CI Attempt after action
--local-verify-attempts3Max 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:

    Nx Cloud not connected. Unlock 70% faster CI and auto-fix broken PRs with https://nx.dev/nx-cloud
  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-PatternWhy 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 scriptsUnreliable, pollutes context, no self-healing
Cancelling CI workflows/pipelinesDestructive, loses CI progress
Running CI checks on main agentWastes main agent context tokens
Independently analyzing/fixing CI failures while pollingRaces 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

Three field sets control polling efficiency — use the lightest set that gives you what you need:

yaml
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:

StatusDefault Behavior
ci_successExit with success
cipe_canceledExit, CI was canceled
cipe_timed_outExit, CI timed out
polling_timeoutExit, polling timeout reached
circuit_breakerExit, no progress after 13 consecutive polls
environment_rerun_capExit, environment reruns exhausted
fix_auto_applyingSelf-healing is handling it — just record last_cipe_url, enter wait mode. No MCP call or local git ops needed.
errorWait 60s and loop

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

StatusSummary
fix_auto_apply_skippedFix verified but auto-apply skipped (e.g., loop prevention). Inform user, offer manual apply.
fix_apply_readyFix verified (all tasks or e2e-only). Apply via MCP.
fix_needs_local_verifyFix has unverified non-e2e tasks. Run locally, then apply or enhance.
fix_needs_reviewFix verification failed/not attempted. Analyze and decide.
fix_failedSelf-healing failed. Fetch heavy data, attempt local fix (gate check first).
no_fixNo fix available. Fetch heavy data, attempt local fix (gate check first) or exit.
environment_issueRequest environment rerun via MCP (gate check first).
self_healing_throttledReject old fixes, attempt local fix.
no_new_cipeCI Attempt never spawned. Auto-fix workflow or exit with guidance.
cipe_no_tasksCI 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
cycle_count = 0            # Only incremented for agent-initiated cycles (counted against --max-cycles)
start_time = now()         # Passed to the decision script as --elapsed-seconds on every poll to enforce --timeout across attempts
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.

Show full SKILL.md (651 more words)Show less
2b. Run decision script
bash
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_minutes>] \
  [--new-cipe-timeout <new_cipe_timeout_minutes>] \
  [--elapsed-seconds <seconds_since_start_time>] \
  [--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>]

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
Tool calls for actions

Several statuses require fetching additional data or calling tools:

  • fix_apply_ready: Call update_self_healing_fix with action APPLY
  • fix_needs_local_verify: Call ci_information with HEAVY_FIELDS for fix details before local verification
  • fix_needs_review: Call ci_information with HEAVY_FIELDS → get suggestedFixDescription, suggestedFixSummary, taskFailureSummaries
  • fix_failed / no_fix: Call ci_information with HEAVY_FIELDS → get taskFailureSummaries for local fix context
  • environment_issue: Call update_self_healing_fix with action RERUN_ENVIRONMENT_STATE
  • self_healing_throttled: Call ci_information with HEAVY_FIELDS → get selfHealingSkipMessage; then call update_self_healing_fix for each old fix
Step 3a: Track State for New-CI-Attempt Detection

After actions that should trigger a new CI Attempt, run:

bash
node <skill_dir>/scripts/ci-state-update.mjs post-action \
  --action <type> \
  --cipe-url <current_cipe_url> \
  --commit-sha <git_rev_parse_HEAD>

Action types: fix-auto-applying, apply-mcp, apply-local-push, reject-fix-push, local-fix-push, env-rerun, auto-fix-push, empty-commit-push

The script returns { waitMode, pollCount, lastCipeUrl, expectedCommitSha, agentTriggered }. Update all tracking state from the output, then go to Step 2.

Step 4: Cycle Classification and Progress Tracking

When the decision script returns action == "done", run cycle-check before handling the code:

bash
node <skill_dir>/scripts/ci-state-update.mjs cycle-check \
  --code <code> \
  [--agent-triggered] \
  --cycle-count <cycle_count> --max-cycles <max_cycles> \
  --env-rerun-count <env_rerun_count>

The script returns { cycleCount, agentTriggered, envRerunCount, approachingLimit, limitReached, message }. Update tracking state from the output.

  • If limitReached → the --max-cycles budget is exhausted. Print message and stop monitoring (do not handle the code or start another cycle). This is a hard stop, not advisory.
  • Else if approachingLimit → ask user whether to continue (with 5 or 10 more cycles) or stop monitoring
  • If previous cycle was NOT agent-triggered (human pushed), log that human-initiated push was detected
Progress Tracking
  • no_progress_count, circuit breaker (5 polls), and backoff reset are handled by ci-poll-decide.mjs (progress = any change in cipeStatus, selfHealingStatus, verificationStatus, or failureClassification)
  • env_rerun_count reset on non-environment status is handled by ci-state-update.mjs cycle-check
  • On new CI Attempt detected (poll script returns newCipeDetected) → reset local_verify_count = 0, env_rerun_count = 0

Error Handling

ErrorAction
Git rebase conflictReport to user, exit
nx-cloud apply-locally failsReject fix via MCP (action: "REJECT"), then attempt manual patch (Reject + Fix From Scratch Flow) or exit
MCP tool errorRetry once, if fails report to user
Subagent spawn failureRetry once, if fails exit with error
Decision script errorTreat as error status, increment no_progress_count
No new CI Attempt detectedIf --auto-fix-workflow, try lockfile update; otherwise report to user with guidance
Lockfile auto-fix failsReport to user, exit with guidance to check CI logs

User Instruction Examples

Users can override default behaviors:

InstructionEffect
"never auto-apply"Always prompt before applying any fix
"always ask before git push"Prompt before each push
"reject any fix for e2e tasks"Auto-reject if failedTaskIds contains e2e
"apply all fixes regardless of verification"Skip verification check, apply everything
"if confidence < 70, reject"Check confidence field before applying
"run 'nx affected -t typecheck' before applying"Add local verification step
"auto-fix workflow failures"Attempt lockfile updates on pre-CI-Attempt failures
"wait 45 min for new CI Attempt"Override new-CI-Attempt timeout (default: 10 min)

© nrwl, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 3 other files (scripts, references) in .agents/skills/monitor-ci of nrwl/nx.

  • SKILL.md
  • references/fix-flows.md
  • scripts/ci-poll-decide.mjs
  • scripts/ci-state-update.mjs

Open the folder on GitHubat commit db71d69

Used in 6 other repositories

We found 17 copies of this SKILL.md (exact, near-identical or edited) in other folders, from 6 other GitHub owners. This page covers the copy in nrwl/nx, which our catalogue first saw on October 7, 2026.

Compare with similar skills

Monitor CI next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Monitor CI compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Monitor CI this skillnrwl/nx29k6 repos~4.7kAutomated safety check: PassMIT
Repo Hygiene Scan and FixQwenLM/qwen-code28k—~1.7kAutomated safety check: PassApache-2.0
Bash Defensive Patternspromovaweb/setupvibe10214 repos~572Automated safety check: PassGPL-3.0
Winui AppLanceMcCarthy/DevOpsExamples1721 repos~2.8kAutomated safety check: PassApache-2.0
Released-kimuson/claude-code-viewer1.3k—~1.2kAutomated safety check: PassMIT
Reviewwerf/werf4.7k—~2kAutomated safety check: PassApache-2.0

Similar skills

  • Scheduled CI skill that scans a repository for small, certain docs, test and code hygiene issues and fixes them on one branch with a commit per finding.

    28k GitHub stars~1.7k tokensUpdated today
    DevOps & CloudAuto-check passed
  • Bash Defensive Patterns

    promovaweb/setupvibe

    Master defensive Bash programming techniques for production-grade scripts.

    102 GitHub starsUsed in 14 repos~572 tokens
    DevOps & CloudAuto-check passed
  • Winui App

    LanceMcCarthy/DevOpsExamples

    Bootstrap, develop, and design modern WinUI 3 desktop applications with C and the Windows App SDK using official Microsoft guidance, WinUI Gallery patterns, Windows App SDK samples, and…

    172 GitHub starsUsed in 1 repo~2.8k tokens
    DevOps & CloudAuto-check passed
  • Release

    d-kimuson/claude-code-viewer

    Run the claude-code-viewer release flow end-to-end. An agent skill from d-kimuson/claude-code-viewer.

    1.3k GitHub stars~1.2k tokensUpdated 1 mo ago
    DevOps & CloudAuto-check passed
  • Review

    werf/werf

    Code review of a pull request, branch, or diff. An agent skill from werf/werf.

    4.7k GitHub stars~2k tokensUpdated today
    DevOps & CloudAuto-check passed
  • Megalinter Check

    nvuillam/npm-groovy-lint

    Collect MegaLinter lint errors for the current repository. An agent skill from nvuillam/npm-groovy-lint.

    248 GitHub starsUsed in 1 repo~3.9k tokens
    DevOps & CloudAuto-check: notes
  • Nx Import

    nrwl/nx

    Import, merge, or combine repositories into an Nx workspace using nx import.

    29k GitHub starsUsed in 6 repos~3.5k tokens
    Auto-check passed
  • Run Nx generators with prioritization for workspace-plugin generators.

    29k GitHub starsUsed in 2 repos~592 tokens
    Auto-check: notes
  • Author or scope a first-party Nx migration. An agent skill from nrwl/nx.

    29k GitHub stars~12k tokensUpdated today
    Auto-check: notes
  • Generate code using nx generators. An agent skill from nrwl/nx.

    29k GitHub starsUsed in 1 repo~2.2k tokens
    Auto-check passed
  • Check modified Nx documentation pages against the astro-docs style guide.

    29k GitHub stars~1.3k tokensUpdated today
    Auto-check passed
  • Sync docs commits from master out to the live docs branches in the nx repo: cherry-picks docs( / feat(nx-dev) commits onto website-<major AND the latest <major.<minor.x release branch.

    29k GitHub stars~1.2k tokensUpdated today
    Auto-check passed

Questions about Monitor CI

What does Monitor CI do?

Monitor Nx Cloud CI pipeline and handle self-healing fixes. An agent skill from nrwl/nx. Monitor CI is an agent skill from nrwl/nx. Monitor Nx Cloud CI pipeline and handle self-healing fixes.

When should I use Monitor CI?

Monitor CI fits situations like: user says monitor ci; watch ci for this branch; check ci status; wants to track CI status.

How do I install Monitor CI in Claude Code?

Run `npx skills add nrwl/nx --skill monitor-ci -a claude-code`. Or copy the skill folder (.agents/skills/monitor-ci in nrwl/nx) into .claude/skills/monitor-ci in your project. Claude Code loads it when a task matches its description.

How do I install Monitor CI in Codex?

Run `npx skills add nrwl/nx --skill monitor-ci -a codex`. Or copy the skill folder (.agents/skills/monitor-ci in nrwl/nx) into .agents/skills/monitor-ci in your project. Codex loads it when a task matches its description.

Can I use Monitor CI in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add nrwl/nx --skill monitor-ci -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/monitor-ci, .gemini/skills/monitor-ci, .github/skills/monitor-ci and .opencode/skills/monitor-ci in your project.

What does Monitor CI need to run?

Going by SKILL.md and its folder, Monitor CI needs JavaScript for the scripts in its folder and the command-line tools its instructions call (git, node, nx, gh and glab). Our summary lists: Node.js.

Does Monitor CI access the network?

SKILL.md names 1 domain. In commands or code: nx.dev; the agent is likely to contact it when it follows the instructions. This is read from the text; nothing was executed.

Is Monitor CI safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.

What licence does Monitor CI use?

Monitor CI is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Monitor CI use?

About 4.7k tokens (SKILL.md is roughly 19k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 1.2k tokens, read only when the agent opens those files.

What are the alternatives to Monitor CI?

Skills that share tags, products or a category with Monitor CI: Repo Hygiene Scan and Fix (QwenLM/qwen-code, 28k stars), Bash Defensive Patterns (promovaweb/setupvibe, 102 stars), Winui App (LanceMcCarthy/DevOpsExamples, 172 stars) and Release (d-kimuson/claude-code-viewer, 1.3k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Monitor CI?

nrwl (a GitHub organization) maintains it in nrwl/nx, which has 29,399 GitHub stars. The repository holds 21 skills in this directory. The repository was last updated on October 9, 2026.

Source: nrwl/nx on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.