1k-monitor-pr-ci
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
$ARGUMENTSis a number, use it directly - If
$ARGUMENTSis a GitHub URL, extract the PR number - If
$ARGUMENTSis 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 checksonly returns CI status.gh pr view --json reviewsreturns PR-level reviews but NOT inline file comments.gh api .../pulls/.../commentsis 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 -100Extract 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)
More from onekeyhq/app-monorepo
react-best-practices
React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.
109implementing-figma-designs
Implements Figma designs 1:1 using OneKey component library (还原设计稿).
771k-coding-patterns
Coding patterns and best practices — React components, promise handling, and TypeScript conventions.
691k-code-quality
Code quality standards — lint (eslint/oxlint), type check (tsc), pre-commit hooks, and comment conventions. All comments must be in English.
681k-date-formatting
Date and time formatting — use OneKey dateUtils (formatDate/formatTime) instead of native JS date methods.
681k-git-workflow
Git workflow and conventions — branching, commit messages, and PR creation.
68