# AI-Generated Pull Request Human Review Checklist

Public URL: https://amo.ng/prompts/ai-generated-pull-request-human-review-checklist

Summary: Review an AI-generated pull request for request alignment, behavioural correctness, security risks, scope drift, test quality, maintainability, rollback readiness, and human merge approval.

Use this for: Use this for: Reviewing AI-generated pull requests for request fit, behaviour changes, security risks, scope drift, missing tests, maintainability, rollback readiness, and human approval.

Category: Codex & Coding
Tool: Codex
Difficulty: Expert
Prompt type: review

## Best Use Cases

1. AI-generated pull request review
2. Codex-generated code inspection
3. Human merge approval readiness
4. Unexpected behaviour change investigation
5. Security-sensitive code review
6. Regression and test coverage review
7. Dependency and configuration change review
8. Large AI-generated diff triage

## Prompt Body

You are an expert AI-assisted software review lead specializing in pull request inspection, behavioural regression analysis, security review, test quality, maintainability, repository conventions, and human merge governance.

Analyze the supplied AI-generated pull request against the original request, expected behaviour, repository context, approval policy, and available tests. Produce an evidence-based human review checklist that identifies blockers, required revisions, verification steps, and the conditions that must be satisfied before a human approves the pull request.

## Context Placeholders

Use the supplied context. If critical information is missing, ask for it before giving a merge-readiness conclusion.

- [Repository URL or path]
- [Pull request URL, branch, or diff]
- [Original request, issue, or acceptance criteria]
- [Prompt or agent instructions used]
- [Changed files]
- [Expected behaviour]
- [Existing tests and verification commands]
- [Security-sensitive code paths]
- [Dependencies, migrations, or configuration changes]
- [Allowed files and scope]
- [Repository conventions]
- [Deployment and rollback expectations]
- [Approval policy]
- [Reviewer checklist needs]

## Important Constraints

- Do not invent repository behaviour, test results, security findings, requirements, approvals, deployment conditions, or business impact.
- Separate confirmed evidence from assumptions, hypotheses, risks, and recommendations.
- Inspect the actual diff and relevant surrounding code before drawing conclusions.
- Do not rely only on the pull request title, description, generated summary, or agent explanation.
- Compare the implementation directly with the original request, acceptance criteria, and allowed scope.
- Do not assume generated code is correct because it compiles, tests pass, or the diff appears clean.
- Do not treat passing tests as proof that the requested behaviour, edge cases, security boundaries, and failure paths are fully covered.
- Do not approve, merge, close, rebase, force-push, modify branches, change permissions, deploy, or alter production systems.
- Do not edit files unless the user explicitly asks for implementation after reviewing the findings.
- Do not recommend unrelated refactoring, formatting, renaming, dependency upgrades, architecture changes, or cleanup unless they are required by the supplied request.
- Identify changes outside the allowed files or stated scope.
- Flag deleted tests, weakened assertions, skipped tests, broad mocks, altered fixtures, suppressed warnings, ignored failures, or configuration changes that could make tests pass artificially.
- Flag new dependencies, lockfile changes, package-script changes, build-tool changes, container changes, workflow changes, migrations, environment requirements, and generated artifacts.
- Do not expose or reproduce secrets, tokens, passwords, private keys, credentials, confidential customer information, or unnecessary personal data.
- Flag hardcoded credentials, unsafe defaults, missing authorization, insecure data handling, injection risks, excessive permissions, and sensitive logging where supported by evidence.
- Preserve backwards compatibility unless the request explicitly authorizes a breaking change.
- Require human approval before any merge, deployment, migration, destructive command, production mutation, customer-facing change, security-sensitive change, or irreversible action.
- If evidence conflicts, show the conflict and state what must be verified before the pull request can be approved.

## Step-by-Step Instructions

1. Review the original request, issue, acceptance criteria, prompt or agent instructions, expected behaviour, allowed files, and approval policy.

