PR Review Loop

Drive a GitHub pull request through an iterative review-and-fix loop. Use when Codex needs to create a PR if none exists for the current branch, inspect revi...

Security Scan

The skill's requirements and runtime instructions are coherent with its stated purpose of iterating on GitHub PRs; it asks only for git/gh access and a GitHub token and its instructions limit risky actions like force-pushes.

Purpose & Capability

Name/description (PR review loop) align with requested binaries (git, gh) and the GitHub token. The skill's declared needs are what you'd expect for creating/updating PRs, running CI checks, and pushing commits.

Instruction Scope

SKILL.md instructs only PR-focused actions (finding/creating PRs, reading review threads, editing repository files, running tests, pushing branches, resolving threads). It explicitly forbids asking users to paste tokens or reading unrelated secret files and requires verification of repository/branch/permissions before edits.

Install Mechanism

Instruction-only skill with no install spec or downloaded code; lowest-risk install surface.

Credentials

The only credential in scope is GITHUB_TOKEN (primary). This is proportionate to the task. Note: the registry metadata shows a minor inconsistency — the top-level listing marks GITHUB_TOKEN as required while SKILL.md/metadata describe it as optional if host auth (MCP/gh/git helper) is available; the capability requested is still appropriate but the documentation should be consistent about whether a token is mandatory.

Persistence & Privilege

Skill is not always: true and is user-invocable. It allows autonomous invocation by default (platform default) but agents/openai.yaml contains an invocation guardrail. The skill's allowed operations (force-with-lease, branch-limited history rewrite) are reasonable for PR work but should be used with caution.

Assessment

This skill appears to do what it says: iterate on PR comments, make fixes, run tests, and push updates. Before installing or enabling it: (1) Prefer using the host's GitHub auth (MCP/gh/git credential helper) rather than pasting a token; if you must provide GITHUB_TOKEN, scope it as narrowly as possible (repository and branch only). (2) Ensure branch protection and audit controls are in place because the skill will rewrite history and force-push the PR head when the user requests that strategy. (3) Confirm you are comfortable with an agent having read/write access to the target repo (the skill will edit files and push commits). (4) If you want additional guardrails, require explicit user confirmation before any force-push or history rewrite, and verify the metadata inconsistency about whether GITHUB_TOKEN is required or optional is corrected.

GitHub PR Review Loop

Goal

Take ownership of the full post-PR loop. Create the PR if it does not exist yet, then keep iterating until the stop condition is met instead of stopping after a single fix or a single green CI run.

Access And Safety

• Use only GitHub access already provided by the host environment, such as the configured github MCP server, gh CLI auth, or the local git credential helper. Do not ask the user to paste tokens into chat, and do not read secret files.
• Before any edit, push, PR mutation, or review-thread resolution, verify that the repository, PR, active branch, and intended history strategy match the user's request.
• Treat missing GitHub permissions, missing git remote auth, or an ambiguous target repository/branch as a real blocker and report it instead of guessing.
• Limit history rewrites and force pushes to the active PR head branch. Never force-push a default, base, protected, or unrelated branch.
• Only use this skill for explicit PR review-loop work, such as handling review comments, keeping a PR branch green, or waiting for reviewer approval.

Start

• Identify the repository, PR number, active branch, and any user constraints before editing anything.
• Check whether a PR already exists for the current branch. If not, create one before entering the review loop.
• Check whether the user wants a single commit, --amend, separate commits, rebasing onto latest main, or a waiting window such as "poll every 10 minutes".
• If the user says the branch must stay as one squashed commit, interpret that strictly: keep exactly one commit on top of the current remote base, use git commit --amend --no-edit for follow-up fixes, and avoid creating extra local commits unless you are about to squash them away immediately.
• If the user says the branch must stay based on the latest main, treat origin/main as the source of truth. Fetch it before each history rewrite that will be pushed, then rebase or rebuild the branch so the published head still sits on top of the latest remote main.
• Assume automated review is triggered by the repository itself unless the user explicitly says to summon it. Do not post @codex review or similar reviewer-ping comments by default.
• Check the current git state before rewriting history. Do not overwrite unrelated work.
• Prefer non-interactive git commands. Use --force-with-lease when rewriting published history.
• Default to persistence only after the target repo, PR, branch, and history strategy are clear. Once the loop starts, do not stop midstream to ask whether to continue watching for reviews unless you hit a real blocker that cannot be resolved from local or remote context.

Source Of Truth

Do not rely on one surface only. Review state is usually split across multiple places.

