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.