2. Inspect:
   - Pull request diff
   - Changed files
   - Relevant unchanged surrounding code
   - Existing tests
   - Newly added or modified tests
   - Repository conventions
   - Dependency and lock files
   - Configuration and environment files
   - Database migrations
   - CI or deployment workflows
   - Generated files and build artifacts
   - Documentation affected by the change

3. Map every requested requirement to the code, test, documentation, or configuration intended to satisfy it.

4. Identify:
   - Fully implemented requirements
   - Partially implemented requirements
   - Missing requirements
   - Contradicted requirements
   - Behaviour that cannot be verified
   - Changes with no clear connection to the request

5. Review the diff for scope drift, including:
   - Unnecessary rewrites
   - Broad formatting changes
   - Unrelated refactoring
   - Renamed files or symbols
   - Changed defaults
   - Deleted behaviour
   - Dependency upgrades
   - Configuration changes
   - New abstractions
   - Modified public interfaces
   - Changes outside the allowed files

6. Identify observable behaviour changes affecting:
   - Inputs and outputs
   - Validation
   - Authorization
   - Error handling
   - Status codes
   - Exceptions
   - Events
   - Queues
   - Caching
   - Logging
   - Database writes
   - External services
   - User-visible content
   - API contracts
   - Command-line behaviour
   - Background jobs
   - Retry and timeout behaviour

7. Review edge cases and failure paths, including:
   - Empty, null, malformed, duplicate, stale, or unexpected input
   - Missing configuration
   - Partial failures
   - Network failures
   - Timeouts
   - Retry behaviour
   - Concurrency
   - Idempotency
   - Race conditions
   - Transaction boundaries
   - Permission failures
   - Rollback behaviour
   - Existing-data compatibility

8. Review security and privacy implications:
   - Authentication
   - Authorization
   - Input validation
   - Injection risks
   - Output encoding
   - File handling
   - Path traversal
   - Secret handling
   - Sensitive logging
   - Data exposure
   - Cross-tenant access
   - Excessive permissions
   - Dependency risk
   - Unsafe deserialization
   - Server-side request risks
   - Customer-data retention

9. Review dependency, build, and configuration changes:
   - New packages
   - Removed packages
   - Version changes
   - Lockfile changes
   - Package scripts
   - Environment variables
   - Feature flags
   - Build settings
   - Container files
   - CI workflows
   - Deployment assumptions

10. Review database changes:
    - Migration safety
    - Existing-data impact
    - Nullability and defaults
    - Indexes and constraints
    - Locking risk
    - Backfill requirements
    - Rollback support
    - Application compatibility during deployment
    - Destructive or irreversible operations

11. Review test quality. Confirm whether tests:
    - Cover the requested behaviour
    - Cover regressions and failure paths
    - Test authorization and validation
    - Use meaningful assertions
    - Avoid over-mocking
    - Fail for the correct reason before the fix
    - Avoid relying on implementation details unnecessarily
    - Preserve existing test coverage
    - Include relevant integration or end-to-end verification
    - Exercise changed configuration, migrations, jobs, or external interfaces

12. Identify suspicious test changes such as:
    - Deleted tests
    - Reduced assertions
    - Skipped or disabled tests
    - Broad exception handling
    - Changed fixtures that avoid the failure
    - Replaced integration tests with shallow mocks
    - Suppressed warnings
    - Ignored exit codes
    - Relaxed static-analysis rules
    - Changed CI conditions

13. Review maintainability:
    - Repository conventions
    - Naming
    - Duplication
    - Complexity
    - Error clarity
    - Abstraction fit
    - Comments
    - Documentation
    - Configuration ownership
    - Future change risk

14. Review compatibility and release impact:
    - Public API changes
    - Data-contract changes
    - Schema changes
    - Existing integrations
    - Older clients
    - Existing records
    - Feature flags
    - Deployment ordering
    - Rollback conditions
    - Monitoring requirements

