/pr-review-ci-loop

name: pr-review-ci-loop
description: Use when a pull request needs one bounded review and CI triage cycle with explicit approval before edits or remote writes.

Purpose

Combine PR review and CI failure triage into one human-controlled loop. Review findings and CI logs are inputs; they are not permission for autonomous remote actions.

When to Use

• A PR needs both technical review and CI failure triage.
• The user wants a single inspect -> summarize -> patch -> recheck cycle.
• Local fixes depend on accurate PR diff and CI log context.

Do not use when the user only asked for a review, only asked for CI diagnosis, or has not approved edits.

Core Rules

• Remote writes such as push, comment, and request re-review are always opt-in.
• Local changes must be grounded in specific review findings or failing CI checks.
• Prefer GitHub-first flows; treat other CI providers as adaptations.
• Do not apply speculative fixes.

Inputs

• PR number, branch, or URL
• Repository remote and base branch
• CI provider access, preferably `gh` for GitHub-hosted PRs
• User approval boundary for local edits and remote writes

Workflow

1. Read PR metadata and diff

gh pr view <pr> --json number,title,author,baseRefName,headRefName,mergeStateStatus,reviewDecision,statusCheckRollup
gh pr diff <pr> --stat
gh pr diff <pr>

Record file count, risky areas, generated files, and public API changes.

2. Identify review risks

Classify findings by severity:

| Category | What to check | | --- | --- | | Correctness | Logic errors, off-by-one, wrong assumptions | | Tests | Missing coverage for changed behavior, broken assertions | | Public API | Breaking changes to exports, signatures, or contracts | | Security | Injection risks, exposed secrets, auth bypass | | Migration / release risk | Schema changes, feature flags, rollback difficulty |

3. Inspect CI failures

gh pr checks <pr>
gh run view <run-id> --log-failed

Extract the first failing assertion or error line. Categorize each failure as code error, flaky, environment, or config.

4. Produce one readout

REVIEW FINDINGS:
  [blocking] <description> - <file:line or section>
  [non-blocking] <description>

CI FAILURES:
  <check name>: <first error line>
  Likely cause: <code error / flaky / env / config>

LIKELY FIXES:
  1. <specific change>
  2. <specific change>

VALIDATION PLAN:
  - Run: <command>
  - Expected: <outcome>

5. Apply approved local fixes

• Apply only what the user approves from the readout.
• Run local validation after each fix.
• Keep commits and pushes separate from local edits unless approved.

6. Remote follow-up

State the exact operation before running it:

NEXT REMOTE ACTION: git push origin <branch>
EFFECT: updates the remote branch, triggering CI re-run
Approve?

Output

• Combined PR review and CI readout
• Approved local diff, if any
• Validation commands and results
• Proposed remote action, if requested

Verification

• [ ] PR metadata and full diff were read.
• [ ] Every changed file was considered or explicitly excluded with reason.
• [ ] Review findings have severity and location.
• [ ] CI failures have a cause category and first useful error line.
• [ ] Any local fix was validated before proposing remote follow-up.
• [ ] Remote follow-up was explicitly approved before execution.

Failure Modes

• Ambiguous review feedback that needs the PR author.
• No access to the PR or CI logs.
• CI failure requires infrastructure changes outside this codebase.
• Fix would require unattended remote writes.