Monitor GitHub Actions

Follow a named GitHub Actions run through completion and report what actually ran. Default to read-only monitoring. A green run icon is not enough when required jobs skipped or the run belongs to the wrong revision.

Route precisely

• Use when asked to watch, wait for, or report the outcome of a GitHub Actions run, release pipeline, or deployment workflow.
• Use prove-checks when the question is whether an already green check could detect a defect.
• Use code-review for a diff and fix-pr for reviewer feedback. Do not edit workflow YAML as part of monitoring unless separately requested.

Pin the target

1. Resolve repository, run ID or URL, workflow name, commit SHA, branch, event, attempt number, and any required jobs or artifacts from the user's request or provider metadata.
2. If multiple runs plausibly match, identify the ambiguity before reporting one as the target. Do not substitute the latest run merely because it is visible.
3. Record the expected outcome: completion only, required jobs passing, a release artifact, deployment environment, or a downstream trigger. These are different claims.

Wait and inspect

Use the provider API or authenticated CLI in bounded waits that allow progress updates. Poll only while the named run remains active; report a timeout as still running, not failed. After completion, read per-job conclusions, including skipped, cancelled, and neutral; verify that each required job actually ran and succeeded unless the task explicitly expects another conclusion. Inspect relevant step logs or artifacts only after they are available. Distinguish workflow source echoed into logs from output emitted by execution.

When a required job failed, classify the observed cause from its logs: deterministic code or configuration failure, missing authorization or secret, infrastructure interruption, or unknown. A re-run uses the same commit. Re-run failed jobs only when the user authorized retries and the failure is plausibly transient; otherwise report the recommended recovery. Never re-run to conceal a deterministic failure or to claim a code fix was tested; new code requires a new run at its new commit.

Report

Return run identity and attempt, observed state, required-job matrix, relevant log or artifact evidence, any action taken, and remaining uncertainty. Say SUCCESS only for the specific requested condition that was observed. Say INCOMPLETE when a required job skipped or an expected artifact is absent, even if the provider's aggregate conclusion is green. Do not claim deployment succeeded solely from build success.