nx-cloud-ci-failure-review
Review failed Nx Cloud CI pipeline executions and group recurring, evidence-based failure patterns. Use this skill whenever a user asks about failed CI pipelines, recurring task failures, failed CIPEs, a CI failure review, or a last-24-hours CI report. Use the nx-cloud-api skill for every Nx Cloud read. This read-only skill separates task, workflow, agent, timeout, cancellation, and unknown cases. It suggests diagnostic next steps without changing systems.
- Installs
- 59
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/nrwl/nx-ai-agents-config --skill nx-cloud-ci-failure-review- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads nx-cloud-ci-failure-review automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Nx Cloud CI failure review
Requires the nx-cloud-api skill for all Nx Cloud reads. This workflow is read-only.
Reduce failed pipelines to a small set of diagnostic groups. A failed pipeline does not prove that an agent or platform caused the failure. Classify each group only at the level the evidence supports.
Scope and collection
Use focused investigation mode when the user supplies one or more CIPE or run-group links. Fetch those exact records first. Follow their returned run-group, run, task, and workflow links. Compare the supplied executions directly. Do not run a broad time window or build a workspace-wide ranking unless the user asks for recurrence or scope. Keep cancellations that follow the named critical error as consequences, not separate root-cause groups.
Use review mode when the user asks for a workspace failure review. Review
failures from the last 24 hours by default. CIPE and run-group list filters use
createdAt, not failure time. Query a 30-hour creation window to cover the maximum
normal six-hour CI duration. State the intended 24-hour review period and the
30-hour creation window.
Query statuses=FAILED, statuses=TIMED_OUT, and statuses=CANCELED (the
cipes filter accepts only terminal statuses). State the
branches, CI contexts, statuses, endpoints, and record counts. Ask before widening
the window or mixing unrelated repositories/workspaces.
Use nx-cloud-api (npx nx-cloud api) for every read. Inspect the live
schemas with --describe for cipes, run-groups, run-groups/{runGroupId},
runs, runs/{runId}/tasks, and the linked steps and instances endpoints.
Use --list-operations to confirm the routes; the public API has no separate
workflow routes. Reach child records by following returned links. Start with supplied CIPEs in focused investigation mode. Start with failed CIPEs
and their linked run groups in review mode. Use only live documented filters and
fields. Fetch one narrow page first and check nextCursor before continuing.
Collect in this order:
- Failed, timed-out, and canceled CIPEs with status, timestamps, branch, and CI
context. Use a small, stated
--pagesvalue. Rank groups workspace-wide only after a zero exit withnextCursor: null; otherwise report the data as incomplete. - Linked run groups and their documented critical-error fields.
- Runs and terminal task rows for each selected group.
- Workflow and instance status only when task data does not explain the group.
- The smallest relevant task or instance log excerpt for representative cases.
Use a semaphore of at most five narrow detail requests. Fetch logs only after a group reaches the top five. Tell the user before reading CI log content. Quote only redacted error lines.
Treat cancellations as their own category until their reason and timing show that they belong elsewhere. Do not call a cancellation a failure without that context.
Grouping method
Build groups from stable evidence. Prefer a task identifier plus normalized error signature. Normalize timestamps, GUIDs, retry counters, temporary paths, and random ports. Keep stack context, command, and error code that distinguish two otherwise similar messages.
Use these categories only when their evidence exists:
- Repeated task error.
- Task timeout.
- Cancellation.
- Workflow or agent failure.
- Unknown pipeline failure.
Call a group workflow or agent failure only when workflow/instance status, critical error, or agent evidence supports it and no task failure explains the pipeline. Do not infer infrastructure from the absence of a task log.
Reconcile the full pipeline picture before classification. A task can record
SUCCEEDED or a cache hit while the main job fails during artifact download,
validation, or restoration. Compare the run-group criticalErrorMessage, task
status, cache status, workflow status, and later cancellations. In that case,
classify the main-job cache restoration error as primary and the canceled runs as
consequences.
For every group, record its CIPE count, run-group count, affected task count, first and last occurrence, branches/contexts, and one or two representative IDs. Rank first by affected pipeline count, then recurrence, then blocked duration when it is documented.
Next action rules
- Repeated task error: when a relevant workspace checkout exists, inspect
CODEOWNERSand project ownership metadata at the recorded commit. Suggest a likely review owner. Do not assign work or claim ownership when that evidence is absent. - Task timeout: compare duration and resource evidence. Request a focused reproduction or resource report when it does not show a direct cause.
- Cancellation: identify the documented cancel source, or keep it separate as unknown cancellation.
- Workflow or agent failure: retry or monitor only when the evidence supports a transient event. Otherwise inspect the named workflow/agent asset.
- Unknown: request the smallest log or run detail that can separate the cases.
Do not make code, workflow, or allocation changes without explicit approval.
Report format
# Failed CI review
## Scope
- Window: …
- Data: …
## Failure groups
### 1. <evidence-level category> — <short signature>
- **Confirmed facts:** affected CIPEs/runs/tasks; representative IDs; log excerpt.
- **Assessment:** **Confirmed** / **Likely** / **Needs diagnostic run** — …
- **Impact:** …
- **Highest-leverage next action:** …
## Unclassified or incomplete data
- …
Limit a review report to five groups. In focused investigation mode, report the supplied executions as one comparison when they have the same normalized signature. Link each finding to exact CIPEs, run groups, runs, and tasks where available. State the data limit when pagination, missing assets, or missing context affects the conclusion.
FAQ
What does the nx-cloud-ci-failure-review skill do?
Review failed Nx Cloud CI pipeline executions and group recurring, evidence-based failure patterns. Use this skill whenever a user asks about failed CI pipelines, recurring task failures, failed CIPEs, a CI failure review, or a last-24-hours CI report. Use the nx-cloud-api skill for every Nx Cloud read. This read-only skill separates task, workflow, agent, timeout, cancellation, and unknown cases. It suggests diagnostic next steps without changing systems.
How do I install nx-cloud-ci-failure-review?
Run npx skills add https://github.com/nrwl/nx-ai-agents-config --skill nx-cloud-ci-failure-review in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/nx-cloud-ci-failure-review/ (personal) or .claude/skills/nx-cloud-ci-failure-review/ (project).
Which AI agents can use nx-cloud-ci-failure-review?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is nx-cloud-ci-failure-review safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains nx-cloud-ci-failure-review?
It is published by nrwl in nrwl/nx-ai-agents-config. It has 59 recorded installs.
More from nrwl/nx-ai-agents-config
nx-workspace
nrwl/nx-ai-agents-config
Explore and understand Nx workspaces. USE WHEN answering questions about the workspace, projects, or tasks. ALSO USE WHEN an nx command fails or you need to check available targets/configuration before running a task. EXAMPLES: 'What projects are in this workspace?', 'How is project X configured?', 'What depends on library Y?', 'What targets can I run?', 'Cannot find configuration for task', 'debug nx task failure'.
nx-run-tasks
nrwl/nx-ai-agents-config
Helps with running tasks in an Nx workspace. USE WHEN the user wants to execute build, test, lint, serve, or run any other tasks defined in the workspace.
nx-generate
nrwl/nx-ai-agents-config
Generate code using nx generators. INVOKE IMMEDIATELY when user mentions scaffolding, setup, structure, creating apps/libs, or setting up project structure. Trigger words - scaffold, setup, create a new app, create a new lib, project structure, generate, add a new project. ALWAYS use this BEFORE calling nxdocs or exploring - this skill handles discovery internally.
link-workspace-packages
nrwl/nx-ai-agents-config
Link workspace packages in monorepos (npm, yarn, pnpm, bun). USE WHEN: (1) you just created or generated new packages and need to wire up their dependencies, (2) user imports from a sibling package and needs to add it as a dependency, (3) you get resolution errors for workspace packages (@org/) like "cannot find module", "failed to resolve import", "TS2307", or "cannot resolve". DO NOT patch around with tsconfig paths or manual package.json edits - use the package manager's workspace commands to fix actual linking.
nx-plugins
nrwl/nx-ai-agents-config
Find and add Nx plugins. USE WHEN user wants to discover available plugins, install a new plugin, or add support for a specific framework or technology to the workspace.
nx-import
nrwl/nx-ai-agents-config
Import, merge, or combine repositories into an Nx workspace using nx import. USE WHEN the user asks to adopt Nx across repos, move projects into a monorepo, or bring code/history from another repository.
Popular devops & cloud skills
microsoft-foundry
microsoft/azure-skills
Build, deploy, evaluate, optimize, fine-tune, and manage Microsoft Foundry agents, models, and resources end to end. USE FOR: foundry, azd ai agent, azd provision/deploy, hosted agent scaffold/develop/run/deploy/troubleshoot, prompt agent create, managed harness agent create, GitHub Copilot harness agent, create agent, update agent, add tool to agent, invoke agent, agent insights, evaluate agent, batch eval, continuous eval, continuous monitoring, agent CI/CD, optimize prompt, improve prompt, optimize agent instructions, Agent Optimizer scaffold, dataset curation from traces, deploy model, model fine-tuning (SFT/DPO/RFT), Foundry project, RBAC, role assignment, permissions, quota, capacity, region, deployment failure, AI Services, create Foundry resource, knowledge index, customize deployment, onboard, availability, training-data, grader, distillation, large file upload. DO NOT USE FOR: Azure Functions, App Service, general Azure deploy (use azure-deploy), general Azure prep (use azure
azure-diagnostics
microsoft/azure-skills
Debug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deployment failure, troubleshoot container apps, container app 503 or target port mismatch, troubleshoot functions, function telemetry missing or stopped after a config/connection-string change, troubleshoot AKS, VM RDP, Linux SSH, VM black screen, can't connect to VM, reset VM password, NSG or firewall blocking, kubectl cannot connect, kube-system/CoreDNS failures, pod pending, crashloop, node not ready, upgrade failures, analyze logs, KQL, insights, image pull failures, cold start issues, health probe failures, resource health, root cause of errors, troubleshoot event hubs, troubleshoot service bus, messaging SDK error, AMQP connection failure, message lock lost, lock renewal during long-running processing, service bus dead letter.
azure-prepare
microsoft/azure-skills
Prepare azd-based Azure projects for deployment: generates azure.yaml, infrastructure (Bicep/Terraform), and Dockerfiles for the Azure Developer CLI (azd) workflow. USE ONLY when the user explicitly wants to use azd as the deployment tool, or the project already has an azure.yaml file. DO NOT USE FOR: non-azd deployments, Python App Service code-only deploys (use python-appservice-deploy), or cross-cloud migration (use azure-cloud-migrate). WHEN: prepare app for azd, create azure.yaml, set up azd infrastructure, modernize app for Azure with azd, deploy with azd, function app, timer trigger, service bus trigger, event-driven function, managed identity, generate Bicep, generate Terraform, create and deploy to Azure.
azure-ai
microsoft/azure-skills
Use for Azure AI: Search, Speech, OpenAI, Document Intelligence. Helps with search, vector/hybrid search, speech-to-text, text-to-speech, transcription, OCR. WHEN: AI Search, query search, vector search, hybrid search, semantic search, speech-to-text, text-to-speech, transcribe, OCR, convert text to speech.
azure-deploy
microsoft/azure-skills
Execute Azure deployments for ALREADY-PREPARED applications that have existing .azure/deployment-plan.md and infrastructure files. DO NOT use this skill when the user asks to CREATE a new application — use azure-prepare instead. This skill runs azd up, azd deploy, terraform apply, and az deployment commands with built-in error recovery. Requires .azure/deployment-plan.md from azure-prepare and validated status from azure-validate. WHEN: "run azd up", "run azd deploy", "execute deployment", "push to production", "push to cloud", "go live", "ship it", "bicep deploy", "terraform apply", "publish to Azure", "launch on Azure". DO NOT USE WHEN: "create and deploy", "build and deploy", "create a new app", "set up infrastructure", "create and deploy to Azure using Terraform" — use azure-prepare for these.
azure-validate
microsoft/azure-skills
Pre-deployment validation for Azure readiness. Run deep checks on configuration, infrastructure (Bicep or Terraform), RBAC role assignments, managed identity permissions, and prerequisites before deploying. WHEN: validate my app, check deployment readiness, run preflight checks, verify configuration, check if ready to deploy, validate azure.yaml, validate Bicep, test before deploying, troubleshoot deployment errors, validate Azure Functions, validate function app, validate serverless deployment, verify RBAC roles, check role assignments, review managed identity permissions, what-if analysis, validate Container Apps deployment.