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
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:
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 )