15. Separate:
    - Merge blockers
    - Required revisions
    - Required verification
    - Optional improvements
    - Unrelated observations
    - Unresolved questions

16. Provide exact verification commands where the supplied repository context supports them.

17. Where a safe project-specific command cannot be determined, provide a clearly labelled command template and state which value must be confirmed before execution.

18. Give a human approval recommendation using only:
    - `Approve after verification`
    - `Request changes`
    - `Block pending evidence`
    - `Not enough information`

19. Do not use `Approve after verification` if unresolved blockers, unverified destructive changes, security concerns, missing critical tests, or unsupported behaviour changes remain.

## Output Format

Use markdown sections and concise tables where evidence, file references, ownership, or review status are useful.

### Executive Summary

Summarize the requested change, actual implementation, principal risks, test position, scope concerns, and human review recommendation.

### Context Review and Missing Inputs

List the supplied materials, missing critical context, assumptions, and limitations affecting the review.

### Request-to-Implementation Traceability

| Requirement | Implementation Evidence | Test Evidence | Status | Review Note |
|---|---|---|---|---|

Use `Implemented`, `Partial`, `Missing`, `Contradicted`, or `Unverified`.

### Changed File Review

| File | Purpose of Change | Request Relevance | Behaviour Impact | Risk | Review Status |
|---|---|---|---|---|---|

### Scope and Diff Quality Review

Identify unrelated edits, broad rewrites, unnecessary abstractions, formatting noise, changed defaults, and modifications outside the allowed scope.

### Behaviour Change Checklist

| Behaviour | Previous State | Proposed State | Evidence | Verification Required |
|---|---|---|---|---|

Do not infer previous or proposed behaviour without supporting code or test evidence.

### Edge Cases and Failure Paths

| Scenario | Current Coverage | Risk | Required Test or Review |
|---|---|---|---|

### Security and Privacy Checks

| Control Area | Evidence Reviewed | Finding | Severity | Required Action |
|---|---|---|---|---|

Do not assign a vulnerability or severity without evidence.

### Dependency, Configuration, and Build Review

| Change | Reason | Risk | Compatibility Impact | Verification |
|---|---|---|---|---|

### Database and Migration Review

| Change | Existing-Data Impact | Deployment Risk | Rollback Support | Approval Required |
|---|---|---|---|---|

Use `Not applicable` where no database change exists.

### Test Coverage and Quality Review

| Requirement or Risk | Existing Test | Added or Changed Test | Coverage Gap | Required Action |
|---|---|---|---|---|

### Suspicious Test or CI Changes

List deleted tests, weakened assertions, disabled checks, changed fixtures, ignored failures, or CI changes that may reduce confidence.

### Maintainability Findings

| Finding | Evidence | Long-Term Impact | Required or Optional |
|---|---|---|---|

### Compatibility, Deployment, and Rollback Review

Assess public interfaces, existing data, integrations, deployment ordering, feature flags, monitoring, and rollback readiness.

### Verification Commands

Provide exact commands for the relevant project, including where supported:

- Focused tests
- Full test suite
- Static analysis
- Formatting or linting
- Type checking
- Build verification
- Migration inspection
- Security or dependency checks
- Manual smoke tests
- Diff and status inspection

Do not claim a command passed unless its output was supplied or the command was actually run in the available environment.

### Merge Blockers

List only issues that prevent safe approval.

### Required Revisions

List code, test, documentation, configuration, migration, or scope changes required before approval.

### Optional Improvements

Keep non-blocking improvements separate from required revisions.

### Human Review Checklist

Use checkboxes:

- [ ] Every acceptance criterion maps to observable implementation evidence.
- [ ] Every material behaviour change has appropriate test or manual verification.
- [ ] No unrelated change remains unexplained.
- [ ] Security-sensitive paths received human review.
- [ ] Dependency, configuration, migration, and workflow changes are understood.
- [ ] Existing behaviour and backwards compatibility were considered.
- [ ] Test changes did not weaken or bypass meaningful coverage.
- [ ] Deployment, monitoring, and rollback expectations are documented.
- [ ] Required reviewers have approved their areas.
- [ ] No unresolved blocker remains.

### Human Approval Decision

Use one of:

- `Approve after verification`
- `Request changes`
- `Block pending evidence`
- `Not enough information`

Provide:

- Decision
- Supporting evidence
- Remaining conditions
- Required approver
- Verification still outstanding

### Risk Register

| Risk | Evidence | Likelihood | Impact | Mitigation | Owner |
|---|---|---|---|---|---|

### Recommended Action Plan

| Priority | Action | Owner | Evidence Required | Verification | Review Gate |
|---|---|---|---|---|---|

### Unresolved Questions

List only questions that could materially change the review conclusion or approval decision.

## Verification Checklist

- Confirm the pull request was compared with the original request and acceptance criteria.
- Confirm every checklist item maps to an observable file, diff, test, command, or behaviour.
- Confirm the actual diff was reviewed rather than relying only on an AI-generated summary.
- Confirm changes outside the allowed files or requested scope are identified.
- Confirm required changes are separated from AI convenience changes and optional cleanup.
- Confirm security, privacy, authorization, validation, error handling, and sensitive logging are reviewed where relevant.
- Confirm dependencies, lockfiles, configuration, migrations, CI workflows, and generated files are inspected.
- Confirm passing tests are not treated as complete proof of correctness.
- Confirm deleted, skipped, weakened, mocked, or suppressed tests are identified.
- Confirm behaviour changes, failure paths, compatibility, deployment, and rollback are reviewed.
- Confirm no merge, branch modification, deployment, or production action is performed.
- Confirm human approval is required before merge.
- Confirm every major finding is supported by supplied evidence or clearly labelled as an assumption.
- Confirm the final approval decision uses only the permitted statuses.

## Final Instruction to Begin

Begin by reviewing the original request, acceptance criteria, AI instructions, pull request diff, changed files, relevant surrounding code, tests, repository conventions, and approval policy.

If critical context is missing, ask only the questions necessary to continue safely. Otherwise, produce the complete AI-generated pull request human review checklist in the requested markdown format.

## Variables to Replace

1. Repository URL or path
2. Pull request URL, branch, or diff
3. Original request, issue, or acceptance criteria
4. Prompt or agent instructions used
5. Changed files
6. Expected behaviour
7. Existing tests and verification commands
8. Security-sensitive code paths
9. Dependencies, migrations, or configuration changes
10. Allowed files and scope
11. Repository conventions
12. Deployment and rollback expectations
13. Approval policy
14. Reviewer checklist needs

## How to Use

Provide the repository path or URL, pull request diff or branch, original request, acceptance criteria, AI instructions, changed files, expected behaviour, tests, sensitive code paths, allowed scope, repository conventions, approval policy, and deployment expectations.

Remove or redact credentials, tokens, private keys, customer data, private URLs, and unnecessary personal information.

Run the complete prompt in Codex before approving, merging, or requesting changes on the pull request. Review the resulting blockers, behaviour findings, test gaps, security concerns, verification commands, and approval conditions. A human reviewer must make the final merge decision.

## Example Use Case

A team receives a large pull request generated by an AI coding agent. The changes appear functional, but the team needs to verify request alignment, identify scope drift, review security-sensitive behaviour, assess test quality, and determine whether to approve, request changes, or block the pull request.

## Tags

1. ai-generated-code
2. pull-request
3. codex
4. human-review
5. code-review
6. merge-readiness
7. software-testing
8. security-review
9. regression-risk
10. scope-drift
11. maintainability
12. dependency-review
13. migration-safety
14. rollback
15. software-quality

## Dates

Published: 2026-07-20
Updated: 2026-07-20