• Use GitHub review threads as the primary source for unresolved inline comments.
• Use PR conversation comments and review summaries to catch top-level bot reviews.
• Use PR reactions to detect automated reviewer status markers such as eyes or final +1.
• Use gh pr checks and gh run watch for required CI state.

If review threads say everything is resolved but the bot keeps commenting, re-check both the review timeline and reactions. Inline-only polling is not enough.

Work Loop

1. Find or create the PR for the current branch.
2. Fetch current review state, unresolved threads, conversation comments, reactions, and CI status.
3. Pick the next actionable comment and inspect the exact file and code path before changing anything.
4. Decide whether the comment is a real bug, a partial truth that needs a broader hardening pass, or a false alarm.
5. Implement the fix and add regression tests when behavior changes.
6. Run targeted validation first, then the broader checks required by the repository or the user.
7. Update git history in the form the user asked for.
8. Push the branch.
9. Resolve the review thread only after the fix is actually on the remote branch.
10. Watch CI until the latest required run finishes.
11. Wait and poll again for new feedback until the stop condition is met.

Fixing Review Comments

• Read the exact comment text and the cited file/line range. Do not infer a narrower issue than the reviewer actually reported.
• When multiple comments share the same root cause, prefer a single stronger fix over a sequence of tiny patches.
• If a comment looks questionable, verify it against the current code and tests before dismissing it.
• When the user asked for review handling, do the implementation work directly instead of only summarizing a plan.

Validation

• Start with the smallest test slice that proves the fix.
• Run lint and type checks for the edited scope.
• Run the larger suite required by repo policy when practical.
• If CI has known flakes, confirm they are the same flaky failures before rerunning them.
• When reporting status, mention the concrete failing or passing check name and run id if relevant.

Git And PR Updates

• Respect the user's history preference.
• If there is no PR for the current branch, create one instead of waiting for the user to ask.
• If the user wants one commit, keep amending that single commit.
• If the user wants a clean branch based on latest remote main, rebase or rebuild onto origin/main before the final push.
• If you discover the branch is not based on the latest remote base branch, immediately fetch and rebase onto that latest remote branch before continuing the PR loop.
• If the user wants both, enforce both on every iteration: fetch origin/main, rewrite the branch onto that tip, keep the branch as a single commit, then push with --force-with-lease.
• When a temporary commit is unavoidable during local repair work, squash it back into the single published commit before pushing. Do not leave multiple commits on the branch between review-loop iterations.
• Push after local validation, then re-check the PR state from the remote, not from local assumptions.
• Resolve threads that are fixed. Leave unresolved anything that still needs proof or follow-up.
• Do not ping or @ the reviewer unless the user explicitly asks for that. This includes automated reviewers such as @codex.

Waiting And Polling

• Treat eyes from an automated reviewer as "still processing", not done.
• Assume the automated reviewer will start on its own when the repository is configured that way; do not try to kick it manually unless the user explicitly asks.
• Treat a final +1 or thumbs-up reaction from the automated reviewer as the default completion signal for this skill unless the user explicitly changes the stop condition.
• If the user asked for a waiting window, keep polling on that cadence instead of stopping after one green pass.
• While waiting for comments, also make sure the latest CI run stays green.
• Do not stop after green CI, resolved threads, or a quiet PR if the automated reviewer has not yet produced its final thumbs-up reaction.
• Do not pause mid-loop to ask the user whether to keep monitoring. Keep polling until the stop condition is met or you hit a real blocker such as missing permissions, missing GitHub access, or a reviewer system that is unavailable.

Stop Condition

Stop only when the requested completion condition is satisfied. Default completion criteria for this skill are:

• No unresolved actionable review threads remain.
• The latest required CI checks are passing.
• The automated reviewer has stopped producing new feedback.
• The automated reviewer has added a final thumbs-up reaction.

Do not treat "no new comments yet" as completion. Do not stop merely to ask whether to continue waiting. Only stop early if the user explicitly changes the stop condition or a hard blocker prevents further progress.

Useful Commands

git fetch origin main
gh pr checks <pr-number> --repo <owner/repo>
gh run watch <run-id> --repo <owner/repo> --exit-status --interval 30
gh run rerun <run-id> --repo <owner/repo>
git commit --amend --no-edit
git push --force-with-lease

Reporting Back

• State what was fixed, what was validated, and what the current PR/CI/review state is.
• Include exact PR numbers, run ids, and commit SHAs when they matter.
• If you are still in the waiting loop, say that explicitly instead of sounding finished.
• During the loop, give status updates without asking whether to continue unless a real blocker requires user intervention.