Follow the sequence

Steps

1
Read the actual diff, dependencies, configuration, migrations, and call paths; map each change to an acceptance criterion.
2
Inspect authorization, input handling, secrets, data boundaries, dependency risk, failure paths, logging, and backward compatibility.
3
Run the required format, type, build, unit, integration, and regression checks; capture commands, versions, results, and failures.
4
Exercise changed UI on target browsers and viewports, including keyboard flow, focus, labels, contrast, errors, loading, and empty states.
5
Record findings with file/line evidence, severity, owner, and retest result; stop merge for unresolved acceptance, security, data-loss, or accessibility blockers.
6
Have a human reviewer approve, request changes, or reject; use a staged rollout with monitoring and a tested rollback path when release is authorized.

Output contract

What you should get

Acceptance-to-diff review matrix
Findings with file/line evidence
Test and UI inspection log
Security and accessibility checks
Human decision plus rollout and rollback plan

Copy and adapt

Prompt

Run the Code Review Checklist Workflow for the goal below.

Goal: Review the actual code diff and prove a website or plugin change meets acceptance criteria before merge or release.

Inputs (replace each placeholder with verified information):
- Change request and acceptance criteria: {{add verified input}}
- Base/head diff and repository context: {{add verified input}}
- Affected data, dependencies, config, and migrations: {{add verified input}}
- Required test commands and environment: {{add verified input}}
- Security, privacy, browser, and accessibility risks: {{add verified input}}
- Rollout, monitoring, and rollback owner: {{add verified input}}

Method:
1. Read the actual diff, dependencies, configuration, migrations, and call paths; map each change to an acceptance criterion.
2. Inspect authorization, input handling, secrets, data boundaries, dependency risk, failure paths, logging, and backward compatibility.
3. Run the required format, type, build, unit, integration, and regression checks; capture commands, versions, results, and failures.
4. Exercise changed UI on target browsers and viewports, including keyboard flow, focus, labels, contrast, errors, loading, and empty states.
5. Record findings with file/line evidence, severity, owner, and retest result; stop merge for unresolved acceptance, security, data-loss, or accessibility blockers.
6. Have a human reviewer approve, request changes, or reject; use a staged rollout with monitoring and a tested rollback path when release is authorized.

Return exactly these reviewable outputs:
- Acceptance-to-diff review matrix
- Findings with file/line evidence
- Test and UI inspection log
- Security and accessibility checks
- Human decision plus rollout and rollback plan

Human review boundary: Do not approve from a summary alone. Inspect the real diff, run the real tests, protect credentials and user data, and keep merge and release approval with an accountable human.

Human review boundaryDo not approve from a summary alone. Inspect the real diff, run the real tests, protect credentials and user data, and keep merge and release approval with an accountable human.