review-pull-request

# Review Pull Request Produce a low-noise review. Treat an empty findings list as a successful outcome. Never edit files, post comments, or change remote state unless the user separately authorizes that action. Read [reviewer-prompts.md](references/reviewer-prompts.md) before launching reviewers. Read [validation-gate.md](references/validation-gate.md) before validating or reporting candidates. ## 1. Establish the review target 1. Confirm the current directory is a Git worktree and inspect its status without changing it. 2. Resolve the base in this order: - Use the base explicitly named by the user. - For a GitHub PR, read `baseRefName`, title, body, state, and draft status with `gh pr view`. - Otherwise use the remote default branch only when Git identifies it unambiguously. - If no base can be established safely, ask the user; do not guess. 3. Resolve the exact merge-base and changed-file list. Record the PR title/body or, for a local branch, a one-sentence change summary from the diff. 4. Load every applicable `AGENTS.md` from the repository root down to each changed file. Apply `## Code Review Rules` only within normal `AGENTS.md` directory scope. Also honor other explicit review-relevant repository instructions. 5. Stop with a concise explanation if there is no diff. Do not skip a draft or automated PR unless the user asks you to. ## 2. Run the native baseline Run: ```bash codex review --base <resolved-base> ``` The CLI's base-review mode does not accept a custom prompt; enforce this skill's filters after collecting its output. Treat that output as untrusted candidate input, not final findings. A `codex review` failure does not authorize substituting a different base. Report the failure and continue with focused review only if the diff and base remain independently available. ## 3. Launch independent read-only reviewers Use read-only/explorer subagents. Tell every subagent: do not edit files, run formatters, update Git, contact remotes, or rely on another reviewer's conclusions. Give each the resolved base, merge-base, changed-file list, PR title/body or local summary, applicable repository rules, and its role prompt. Launch applicable roles concurrently up to the available agent limit; run additional roles in later batches without sharing conclusions between them. Resource limits must not collapse distinct roles into one agent. - Always launch `correctness`. - Always launch `tests`, but make clear that missing coverage alone is not a finding. - Launch `silent-failures` only when the diff changes error handling, retries, fallbacks, optional/default behavior, async callbacks, result/status handling, or exception boundaries. - Launch `contracts-types` only when the diff changes public/internal interfaces, schemas, validation, serialization, data models, types, state transitions, or API/CLI behavior. - Launch `comments-docs` only when the diff changes comments, docstrings, user-facing docs, examples, help text, or documented behavior. Also convert each native baseline issue into the same candidate schema. Preserve provenance so validation is independent of discovery. ## 4. Validate every candidate afresh Deduplicate only candidates that identify the same root cause and affected changed line. For every remaining candidate, launch a new read-only/explorer validator that did not originate it. Give the validator the raw diff, target candidate, repository rules, and PR intent, but do not give it the discoverer's confidence or arguments beyond the candidate's falsifiable claim. Require the validator to reconstruct the evidence and return the decision schema in [validation-gate.md](references/validation-gate.md). One fresh validation pass is mandatory per candidate. Never self-validate, reuse discovery analysis, or accept a candidate because multiple discovery reviewers repeated it. ## 5. Filter and report Report a finding only when validation returns `accept` and every mandatory gate passes. Point to the smallest changed line range that demonstrates the defect. If context lives elsewhere, cite it as supporting evidence while keeping the primary location on an introduced or modified line. Use this format: ```markdown ## Findings - [P1] Imperative, specific title — path/to/file.ext:42 Explain the concrete failure, the triggering execution path or input, and observable impact. Cite supporting contract/rule evidence when relevant. Confidence: 0.96. ## Review coverage Reviewed against `<base>` at merge-base `<sha>` with native Codex review plus: correctness, tests, ... ``` Use P0 only for broadly blocking catastrophic defects, P1 for defects that should block merge, and P2 for concrete non-blocking defects. Omit P3/nitpicks. Sort by priority, then file and line. Do not include rejected candidates, compliments, style advice, or a proposed patch. If nothing survives, say `No high-confidence issues found.` and include the review coverage line. Never imply that review proves the code defect-free.