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.
Fetches monitor-ci from nrwl/nx-ai-agents-config and configures it for Cursor.
3
Select Cursor when prompted
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
◆ Which agents do you want to install to?
│
│ ── Universal (.agents/skills) ────────────────
│ · Cline · Codex · Goose · Windsurf
│ ●Cursor(selected)
│ · Cursor · Aider · Continue
4
Verify installation
Confirm successful installation by checking the skill directory location:
.cursor/skills/monitor-ci
Restart Cursor to activate monitor-ci. Access via /monitor-ci in your agent's command palette.
⚠
Security Notice
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
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.json at workspace root for nxCloudId or nxCloudAccessToken
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
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'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-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
The ci_information and update_self_healing_fix tools are called via the ci-monitor-subagent, not directly from the orchestrator. Calling MCP tools directly wastes main agent context with large response payloads. The field sets below are for composing subagent prompts (see Step 2a).
Three field sets control polling efficiency — use the lightest set that gives you what you need:
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 13 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:
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 -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
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:
The script returns { cycleCount, agentTriggered, envRerunCount, approachingLimit, message }. Update tracking state from the output.
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
Error
Action
Git rebase conflict
Report to user, exit
nx-cloud apply-locally fails
Reject fix via MCP (action: "REJECT"), then attempt manual patch (Reject + Fix From Scratch Flow) or exit
MCP tool error
Retry once, if fails report to user
Subagent spawn failure
Retry once, if fails exit with error
Decision script error
Treat as error status, increment no_progress_count
No new CI Attempt detected
If --auto-fix-workflow, try lockfile update; otherwise report to user with guidance
Lockfile auto-fix fails
Report to user, exit with guidance to check CI logs
User Instruction Examples
Users can override default behaviors:
Instruction
Effect
"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
✓
Make data-driven prioritization decisions faster
Stakeholder Communication
Draft PRDs, status updates, and stakeholder presentations
›Access to product documentation and roadmap tools (Jira, Notion, etc.)
›Understanding of product management frameworks (RICE, Jobs-to-be-Done, etc.)
›Stakeholder contact information and communication channels
Time Estimate
30-60 minutes to see productivity improvements
Steps
1Install product management skill
2Start with user story generation for known feature
3Progress to competitive analysis: research 2-3 competitors
4Use for roadmap prioritization: apply RICE/ICE scoring
5Draft stakeholder communications and refine based on feedback
6Build template library for recurring PM tasks
7Share effective prompts with product team
Common Pitfalls
⚠Not validating competitive research—verify facts before sharing
⚠Accepting user stories without involving engineering team
⚠Over-relying on frameworks without qualitative judgment
⚠Not customizing outputs to company culture and communication style
⚠Skipping stakeholder validation of generated requirements
Best Practices
✓ Do
+Validate research and competitive analysis with real data
+Collaborate with engineering when generating technical requirements
+Customize frameworks and templates to your company context
+Use skill for first drafts, refine with stakeholder input
+Document successful prompt patterns for PM tasks
+Combine AI efficiency with human judgment and intuition
✗ Don't
−Don't publish competitive analysis without fact-checking
−Don't finalize user stories without engineering review
−Don't make prioritization decisions solely on AI scoring
−Don't skip customer validation of generated requirements
−Don't ignore company-specific context and culture
💡 Pro Tips
★Provide context: company goals, constraints, customer feedback
★Ask for alternatives: 'Show 3 ways to prioritize this roadmap'
★Request stakeholder-specific formatting: 'Executive summary vs. engineering spec'
★Use skill for 70% generation + 30% customization to company needs
When to Use This
✓ Use when
Use for user story writing, competitive research, roadmap prioritization, stakeholder communication, and PRD drafting. Best for reducing repetitive documentation and research work.
✗ Avoid when
Avoid for strategic product vision (requires deep customer empathy), pricing decisions (needs market and financial expertise), or when face-to-face customer discovery is more valuable than speed.
Learning Path
1Basic: user stories, feature specs, status updates
