GH PR Results Review

Workflow

1. •Identify the PR number and check status.

• •Run:

gh pr checks <pr-number> 2>&1

• •Capture failing checks, durations, run URL, and job URLs.
• •If no failures exist, report success and stop.

1. •Resolve run and failing job IDs.

• •Derive the workflow run ID from the run URL when available.
• •Derive each failing job ID from job URLs, or list jobs with:

gh run view <run-id> --json jobs

1. •Pull logs for failed jobs.

• •For each failed job:

gh run view <run-id> --job <job-id> --log 2>&1 | tail -80

• •If the tail misses the error, inspect more lines or grep for error markers:

gh run view <run-id> --job <job-id> --log 2>&1 | rg -n "error|failed|traceback|E999|F401|mypy|pytest"

1. •Summarize root causes with evidence.

• •Report by failing check/job name.
• •Include the shortest exact evidence line(s) that explain failure.
• •State likely fix direction (for example: ruff import ordering, mypy type mismatch, failing pytest assertion).

Output Format

Use this structure:

check the CI failure details.

Reviewed GitHub Actions logs for test and linting results
Bash
gh pr checks <pr-number> 2>&1
<key failing checks output>

Bash
gh run view <run-id> --job <job-id> --log 2>&1 | tail -60
<relevant error/failure excerpt>

Bash
gh run view <run-id> --job <job-id> --log 2>&1 | tail -40
<relevant error/failure excerpt>

Then provide a short diagnosis section:

• •Finding: one sentence per failed job.
• •Evidence: command + key line.
• •Next fix: concrete first edit to attempt.

Guardrails

• •Do not claim a job failed without a log line proving it.
• •Prefer job-specific logs over workflow-level summaries.
• •Keep excerpts tight; include only lines needed to justify the finding.
• •If GitHub CLI lacks permission or run is missing, state the blocker and requested access explicitly.