Monitor PR CI & Reviews
Monitor a pull request's CI checks and review comments. Auto-fix CI failures, prompt user for review feedback.
Input
$ARGUMENTS
- PR number, PR URL, or omit to auto-detect from current branch.
Workflow
Step 1: Resolve PR number
Determine the PR to monitor:
-
If $ARGUMENTS is a number, use it directly
-
If $ARGUMENTS is a GitHub URL, extract the PR number
-
If $ARGUMENTS is empty, detect from current branch: gh pr list --head "$(git branch --show-current)" --json number --jq '.[0].number'
-
If no PR found, stop and inform the user
Step 2: Poll loop
Each iteration ([Check N/30] ):
MUST run ALL three commands in parallel on every iteration (missing any one may cause review comments to be silently ignored):
1. CI check status
gh pr checks <PR_NUMBER>
2. PR-level reviews and general comments
gh pr view <PR_NUMBER> --json reviews,comments,reviewDecision
3. Inline review comments (e.g. from Devin, human reviewers)
gh api repos/{owner}/{repo}/pulls/<PR_NUMBER>/comments
--jq '.[] | {user: .user.login, body: .body, path: .path, line: .original_line, created_at: .created_at}'
Why all three? gh pr checks only returns CI status. gh pr view --json reviews returns PR-level reviews but NOT inline file comments. gh api .../pulls/.../comments is the ONLY way to get inline code review comments (the kind that appear on specific lines in the diff). Skipping it means inline comments from bots like Devin or human reviewers will be completely invisible.
Display status summary:
[Check 3/30]
CI Status:
| Check | Status | Duration |
|---|---|---|
| lint (24.x) | pass | 5m34s |
| unittest (24.x) | pending | - |
Reviews: 1 new comment from @reviewer
Decide next action based on priority:
CI Status Reviews Action
Any fail
Auto-fix CI failure (Step 3)
Any pending New comments Show comments to user, keep waiting
Any pending No new comments Wait 60s, re-check
All pass New comments Show comments to user (Step 4)
All pass No new comments Done (Step 5)
Step 3: Auto-fix CI failures
For each failed check:
Get failure log:
gh run view <RUN_ID> --log-failed 2>&1 | tail -100
Extract the run ID from the check URL.
Analyze the failure and determine the cause.
Fixable (lint error, type error, test failure from our changes):
-
Fix the code
-
Commit: fix: resolve CI <check-name> failure
-
Push to PR branch
-
Wait 30s, return to Step 2
Not fixable (infra issue, flaky test, unrelated failure):
-
Report failure details to user
-
Suggest actions (re-run, skip, manual fix)
-
Ask user how to proceed
Step 4: Handle review comments
When new review comments are detected:
Display each comment clearly:
New review comment from @reviewer: File: src/views/Example.tsx:42
Consider using useCallback here to prevent re-renders
Review decision: CHANGES_REQUESTED
Prompt the user:
-
Show all unresolved comments
-
Ask: "Do you want me to address these review comments?"
-
If user says yes: fix the code, commit, push, return to Step 2
-
If user says no/later: continue monitoring CI only
Track comment state: Remember which comments have been shown to avoid repeating them in subsequent iterations.
Step 5: Final report
When all CI checks pass and no new unhandled comments:
All CI checks passed!
| Check | Status | Duration |
|---|---|---|
| lint (24.x) | pass | 5m34s |
| unittest (24.x) | pass | 4m42s |
| CodeQL | pass | 2m7s |
Review status: approved / no reviews / changes requested PR: <URL>
-
All CI passed + approved → ready to merge
-
All CI passed + no review → waiting for review
-
All CI passed + changes requested → needs to address comments
Polling Rules
-
60 seconds between checks when pending
-
30 seconds after fix+push to allow CI restart
-
Maximum 30 iterations (~30 min), then ask user to continue or stop
-
Always show [Check N/30]
Important Notes
-
CI failures: auto-fix without asking
-
Review comments: always show to user, ask before fixing
-
Never force-push or amend commits
-
Each fix is a new commit
-
Fix multiple CI failures in one commit when possible
-
Do NOT re-run checks automatically (only if user requests gh run rerun )