// Fetch the latest CI pipeline execution for the current branch. Returns the most recent CIPE which may be completed, in progress, or null. Use when you need to review CI status, check failures, or inspect CI state.
| name | get-latest-ci |
| description | Fetch the latest CI pipeline execution for the current branch. Returns the most recent CIPE which may be completed, in progress, or null. Use when you need to review CI status, check failures, or inspect CI state. |
Fetch the latest CI pipeline execution for the current branch. This is a one-shot fetch — return results immediately. Do NOT poll, loop, or wait for status changes.
git branch --show-currentgit rev-parse --short HEAD{% if platform == "claude" %}
Spawn a general-purpose subagent using the Task tool. The subagent will call the MCP tool and return results. Do NOT attempt to fetch CI information yourself — always delegate to the subagent.
{% raw %}
Task(
subagent_type: "general-purpose",
description: "Fetch latest CI status",
prompt: "Fetch the latest CI pipeline execution status. Do NOT use Bash for this.
Use the ci_information tool from the nx MCP server with these parameters:
select: 'cipeStatus,cipeUrl,branch,commitSha,selfHealingStatus,verificationStatus,userAction,failedTaskIds,verifiedTaskIds,selfHealingEnabled,failureClassification,couldAutoApplyTasks,shortLink,confidence,confidenceReasoning,hints'
Return ALL fields from the response as-is. Do not summarize or omit any fields.
If cipeStatus is FAILED and selfHealingStatus is COMPLETED or FAILED and there are failedTaskIds, make a SECOND call to the same tool with:
select: 'taskOutputSummary,suggestedFix,suggestedFixReasoning,suggestedFixDescription'
Return those fields too. Only return the first page — do not paginate."
)
{% endraw %} {% elsif platform == "codex" %}
Use a Codex built-in subagent to call the MCP tool and return results. Do NOT attempt to fetch CI information in the main conversation — delegate it so the MCP payload stays isolated.
{% raw %}
spawn_agent(
agent_type: "default",
message: "Fetch the latest CI pipeline execution status. Do NOT use shell commands for this.
Use the ci_information tool from the nx MCP server with these parameters:
select: 'cipeStatus,cipeUrl,branch,commitSha,selfHealingStatus,verificationStatus,userAction,failedTaskIds,verifiedTaskIds,selfHealingEnabled,failureClassification,couldAutoApplyTasks,shortLink,confidence,confidenceReasoning,hints'
Return ALL fields from the response as-is. Do not summarize or omit any fields.
If cipeStatus is FAILED and selfHealingStatus is COMPLETED or FAILED and there are failedTaskIds, make a SECOND call to the same tool with:
select: 'taskOutputSummary,suggestedFix,suggestedFixReasoning,suggestedFixDescription'
Return those fields too. Only return the first page — do not paginate."
)
{% endraw %}
Collect the result with wait_agent when you need to report it.
{% else %}
Call the ci_information tool from the nx MCP server with these parameters:
{% raw %}
select: 'cipeStatus,cipeUrl,branch,commitSha,selfHealingStatus,verificationStatus,userAction,failedTaskIds,verifiedTaskIds,selfHealingEnabled,failureClassification,couldAutoApplyTasks,shortLink,confidence,confidenceReasoning,hints'
{% endraw %}
If cipeStatus is FAILED and selfHealingStatus is COMPLETED or FAILED and there are failedTaskIds, make a second call with:
{% raw %}
select: 'taskOutputSummary,suggestedFix,suggestedFixReasoning,suggestedFixDescription'
{% endraw %}
Only return the first page — do not paginate. {% endif %}
Based on the subagent's response, report to the user. Always include the CIPE URL when available.
If the response contains a non-empty hints array, include those hints in the output to the user.
[get-latest-ci] No CI pipeline execution found for branch '<branch>'.
[get-latest-ci] CI passed!
[get-latest-ci] URL: <cipeUrl>
[get-latest-ci] Commit: <commitSha>
[get-latest-ci] CI is <IN_PROGRESS|NOT_STARTED>.
[get-latest-ci] URL: <cipeUrl>
[get-latest-ci] Commit: <commitSha>
If self-healing is also in progress, add:
[get-latest-ci] Self-healing: <selfHealingStatus> | Verification: <verificationStatus>
When cipeStatus == 'FAILED' AND selfHealingStatus == 'COMPLETED' AND suggestedFix != null:
[get-latest-ci] CI failed.
[get-latest-ci] URL: <cipeUrl>
[get-latest-ci] Commit: <commitSha>
[get-latest-ci] Failed tasks: <failedTaskIds>
[get-latest-ci]
[get-latest-ci] Self-healing fix available!
[get-latest-ci] Short link: <shortLink>
[get-latest-ci] Confidence: <confidence> — <confidenceReasoning>
[get-latest-ci] Verification: <verificationStatus>
[get-latest-ci] Auto-apply eligible: <couldAutoApplyTasks>
[get-latest-ci]
[get-latest-ci] Fix description: <suggestedFixDescription>
[get-latest-ci] Fix reasoning: <suggestedFixReasoning> (truncated to first page)
When cipeStatus == 'FAILED' AND selfHealingStatus == 'IN_PROGRESS':
[get-latest-ci] CI failed. Self-healing is generating a fix...
[get-latest-ci] URL: <cipeUrl>
[get-latest-ci] Commit: <commitSha>
[get-latest-ci] Failed tasks: <failedTaskIds>
[get-latest-ci]
[get-latest-ci] Use /monitor-ci to wait for the fix and apply it.
When cipeStatus == 'FAILED' AND (selfHealingStatus is FAILED, NOT_EXECUTABLE, or null):
[get-latest-ci] CI failed.
[get-latest-ci] URL: <cipeUrl>
[get-latest-ci] Commit: <commitSha>
[get-latest-ci] Failed tasks: <failedTaskIds>
[get-latest-ci] Self-healing: <selfHealingStatus or "not available">
[get-latest-ci] Classification: <failureClassification>
If taskOutputSummary was fetched, include a brief summary of failures.
When failureClassification == 'ENVIRONMENT_STATE':
[get-latest-ci] CI failed due to environment issue.
[get-latest-ci] URL: <cipeUrl>
[get-latest-ci] Classification: ENVIRONMENT_STATE
[get-latest-ci]
[get-latest-ci] Use /monitor-ci to request an environment rerun.
[get-latest-ci] CI was <CANCELED|TIMED_OUT>.
[get-latest-ci] URL: <cipeUrl>
[get-latest-ci] Commit: <commitSha>
When cipeStatus == 'FAILED' AND failedTaskIds is empty AND selfHealingStatus is null:
[get-latest-ci] CI failed but no Nx tasks were recorded (likely infrastructure issue).
[get-latest-ci] URL: <cipeUrl>
[get-latest-ci] Check CI provider logs for details.
/monitor-ci.Guidance for coordinating changes across multiple repositories using Polygraph. Use when working on a feature that affects another repository, coordinating changes/branches/PRs across repos, delegating tasks to child agents in different repos, discovering how code is consumed across repositories, or starting a multi-repo coordination session. TRIGGER when user mentions "polygraph", "other repos", "other repositories", "who uses this", "what uses this", "cross-repo", "multi-repo", "consuming this API/endpoint", "dependent repositories", or asks about what other repos are doing with shared code/APIs/endpoints.
Validate a publisher package change against consumer repos by building + packing the publisher and installing the tarballs into each consumer, so consumer CI can run against the unmerged change. USE WHEN a publisher repo (e.g. a design system, shared library, SDK) has a pending change that needs to be tested in downstream repos before its version is merged and published. TRIGGER when user says "pack and copy", "pre-release test in consumers", "test this package change in <consumer>", "install the unreleased version into the apps", or "validate this change against <consumer repo>".
Wait for CI to settle across all repos in a Polygraph session, then report results and investigate failures. USE WHEN user says "await polygraph", "wait for polygraph ci", "polygraph ci status", "check polygraph ci", "watch polygraph session", "monitor polygraph".