---
description: "System default workflow for pull request review and follow-through"
targets:
  - pull_request
autoSelect: false
updateMode: strict
requires:
  skills: []
  mcp: []
---
# Pull Request Review And Follow-Through

## Goal

Review or follow through on a pull request by determining whether the change matches its stated purpose, is safe for its affected surface, and has enough observable evidence for the requested outcome or review conclusion.

## Rules

- Treat the linked request, PR description, comments, and diff as separate evidence sources. Reconcile them before judging completion.
- Keep the review domain-neutral: software, documentation, configuration, workflows, data files, procedures, generated artifacts, and mixed changes all require intent, scope, risk, and evidence checks.
- Distinguish review-only work from authorized follow-through. Do not modify files, push changes, approve, merge, close, or perform irreversible actions unless the current run explicitly allows that action.
- Separate blocking findings from non-blocking observations. A blocking finding must explain what expected outcome could fail, where the evidence appears, and what change or decision would resolve it.
- Do not treat a review note, plan, or blocker report as proof that the PR outcome is complete unless reporting is the requested deliverable.

## Suggested Process

### 1. Reconstruct Purpose And Scope

- Identify the PR's stated goal, linked request, expected user or operational outcome, and any explicit constraints.
- Name the affected artifacts and audiences: runtime behavior, documentation readers, operators, reviewers, automation, data consumers, generated outputs, or downstream maintainers.
- Define in-scope and out-of-scope changes from the request and PR context before evaluating the diff.

### 2. Inspect The Change

- Compare the diff against the reconstructed scope and flag unrelated, surprising, missing, or over-broad changes.
- Read nearby context or rendered/generated outputs when the diff alone cannot prove correctness.
- For generated or derived artifacts, check whether their source, generation method, or expected synchronization is clear enough for the PR claim.

### 3. Review Quality And Risk

- Check correctness and completeness against the requested outcome, not only internal consistency.
- Consider safety, security, privacy, operational risk, compatibility, maintainability, rollback difficulty, and user-facing impact when relevant to the changed surface.
- For documentation or procedure changes, verify accuracy, clarity, audience fit, and whether instructions can be followed without missing prerequisites.
- For configuration, workflow, or data changes, inspect schema, naming, ordering, defaults, references, and failure behavior where applicable.

### 4. Verify With Evidence

- Use the smallest available checks that can prove the review claim: tests, linters, builds, previews, schema validation, rendered documents, artifact inspection, command output, file state, or reasoned trace through changed logic.
- When checks are unavailable or inappropriate, explain what was inspected instead and the claim boundary that evidence supports.
- If a check fails, decide whether it blocks the PR outcome, requires follow-through inside the authorized scope, or should be routed as a separately tracked blocker.

### 5. Follow Through Only When Authorized

- If the run authorizes edits, keep changes scoped to the PR goal and preserve unrelated work.
- After follow-through changes, re-check the specific claim the edit was meant to fix and report the new evidence.
- If follow-through would require product judgment, credentials, external approval, broad redesign, or irreversible action, stop and hand off instead of guessing.

## Handoff To Human When

- The PR intent, linked request, or acceptable scope remains ambiguous after inspecting available repository and PR evidence.
- Correctness depends on unavailable credentials, private external systems, production state, legal or compliance judgment, or product decisions.
- The next safe action would approve, merge, deploy, delete, rewrite history, publish, or otherwise perform an irreversible operation without explicit authorization.
- Required verification cannot be obtained and the remaining risk materially affects whether the PR should proceed.

## Success Criteria

- The final result states whether this was review-only or authorized follow-through.
- The result names the PR purpose, inspected change surface, and any scope mismatch or confirms none was found.
- Each blocking issue includes a concrete location or evidence reference, the expected result, the observed problem, and the action needed to resolve it.
- Non-blocking observations are clearly labeled separately from blockers.
- Verification evidence is reviewer-checkable: it names the evidence type, the target change or review claim inspected, and the expected observed result, plus the actual result or why it could not be obtained.
- Residual risk and unresolved questions are stated with claim boundaries, especially when evidence is partial, sampled, reasoned, or blocked.
- If the PR outcome is claimed complete, the evidence proves the requested outcome itself, not merely that a review, plan, or blocker report was produced.
