The PR is up, but red CI is a human’s job again

An AI agent implements a feature, runs local tests, and even opens a PR. But when a failure occurs only in remote CI, the flow breaks. A person has to check the notification, copy the logs, and explain the failed context again before the agent can start the next fix.

The gap Nx aims to fill is not code generation, but the loss of information after a PR. It lets a local agent retrieve Nx Cloud pipeline status, failed task output, and Self-Healing CI fix suggestions.

That said, this is not a one-command feature that automatically resolves every failure. You need to prepare local Nx execution, the Nx Cloud and VCS connection, the CI fix-ci step, and the agent’s MCP and skill setup in sequence. The conditions for generating a fix suggestion and automatically applying it must also be evaluated separately.

What the agent gets back is post-failure context

Nx MCP provides ci_information to check the current branch’s CI status, ci_task_output to retrieve individual task output, and update_self_healing_fix to apply or reject a Self-Healing suggestion. In other words, the agent can directly retrieve the information people used to relay between the CI screen and the editor.

Post-PR stageBefore connectionAfter connection
Status checkA person checks CI notifications and the CI screenThe agent queries Nx Cloud status
Failure handoffCopy logs and write a new promptRetrieve failed task output directly
Fix suggestionA person explains the cause againReview a Self-Healing suggestion and apply or reject it
Completion decisionA person resumes the flow after every failureQuery CI status again to decide the next step

There is one naming detail to correct here. The original official post calls it ci-monitor, but the name found in the current public repository’s skill path and metadata is monitor-ci. If you search for the old name as an installation path or skill name, it may not match the current setup.

Self-Healing CI uses failure logs and the Nx project graph to analyze the cause and create a fix, then reruns the originally failed task to verify whether the fix worked. That verification applies to a particular failed task. It does not guarantee the overall business correctness of the code or that the PR is ready to merge.

First, confirm Nx runs in a fresh checkout

This procedure targets an existing workspace with nx.json and Nx included in package.json. Initializing a repository without Nx changes dependencies and configuration files, so it should be treated as a separate adoption task.

  1. Prepare the Node.js version and package manager specified by the repository.
    Check package.json, the lockfile, version-management files, and the existing CI configuration. Follow that repository’s setup for the exact Node.js version and installation command.
  2. Run the project dependency installation command that matches the lockfile.
    When installation finishes, run npx nx --version from the workspace root, or run the Nx task the repository normally uses. The first success criterion is that local Nx starts successfully.
  3. Stop the connection work if Nx is absent.
    If neither nx.json nor Nx in package.json is present, do not start with configure-ai-agents. Since npx nx@latest init adds Nx dependencies and configuration, it is a separate change the team should review.

Connect Nx Cloud and CI first

Before configuring the agent, establish the route through which remote CI can leave status and fix suggestions. You need an Nx Cloud account, a supported VCS integration, and permission to change the workspace and CI configuration.

  1. Open the Self-Healing CI setup documentation and connect the workspace.
    Run npx nx@latest connect at the workspace root, then complete browser authentication.
  2. Verify the VCS connection in Nx Cloud.
    Connect a GitHub, GitLab, Azure DevOps, or Bitbucket repository listed as supported in the official documentation, then enable Self-Healing CI in Workspace Settings.
  3. Add npx nx fix-ci at the end of the correct CI job.
    Place it in the main or orchestrator job that starts Nx tasks, and configure it to run even when prior steps fail. In GitHub Actions, this requires if: always(); other CI systems need the equivalent condition. In a BYOC setup, the same handling is needed in every agent job as well as the main job.

If fix-ci runs only on the success path, it cannot handle failures.

Check the CI logs to make sure it actually runs after an earlier test fails, not just that it is positioned correctly. The syntax for an always-run condition differs by CI provider, so use the syntax of your existing pipeline.

Verify agent setup in two parts: installation and operation

Once the Nx Cloud connection is complete, configure Nx MCP and the monitor-ci skill in your coding client. The official setup command checks the existing Nx workspace, then creates client-specific rules, MCP, and skill files.

  1. Generate the configuration for the client you use.
    Run npx nx configure-ai-agents and select interactively, or use npx nx configure-ai-agents --agents <claude|codex|copilot|cursor|gemini|opencode> --no-interactive in an automated environment.
  2. Review the generated changes.
    Check the diff to confirm that rule files and MCP and skill settings were added in the expected client locations. Before committing directly to the repository, also check for conflicts with organizational rules or existing configuration.
  3. Check installation status.
    Run npx nx configure-ai-agents --check=all. If the rules, MCP, and skills checks pass, the configuration files were installed successfully. This check does not mean remote CI queries have succeeded.
  4. Verify VCS credentials and permissions.
    If you expect the agent to create PRs, it needs the credentials and permissions to commit, push, and create PRs. Without them, have a person create the PR and request monitoring only.
  5. Send the first prompt from a PR branch, not the default branch.
    If it has permission to create a PR, you can enter the official example: Commit the work, create a PR and monitor CI. At first, do not assume automatic application; confirm that the agent can retrieve Nx Cloud pipeline status first.

Suggestion generation and automatic application are different gates

Do not immediately interpret the absence of a Self-Healing suggestion as low AI reliability. The stage that creates a suggestion and the stage that automatically applies a created suggestion have different conditions.

StageConditions to checkSuccess signal
Agent installationRules, MCP, and skill configuration--check=all check passes
CI monitoringNx Cloud connection and MCP tool exposurePipeline status for the current PR branch is retrieved
Suggestion generationPR CI run, Self-Healing enabled, branch rules, eligible tasks, and exclusion patternsA suggestion or status message for the failed task appears
Automatic applicationAuto-apply patterns, high confidence, and failed-task rerun verificationA suggestion that passes every condition is applied automatically

If no suggestion is generated, check whether CI ran on the PR, whether Self-Healing is enabled, whether it was run on a default or protected branch, and whether the failed task was caught by eligible-task or exclusion patterns. Conversely, if a suggestion appears but is not automatically applied, then examine the auto-apply patterns, confidence, and rerun verification result separately.

monitor-ci is publicly designed to distinguish outcomes such as success, nothing to fix, environment issues, and timeouts. So if CI on the first PR passes from the start, it is normal to have no fix suggestion. If the agent retrieved that run’s status, the first goal—establishing the monitoring connection—has been achieved.

Do not define the first rollout’s goal as “unattended merging.”

Start by validating the connection with tasks such as linting or unit tests, where failures and rerun results are clear. If people need to copy and relay CI logs less often, and the agent reports failed output and fix-suggestion status distinctly, the automation gap Nx set out to fill has genuinely closed.

If you want to dig deeper

End to End Autonomous AI Agent Workflows with Nx is the starting point explaining why people have to re-engage after a PR and the full flow for an agent monitoring CI. nx.dev

AI-Powered Self-Healing CI lets you separately review VCS connection, fix-ci placement, the scope of suggestion generation, and the conditions for automatic application. nx.dev

Integrate Nx with your Coding Assistant covers supported clients, non-interactive setup, and the --check=all procedure. nx.dev